Una de las «leyes» asociadas con DevOps se atribuye a un programador llamado Melvin Conway. Su ley se formuló en 1967 y afirma sencillamente que «las organizaciones que diseñan sistemas... están condicionadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones».
He destacado la palabra «sistemas» porque, con demasiada frecuencia, la ley de Conway se aplica únicamente a las aplicaciones, es decir, a los sistemas de software. Pero lo cierto es que los «sistemas» abarcan desde las aplicaciones hasta los pipelines integrados que permiten entregarlas y desplegarlas. Sus pipelines.
Cuando hablamos de adoptar metodologías DevOps en el ámbito del despliegue (es decir, en producción), también debemos tener presentes principios relacionados, como la ley de Conway. Porque esta ley se aplica tanto al diseño de los pipelines de despliegue como a las aplicaciones que estos lanzan al mercado.
Quizá recuerde dos preguntas de nuestro informe «Estado de los servicios de aplicaciones de 2019». La primera preguntaba por la estructura organizativa de TI: operaciones combinadas, equipos de una sola función o equipos multifuncionales. Descubrimos que casi la mitad (46 %) de los más de 2000 encuestados se organizaban en equipos de una sola función. Las operaciones combinadas ocupaban un meritorio segundo puesto, con un 37 %. Los equipos multifuncionales son menos habituales, ya que solo el 15 % de los encuestados trabajaba en estructuras de este tipo.
Esto es importante al pasar a analizar el estado de la automatización de los procesos de despliegue, ya que los resultados reflejan claramente el predominio de los equipos especializados en una única función.
Los datos muestran un esfuerzo de automatización desigual que no ayudará a alcanzar el objetivo de casi la mitad (48 %) de los encuestados en materia de transformación digital: desplegar aplicaciones con mayor rapidez y frecuencia. La disparidad entre estos ámbitos consolidados de TI constituye una prueba fehaciente de que la ley de Conway se aplica a cualquier sistema, en cualquier lugar.
Al profundizar, observamos que poco más de uno de cada diez encuestados (11 %) ha automatizado solo uno de estos ámbitos. Uno de cada cuatro (25 %) ha conseguido automatizar dos o tres ámbitos. Y poco más de uno de cada cinco (21 %) ha automatizado los cuatro ámbitos principales necesarios para disponer de un proceso de despliegue totalmente automatizado.
Un porcentaje significativo —el 42 %— no ha automatizado NINGUNO de estos ámbitos.
La desigualdad en la automatización a lo largo del proceso de despliegue es una pieza importante del rompecabezas del tiempo de obtención de valor, ya que cada vez que se encuentra un proceso manual en dicho proceso se produce un retraso. Ese retraso aumenta el tiempo de obtención de valor (o el tiempo de comercialización, si se prefiere). Las diferencias entre los porcentajes ponen de manifiesto el impacto de que las organizaciones mantengan una «estructura de equipos con una única función», pues observamos que se automatizan «silos» individuales sin apenas tener en cuenta cómo interactúan con el resto del proceso.
Por eso se prefieren las estructuras de operaciones combinadas o de equipos multifuncionales, ya que los canales de comunicación entre los distintos ámbitos de TI se convierten en un proceso entre iguales que facilita el diseño de un sistema que abarca múltiples aspectos. Cuando un equipo diseña un canal de despliegue (sistema), puede tenerlo en cuenta en su conjunto, en lugar de considerarlo como una serie de componentes independientes.
El trabajo de automatización en sí podría (y probablemente debería) estar a cargo de expertos en cada área. Sin embargo, el diseño general y los métodos de integración (API) deben definirse en el seno de un equipo abierto y colaborativo. De lo contrario, acabaremos creando silos de automatización que podrían contribuir o no al objetivo empresarial de lanzar productos al mercado con mayor rapidez y frecuencia.
Por tanto, si sus intentos de automatizar los pipelines de producción están sufriendo retrasos o desviaciones, dé un paso atrás y analice las estructuras organizativas existentes y cómo afectan al diseño de ese pipeline. Puede que descubra que, antes de poder automatizar algo de forma eficaz, necesita promover estructuras organizativas más eficientes que respalden ese esfuerzo.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.