¿Estará lista su propiedad de bases de datos si la velocidad de desarrollo aumenta en una orden de magnitud?

Las herramientas asistidas por inteligencia artificial han aumentado la velocidad y reducido el costo de producir código. Sin embargo, los líderes empresariales cuestionan por qué esta eficiencia no se traduce en innovación superior y un tiempo de comercialización más rápido. En lugar de acelerar todo el ciclo de entrega, este aumento de velocidad ha expuesto simplemente la fragilidad de los procesos de cambio de base de datos existentes.

Durante la última década, la respuesta a “¿cómo podemos movernos más rápido?” ha sido construir mejores pipelines, invertir en CI/CD y desplazarse hacia la izquierda en las pruebas. Estas inversiones han dado sus frutos: el código de la aplicación se mueve a un ritmo notable en organizaciones de ingeniería maduras. Sin embargo, estos beneficios no se han sentido de manera uniforme en toda la pila de tecnología. La base de datos a menudo se ha tratado como un caso especial; un activo protegido que requiere un estándar de atención diferente, procesos más lentos y supervisión manual. Había buenas razones para que se desarrollara este patrón, ya que las bases de datos contienen los datos que ejecuta el negocio y los errores pueden ser catastróficos. Si bien la precaución una vez parecía razonable, el costo de esa precaución ha cambiado. Al aumentar la presión sobre los administradores de bases de datos y los equipos de operaciones para realizar cambios en la base de datos al mismo ritmo que los desarrolladores pueden escribir código ahora, la disparidad en la pila se ha convertido en una responsabilidad. Estos equipos no pueden seguir el ritmo, y los cambios en la base de datos ahora están matando la ventaja de velocidad proporcionada por la herramienta asistida por inteligencia artificial. Resolver una restricción: el tiempo necesario para escribir código, ha resaltado simplemente la siguiente restricción en el proceso. Esto es pensamiento de sistemas llevado a la vida, y la fricción resultante se está volviendo cada vez más dolorosa para la empresa.

La velocidad y el control no son opuestos. Pero la forma en que la mayoría de las organizaciones gobiernan el cambio de base de datos los trata como si lo fueran.

El modelo tradicional de gobernanza de base de datos se diseñó para un mundo de lanzamientos trimestrales. Solicitudes de cambio, comités de aprobación, ciclos de revisión manual, planes de reversión escritos con anticipación a las implementaciones que ocurrían cuatro veces al año. Nada de eso es inherentemente incorrecto. Fue un enfoque de gestión de riesgos que creció para adaptarse al tiempo disponible entre implementaciones. El problema es que la cadencia de implementación ha cambiado, y para la mayoría de las organizaciones, el enfoque de gobernanza no ha mantenido el ritmo. Los equipos están obligados a enviar continuamente, pero aún rutean los cambios de base de datos a través de procesos construidos para una era diferente. El resultado no es seguridad. El resultado es fricción, soluciones alternativas y una creciente clase de “pequeños” cambios de base de datos que evitan la gobernanza por completo porque el proceso formal es demasiado lento para ser práctico.

Ese es donde vive el verdadero riesgo.

Cuando la gobernanza es demasiado lenta para usarse, la gente deja de usarla. Los cambios de esquema se aplican directamente en producción. Los hotfix se envían sin control de versiones, y con la buena intención de enviarlos correctamente con el próximo lanzamiento formal, pero eso no sucede porque la gente está ocupada. Los pasos manuales que debían ser la red de seguridad se convierten en lo que la gente evita cuando está bajo presión. Y la presión, en la entrega de software, es el estado predeterminado.

La respuesta no es frenar la tubería. Es mover la gobernanza dentro de ella.

Las organizaciones que han resuelto este problema no lo han hecho relajando sus estándares. Han hecho el trabajo más difícil de hacer que la gobernanza sea lo suficientemente rápida como para ser el camino de menor resistencia. Cambios de esquema controlados por versiones, detección de deriva automatizada, comprobaciones de políticas deterministas incrustadas en la tubería CI/CD en lugar de aplicarse como una puerta al final. Mientras que las herramientas impulsadas por inteligencia artificial son probabilísticas, ofreciendo sugerencias basadas en patrones, la gobernanza debe permanecer determinista para ser efectiva. Al utilizar comprobaciones predecibles y repetibles, se garantiza que cada cambio sea auditable y cumpla con los estándares de seguridad antes de que llegue a producción. La aprobación todavía ocurre. La traza de auditoría todavía existe. Pero sucede en el mismo flujo que todo lo demás, en lugar de como un proceso separado y más lento que se encuentra fuera de él.

Esto importa por una razón más allá de la productividad del desarrollador. Los requisitos de cumplimiento no se están volviendo más ligeros. La combinación de GDPR, DORA (Ley de Resiliencia Operativa Digital de la UE) y un conjunto creciente de regulaciones específicas del sector significa que la gobernanza de la base de datos es cada vez más una cuestión legal y regulatoria, no solo operativa. Las organizaciones que no pueden demostrar un historial rastreable y auditable de cambios en la base de datos están expuestas de maneras que se están volviendo materiales. El argumento para incrustar la gobernanza en la tubería no es solo que hace que la entrega sea más rápida. Es lo que hace que el cumplimiento sea rastreable a escala.

La inteligencia artificial está aumentando la urgencia.

La actual ola de desarrollo asistido por inteligencia artificial está haciendo que este problema sea más agudo, no menos. Cuando los desarrolladores pueden generar e iterar sobre el código de la aplicación una orden de magnitud más rápido que antes, la base de datos se convierte en un cuello de botella más obvio en relación con todo lo que la rodea. Pero hay un efecto de segundo orden que es menos discutido. Las herramientas de inteligencia artificial son muy buenas para generar lógica de aplicación. Son menos buenas para comprender las consecuencias a largo plazo de los cambios de esquema en una base de datos de producción compleja y en vivo. La combinación de una mayor velocidad de desarrollo de aplicaciones y sugerencias de esquema generadas por inteligencia artificial sin una gobernanza madura es exactamente el tipo de presión que produce incidentes. La velocidad sin guardrails estructurales crea las condiciones para que los errores ocurran más rápido.

Las organizaciones que van a navegar esto bien son aquellas que tratan la gobernanza de la base de datos como una preocupación de ingeniería de primera clase en lugar de un pensamiento de cumplimiento posterior. Eso significa que el control de versiones para el esquema de la base de datos es un valor predeterminado no negociable, y las pruebas automatizadas manejan comprobaciones rutinarias para que la supervisión manual pueda centrarse en cambios de alto riesgo y alto juicio en lugar de convertirse en un cuello de botella de última etapa. Finalmente, significa detección de deriva que identifica la divergencia antes de que cause un incidente.

La mayoría de las propiedades empresariales lo hacen más difícil de lo que debería ser.

Hay una realidad que se compone junto con la mayoría de estas observaciones. La mayoría de las propiedades de bases de datos empresariales no son de primera generación. Representan décadas de cambios de esquema acumulados, que se ejecutan en varias plataformas de sistema de gestión de bases de datos, algunas en las instalaciones y algunas en la nube, con diferentes grados de documentación y conocimiento tribal distribuidos en equipos que han girado muchas veces. La conversación de modernización a menudo supone un punto de partida limpio que la mayoría de las organizaciones no tienen. Ahí es donde el desafío es realmente más agudo y a menudo impide el progreso. Ya sea que el objetivo sea apoyar la innovación, limpiar y migrar datos para inteligencia artificial o mejorar la resiliencia operativa; se reduce a lo mismo. La pregunta no es cómo construir una práctica de DevOps de base de datos perfecta en un nuevo sistema. La pregunta es cómo introducir una gobernanza significativa en una propiedad de herencia compleja sin detener el negocio mientras lo hace.

La gobernanza incrustada en la tubería de manera incremental es la única respuesta práctica a esa pregunta. No necesitas reemplazar toda la propiedad antes de que puedas mejorar tus prácticas de gestión de cambios. Herramientas modernas como Redgate Flyway existen para aliviar la base de datos como el cuello de botella y comenzar con los cambios que se realizan hoy, en las tuberías que ya existen, y construir desde allí.

Las organizaciones que ganarán en crecimiento en los próximos cinco años no serán aquellas que tengan las propiedades más limpias. Serán aquellas que hayan descubierto cómo hacer que el cambio sea confiable, al ritmo que el negocio requiere, en la propiedad que realmente tienen.

Es el problema que vale la pena resolver. Y es resoluble.