Proceso de revisión

La revisión de la arquitectura debe realizarse de manera consistente y adoptar un enfoque libre de culpas que fomente la reflexión profunda. Debe ser un proceso ligero (horas, no días) que sea una conversación y no una auditoría. El objetivo de revisar una arquitectura consiste en identificar todos los problemas graves que puedan necesitar solucionarse o las áreas que se puedan mejorar. El resultado de la revisión es un conjunto de acciones que debe mejorar la experiencia de un cliente que utiliza la carga de trabajo.

Como se analiza en la sección “Sobre la arquitectura”, el objetivo es que cada miembro del equipo se responsabilice por la calidad de su arquitectura. Recomendamos que los miembros del equipo que construyen una arquitectura utilicen el Marco de Buena Arquitectura para revisarla continuamente, en lugar de llevar a cabo una reunión formal de revisión. Un enfoque continuo permite que los miembros del equipo actualicen las respuestas a medida que la arquitectura evoluciona y la mejoren a medida que se entregan las características.

La Buena Arquitectura de AWS se adapta a la forma en que AWS revisa los sistemas y servicios internamente. Se basa en un conjunto de principios de diseño que influye en el enfoque arquitectónico y en preguntas que aseguran que las personas no descuiden las áreas que a menudo aparecen en el análisis de causa raíz (RCA). Siempre que haya un problema grave con un sistema interno, el servicio de AWS o el cliente, analizamos el RCA para ver si podemos mejorar los proceso de revisión que utilizamos.

Las revisiones se deben aplicar a los hitos clave en el ciclo de vida del producto al principio de la etapa de diseño para evitar caminos sin retorno« [ Muchas decisiones son reversibles, es decir, con un camino de ida y vuelta. Esas decisiones se pueden utilizar como un proceso ligero. Es difícil o imposible revertir los caminos sin retorno y exigen más inspección antes de recorrerlos. ] »  que son difíciles de cambiar antes de la fecha de la puesta en marcha. Luego de la puesta en marcha, su carga de trabajo seguirá evolucionando a medida que agregue características y cambie las implementaciones tecnológicas. La arquitectura de una carga de trabajo cambia con el tiempo. Tendrá que cumplir con las prácticas recomendadas de higiene para evitar que sus características arquitectónicas se degraden a medida que evolucionan. A medida que hace cambios importantes en la arquitectura, debe cumplir con una serie de procesos de higiene que incluyen una revisión de Well-Architected.

Si desea utilizar la revisión como una instantánea única o como una medición independiente, querrá asegurarse de tener a todas las personas adecuadas en la conversación. A menudo descubrimos que las revisiones son la primera vez que un equipo entiende realmente lo que ha implementado. Un enfoque que funciona bien al revisar la carga de trabajo de otro equipo es tener una serie de conversaciones informales sobre su arquitectura en la que se pueden obtener las respuestas a la mayoría de las preguntas. Luego puede seguir con una o dos reuniones en las que puede ganar claridad o profundizar en áreas de ambigüedad o riesgo percibido.

Estos son algunos puntos sugeridos para facilitar sus reuniones:

Después de haber hecho la revisión, debe tener una lista de problemas a los que puede dar prioridad en función de su contexto empresarial. También querrá tener en cuenta el impacto de esos problemas en el trabajo diario de su equipo. Si aborda estos problemas a tiempo, podría liberar tiempo para trabajar en la creación de valor empresarial en lugar de resolver problemas recurrentes. A medida que aborda los problemas, puede actualizar su revisión para ver cómo mejora la arquitectura.

Si bien el valor de una revisión es evidente después de haber hecho una, puede que un nuevo equipo se resista al principio. Estas son algunas de las objeciones que se pueden manejar a través de la capacitación del equipo sobre los beneficios de una revisión:

A medida que lleve a cabo varias revisiones con los equipos en su organización, podrá identificar problemas temáticos. Por ejemplo, puede ver que un grupo de equipos tiene conjuntos de problemas en un pilar o tema en particular. Querrá analizar todas sus revisiones de manera holística e identificar los mecanismos, las capacitaciones o las charlas de ingeniería principal que pueden ayudar a abordar esos problemas temáticos.