Velocidad negativa: cómo elevar el límite de complejidad
Uno de los objetivos más comunes de una organización de ingeniería: ofrecer software de alta calidad rápidamente.
Echa un vistazo a la declaración de principios de tu director de sistemas informáticos o tecnología y escúchalos hablar. Lo más probable es que quieran alcanzar alguna permutación de este objetivo. Si bien es un objetivo habitual, hay un amplio espectro entre los equipos que alcanzan este nirvana y los equipos atrapados en el purgatorio de la entrega de software. Algunos equipos lanzan constantemente código nuevo a producción con poco impacto negativo en los clientes o pocos incidentes, mientras que otros tienen problemas con las publicaciones trimestrales.
¿Qué causa esta discrepancia en el rendimiento?
La complejidad en la entrega de software es la diferencia entre ofrecer software de alta calidad, rápido y... no hacerlo. Es la diferencia entre hacer sonar la campana de la victoria tras una publicación exitosa cada semana y un equipo de entrega de software desvinculado, frustrado porque meses de trabajo en la última publicación se han traducido en seis errores nuevos y una reversión.
Compara la calidad y la velocidad a la que las empresas emergentes lanzan nuevos productos y funciones con las de una organización grande y consolidada. Por ejemplo, en el sector financiero, las empresas emergentes de tecnología financiera han reducido la cuota de mercado de los grandes bancos consolidados durante la última década. Los grandes bancos suelen mencionar las injustas ventajas de las empresas emergentes de tecnología financiera, que operan con menos supervisión normativa y sin sistemas de aplicaciones monolíticos y tradicionales que mantener. Un equipo más pequeño permite una mayor agilidad y la capacidad de cambiar en función de las necesidades del cliente. Básicamente, las empresas de tecnología financiera no cuentan con la complejidad de los bancos consolidados, lo que les permite moverse más rápido y con menos riesgo. Aunque puede ralentizar a los equipos de software, la complejidad no siempre es negativa.
The benefits of SOA
SOA's modularity and standardized protocols enable services to communicate effectively, promoting reusability, interoperability, and scalability. These key benefits translate into tangible advantages for companies:
- Reusability: Reusing existing services reduces development time and costs and promotes consistency and quality. Companies can accelerate development cycles and improve overall efficiency.
- Interoperability: Services can communicate and exchange data regardless of their underlying technology or programming language. This facilitates enterprise-wide data integration and collaboration. Interoperability streamlines business processes and helps companies adapt to evolving technologies.
-
Scalability: SOA's modular design enables independent scaling of services to meet fluctuating demands. It ensures applications can handle spikes in traffic or expanding user bases without compromising performance or stability. Companies can adapt their infrastructure to changing needs without costly rewrites or redesigns.
Material relacionado
Ten controlado todo el software
VER LA SOLUCIÓN
Gestiona tus componentes con Compass
La complejidad en la entrega de software
La complejidad puede ser algo bueno: es extremadamente gratificante resolver problemas complicados. Sirve de motivación para que los equipos estén a la altura del desafío, aborden problemas difíciles y den un vuelco al sector. Por el contrario, hay un punto en el que la complejidad ya no consiste en resolver un problema difícil y tiene un impacto negativo en los equipos de software.
La complejidad organizativa desempeña un papel clave en la reducción de la eficacia de los equipos de software. El diccionario Collins define la complejidad como "estado en el que muchas partes diferentes están conectadas o relacionadas entre sí de forma complicada". En términos prácticos, la complejidad organizativa es la suma de la información, las dependencias, los cambios, los demás equipos, las herramientas y las solicitudes que los equipos de software deben tener en cuenta cuando interactúan con el resto de la organización.
Los niveles más altos de complejidad organizativa naturalmente hacen que sea más difícil ofrecer software de alta calidad a gran velocidad, ya que los equipos dedican más tiempo a adaptarse a la organización que a resolver problemas complicados. Las organizaciones en crecimiento pronto descubren que los equipos de software alcanzan un límite de complejidad, es decir, la cantidad de complejidad que pueden gestionar antes de que afecte a la satisfacción laboral, y a la calidad y velocidad del software producido. Puede parecer lógico, entonces, que reducir la complejidad organizativa permita a los equipos centrarse en resolver problemas complicados y entregar el software más rápido y con mayor calidad. Veamos por qué no siempre es así.
Benefits of microservices
Dados los beneficios, más partes de la organización comenzaron a adoptar una arquitectura de microservicios, lo que hizo que la complejidad organizativa empezara a aumentar. Los equipos con más autonomía requerían más colaboración, y más microservicios significaban más dependencias. El ritmo del cambio se disparó: eran señales de una expansión descontrolada del software. El aumento de la complejidad provocó que la eficacia de los equipos de software se estabilizara, como lo demuestra una caída en la velocidad de cambio, y la carga cognitiva pasó a ser un problema para los equipos de software.
Cómo saber si te estás acercando al límite de complejidad
Alcanzar el límite de complejidad puede parecer inevitable, pero hay algunos indicadores de que los equipos se están acercando a su límite. Antes que nada, debo decir que no existe una métrica absoluta que te indique cuán cerca estás del límite de complejidad, pero los siguientes indicadores pueden ayudarte a identificar en qué punto te encuentras.
El indicador más claro de que un equipo ha alcanzado el límite de complejidad es cuando dedica más tiempo a analizar la complejidad organizativa que a resolver los complicados problemas en los que debe centrarse. Las tendencias en las métricas de DORA sobre los plazos de los cambios (velocidad) y de la tasa de errores de cambios (calidad) muestran si los equipos pierden o ganan velocidad a lo largo del tiempo. Aunque hay otros factores que influyen en estas métricas, son un buen indicador de la eficacia de los equipos.
La satisfacción de los desarrolladores es otro indicador de la complejidad organizativa a la que se enfrentan los equipos de software. Más que ningún otro perfil de puesto, a los desarrolladores les encanta dedicar su tiempo a resolver problemas complicados y, al mismo tiempo, detestan las tareas innecesarias que se interponen en el camino. La baja satisfacción de los desarrolladores es un buen indicio de que la complejidad organizativa es un problema para tu equipo de software.
| Feature | SOA | Microservices |
| Architectural style |
|
|
| Service granularity |
|
|
| Independence |
|
|
| Communication |
|
|
| Data storage |
|
|
| Scalability |
|
|
| Deployment |
|
|
| Coupling |
|
|
Cómo saber si te estás acercando al límite de complejidad
Alcanzar el límite de complejidad puede parecer inevitable, pero hay algunos indicadores de que los equipos se están acercando a su límite. Antes que nada, debo decir que no existe una métrica absoluta que te indique cuán cerca estás del límite de complejidad, pero los siguientes indicadores pueden ayudarte a identificar en qué punto te encuentras.
El indicador más claro de que un equipo ha alcanzado el límite de complejidad es cuando dedica más tiempo a analizar la complejidad organizativa que a resolver los complicados problemas en los que debe centrarse. Las tendencias en las métricas de DORA sobre los plazos de los cambios (velocidad) y de la tasa de errores de cambios (calidad) muestran si los equipos pierden o ganan velocidad a lo largo del tiempo. Aunque hay otros factores que influyen en estas métricas, son un buen indicador de la eficacia de los equipos.
La satisfacción de los desarrolladores es otro indicador de la complejidad organizativa a la que se enfrentan los equipos de software. Más que ningún otro perfil de puesto, a los desarrolladores les encanta dedicar su tiempo a resolver problemas complicados y, al mismo tiempo, detestan las tareas innecesarias que se interponen en el camino. La baja satisfacción de los desarrolladores es un buen indicio de que la complejidad organizativa es un problema para tu equipo de software.
La simplificación es una estrategia perdedora
Cuando las empresas se dan cuenta de que sus equipos se ahogan en la complejidad, suelen poner en marcha un "proyecto de simplificación" con el objetivo de restablecer la simplicidad en su organización. La simplificación es una estrategia perdedora por dos razones: la complejidad aumenta más rápido de lo que cualquier organización puede simplificar su entorno, y estos "proyectos de simplificación" funcionan en el mismo entorno complejo que pretenden simplificar.
Un punto de partida habitual para la simplificación es reducir el número de aplicaciones mediante el desmantelamiento o la consolidación siempre que sea posible. El desmantelamiento de una aplicación requiere que el equipo conozca todas las dependencias ascendentes y descendentes, sepa quién usa la aplicación, cómo reemplazar la funcionalidad, dónde y cómo se archivarán o migrarán los datos, y haga frente a muchas otras complicaciones que surgen con este tipo de trabajo. Lamentablemente, la importante inversión de esfuerzo necesaria para hacerlo no se ve recompensada con una reducción igualmente significativa de la complejidad. Hay un límite en la cantidad de aplicaciones que una empresa puede retirar sin afectar a la principal experiencia empresarial o de usuario, pero no hay límite en cuanto al número de nuevos componentes de software que los ingenieros pueden crear. En los 12 meses que se tarda en desmantelar una aplicación, es probable que se hayan creado cientos de microservicios nuevos. Dado que un entorno tecnológico saludable crece con el tiempo, no es práctico mantener en él un número fijo de aplicaciones o componentes de software para reducir la complejidad.
Los proyectos de simplificación suelen incluir la reelaboración de la estructura organizativa para eliminar la complejidad del flujo de comunicación. Las estructuras organizativas menos complicadas involucran a equipos grandes y jerárquicos con todo el personal ubicado en el mismo lugar. Las estructuras organizativas más complicadas involucran a equipos pequeños, distribuidos y autónomos. La ley de Conway demuestra que es probable que los equipos jerárquicos grandes produzcan aplicaciones monolíticas, mientras que los equipos pequeños y distribuidos probablemente produzcan aplicaciones mediante arquitecturas modulares, como los microservicios. Los patrones de arquitectura modular, como la arquitectura de microservicios, permiten producir software de alta calidad a gran velocidad, lo que significa que una estructura organizativa más compleja tiene más probabilidades de conducir al éxito. Si bien "simplificar" la estructura organizativa facilita su comprensión, es contraproducente para el objetivo final del proyecto de simplificación.
La simplificación es importante y vale la pena, pero es mejor incorporarla como mejora continua para los equipos de software (y los equipos de equipos) que como una actividad única. La simplificación puede retrasar el momento en el que se alcanza el límite de complejidad, pero no devolverá a la organización las aceleradas libertades de las que se disfrutaba en un entorno de empresa emergente.
Elevar el límite de complejidad
What are the challenges of adopting SOA and microservices?
Para volver a la eficacia de los equipos de software, las organizaciones deben elevar el límite de complejidad. Elevar el límite de complejidad significa aumentar la complejidad organizativa a la que puede enfrentarse cada equipo antes de que esto afecte a la satisfacción laboral, y a la calidad y la velocidad con las que el equipo lanza el software.
La ingeniería de plataformas es un concepto importante a la hora de elevar el límite de complejidad de una organización. Los equipos de ingeniería de plataformas sólidos se centran en reducir la carga cognitiva de los equipos de software al abstraer la complejidad organizativa de su trabajo diario. Cuando se implementa correctamente, la ingeniería de plataformas permite a los equipos reequilibrar la mayor parte del esfuerzo que dedican a resolver problemas complicados y dedicar menos tiempo a analizar la complejidad organizativa.
Can SOA and microservices coexist?
Atlassian creó Compass, una plataforma de experiencia para desarrolladores, por esta misma razón. Compass ayuda a elevar el límite de complejidad al facilitar a los equipos de software el análisis de la complejidad organizativa a través del catálogo de componentes, las métricas y los cuadros de mandos para que puedan centrarse en crear una cultura de ingeniería sólida. El principal argumento es que la complejidad organizativa no se redujo en Atlassian; de hecho, siguió creciendo a medida que más y más miembros de la organización pasaban a una arquitectura de microservicios. Redujimos el tiempo que los equipos de software dedicaban a enfrentarse a esa complejidad, que es la diferencia entre llevar a cabo un proyecto de simplificación y elevar el límite de complejidad.
Atlassian tiene más de 10 000 empleados y más de 17 000 componentes de software, pero nuestros equipos de software funcionan en gran medida con la libertad de una empresa emergente, lanzando software de alta calidad rápidamente. ¿Nuestra clave del éxito? Elevar el límite de complejidad para mejorar la eficacia de los equipos de software.
Aquí tienes dos acciones para empezar a elevar tu límite de complejidad:
- Realiza un seguimiento y evalúa tus métricas de DORA. ¿Cómo van las métricas de DORA para tu equipo? Si aún no las estás controlando, las métricas de DORA se proporcionan listas para usar con Compass.
- Conoce y evalúa la satisfacción de los desarrolladores. ¿Cómo se sienten los desarrolladores de tus equipos de software? La mayoría de las organizaciones realizan encuestas de satisfacción de los empleados. Pide los resultados, desglosados por área funcional, para hacerte una idea de la satisfacción de los desarrolladores. Las preguntas clave incluyen valorar las siguientes afirmaciones:
- Me enorgullece hacer lanzamientos
- La cantidad de estrés en mi trabajo es manejable
- Soy consciente de cómo mi trabajo contribuye a los objetivos de la empresa
Como alternativa, Compass recopila esta información durante el ritual CheckOps, en el que los equipos comparten lo que piensan de la última semana e indican lo que podría haber ido mejor.
Para elevar el límite de complejidad se requiere una combinación de herramientas, procesos y rituales. Una plataforma de experiencia para desarrolladores como Compass puede ayudarte a conocer el estado del sistema, asignar las dependencias y crear rituales continuos, lo que ayuda a superar el límite de complejidad y a aprovechar el potencial de los equipos de entrega de software de tu organización.
Prueba Compass gratis hoy mismo.
How does each architecture impact deployment and DevOps practices?
Both SOA and microservices deployments benefit from Open DevOps practices. However, the specifics will differ depending on the architecture.
SOA typically involves monolithic deployments, where teams deploy an entire application as a single unit. This approach requires careful coordination between teams. It can be time-consuming and complex, especially for large applications.
DevOps emphasizes collaboration and automation between development and operations teams to address these challenges. This enables more frequent and reliable deployments. By automating testing, configuration management, and infrastructure provisioning, DevOps can help streamline SOA deployments and minimize errors.
Microservices architecture enables more granular deployments. Teams deploy each microservice independently.
DevOps principles are also essential for microservices deployments. DevOps practices such as continuous integration and continuous delivery allow teams to automate the process of testing, deploying, and building microservices. This facilitates rapid and frequent releases.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
Comunidad de Compass
Tutorial: Crear un componente
