Formación escrita en DevOps

¿Cómo estructurar su organización DevOps y diseñar la arquitectura del software?

Según la ley de Conway, las organizaciones que diseñan sistemas están limitadas a crear sistemas que reproducen sus propias estructuras de comunicación. En otras palabras, su software no puede superar la eficiencia con que sus equipos se comunican e interactúan. Por tanto, la estructura de los equipos afectará a la arquitectura del software, al rendimiento de TI y, en última instancia, al del negocio.

La estructura de su organización determina el software que obtiene

La mayoría de las empresas, probablemente incluida la suya, divide la organización de entrega de software en varios equipos y termina creando software con ese mismo número de capas. Experimentos controlados demostraron que, al pedir a una organización de 6 equipos que creara un programa, los equipos propusieron una arquitectura de 6 capas. Cuando se pidió a otra organización con 3 equipos que creara el mismo programa, propuso una arquitectura de 3 capas. Hay muchos ejemplos similares.

Una conocida aseguradora con 86,000 empleados en todo el mundo tenía una organización de TI dividida en 2 equipos funcionales principales que entregaban el backend para gestionar clientes, contratos, facturas y servicios. Uno se centraba en el lenguaje Java y el otro en los procedimientos almacenados de PL/SQL. Además, dependían de servicios centralizados de operaciones de TI, administración de bases de datos, infraestructura, redes, seguridad y aseguramiento de la calidad para toda la organización, lo que dificultaba aún más una entrega segura.

Otro problema era que, pese a la separación de los equipos, la arquitectura no separaba bien la lógica de orquestación del negocio en Java de la lógica de acceso a datos en PL/SQL. Entregaron cientos de funcionalidades, cada una con código Java y PL/SQL enmarañado. Cada cambio o solicitud de una funcionalidad nueva exigía decenas de traspasos de un equipo a otro, que creaban largas colas y alargaban el plazo hasta de los cambios menores. Además, en ese entorno complejo, como era difícil prever el efecto incluso de cambios pequeños, estropeaban continuamente funcionalidades existentes en producción y provocaban interrupciones cuya resolución requería tiempo, rehacer trabajo, elevar problemas y lidiar con estrés.

Para cambiar esta forma de trabajar, los dos equipos funcionales se fusionaron en un solo equipo de producto. Rediseñaron gradualmente el software convirtiendo la capa de acceso a datos en un conjunto de funciones de API. También construyeron un nuevo sistema de negocio totalmente desacoplado del funcionamiento interno de la API de acceso a datos. Desde las primeras etapas mejoró la moral porque los especialistas en Java y PL/SQL empezaron a trabajar por el éxito de un producto común en vez de defender los intereses de sus antiguos silos. Al crear una arquitectura débilmente acoplada, el impacto de los cambios se volvió más fácil de identificar, los cambios se hicieron más sencillos y rápidos de implementar y los defectos, más fáciles de localizar y corregir. Como resultado, el tiempo medio de entrega de funcionalidades nuevas pasó de 4 meses a 3 semanas. La cola de incidencias ahora está casi vacía y el equipo aprovecha la capacidad disponible para revisar, refactorizar y mejorar aún más el código base.

Organizaciones matriciales, equipos funcionales y la ilusión de optimizar costes

Las empresas se organizan en equipos funcionales de especialidades como bases de datos, redes, operaciones, seguridad de la información, aseguramiento de la calidad, gestión de versiones, gestión de proyectos y gestión de productos. Los equipos de proyecto se forman con personas de distintos silos funcionales. En estas organizaciones matriciales de proyectos que intentan entregar productos y servicios, los responsables de proyectos suelen encargarse de que se entregue algo y los responsables de producto, de que se entregue lo adecuado.

El problema de esta estructura es que los equipos funcionales apenas conocen el alcance del trabajo al que contribuyen. En casos extremos, aunque frecuentes, no les interesa la visión general ni el rendimiento de TI y del negocio del producto y servicio al que contribuyen. Su prioridad es quedar a cubierto cuando el proyecto se tuerce y empiezan los reproches.

Como los equipos funcionales suelen tener largas colas de solicitudes, tardan en poder ayudar a su proyecto. Dado que los proyectos compiten por los mismos recursos funcionales, la única forma de conseguir atención rápida es elevar el problema. Las escaladas repetidas perjudican el ambiente de trabajo y la confianza entre equipos.

Los traspasos repetidos, los retrasos, los problemas de calidad, el trabajo repetido, los cuellos de botella y el estrés pasan a formar parte del día a día. Las organizaciones matriciales no pueden dar mejores resultados mientras persigan una supuesta optimización de costes, opaca y engañosa. Por los problemas de calidad, el trabajo repetido y los retrasos, una organización funcional probablemente cuesta más que cualquier otra reorganización que se le ocurra. Además, si su organización ya ha externalizado a lugares distantes funciones vitales como el aseguramiento de la calidad y las operaciones de TI, es probable que a TI le cueste mantener entregas seguras y satisfacer las necesidades críticas para la continuidad del negocio.

¿Cómo resuelve DevOps este problema? Con equipos orientados a productos y servicios

Para resolverlo, DevOps propone dejar atrás la supuesta optimización de costes de los equipos funcionales y centrarse en una mejora de la velocidad que ya ha demostrado su eficacia. Si lo aplica bien, DevOps le permitirá ahorrar costes mientras su equipo y usted entregan con rapidez y de forma continua.

DevOps propone formar equipos orientados a productos y servicios. Son equipos independientes, multifuncionales, autónomos, autosuficientes y generalmente pequeños que cubren todas las fases del ciclo de vida de ingeniería de un producto o servicio de software, en vez de las de un proyecto temporal. Abarcan la arquitectura, el diseño, la programación, las pruebas, la experimentación, el despliegue, las operaciones y el mantenimiento. Sí, ha leído bien. ¿Quién puede operar y mantener el software mejor que quienes lo crearon? Nadie. Por eso, los equipos de DevOps más exitosos de Amazon y Netflix siguen a cargo de sus productos y servicios tras publicarlos. También se ocupan de operar y mantener el software en sus propios sistemas de producción.

Su organización pasa de financiar proyectos temporales a financiar productos y servicios

Para mejorar el rendimiento del negocio, su organización deja de financiar proyectos temporales cuyos resultados concretos son difíciles de evaluar a largo plazo. Con DevOps, financia su misión, su propósito y los productos y servicios que los respaldan. El éxito de los equipos se evalúa por el rendimiento de TI y del negocio y por el retorno de la inversión en las áreas en las que ofrecen productos, servicios y microservicios a clientes internos, externos o ambos. Los equipos se responsabilizan de los productos y servicios que crean y ofrecen, en lugar de limitarse a pertenecer a silos funcionales que apenas prestan atención a los resultados del negocio.

¿Cómo formar sus equipos de DevOps y diseñar su arquitectura de software?

DevOps no propone desmantelar y reorganizar de golpe todos los proyectos en curso. Una forma de adaptar los equipos a DevOps con poco impacto en su funcionamiento es incorporar especialistas funcionales a los equipos de proyecto. Cuando cuenten con especialistas en las áreas que necesitan, como aseguramiento de la calidad, seguridad de la información, bases de datos, redes, servidores y operaciones, podrá esperar que diseñen, desplieguen y mantengan por sí solos sus productos y servicios de software.

En estos nuevos equipos de DevOps orientados a productos y servicios, la disponibilidad, la calidad, el rendimiento, la seguridad de la información y el cumplimiento normativo son parte del trabajo diario de todos. ¿Cómo van a crear aplicaciones seguras, de alta disponibilidad y calidad, capaces de soportar la carga y la presión que exigen los clientes si no atienden a esos requisitos no funcionales hasta terminar el diseño y el desarrollo? ¿Cómo van a evaluar y validar bien la seguridad y la calidad los especialistas externos si no han participado en ninguna etapa de ingeniería? Por eso, los equipos de DevOps de alto rendimiento recurren a especialistas externos solo para asesorarse y conservan toda la responsabilidad sobre los requisitos no funcionales durante todo el ciclo de vida.

Otra opción que puede considerar

Google es una organización DevOps de gran éxito que sigue usando ampliamente equipos funcionales junto a equipos de DevOps orientados a productos y servicios. En Google, ambos consideran la misión de la organización, sus productos y sus servicios un objetivo compartido. Los equipos funcionales crean modelos reutilizables, como plantillas, listas de comprobación y estructuras básicas de aplicaciones, y sistemas de autoservicio, por ejemplo, para aprovisionar y configurar servidores y redes sin ayuda. Así evitan convertirse en cuellos de botella para los equipos de productos y servicios. Colaboran con ellos y los apoyan desde las primeras etapas del ciclo de vida, hacen revisiones constructivas entre pares de diseños, código y pruebas y los asesoran de forma continua.

¿Cuántas personas debería tener un equipo de DevOps?

El tamaño ideal es de 5 a 10 personas. Un equipo de ese tamaño simplifica la comunicación y la coordinación. Además, sus integrantes y quien lo dirige no pierden tanto tiempo con tareas secundarias y administrativas. También se limita el tamaño de los productos y servicios que gestiona el equipo, lo que reduce la complejidad y la dificultad de mantener y operar el software. En equipos pequeños, cada integrante ve el conjunto y gana algo de experiencia en liderazgo al participar en una misión crucial para la organización. Quien dirige el equipo trabaja con la alta dirección para entender sus objetivos y transmitirlos al equipo.

¿Qué pasa si un equipo de hasta 10 personas ya no puede gestionar su producto y servicio?

Separe un nuevo producto y servicio y forme otro equipo de DevOps para que se haga cargo. Los productos y servicios no tienen por qué dirigirse solo a clientes externos que paguen por ellos. También puede crear productos, servicios o API de microservicios internos con sus respectivos equipos para clientes internos. Por ejemplo, si su sistema de facturación supera la capacidad de un equipo de hasta 10 personas, forme otro para asumir la API de acceso a la base de datos. Quizá otro pueda encargarse de la API de pagos en línea y otro de los procesos por lotes. Todos deberían usar un repositorio de código común y una canalización de despliegue compartida para garantizar la integración continua, la entrega rápida y el éxito de la organización.

En una arquitectura fuertemente acoplada, cambios pequeños en una aplicación pueden acabar causando muchos efectos adversos en numerosos flujos de trabajo. Por ello, los productos, servicios y API de microservicios deben tener un acoplamiento débil. Cada equipo de DevOps debe ocuparse de una sola parte de la arquitectura y poder diseñar, desarrollar y desplegar su software de forma independiente. Un mecanismo de alerta temprana incorporado en la canalización debe avisar de forma automática y rápida a los equipos de los posibles efectos adversos de cada cambio registrado.

¿Cómo pueden equipos pequeños de hasta 10 personas encargarse por sí solos de todas las fases de la ingeniería de software, desde la arquitectura hasta las operaciones?

Para conseguirlo, anime a todos los integrantes a convertirse en generalistas y facilite que adquieran nuevas habilidades continuamente.

Contrate solo a personas con ganas de aprender y crecer, sea cual sea su nivel actual de conocimientos y experiencia. Evite a quienes esperan que se les evalúe según un conjunto fijo de funciones y responsabilidades. Ya sabe que ni su organización ni sus productos y servicios se mantienen estáticos.

La demanda cambiará mañana, si no cambia hoy.

CONCLUSIÓN

En este capítulo hemos explicado los resultados deficientes de las organizaciones matriciales, los silos funcionales asociados y cómo responde DevOps a ese problema.

DevOps propone formar equipos pequeños, de hasta 10 personas, orientados a productos, servicios o API de microservicios.

Estos equipos deben estar compuestos por ingenieros de software generalistas que trabajen en toda la pila tecnológica y puedan encargarse por sí solos de todo el ciclo de vida, desde el diseño hasta el mantenimiento.

DevOps se basa en una arquitectura orientada a servicios (SOA) débilmente acoplada, en la que cada equipo de DevOps asume y opera una parte de la arquitectura.