Read in English · Lire en français · Auf Deutsch lesen
Capítulo 11 de 12 · Avanzado
Evaluación, toma de decisiones y gobernanza
Este capítulo trata de cómo evaluar, gobernar y hacer evolucionar las arquitecturas a lo largo del tiempo. Abarca la evaluación formal con el ATAM, las revisiones ligeras como el risk-storming y los pre-mortems, las funciones de aptitud y la arquitectura evolutiva, la gobernanza en organizaciones ágiles, Team Topologies y el diseño sociotécnico, la modernización de sistemas heredados con el strangler fig, el liderazgo y la influencia, y la justificación económica y ética del trabajo de arquitectura. Reúne todos los capítulos anteriores, usa la plataforma de reparto de comida como ejemplo recurrente y está escrito para desarrolladores con experiencia, líderes técnicos y arquitectos que toman o guían decisiones significativas.
Introducción en video al capítulo 11
7 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
Te damos la bienvenida al Capítulo 11, Evaluación, toma de decisiones y gobernanza. Los capítulos anteriores te enseñaron a describir lo que un sistema debe lograr, a estructurarlo y a hacerlo rápido, fiable, seguro y económico. Este capítulo trata del trabajo que rodea esas decisiones durante toda la vida de un sistema: comprobarlas antes de comprometer el dinero, mantenerlas vigentes mientras llegan cientos de cambios cada mes y justificarlas en términos económicos y éticos.
El capítulo está escrito para desarrolladores con experiencia, líderes técnicos y arquitectos que toman o guían decisiones significativas. Es donde el curso se une, así que se apoya en todos los capítulos anteriores. Remite sobre todo a los Capítulos 1 a 4: los compromisos, la deuda técnica, los escenarios de atributos de calidad, la ley de Conway y los registros de decisiones. Los Capítulos 5 a 10 ayudan, pero no son imprescindibles. El nivel es avanzado, pero cada sección empieza con una explicación breve para quienes se inician. Y conduce al Capítulo 12, que aplica toda la disciplina a sistemas construidos en torno a modelos de inteligencia artificial.
El ejemplo recurrente es la plataforma de reparto de comida que se usa desde el Capítulo 2. Verás cómo se evalúa su arquitectura, cómo se le aplica risk-storming, cómo se protege con funciones de aptitud, cómo se gobierna, cómo se reorganiza en torno a los equipos y cómo se moderniza en parte. La sección once punto uno trata la evaluación formal con el Architecture Tradeoff Analysis Method, o ATAM: sus nueve pasos repartidos en dos reuniones, quién participa y sus resultados, como los riesgos, los puntos de sensibilidad, los puntos de compromiso y los temas de riesgo. La sección once punto dos explica por qué las juntas de revisión mensuales fracasan tan a menudo y qué funciona en su lugar: el risk-storming, el pre-mortem, las katas de arquitectura y las revisiones de diseño por escrito. La sección once punto tres convierte la evaluación puntual en una protección continua. Una función de aptitud es una comprobación objetiva de una característica arquitectónica, idealmente automatizada, como una regla de dependencia o una prueba de carga con umbrales de percentil. La sección once punto cuatro se pregunta cómo una organización con muchos equipos autónomos mantiene coherente su arquitectura, mediante principios, estándares, guardrails y compuertas, el proceso de consejo y los radares tecnológicos.
Este diagrama de la sección once punto cuatro compara dos formas de gobernar. En la gobernanza basada en compuertas, un equipo diseña y luego espera semanas en la cola de una junta de revisión. Si el diseño se rechaza, se rediseña y vuelve a esperar. Solo después de la aprobación puede el equipo construir y lanzar. En la gobernanza basada en guardrails, el equipo decide y su cambio pasa por un pipeline con guardrails: política como código y funciones de aptitud que comprueban reglas objetivas de forma automática. Puede llegar al lanzamiento en minutos. Debajo están los apoyos: el proceso de consejo para las decisiones significativas, los principios y un radar tecnológico para una dirección compartida, y un camino pavimentado de plantillas y plataforma. Los guardrails dejan a las personas libres para las decisiones que requieren criterio. Y en el proceso de consejo, cualquiera puede tomar una decisión arquitectónica, después de pedir consejo a los afectados y a los expertos, y de dejarla registrada.
La sección once punto cinco se toma en serio la ley de Conway como herramienta de diseño. Presenta Team Topologies: cuatro tipos de equipo, tres formas de interactuar entre equipos y los límites de la carga cognitiva de un equipo. La sección once punto seis se ocupa de los sistemas que ya existen: por qué las reescrituras big-bang fracasan tan a menudo y qué técnicas incrementales funcionan. La sección once punto siete trata la parte humana del rol: liderar sin autoridad formal, generar confianza, facilitar decisiones, gestionar el conflicto y comunicarse con la dirección ejecutiva. Y la sección once punto ocho cierra el capítulo con dos argumentos que un arquitecto debe saber defender bien: la justificación económica, con el valor actual neto y el periodo de recuperación, y la justificación ética, incluidos los daños previsibles y la sostenibilidad.
Este diagrama de la sección once punto seis muestra una de esas técnicas, el strangler fig: sustituir un sistema heredado pieza a pieza mientras sigue funcionando. Primero, interceptar. Los clientes llaman a una fachada de enrutamiento, que todavía envía todo el tráfico al monolito heredado. Todavía no cambia nada en el comportamiento. Después, la primera porción. La fachada envía una funcionalidad, el seguimiento de pedidos, a un servicio nuevo y pequeño, con una sincronización temporal de datos entre lo antiguo y lo nuevo. Porción a porción, la mayor parte del tráfico se traslada, hasta que solo queda la facturación en el sistema antiguo. Por último, todo el tráfico va a los servicios nuevos y el sistema heredado se apaga. La migración solo termina cuando se han eliminado tanto el sistema antiguo como el código temporal.
La arquitectura no está terminada cuando se dibuja el diagrama. Sus decisiones tienen que ponerse a prueba, protegerse mientras el sistema cambia, tomarlas las personas adecuadas, llevarlas a cabo equipos cuya estructura encaje con ellas y justificarse ante los patrocinadores y la sociedad. Los arquitectos más eficaces hacen que este trabajo sea ligero y continuo, en lugar de pesado y ocasional. Revisiones de riesgos breves, en lugar de auditorías anuales. Guardrails automatizados, en lugar de colas de aprobación. Consejo, en lugar de permiso. Y migración incremental, en lugar de reescrituras. La disciplina que lo une todo es la misma con la que empezó este curso: nombra la cualidad que necesitas, hazla medible, decide de forma deliberada, anota por qué y sigue comprobando.
Al final del capítulo, sabrás explicar cuándo evaluar una arquitectura y dirigir un ATAM o una revisión ligera como el risk-storming, con un registro de riesgos y responsables. Sabrás diseñar funciones de aptitud que conviertan los escenarios de atributos de calidad en comprobaciones automatizadas. Sabrás planificar una modernización incremental con el strangler fig, branch by abstraction y ejecuciones en paralelo. Y sabrás calcular el valor actual neto y el periodo de recuperación de una justificación económica, y revisar una arquitectura en busca de inquietudes éticas y de sostenibilidad.
Puedes leer el capítulo en orden o ir directamente a la sección que necesites. Si una idea de un capítulo anterior no te resulta familiar, sigue el enlace para volver a ella. Calcula unas tres horas y media para leer el capítulo completo. Al final de cada sección hay preguntas de autoevaluación. Respóndelas mentalmente antes de mirar las respuestas. Cuando estés listo, hay una prueba del capítulo opcional, que lleva unos cuarenta y cinco minutos. Tiene veinte preguntas de opción múltiple y dos respuestas escritas. La nota de aprobado es el ochenta por ciento.
Esa es la forma del capítulo. Empieza por la sección once punto uno, sobre la evaluación de la arquitectura y el ATAM. Nos vemos allí.
De un vistazo
Aprenderás a
- Explicar cuándo y por qué evaluar una arquitectura, y aplicar los nueve pasos del ATAM para obtener riesgos, no riesgos, puntos de sensibilidad, puntos de compromiso y temas de riesgo.
- Facilitar revisiones ligeras como el risk-storming y los pre-mortems, y convertir sus resultados en un registro de riesgos con responsables.
- Diseñar funciones de aptitud que conviertan los escenarios de atributos de calidad en comprobaciones automatizadas de la estructura, el rendimiento, la seguridad, la resiliencia y los datos.
- Redactar principios de arquitectura y elegir entre guardrails, compuertas y el proceso de consejo para gobernar distintos tipos de decisión.
- Aplicar los tipos de equipo, los modos de interacción y la carga cognitiva de Team Topologies para alinear los equipos con la arquitectura prevista.
- Planificar una modernización incremental de un sistema heredado con el strangler fig, branch by abstraction y ejecuciones en paralelo.
- Liderar e influir en las decisiones arquitectónicas sin autoridad formal, también al comunicarse con la dirección ejecutiva.
- Calcular el valor actual neto y el periodo de recuperación de una justificación económica, y revisar una arquitectura en busca de inquietudes éticas y de sostenibilidad.
Antes de empezar
Capítulos 1 a 4, en especial las decisiones y los compromisos (Sección 1.6), la deuda técnica (Sección 1.7), los escenarios de atributos de calidad y los árboles de utilidad (Secciones 2.3 y 2.8), la ley de Conway (Sección 3.7) y los registros de decisiones (Sección 4.5). Los Capítulos 5 a 10 ayudan, pero no son imprescindibles.
Tiempo
Unas 3½ horas de lectura; 45 minutos para la prueba.
Términos clave
ATAM · Árbol de utilidad · Punto de sensibilidad · Punto de compromiso · Risk-storming · Pre-mortem · Función de aptitud (fitness function) · Arquitectura evolutiva · Proceso de consejo (advice process) · Radar tecnológico · Team Topologies · Strangler fig (higuera estranguladora) · Valor actual neto · Software Carbon Intensity
Evaluar, gobernar y hacer evolucionar la arquitectura
Los capítulos anteriores enseñaron a describir lo que un sistema debe lograr, a estructurarlo y a hacerlo rápido, fiable, seguro y económico. Este capítulo trata del trabajo que rodea esas decisiones durante toda la vida de un sistema: comprobar que son sólidas antes de comprometer el dinero, mantenerlas vigentes mientras llegan cientos de cambios cada mes, decidir quién puede tomar qué decisiones en una organización con muchos equipos, reorganizar los equipos y los sistemas heredados, persuadir a las personas y justificar el costo del trabajo de arquitectura en términos económicos y éticos. Es donde el curso se une, así que remite a menudo a lo anterior: a los escenarios de atributos de calidad y los árboles de utilidad del Capítulo 2, a los principios y las métricas del Capítulo 3, a los registros de decisiones del Capítulo 4, a la ley de Conway de la Sección 3.7 y a la deuda técnica de la Sección 1.7.
El nivel es avanzado, pero cada sección empieza con una explicación breve para quienes se inician, y el ejemplo recurrente es la plataforma de reparto de comida que se usa desde el Capítulo 2: clientes, restaurantes y repartidores, servicios de pedidos, despacho y notificaciones, un intermediario de eventos y un proveedor de pagos externo. Verás cómo se evalúa su arquitectura, cómo se le aplica risk-storming, cómo se protege con funciones de aptitud, cómo se gobierna mediante principios y un radar tecnológico, cómo se reorganiza en torno a los equipos y cómo se moderniza en parte.
Evaluar y proteger las decisiones: Secciones 11.1 a 11.3
La Sección 11.1 trata la evaluación de la arquitectura formal y el ATAM del SEI: por qué y cuándo evaluar, sus nueve pasos repartidos en dos reuniones, quién participa y sus resultados característicos: riesgos, no riesgos con sus supuestos, puntos de sensibilidad, puntos de compromiso y temas de riesgo. El árbol de utilidad de la Sección 2.8 vuelve a su contexto original, y el CBAM muestra cómo sopesar el beneficio de cada corrección frente a su costo. Un ATAM resumido de la plataforma de reparto de comida muestra las tablas que produce realmente una evaluación.
La Sección 11.2 explica por qué las juntas de revisión mensuales fracasan tan a menudo y qué funciona en su lugar: el risk-storming de Simon Brown, el pre-mortem de Gary Klein, las katas de arquitectura de Ted Neward, el TARA de Eoin Woods para sistemas existentes, las revisiones de diseño por escrito y las listas de comprobación. Termina con un formato paso a paso para una revisión de 90 minutos y una guía para elegir entre las técnicas.
La Sección 11.3 convierte la evaluación puntual en una protección continua. Una función de aptitud (fitness function) es una comprobación objetiva de una característica arquitectónica, idealmente automatizada: una regla de dependencia, una prueba de carga con umbrales de percentil, un análisis de vulnerabilidades, un experimento de caos o una comprobación de compatibilidad de esquemas. Junto con cambios pequeños, frecuentes y seguros, las funciones de aptitud hacen posible una arquitectura evolutiva. Tres escenarios del Capítulo 2 se convierten en comprobaciones que funcionan, con código.
Gobernar, organizar y modernizar: Secciones 11.4 a 11.6
La Sección 11.4 se pregunta cómo una organización con muchos equipos autónomos mantiene coherente su arquitectura. Distingue entre principios, estándares, guardrails (salvaguardas) y compuertas; muestra cómo redactar principios con un nombre, un enunciado, una justificación y unas implicaciones; y describe la toma de decisiones descentralizada mediante el proceso de consejo (advice process) de Andrew Harmel-Law, los foros asesores de arquitectura y los radares tecnológicos, con el cumplimiento automatizado mediante funciones de aptitud y política como código.
La Sección 11.5 se toma en serio la ley de Conway como herramienta de diseño. Presenta Team Topologies, de Matthew Skelton y Manuel Pais: cuatro tipos de equipo, tres modos de interacción, la carga cognitiva del equipo, las API de equipo y los planos de fractura, y muestra cómo rediseñar los equipos de la plataforma de reparto de comida en torno a flujos de cambio. La Sección 11.6 se ocupa de los sistemas que ya existen: por qué las reescrituras big-bang fracasan tan a menudo, el abanico de estrategias de migración y las técnicas incrementales que funcionan, como el strangler fig, branch by abstraction, las ejecuciones en paralelo, la captura de datos de cambios y las capas anticorrupción, aplicadas paso a paso extrayendo un módulo de pedidos de un monolito con el strangler fig.
Liderar, justificar y actuar con responsabilidad: Secciones 11.7 y 11.8
La Sección 11.7 trata la parte humana del rol: liderar sin autoridad formal, generar confianza, facilitar decisiones por consentimiento o por consenso, gestionar el conflicto y la política organizativa, comunicarse con la dirección ejecutiva, la mentoría, las trayectorias de ingeniería staff-plus y las trampas de decisión en las que caen las personas con experiencia, con una decisión disputada sobre un bus de eventos resuelta paso a paso.
La Sección 11.8 cierra el capítulo con los dos argumentos que un arquitecto más necesita saber defender bien. La justificación económica: costos, beneficios, riesgos y opciones, con el valor actual neto y el periodo de recuperación calculados en un ejemplo práctico, y la deuda técnica expresada en dinero y en tiempo. Y la justificación ética: los códigos de conducta profesionales, los daños previsibles como la pérdida de privacidad, el sesgo, la falta de accesibilidad y el diseño manipulador, y la sostenibilidad medida con la especificación Software Carbon Intensity.
La idea que debes llevarte
La arquitectura no está terminada cuando se dibuja el diagrama. Sus decisiones tienen que ponerse a prueba frente a lo que necesita el negocio, protegerse mientras el sistema cambia, tomarlas las personas adecuadas con el consejo adecuado, llevarlas a cabo equipos cuya estructura encaje con ellas y justificarse en términos que los patrocinadores y la sociedad puedan aceptar. Los arquitectos más eficaces hacen que este trabajo sea ligero y continuo en lugar de pesado y ocasional: revisiones de riesgos breves en lugar de auditorías anuales, guardrails automatizados en lugar de colas de aprobación, consejo en lugar de permiso, migración incremental en lugar de reescrituras. La disciplina que lo une todo es la misma con la que empezó este curso: nombra la cualidad que necesitas, hazla medible, decide de forma deliberada, anota por qué y sigue comprobando.
Las 8 secciones
Prueba del capítulo
Comprueba lo que has entendido del capítulo 11
Opcional: 20 preguntas de opción múltiple y 2 respuestas escritas breves, elegidas de nuevo cada vez de un banco de 72 preguntas. Nota de aprobado: 80%. Superar todas las pruebas de capítulo y después la evaluación final da derecho al Certificado de Finalización Be Wise.
Haz la prueba del capítulo 11 en la appLecturas recomendadas
- Software Architecture in Practice, 4th edition, Len Bass, Paul Clements and Rick Kazman (2021), Addison-Wesley. El libro de texto de referencia; sus capítulos sobre evaluación de la arquitectura describen el ATAM y su variante ligera, de la mano de los autores del método.
- ATAM: Method for Architecture Evaluation (CMU/SEI-2000-TR-004), Rick Kazman, Mark Klein and Paul Clements (2000), Software Engineering Institute, Carnegie Mellon University. El informe técnico original que define los pasos, los roles y los resultados del ATAM, con un caso práctico.
- Building Evolutionary Architectures: Automated Software Governance, 2nd edition, Neal Ford, Rebecca Parsons, Patrick Kua and Pramod Sadalage (2022), O'Reilly Media. El origen de las funciones de aptitud arquitectónicas y la exposición más clara de la arquitectura evolutiva.
- Performing a Project Premortem, Gary Klein (2007), Harvard Business Review. El breve artículo que presentó el pre-mortem: imaginar primero el fracaso y después prevenirlo.
- Scaling the Practice of Architecture, Conversationally, Andrew Harmel-Law (2021), martinfowler.com. Describe el proceso de consejo, los foros asesores, los principios elaborados por los equipos y un radar tecnológico interno.
- Design It! From Programmer to Software Architect, Michael Keeling (2017), Pragmatic Bookshelf. Una guía práctica de la arquitectura como actividad de equipo, con muchas actividades de taller, diseño y evaluación para equipos.
- Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones), Marianne Bellotti (2021), No Starch Press. Una guía franca y basada en la experiencia para modernizar sistemas heredados sin una reescritura condenada al fracaso.