Lo que dice su distribución sobre su estructura organizativa

Una de las “leyes” asociadas con DevOps pertenece a un programador llamado Melvin Conway. Su ley fue introducida en 1967 y simplemente establece que "las organizaciones que diseñan sistemas... están obligadas a producir diseños que sean copias de las estructuras de comunicación de estas organizaciones".

He enfatizado la palabra "sistemas" porque muy a menudo la Ley de Conway se aplica sólo a las aplicaciones. A los sistemas de software. Pero la realidad es que los "sistemas" abarcan todo, desde las aplicaciones hasta los canales integrados que las entregan e implementan. Sus tuberías.

Cuando hablamos de adoptar metodologías DevOps en el lado de implementación (es decir, producción), también debemos tener en cuenta los principios asociados, como la Ley de Conway. Porque esa ley se aplica al diseño de los procesos de implementación, tal como se aplica a las aplicaciones que lanza al mercado.

Quizás recuerdes dos preguntas de nuestro Informe sobre el estado de los servicios de aplicação de 2019. La primera pregunta fue sobre la estructura organizacional de TI: operaciones combinadas, equipos de una sola función o multifuncionales. Descubrimos que casi la mitad (46%) de los más de 2000 encuestados estaban organizados como equipos de función única. Las operaciones combinadas ocuparon un respetable segundo lugar con un 37%. Los equipos multifuncionales son menos comunes: solo el 15% de los encuestados operan en dichas estructuras.

Esto es importante a medida que pasamos a examinar el estado de la automatización del proceso de implementación. Porque los resultados son definitivamente un reflejo del predominio de los equipos monofuncionales.

Los datos aquí muestran un esfuerzo de automatización inconsistente que no ayudará a alcanzar el objetivo de casi la mitad (48%) de los encuestados con respecto a la transformación digital : implementar aplicaciones más rápido y con mayor frecuencia. La disparidad entre estos dominios establecidos dentro de TI es una prueba existencial de que la Ley de Conway se aplica a cualquier sistema, en cualquier lugar.

Investigando más a fondo, descubrimos que poco más de uno de cada diez (11 %) ha automatizado solo uno de estos dominios. Uno de cada cuatro (25%) ha logrado automatizar dos o tres dominios. Y poco más de uno de cada cinco (21%) ha automatizado los cuatro dominios principales necesarios para completar un proceso de implementación automatizada .

Un porcentaje significativo -42%- ha automatizado EXACTAMENTE CERO de estos dominios.

La inequidad de la automatización en todo el proceso de implementación es una parte importante del rompecabezas del tiempo para generar valor porque cada vez que se encuentra con un proceso manual en el proceso se produce una demora. Ese retraso ralentiza el tiempo para obtener valor (o el tiempo de comercialización, si lo prefiere). Las diferencias en las tasas muestran el impacto de que las organizaciones permanezcan en una "estructura de equipo de función única", porque estamos viendo "silos" individuales automatizados con poca o ninguna preocupación por cómo interactúan con el resto del flujo de trabajo.

Es por esto que se prefieren las operaciones combinadas o estructuras de equipos multifuncionales. Porque los canales de comunicación entre dominios de TI se convierten en un proceso de pares que facilita mejor el diseño de un sistema que abarque múltiples preocupaciones. Cuando un equipo diseña un ducto (sistema), es posible tener en cuenta el ducto como un todo en lugar de como partes compuestas.

El trabajo de automatización en sí podría (y probablemente debería) ser manejado por expertos en el dominio. Pero el diseño general y los métodos de integración (API) deben diseñarse en un equipo abierto y colaborativo; de lo contrario, terminamos con silos de automatización que pueden o no servir al objetivo comercial de llegar al mercado más rápido y con mayor frecuencia.

Entonces, si encuentra demoras o desvíos en sus intentos de automatizar los procesos de producción, dé un paso atrás y considere las estructuras organizacionales existentes y cómo impactan en el diseño de ese proceso. Es posible que descubra que antes de poder automatizar eficazmente cualquier cosa, necesita impulsar estructuras organizativas más efectivas para respaldar el esfuerzo.