Capítulo 1. La evolución de la arquitectura del software
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Construir sistemas que envejezcan con elegancia y eficacia es uno de los retos perdurables del desarrollo de software en general y de la arquitectura de software en particular. Este libro cubre dos aspectos fundamentales de cómo construir software evolucionable: la utilización de prácticas de ingeniería eficaces derivadas del movimiento del software ágil y la estructuración de la arquitectura para facilitar el cambio y la gobernanza.
Los lectores llegarán a comprender el estado del arte sobre cómo gestionar el cambio en la arquitectura de forma determinista, unificando los intentos anteriores de proporcionar protección a las características de la arquitectura y las técnicas procesables para mejorar la capacidad de cambiar la arquitectura sin romperla.
Los retos de la evolución del software
putrefacción de bits: también conocida como putrefacción del software, putrefacción del código, erosión del software, decadencia del software o entropía del software, es un lento deterioro de la calidad del software a lo largo del tiempo o su disminución de la capacidad de respuesta, que acabará provocando que el software sea defectuoso.
Los equipos llevan mucho tiempo luchando por construir software de alta calidad que siga siendo de alta calidad a lo largo del tiempo, incluidos los adagios que reflejan esta dificultad, como las variadas definiciones de la putrefacción de bits mostradas anteriormente. Al menos dos factores impulsan esta lucha: los problemas de vigilar todas las piezas móviles de un software complejo y la naturaleza dinámica del ecosistema de desarrollo de software.
El software moderno consta de miles o millones de piezas individuales, cada una de las cuales puede modificarse en algún conjunto de dimensiones. Cada uno de esos cambios tiene efectos predecibles y, a veces, impredecibles. Los equipos que intentan un gobierno manual acaban abrumados por el enorme volumen de piezas y los efectos secundarios combinatorios.
Gestionar las innumerables interacciones del software ya sería bastante malo en un contexto estático, pero eso no existe. El ecosistema de desarrollo de software está formado por todas las herramientas, marcos, bibliotecas y buenas prácticas, es decir, el estado del arte acumulado en el desarrollo de software en un momento dado. Este ecosistema forma un equilibrio -muy parecido a un sistema biológico- que los desarrolladores pueden comprender y dentro del cual pueden construir cosas. Sin embargo, ese equilibrio es dinámico:constantemente aparecen cosas nuevas, que al principio alteran el equilibrio hasta que surge uno nuevo. Visualiza a un monociclista transportando cajas: dinámico porque el monociclista sigue ajustándose para mantenerse erguido, y en equilibrio porque sigue manteniendo el equilibrio. En el ecosistema del desarrollo de software, cada nueva innovación o práctica puede alterar el statu quo, forzando el establecimiento de un nuevo equilibrio. Metafóricamente, seguimos arrojando más cajas sobre la carga del monociclista, obligándole a restablecer el equilibrio.
En muchos sentidos, los arquitectos se parecen a nuestro desventurado monociclista, en constante equilibrio y adaptación a las condiciones cambiantes. Las prácticas de ingeniería de la Entrega Continua representan ese cambio tectónico en el equilibrio: la incorporación de funciones antes aisladas, como las operaciones, al ciclo de vida del desarrollo de software permitió nuevas perspectivas sobre lo que significa el cambio. Los arquitectos empresariales ya no pueden confiar en planes estáticos de cinco años, porque todo el universo del desarrollo de software evolucionará en ese plazo, haciendo que toda decisión a largo plazo sea potencialmente discutible.
El cambio disruptivo es difícil de predecir, incluso para los profesionales expertos. El auge de los contenedores a través de herramientas como Docker es un ejemplo de un cambio desconocido en la industria. Sin embargo, podemos rastrear el auge de la contenedorización a través de una serie de pequeños pasos graduales. Hubo un tiempo en que los sistemas operativos, los servidores de aplicaciones y otras infraestructuras eran entidades comerciales, que requerían licencias y grandes gastos. Muchas de las arquitecturas diseñadas en esa época se centraban en el uso eficiente de los recursos compartidos. Gradualmente, Linux se convirtió en lo suficientemente bueno para muchas empresas, reduciendo el coste monetario de los sistemas operativos a cero. Después, las prácticas DevOps, como el aprovisionamiento automático de máquinas mediante herramientas como Puppet y Chef, hicieron que Linux fuera libre desde el punto de vista operativo. Una vez que el ecosistema se hizo libre y se utilizó ampliamente, la consolidación en torno a formatos portátiles comunes era inevitable: así, Docker. Pero la contenedorización no podría haberse producido sin todos los pasos evolutivos que conducen a ese fin.
El ecosistema de desarrollo de software evoluciona constantemente, lo que da lugar a nuevos enfoques arquitectónicos. Aunque muchos desarrolladores sospechan que una cábala de arquitectos se retira a una torre de marfil para decidir cuál será la Próxima Gran Cosa, el proceso es mucho más orgánico. Constantemente surgen nuevas capacidades en nuestro ecosistema, que proporcionan nuevas formas de combinarlas con las ya existentes y otras nuevas para habilitar nuevas capacidades. Por ejemplo, considera el reciente auge de las arquitecturas de microservicios. A medida que se popularizaban los sistemas operativos de código abierto, combinados con prácticas de ingeniería impulsadas por la Entrega Continua, suficientes arquitectos inteligentes descubrieron cómo construir sistemas más escalables que finalmente necesitaron un nombre: así, microservicios.
Una parte del trabajo de un arquitecto es el diseño estructural para resolver problemas concretos: tienes un problema y has decidido que el software lo resolverá. Al considerar el diseño estructural, podemos dividirlo en dos áreas: el dominio (o requisitos) y las características de la arquitectura, como se ilustra en la Figura 1-1.
Figura 1-1. Todo el ámbito de la arquitectura del software abarca los requisitos más las características de la arquitectura: las "-habilidades" del software
Los requisitos mostrados en la Figura 1-1 representan el dominio del problema que aborda la solución de software. Las otras partes se conocen como características de la arquitectura (nuestro término preferido), requisitos no funcionales, atributos de calidad del sistema, requisitos transversales y muchos otros nombres. Independientemente del nombre, representan capacidades críticas necesarias para el éxito del proyecto, tanto para su lanzamiento inicial como para su mantenimiento a largo plazo. Por ejemplo, características de la arquitectura como la escala y el rendimiento pueden constituir criterios de éxito para un mercado, mientras que otras como la modularidad contribuyen a la mantenibilidad y la evolucionabilidad.
El software rara vez es estático; sigue evolucionando a medida que los equipos añaden nuevas características, puntos de integración y otros muchos cambios habituales. Lo que los arquitectos necesitan son mecanismos de protección para las características de la arquitectura, similares a las pruebas unitarias pero centradas en las características de la arquitectura, que cambian a un ritmo diferente y a veces están sujetas a fuerzas distintas del dominio. Por ejemplo, las decisiones técnicas de una empresa pueden impulsar un cambio en la base de datos que sea independiente de la solución del dominio.
Este libro describe los mecanismos y las técnicas de diseño para añadir el mismo tipo de garantía continua sobre la gobernanza arquitectónica que los equipos de alto rendimiento tienen ahora sobre otros aspectos del proceso de desarrollo de software.
Las decisiones arquitectónicas son aquellas en las que cada elección ofrece compensaciones significativas. A lo largo de este libro, cuando nos referimos al papel de arquitecto, englobamos a cualquiera que tome decisiones arquitectónicas, independientemente de su cargo en una organización. Además, las decisiones arquitectónicas importantes prácticamente siempre requieren la colaboración con otras funciones.
Arquitectura evolutiva
Tanto los mecanismos de evolución como las decisiones que toman los arquitectos al diseñar el software se derivan de la siguiente definición:
Una arquitectura de software evolutiva admite cambios guiados e incrementales en múltiples dimensiones.
La definición consta de tres partes, que describimos con más detalle a continuación.
Cambio guiado
Una vez que los equipos han elegido las características importantes, quieren guiar los cambios en la arquitectura para proteger esas características. Para ello, tomamos prestado un concepto de la informática evolutiva llamado funciones de aptitud. Una función de aptitud es una función objetivo utilizada para resumir lo cerca que está una posible solución de diseño de alcanzar los objetivos fijados. En la informática evolutiva, la función de aptitud determina si un algoritmo ha mejorado con el tiempo. En otras palabras, a medida que se genera cada variante de un algoritmo, las funciones de aptitud determinan lo "apta" que es cada variante, basándose en cómo definió "apta" el diseñador del algoritmo.
Tenemos un objetivo similar en la arquitectura evolutiva: a medida que la arquitectura evoluciona, necesitamos mecanismos para evaluar cómo afectan los cambios a las características importantes de la arquitectura y evitar la degradación de esas características con el tiempo. La metáfora de la función de adecuación engloba una variedad de mecanismos que empleamos para garantizar que la arquitectura no cambie de formas indeseables, como métricas, pruebas y otras herramientas de verificación. Cuando un arquitecto identifica una característica arquitectónica que quiere proteger a medida que las cosas evolucionan, define una o varias funciones de aptitud para proteger esa característica.
Históricamente, una parte de la arquitectura se ha considerado a menudo una actividad de gobierno, y los arquitectos sólo han aceptado recientemente la noción de posibilitar el cambio mediante la arquitectura. Las funciones de adecuación arquitectónica permiten tomar decisiones en el contexto de las necesidades de la organización y las funciones empresariales, al tiempo que hacen que la base de esas decisiones sea explícita y comprobable. La arquitectura evolutiva no es un enfoque ilimitado e irresponsable del desarrollo de software. Más bien es un enfoque que equilibra la necesidad de cambios rápidos y la necesidad de rigor en torno a los sistemas y las características arquitectónicas. La función de adecuación impulsa la toma de decisiones arquitectónicas, guiando la arquitectura al tiempo que permite los cambios necesarios para apoyar los entornos empresariales y tecnológicos cambiantes.
Utilizamos funciones de aptitud para crear directrices evolutivas para las arquitecturas; las tratamos en detalle en el Capítulo 2.
Cambio incremental
El cambio incremental describe dos aspectos de la arquitectura del software: cómo construyen los equipos el software de forma incremental y cómo lo implementan.
Durante el desarrollo, una arquitectura que permite cambios pequeños e incrementales es más fácil de evolucionar porque los desarrolladores tienen un ámbito de cambio menor. Para la implementación, el cambio incremental se refiere al nivel de modularidad y desacoplamiento de las funciones empresariales y cómo se corresponden con la arquitectura. Sirva un ejemplo.
Supongamos que PenultimateWidgets, un gran vendedor de widgets, tiene una página de catálogo respaldada por una arquitectura de microservicios y prácticas de ingeniería modernas. Una de las funciones de la página permite a los usuarios valorar diferentes widgets con estrellas. Otros servicios del negocio de PenultimateWidgets también necesitan valoraciones (representantes del servicio de atención al cliente, evaluación del proveedor de envíos, etc.), así que todos comparten el servicio de valoración por estrellas. Un día, el equipo de clasificación por estrellas lanza una nueva versión junto a la existente que permite clasificaciones con media estrella, una mejora pequeña pero significativa. Los demás servicios que requieren valoraciones no están obligados a pasar a la nueva versión, sino a migrar gradualmente según les convenga. Parte de las prácticas DevOps de PenultimateWidgets incluyen el monitoreo de la arquitectura no sólo de los servicios, sino también de las rutas entre servicios. Cuando el grupo de operaciones observa que nadie ha enrutado a un servicio concreto en un intervalo de tiempo determinado, desintegran automáticamente ese servicio del ecosistema.
Este es un ejemplo de cambio incremental a nivel arquitectónico: el servicio original puede funcionar junto al nuevo mientras otros servicios lo necesiten. Los equipos pueden migrar al nuevo comportamiento a su antojo (o según las necesidades), y la versión antigua se recoge automáticamente de la basura.
Para que el cambio incremental tenga éxito es necesario coordinar un puñado de prácticas de Entrega Continua. No todas estas prácticas son necesarias en todos los casos, sino que suelen darse juntas en la naturaleza. En el Capítulo 3 hablamos de cómo lograr el cambio incremental.
Múltiples dimensiones arquitectónicas
No hay sistemas separados. El mundo es un continuo. Dónde trazar un límite alrededor de un sistema depende del propósito de la discusión.
Donella H. Meadows
Los físicos griegos clásicos aprendieron gradualmente a analizar el universo basándose en puntos fijos, lo que culminó en la mecánica clásica. Sin embargo, instrumentos más precisos y fenómenos más complejos refinaron gradualmente esa definición hacia la relatividad a principios del siglo XX. Los científicos se dieron cuenta de que lo que antes consideraban fenómenos aislados, en realidad interactuaban entre sí. Desdela década de 1990, los arquitectos ilustrados consideran cada vez más la arquitectura del software comomultidimensional. La EntregaContinua amplió esa visión para abarcar las operaciones. Sin embargo, los arquitectos de software suelen centrarse principalmente en la arquitectura técnica -cómo encajan los componentes de software-, pero ésta es sólo una dimensión de un proyecto de software. Si los arquitectos quieren crear una arquitectura que pueda evolucionar, deben tener en cuenta todas las partes interconectadas del sistema a las que afecta el cambio. Al igual que sabemos por la física que todo es relativo a todo lo demás, los arquitectos saben que hay muchas dimensiones en un proyecto de software.
Para construir sistemas de software evolucionables, los arquitectos deben pensar más allá de la arquitectura técnica. Por ejemplo, si el proyecto incluye una base de datos relacional, la estructura y la relación entre las entidades de la base de datos también evolucionarán con el tiempo. Del mismo modo, los arquitectos no quieren construir un sistema que evolucione de forma que exponga una vulnerabilidad de seguridad. Todos estos son ejemplos de dimensiones de la arquitectura: las partes de la arquitectura que encajan entre sí de formas a menudo ortogonales. Algunas dimensiones encajan en lo que a menudo se denominan preocupaciones arquitectónicas (la lista de "-habilidades" mencionada anteriormente), pero las dimensiones son en realidad más amplias, y encapsulan cosas que tradicionalmente quedan fuera del ámbito de la arquitectura técnica. Cada proyecto tiene dimensiones que el arquitecto debe tener en cuenta al pensar en la evolución. He aquí algunas dimensiones comunes que afectan a la evolucionabilidad en las arquitecturas de software modernas:
- Técnico
-
Las partes de implementación de la arquitectura: los marcos, las bibliotecas dependientes y el lenguaje o lenguajes de implementación.
- Datos
-
Esquemas de la base de datos, disposición de las tablas, planificación de la optimización, etc. El administrador de la base de datos suele encargarse de este tipo de arquitectura.
- Seguridad
-
Define políticas y directrices de seguridad, y especifica herramientas para ayudar a descubrir deficiencias.
- Operativo/Sistema
-
Se refiere a cómo se mapea la arquitectura con la infraestructura física y/o virtual existente: servidores, clusters de máquinas, conmutadores, recursos en la nube, etc.
Cada una de estas perspectivas forma una dimensión de la arquitectura: una partición intencionada de las partes que soportan una perspectiva concreta. Nuestro concepto de dimensiones arquitectónicas abarca las características arquitectónicas tradicionales ("-habilidades") más cualquier otra función que contribuya a construir software. Cada una de ellas forma una perspectiva de la arquitectura que queremos preservar a medida que evoluciona nuestro problema y cambia el mundo que nos rodea.
Cuando los arquitectos piensan en términos de dimensiones arquitectónicas, les proporciona un mecanismo mediante el cual pueden analizar la evolucionabilidad de diferentes arquitecturas evaluando cómo reacciona cada dimensión importante ante el cambio. A medida que los sistemas se entrelazan más con preocupaciones contrapuestas (escalabilidad, seguridad, distribución, transacciones, etc.), los arquitectos deben ampliar las dimensiones que rastrean en los proyectos. Para construir un sistema evolucionable, los arquitectos deben pensar en cómo podría evolucionar el sistema en todas las dimensiones importantes.
Todo el ámbito arquitectónico de un proyecto está formado por los requisitos del software más las demás dimensiones. Podemos utilizar funciones de adecuación para proteger esas características a medida que la arquitectura y el ecosistema evolucionan juntos a lo largo del tiempo, como se ilustra en la Figura 1-2.
Figura 1-2. Una arquitectura consta de requisitos y otras dimensiones, cada una protegida por funciones de adecuación
En la Figura 1-2, los arquitectos han identificado la auditabilidad, los datos, la seguridad, el rendimiento, la legalidad y la escalabilidad como las características arquitectónicas adicionales importantes para esta aplicación. A medida que los requisitos empresariales evolucionan con el tiempo, cada una de las características arquitectónicas utiliza también funciones de adecuación para proteger su integridad.
Aunque los autores de este texto insistimos en la importancia de una visión holística de la arquitectura, también somos conscientes de que una gran parte de la arquitectura evolutiva tiene que ver con patrones de arquitectura técnica y temas relacionados como el acoplamiento y la cohesión. Analizamos cómo afecta el acoplamiento de la arquitectura técnica a la evolucionabilidad en el Capítulo 5 y las repercusiones del acoplamiento de datos en el Capítulo 6.
El acoplamiento no sólo se aplica a los elementos estructurales de los proyectos de software. Muchas empresas de software han descubierto recientemente el impacto de la estructura del equipo en cosas sorprendentes como la arquitectura. Hablamos de todos los aspectos del acoplamiento en el software, pero el impacto del equipo surge tan pronto y con tanta frecuencia que tenemos que hablar de ello aquí.
La arquitectura evolutiva ayuda a responder a dos preguntas comunes que surgen entre los arquitectos del ecosistema moderno de desarrollo de software: ¿Cómo es posible la planificación a largo plazo cuando todo cambia constantemente? y Una vez que he construido una arquitectura, ¿cómo puedo evitar que se degrade con el tiempo? Exploremos estas preguntas con más detalle .
¿Cómo es posible la planificación a largo plazo cuando todo cambia constantemente?
Las plataformas de programación que utilizamos ejemplifican la evolución constante. Las nuevas versiones de un lenguaje de programación ofrecen mejores API para mejorar la flexibilidad o la aplicabilidad a nuevos problemas; los nuevos lenguajes de programación ofrecen un paradigma diferente y un conjunto distinto de construcciones. Por ejemplo, Java se introdujo como sustituto de C++ para aliviar la dificultad de escribir código de red y mejorar los problemas de gestión de la memoria. Cuando miramos a los últimos 20 años, observamos que muchos lenguajes siguen evolucionando continuamente sus API, mientras que aparecen lenguajes de programación totalmente nuevos para atacar regularmente problemas más novedosos. La evolución de los lenguajes de programación se muestra en la Figura 1-3.
Figura 1-3. Evolución de los lenguajes de programación más populares
Independientemente del aspecto concreto del desarrollo de software -la plataforma de programación, los lenguajes, el entorno operativo, las tecnologías de persistencia, las ofertas en la nube, etc.-, esperamos un cambio constante. Aunque no podemos predecir cuándo se producirán los cambios en el panorama técnico o de dominio, ni qué cambios persistirán, sabemos que el cambio es inevitable. En consecuencia, debemos diseñar nuestros sistemas sabiendo que el panorama técnico cambiará.
Si el ecosistema cambia constantemente de forma inesperada, y si la previsibilidad es imposible, ¿cuál es la alternativa a los planes fijos? Los arquitectos empresariales y otros desarrolladores deben aprender a adaptarse. Parte del razonamiento tradicional para hacer planes a largo plazo era económico; los cambios de software eran caros. Sin embargo, las prácticas modernas de ingeniería invalidan esa premisa al abaratar los cambios mediante la automatización de procesos antes manuales y otros avances como DevOps.
Durante años, muchos desarrolladores inteligentes reconocieron que algunas partes de sus sistemas eran más difíciles de modificar que otras. Por eso la arquitectura del software se define como "las partes que son difíciles de cambiar después". Esta cómoda definición separaba las cosas que puedes modificar sin mucho esfuerzo de los cambios verdaderamente difíciles. Por desgracia, esta definición también se convirtió en un punto ciego a la hora de pensar en la arquitectura: la suposición de los desarrolladores de que el cambio es difícil se convierte en una profecía autocumplida.
Hace varios años, algunos arquitectos de software innovadores volvieron a plantearse el problema de "lo difícil es cambiar después": ¿y si incorporamos la capacidad de cambio a la arquitectura? En otras palabras, si la facilidad de cambio es un principio básico de la arquitectura, entonces el cambio ya no es difícil. Construir la evolucionabilidad en la arquitectura permite, a su vez, que surja todo un nuevo conjunto de comportamientos, alterando de nuevo el equilibrio dinámico.
Aunque el ecosistema no cambie, ¿qué ocurre con la erosión gradual de las características arquitectónicas que se produce? Los arquitectos diseñan arquitecturas, pero luego las exponen al desordenado mundo real de la implementación de cosas sobre la arquitectura. ¿Cómo pueden los arquitectos proteger las partes importantes que han definido?
Una vez que he construido una arquitectura, ¿cómo puedo evitar que se degrade con el tiempo?
En muchas organizaciones se produce una desafortunada decadencia, a menudo llamada putrefacción de bits. Los arquitectos eligen determinados patrones arquitectónicos para gestionar los requisitos empresariales y las "-habilidades", pero esas características suelen degradarse accidentalmente con el tiempo. Por ejemplo, si un arquitecto ha creado una arquitectura por capas con la presentación en la parte superior, la persistencia en la inferior y varias capas intermedias, los desarrolladores que trabajan en la elaboración de informes a menudo pedirán permiso para acceder directamente a la persistencia desde la capa de presentación, pasando por alto las otras capas, por razones de rendimiento. Los arquitectos construyen capas para aislar los cambios. Luego, los desarrolladores se saltan esas capas, aumentando el acoplamiento e invalidando el razonamiento subyacente a las capas.
Una vez que han definido las características arquitectónicas importantes, ¿cómo pueden los arquitectos proteger esas características para asegurarse de que no se erosionan? Añadir la evolucionabilidad como característica arquitectónica implica proteger las demás características a medida que evoluciona el sistema. Por ejemplo, si un arquitecto ha diseñado una arquitectura para la escalabilidad, no querrá que esa característica se degrade a medida que el sistema evolucione. Así pues, la evolucionabilidad es una metacaracterística, una envoltura arquitectónica que protege todas las demás características arquitectónicas.
El mecanismo de la arquitectura evolutiva se solapa en gran medida con las preocupaciones y objetivos de la gobernanza arquitectónica: principios definidos en torno al diseño, la calidad, la seguridad y otros aspectos de la calidad. Este libro ilustra las muchas formas en que los enfoques de la arquitectura evolutiva permiten automatizar la gobernanza arquitectónica.
¿Por qué evolutivo?
Una pregunta habitual sobre la arquitectura evolutiva se refiere al propio nombre: ¿por qué llamarla arquitectura evolutiva y no otra cosa? Otros términos posibles son incremental, continua, ágil, reactiva y emergente, por nombrar sólo algunos. Pero cada uno de estos términos yerra el blanco. La definición de arquitectura evolutiva que exponemos aquí incluye dos características críticas: incremental y guiada.
Los términos continuo, ágil y emergente recogen todos la noción de cambio a lo largo del tiempo, que es claramente una característica crítica de una arquitectura evolutiva, pero ninguno de estos términos recoge explícitamente ninguna noción de cómo cambia una arquitectura o cuál podría ser la arquitectura final deseada. Aunque todos los términos implican un entorno cambiante, ninguno de ellos abarca el aspecto que debería tener la arquitectura. La parte guiada de nuestra definición refleja la arquitectura que queremos conseguir: nuestro objetivo final.
Preferimos la palabra evolutivo a adaptable porque nos interesan las arquitecturas que experimentan un cambio evolutivo fundamental, no las que han sido parcheadas y adaptadas a una complejidad accidental cada vez más incomprensible. Adaptarse implica encontrar alguna forma de hacer que algo funcione, independientemente de la elegancia o longevidad de la solución. Para construir arquitecturas que evolucionen de verdad, los arquitectos deben apoyar el cambio genuino, no las soluciones improvisadas. Volviendo a nuestra metáfora biológica, la evolución se refiere al proceso de tener un sistema que se adapte a su propósito y pueda sobrevivir al entorno siempre cambiante en el que opera. Los sistemas pueden tener adaptaciones individuales, pero como arquitectos, debemos preocuparnos por el sistema global evolucionable.
Otra comparación útil que pueden hacer los arquitectos es entre la arquitectura evolutiva y el diseño emergente, y por qué no existe tal cosa como una "arquitectura emergente". Un error común sobre el desarrollo ágil de software es la supuesta falta de arquitectura: "Empecemos a codificar y la arquitectura surgirá sobre la marcha". Sin embargo, esto depende de lo simple que sea el problema. Piensa en un edificio físico. Si necesitas construir una caseta para el perro, no necesitas una arquitectura; puedes ir a la ferretería, comprar madera y armarla a golpes. Si, por el contrario, necesitas construir un edificio de oficinas de 50 plantas, ¡seguro que necesitas arquitectura! Del mismo modo, si estás construyendo un sencillo sistema de catálogos para un pequeño número de usuarios, probablemente no necesites mucha planificación previa. Sin embargo, si estás diseñando un sistema de software que necesita un rendimiento estricto para un gran número de usuarios, ¡la planificación es necesaria! El propósito de la arquitectura ágil no es no hacer arquitectura; es no hacer arquitectura inútil: no pasar por procesos burocráticos que no añaden valor al proceso de desarrollo de software.
Otro factor que complica la arquitectura del software son los distintos tipos de complejidad esencial para los que deben diseñar los arquitectos. Al evaluar las compensaciones, a menudo no se trata de la fácil distinción entre sistema simple y complejo, sino más bien de sistemas que son complejos de diferentes maneras. En otras palabras, cada sistema tiene un conjunto único de criterios de éxito. Aunque hablemos de estilos arquitectónicos como los microservicios, cada estilo es un punto de partida para un sistema complejo que crece sin parecerse a ningún otro.
Del mismo modo, si un arquitecto construye un sistema muy sencillo, puede permitirse prestar poca atención a las cuestiones arquitectónicas. Sin embargo, los sistemas sofisticados requieren un diseño intencionado, y necesitan un punto de partida. La emergencia sugiere que se puede empezar sin nada, mientras que la arquitectura proporciona el andamiaje o la estructura para todas las demás partes del sistema; algo debe estar en su lugar para empezar.
El concepto de emergencia también implica que los equipos pueden ir crescendo lentamente su diseño hacia la solución arquitectónica ideal. Sin embargo, al igual que ocurre con la arquitectura de construcción, no existe una arquitectura perfecta, sino distintas formas en que los arquitectos afrontan los compromisos. Los arquitectos pueden aplicar a la mayoría de los problemas una amplia variedad de estilos arquitectónicos diferentes y tener éxito. Sin embargo, algunos de ellos se ajustarán mejor al problema, ofreciendo menos resistencia y menos soluciones provisionales.
Una clave de la arquitectura evolutiva es el equilibrio entre cuánta estructura y gobernanza son necesarias para apoyar los objetivos a largo plazo y la formalidad y fricción innecesarias.
Resumen
Los sistemas de software útiles no son estáticos. Deben crecer y cambiar a medida que cambia el dominio del problema y evoluciona el ecosistema, proporcionando nuevas capacidades y complejidades. Los arquitectos y desarrolladores pueden hacer que los sistemas de software evolucionen con gracia, pero deben comprender tanto las prácticas de ingeniería necesarias para que eso ocurra como la mejor forma de estructurar su arquitectura para facilitar el cambio.
Los arquitectos también tienen la tarea de gobernar el software que diseñan, junto con muchas de las prácticas de desarrollo utilizadas para construirlo. Afortunadamente, los mecanismos que descubrimos para facilitar la evolución también proporcionan formas de automatizar importantes actividades de gobierno del software. En el próximo capítulo profundizaremos en los mecanismos para conseguirlo.
Get Construyendo Arquitecturas Evolutivas, 2ª Edición now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
