El rol de DevOps y su conexión con la arquitectura empresarial

Lo ágil no es el problema

Muchos creen que la entrega ágil e incluso la disgregación en componentes han hecho a los equipos de desarrollo demasiado miopes. La conveniencia a menudo fomenta arreglos rápidos que se ajustan a los objetivos de negocio a corto plazo, pero fracasan en el largo plazo, incluso cuando las tendencias a largo plazo están disponibles. El DAD, que agrega disciplina específicamente a la entrega ágil, se supone que fomenta una visión a largo plazo de la relación de los requerimientos de programación con los objetivos del negocio. Esto es lo que crea el vínculo explícito entre DAD y arquitectura empresarial.

El reto para muchas empresas es que ya tienen entrega ágil, no tienen DAD incorporado y no tienen un mecanismo para hacer frente a los proyectos ya desplegados bajo el sistema más antiguo e indisciplinado. DevOps puede ayudar a adaptar los principios del DAD a los proyectos utilizando DevOps para vincularlos de nuevo a arquitectura empresarial. La clave para crear este enlace es expandir la conexión normal entre DevOps y las aplicaciones, habitualmente incorporadas en los procesos ALM, para conectarse con los procesos de negocio a través del enlace del modelo de arquitectura empresarial. El papel de DevOps como enlace EA-a-DAD es crítico.

La conexión del ciclo de vida del proceso de negocios

La EA es responsable de definir procesos de negocio y vincular esos procesos a las aplicaciones. Las prácticas ágiles de entrega se han centrado en acelerar la parte de aplicación de ese enlace, sin prestar mucha atención al lado del proceso de negocios. DAD propone imponer disciplina de negocios en el ciclo de vida de la aplicación, lo cual lo vincula más estrechamente a los procesos de negocio de EA. Esto se ha entendido en teoría, pero a menudo ha sido difícil de poner en práctica.

Las herramientas de DevOps requieren que operaciones comprenda dos cosas: qué componentes específicos se deben implementar para una aplicación determinada, y qué componentes se implementan de forma autónoma como servicios para múltiples aplicaciones. Las aplicaciones se pueden vincular a procesos de negocios, por lo que DevOps soporta los procesos de negocios y a EA a través de estos vínculos. Los componentes compartidos representan el soporte de TI para los procesos de negocios compartidos. Un papel clave de DevOps es proporcionar estos vínculos críticos, y si DevOps está debidamente vinculado a EA, entonces puede soportar la transformación de las prácticas de negocios de EA en aplicaciones.

Cómo deben estructurarse los modelos DevOps

Cada modelo de DevOps debe estar vinculado a cualquier aplicación que soporte, y las empresas deben identificar los procesos de negocio de EA que dichas aplicaciones soportan a su vez. Esto permite a los arquitectos empresariales mapear una zona de impacto de negocios para cada proceso DevOps, y este mapeo debe ser una parte fundamental de la documentación de DevOps como serían las aplicaciones objetivo o los componentes afectados. De esta manera, el impacto de los cambios de DevOps en los procesos de negocio –incluso si el impacto es simplemente un riesgo de interrupción durante el cambio– puede ser evaluado. Este requisito también asegurará que los equipos de desarrollo entiendan el ciclo de vida del proceso de negocio, o incluso los ciclos de vida, que sus ciclos de vida de aplicación pueden impactar.

Si bien la disciplina para exigir que los vínculos EA-a-aplicación estén documentados en DevOps es importante, puede no ser suficiente si los modelos DevOps no se desarrollan correctamente. El requisito crítico es asegurar que los modelos sean jerárquicos, donde el despliegue de la aplicación se define como una serie de despliegues de componentes referenciados, en lugar de alguna estructura monolítica extensa. La jerarquía en DevOps fomenta la reutilización de componentes e incluso ayuda a identificar componentes que deben considerarse como servicios de multiaplicación al destacar requisitos comparables de implementación y conexión.

Evitar cambios no sincronizados

Es importante que la EA y el desarrollo de aplicaciones se sincronicen durante el desarrollo, pero los cambios de aplicaciones y de negocio son una oportunidad tanto para que el ciclo de vida del proceso de negocio, como el ciclo de vida de la aplicación se desconecten. Dado que EA y el desarrollo responden a sus propias prioridades, los cambios pueden hacerse en un área sin reflejarlos completamente en la otra. Durante los procesos de desarrollo y despliegue de ALM, la vinculación de DevOps con EA debe utilizarse para probar cualquier ciclo de proceso de negocio afectado por los cambios de la aplicación. Dado que las empresas deben tratar siempre un cambio de DevOps como un cambio de aplicación para fines de ALM, esto enlazará los dos ciclos de vida de manera eficaz.

ALM en sí puede beneficiarse de una cadena de retroalimentación con EA generada por DevOps y un registro de vinculación de aplicaciones a los procesos de negocio. Es fácil para ALM convertirse en una especie de lago técnico, donde los desarrolladores y operaciones revisan los impactos y los cambios de pruebas sin reconocer completamente los impactos del proceso de negocio que EA reclamaría. Un enlace generado por DevOps para EA permitirá a aquellos que diseñan los procesos ALM relacionarlos con los procesos de negocio, e incluso identificar y notificar a las organizaciones de línea que probablemente se verán afectadas en cada procedimiento ALM. Eso prueba completamente cada cambio de aplicación de la mejor manera: con las personas que la utilizan.

Problemas de deuda técnica

La gestión de la deuda técnica es el punto final, y tal vez el más complejo, en el soporte de DevOps de EA. El término se utiliza para describir una carga creciente de estrategias de TI subóptimas que surgen porque los equipos de desarrollo no ven lo suficientemente hacia delante para reconocer lo óptimo de una determinada estrategia de TI. Existe un interés mayor en dar a EA un rol de defensa para la idoneidad a largo plazo de un diseño o función de un componente técnico dado.

Esto es lógico, dado que las arquitecturas empresariales son custodios de los requerimientos de negocios a largo plazo, pero significa cambiar algunos requerimientos tecnológicos en misiones de EA, una separación de la división aguda entre la arquitectura empresarial y los arquitectos de aplicaciones. Otra función de DevOps debería ser ayudar a facilitar el cambio de rol y minimizar la fricción entre los dos grupos.

Conclusión: La entrega continua necesita DevOps

Muchos arquitectos empresariales y arquitectos de aplicaciones creen que la combinación de computación de nube, TI en las sombras y entrega continua borrará, en última instancia, el límite entre la aquitectura empresarial y los arquitectos de aplicaciones. Incluso en el corto plazo, seguramente generará más cooperación entre fronteras y el papel que DevOps debe ser para formar la base para esa cooperación.