Definir un framework para maximizar el impacto que tienen los arquitectos de software dentro de una organización es un proceso continuo.
Las funciones de un arquitecto de software incluyen garantizar la calidad de los sistemas de una organización, proporcionar orientación técnica y empoderar a los equipos para tomar decisiones locales con alineación estratégica, normalmente está dado por un grupo dedicado a la arquitectura, separado en múltiples niveles. La definición de éste puede enfocarse bajo el concepto de “Shift Left” que refiere a la práctica de adelantar actividades y decisiones hacia las etapas iniciales de un proceso, en lugar de dejarlas para el final.
Shift Left aplicado a la arquitectura
Un ejemplo práctico de aplicar "Shift Left" en arquitectura es establecer un conjunto de lineamientos y estándares que los equipos deben seguir al desarrollar nuevos proyectos. Estos lineamientos pueden incluir principios de diseño, patrones arquitectónicos recomendados, prácticas de seguridad, entre otros.
En lugar de esperar hasta el final del proceso de desarrollo para que los arquitectos revisen y validen el diseño de cada proyecto, se fomenta que los equipos consulten los lineamientos y realicen revisiones internas desde las etapas iniciales. Esto permite identificar posibles problemas o desviaciones antes de que se invierta demasiado tiempo y esfuerzo en el desarrollo.
Por ejemplo, supongamos que un equipo está desarrollando un nuevo servicio en la nube para la organización. Aplicando el concepto "Shift Left", los arquitectos pueden proporcionar un conjunto de lineamientos que incluya aspectos como la elección de una arquitectura basada en microservicios, el uso de contenedores para la implementación y la implementación de prácticas de seguridad adecuadas.
El equipo puede entonces utilizar estos lineamientos para desarrollar el servicio, asegurándose de que cumple con las mejores prácticas establecidas. Durante el proceso, pueden realizar revisiones internas y consultas con los arquitectos para asegurarse de que están siguiendo el enfoque correcto y abordando posibles desafíos de manera adecuada.
Al aplicar "Shift Left", los arquitectos están empoderando al equipo para tomar decisiones locales, al tiempo que brindan orientación y lineamientos desde el inicio del proyecto. Esto permite que el equipo avance de manera más eficiente y efectiva, garantizando la calidad y la alineación estratégica del servicio desarrollado.
Se recomienda utilizar el siguiente proceso para el desarrollo de un framework de arquitectura:
- El Ascensor del Arquitecto de Software
- Registro de decisiones de Arquitectura
- Lineamientos y estándares
- Asesoría y consultas
- Arquitectura de Referencia y pruebas de concepto
- Oportunidades de mejora
- Priorizar inversiones
- Planificación de recursos y diseño de proyectos
- Ejecución
- Arquitectos multirol
El Ascensor del Arquitecto de Software
Uno de los mejores conceptos que se puede aplicar para la creación / adopción de un framework de Arquitectos de Software viene de Gregor Hohpe, autor del libro The Transformation Architect - The Architect Elevator.
En el libro se muestra el “Penthouse” como una representación de las funciones de ejecutivos y arquitectos empresariales que toman las decisiones de estrategias, inversiones y presupuestos, mientras que el “Cuarto de máquinas”, que se encuentra en la parte inferior del edificio, representa el equipo que ejecuta los proyectos y se toman decisiones locales.
Registro de decisiones de Arquitectura
Un "Registro de Decisiones de Arquitectura" (ADR por sus siglas en inglés) se utiliza para capturar la justificación, el contexto y las implicaciones de las decisiones tomadas en el equipo de arquitectura. Esto incluye información como los problemas que se abordaron, las alternativas consideradas, los criterios de decisión utilizados y la decisión final tomada, este registro normalmente es generado por los Arquitectos Empresariales y sirven para empoderar a los equipos y que estos puedan tomar decisiones locales pero que a su vez estén alineados con la estrategia de TI.
Existe una línea muy fina entre la diversidad (que agrega valor) y el caos (que no lo hace), la evolución no gestionada conducirá a un caos completo (no tengas miedo de tener alguna influencia arquitectónica). — Stefan Tilkov
Si bien es cierto existen problemas que pueden ser solucionados de diferentes maneras, utilizando un ADR podemos reducir las posibilidades en el tiempo de caos y de perder la estrategia de TI, esto se explica con el concepto de “Cono de posibilidades”.
Por ejemplo, si ya se ha definido un único proveedor de nube, dejando documentada esa definición se elimina esfuerzo y tiempo que puedan tomar otros equipos para realizar exploraciones, pruebas de concepto, etc.
Lineamientos y estándares
Una vez que se toman las decisiones, los detalles son importantes para garantizar que la decisión sea entregada y comprendida de manera efectiva para que pueda ser adoptada por los equipos. El objetivo es lograr resultados deterministas a través de un conjunto estándar de "herramientas de conocimiento" para garantizar la calidad y consistencia de la madurez de Arquitectura, además puede tener varios pasos como:
- Definición de lineamientos: creación de estándares.
- Adopción de lineamientos: revisión de la gerencia, planes de implementación y capacitación.
- Revisión de lineamientos: revisión periódica y medición de la alineación.
Lineamientos
Los lineamientos son directrices o pautas establecidas para orientar las acciones y decisiones de los equipos en relación a la arquitectura de software. Estos lineamientos son fundamentales para garantizar la calidad y consistencia de los sistemas desarrollados dentro de una organización. Al seguir los lineamientos establecidos, los equipos pueden asegurarse de que sus soluciones cumplan con los estándares y prácticas recomendadas.
Un ejemplo de lineamiento podría ser la adopción de un patrón arquitectónico específico, como la arquitectura de microservicios. Este lineamiento indica que los equipos deben diseñar sus sistemas utilizando un enfoque basado en microservicios, donde cada servicio se desarrolla y despliega de forma independiente. Al seguir este lineamiento, los equipos pueden aprovechar los beneficios de la escalabilidad, flexibilidad y resistencia que proporciona la arquitectura de microservicios.
Además de los lineamientos, es importante medir la madurez de los equipos en términos de su capacidad para seguir los lineamientos y aplicar las mejores prácticas de arquitectura. Esto se puede lograr mediante la implementación de un modelo de evaluación de madurez, que permite evaluar y medir el nivel de adopción de los lineamientos por parte de los equipos.
Un ejemplo de modelo de evaluación de madurez podría ser utilizar una escala de cinco niveles, donde cada nivel representa un grado de madurez en la adopción de los lineamientos. Por ejemplo:
- Nivel 1: Inicial - Los equipos tienen un conocimiento básico de los lineamientos, pero su adopción es limitada y no está estandarizada.
- Nivel 2: Repetible - Los equipos siguen los lineamientos de manera consistente, pero aún hay margen de mejora en términos de estandarización y documentación.
- Nivel 3: Definido - Los equipos tienen procesos establecidos para seguir los lineamientos y la adopción es estandarizada en toda la organización.
- Nivel 4: Gestionado - Los equipos monitorean y miden regularmente su adopción de los lineamientos, y realizan mejoras continuas en función de los resultados.
- Nivel 5: Optimizado - Los equipos son líderes en la adopción de los lineamientos y continúan mejorando y refinando sus prácticas de arquitectura.
Al medir la madurez de los equipos, las organizaciones pueden identificar áreas de mejora y brindar apoyo y recursos adicionales para ayudar a los equipos a alcanzar niveles más altos de madurez.
Un enfoque común para medir la madurez de los equipos en relación a los lineamientos de arquitectura es utilizar encuestas o evaluaciones que permitan a los equipos autoevaluarse en función de los criterios establecidos. Algunos ejemplos de preguntas que se pueden incluir en una encuesta de madurez son:
- ¿El equipo conoce los lineamientos de arquitectura establecidos?
- ¿El equipo sigue consistentemente los lineamientos al diseñar y desarrollar soluciones?
- ¿El equipo documenta y comparte su arquitectura y decisiones de diseño con otros equipos?
- ¿El equipo realiza revisiones y evaluaciones regulares de su arquitectura para identificar áreas de mejora?
- ¿El equipo busca activamente oportunidades para aprender y mejorar sus habilidades en arquitectura de software?
- ¿El equipo tiene una comprensión clara de cómo sus soluciones se alinean con la estrategia de arquitectura de la organización?
Estas preguntas pueden adaptarse y personalizarse según los lineamientos específicos y las necesidades de la organización. Las respuestas a estas preguntas pueden proporcionar una visión general de la madurez de los equipos y ayudar a identificar áreas de fortaleza y oportunidades de mejora.
Es importante destacar que la medición de la madurez de los equipos no es un proceso único, sino que debe ser realizado de forma periódica para evaluar el progreso y realizar ajustes según sea necesario. Además, es fundamental proporcionar retroalimentación y apoyo a los equipos para ayudarlos a mejorar y alcanzar niveles más altos de madurez en la adopción de los lineamientos de arquitectura.
Asesoría y consultas
Con los lineamientos y estándares definidos, la siguiente etapa es la adopción, a través del trabajo directo con el “Cuarto de Máquinas” en un papel de asesoría. Idealmente, se hace referencia a los artefactos generados previamente para asegurar la máxima transparencia en cuanto a las expectativas.
La responsabilidad de Arquitectura es encontrar constantemente una forma de comunicar la estrategia, lineamientos y estándares. Los equipos son responsables de revisar, encontrar un camino hacia la adopción y brindar retroalimentación en caso de que se quieran tomar decisiones donde no exista un lineamiento o donde se deba evoluacionar alguno de estos.
En esta etapa es clave entender que debe de existir “curiosidad mutua”, los Arquitectos Empresariales no lo ven todo y los Arquitectos Técnicos no consideran el contexto organizativo más amplio.
Arquitectura de Referencia y pruebas de concepto
A través del proceso de asesoramiento del equipo, Arquitectura puede obtener información y retroalimentación para realizar ajustes o inversiones. Comenzando con preguntas como:
- ¿Podría crearse como una capacidad reutilizable por más de un equipo?
- ¿Podría reducir costos?
- ¿Las capacidades actuales limitan el futuro del negocio?
Luego se puede realizar una etapa de exploración y realizar pruebas de concepto para aceptar o rechazar alguna idea, para esto se utilizan arquitecturas de referencia.
Prueba de Concepto
Una prueba de concepto es un ejercicio o experimento que se realiza para evaluar la viabilidad técnica, funcional o comercial de una idea o concepto. Se utiliza para probar y validar hipótesis antes de invertir recursos significativos en el desarrollo completo de un producto o proyecto.
La prueba de concepto generalmente se realiza en una escala más pequeña y con un alcance limitado, pero con el objetivo de demostrar la factibilidad y el potencial de la idea. Puede involucrar la creación de un prototipo, la simulación de un escenario o la realización de experimentos controlados.
Supongamos que una empresa está considerando implementar un nuevo sistema de gestión de inventario automatizado en su almacén. Antes de invertir en la implementación completa del sistema, deciden realizar una prueba de concepto para evaluar su viabilidad.
En la prueba de concepto, seleccionan una sección del almacén y la equipan con sensores, lectores de códigos de barras y otros dispositivos necesarios para el sistema de gestión de inventario automatizado. Luego, realizan pruebas para verificar si el sistema puede realizar las tareas requeridas, como rastrear y registrar la ubicación y cantidad de los productos en tiempo real.
Durante la prueba de concepto, recopilan datos, evalúan el rendimiento del sistema y analizan los resultados. Si la prueba de concepto demuestra que el sistema de gestión de inventario automatizado cumple con los requisitos y beneficios esperados, la empresa puede optar por implementarlo en todo el almacén.
La prueba de concepto permite a la empresa reducir los riesgos y tomar decisiones informadas antes de comprometerse completamente con la implementación del sistema. También brinda la oportunidad de identificar posibles desafíos y realizar ajustes o mejoras antes de escalar el proyecto.
Arquitectura de Referencia
La arquitectura de referencia es un conjunto de patrones, prácticas y estándares que se utilizan como guía para el diseño y desarrollo de sistemas de software en una organización. Proporciona un marco de referencia común que ayuda a los equipos de desarrollo a construir sistemas coherentes y de alta calidad.
Un ejemplo de arquitectura de referencia es el modelo de arquitectura de microservicios. En este modelo, los sistemas se dividen en componentes pequeños e independientes conocidos como microservicios. Cada microservicio se puede desarrollar, implementar y escalar de forma independiente, lo que permite una mayor flexibilidad y agilidad en el desarrollo de aplicaciones.
La arquitectura de referencia también puede incluir patrones arquitectónicos específicos, como el patrón de arquitectura de tres capas (presentación, lógica de negocio y persistencia de datos), que se utiliza para separar y organizar las diferentes responsabilidades de un sistema.
Oportunidades de mejora
Las oportunidades de mejora identificadas por arquitectura y que han pasado por el Cuarto de Máquinas para recibir retroalimentación, a través de la exploración y pruebas de concepto, se sintetizan y se ejecutan para evolucionar los lineamientos.
El objetivo es generar un caso de negocio para cambiar la estrategia o los presupuestos de inversión. Una plantilla mínima para estandarizar estos detalles debería incluir:
- Declaración del problema: se explica por qué es un problema para la organización.
- Contexto: se proporcionan antecedentes relevantes y detalles sobre el problema.
- Beneficios: se detalla la ventaja que la organización obtiene de esta inversión.
- Riesgos: se mencionan las peligros de no tomar medidas sobre esta oportunidad.
- Análisis de costo-beneficio: se evalúa la relación entre los costos y los beneficios esperados de la inversión.
- Plan de implementación: se describe cómo se llevará a cabo la implementación de la oportunidad de mejora.
Priorizar inversiones
La priorización de las inversiones puede variar de una empresa a otra. El momento ideal es antes de que ocurra el próximo ciclo de planificación o inversión para evitar interrumpir los entregables actualmente comprometidos.
Priorizar las oportunidades con los mayores beneficios o riesgos para su revisión, teniendo en cuenta que no todo se abordará al mismo tiempo. La eficiencia de la comunicación es importante durante esta fase debido a la probabilidad de que haya muchas prioridades de negocio compitiendo.
La priorización de inversiones es un proceso crucial para garantizar que los recursos se asignen de manera efectiva y estratégica. Para llevar a cabo este proceso, se pueden utilizar dos enfoques de razonamiento: el razonamiento inductivo y el razonamiento deductivo.
El razonamiento inductivo se utiliza en el Cuarto de Máquinas, donde se analizan los datos y se evalúan diferentes opciones y soluciones potenciales. Este enfoque se basa en la observación de patrones o tendencias en los datos y la formulación de una conclusión general. Por ejemplo, al analizar los datos A, B y C, se pueden identificar ciertos patrones o características comunes que llevan a la conclusión de que la solución D es la mejor opción. El razonamiento inductivo es útil para generar ideas y opciones, y para explorar diferentes posibilidades antes de tomar decisiones.
Por otro lado, el razonamiento deductivo se aplica en el Penthouse, donde se seleccionan y priorizan las inversiones basadas en los datos y análisis presentados. En este enfoque, se parte de una premisa general y se aplican principios o reglas específicas para llegar a una conclusión específica. Por ejemplo, respaldados por los datos A, B y C, se concluye que la solución D debe ser implementada. El razonamiento deductivo es útil para tomar decisiones informadas y estratégicas, ya que se basa en datos y análisis concretos.
Implementar estos enfoques de razonamiento ayuda a garantizar que las inversiones se tomen de manera informada y estratégica. Al utilizar el razonamiento inductivo en el Cuarto de Máquinas, se pueden identificar diferentes opciones y soluciones potenciales, explorar posibilidades y evaluar impactos. Luego, en el Penthouse, se aplica el razonamiento deductivo para seleccionar y priorizar las inversiones que maximicen el impacto y los resultados para la organización. Este proceso de priorización basado en razonamiento inductivo y deductivo mejora la eficiencia de la toma de decisiones y ayuda a garantizar que los recursos se asignen de manera óptima.
En resumen, la priorización de inversiones utilizando el razonamiento inductivo y deductivo es un enfoque efectivo para tomar decisiones informadas y estratégicas. Al utilizar el razonamiento inductivo en el Cuarto de Máquinas y el razonamiento deductivo en el Penthouse, se pueden explorar diferentes opciones, evaluar impactos y seleccionar las inversiones que generen el mayor valor para la organización.
Planificación de recursos y diseño de proyectos
Para las oportunidades que se aprueban durante el proceso de inversión, la función de Arquitectura facilita un camino hacia la ejecución a través de la planificación técnica y de proyectos, descomponiendo los esfuerzos en categorías amplias, con la ayuda de las siguientes preguntas:
- ¿El equipo necesita una Arquitectura de referencia?
- ¿Qué sistemas necesitan ser creados o refactorizados?
- ¿Cuál es la composición ideal del equipo para este esfuerzo?
- ¿Qué habilidades específicas faltan para asegurar el éxito?
- ¿Cuántos equipos se ven afectados al implementar esto?
- ¿Este esfuerzo puede ser asignado a un solo equipo o necesita ser un programa más amplio de varios equipos?
- ¿Cuánto tiempo tomará este esfuerzo?
Un buen recurso para utilizar durante el diseño de proyecto es el libro Righting Software, este libro habla de la descomposición del trabajo y composición de equipos en base a presupuesto y tiempo. A continuación se encuentra un gráfico que indica cómo podrían conformarse los equipos.
Ejecución
Esto se puede dividir en responsabilidad, entrega y ejecución de un proyecto, es crucial que el patrocinador de la iniciativa asuma la responsabilidad de garantizar que se cumplan los objetivos establecidos y que el proyecto se ejecute de manera efectiva.
La responsabilidad implica asegurarse de que todas las partes involucradas comprendan sus roles y responsabilidades, y que exista una clara comunicación y coordinación entre los diferentes equipos y stakeholders. El patrocinador debe garantizar que se asignen los recursos adecuados, tanto humanos como financieros, para llevar a cabo el proyecto de manera exitosa.
La entrega se refiere a la entrega de los resultados del proyecto de acuerdo con los plazos y requisitos establecidos. Esto implica asegurarse de que se cumplan todas las etapas y actividades planificadas, y que se realicen las pruebas y validaciones necesarias antes de la entrega final. El patrocinador debe supervisar y seguir de cerca el progreso del proyecto, asegurándose de que se cumplan los hitos y que cualquier desviación se aborde de manera oportuna.
La ejecución se refiere a la implementación efectiva de los resultados del proyecto en el entorno operativo. Esto puede implicar la capacitación del personal, la instalación de infraestructuras o la integración de sistemas existentes. El patrocinador debe asegurarse de que se realicen todas las actividades necesarias para la ejecución exitosa del proyecto, y que se realicen las pruebas y ajustes necesarios para garantizar un funcionamiento sin problemas.
Arquitectos multirol
En ciertos escenarios, puede haber un deseo de incorporar Arquitectos en multiples roles (product owner, desarrollador, seguridad). Si bien se pierde la capacidad dedicada del arquitecto para dirigir el ascensor, también existen beneficios en este intercambio, algunos de estos son:
- Mayor comprensión del contexto: Al involucrarse en diferentes roles, el arquitecto tiene una visión más amplia y profunda del contexto y los desafíos del proyecto. Esto le permite tomar decisiones más informadas y estratégicas al considerar cómo cada componente o decisión afecta a todo el sistema.
- Mejor comunicación y colaboración: Al estar directamente involucrado en el trabajo diario del equipo, el arquitecto puede establecer una comunicación más efectiva y colaborativa con los miembros del equipo. Esto facilita la comprensión mutua, la resolución de problemas y la alineación de objetivos.
- Mayor agilidad y adaptabilidad: Al asumir varios roles, el arquitecto se vuelve más versátil y adaptable a diferentes situaciones y cambios en el proyecto. Puede ajustar rápidamente su enfoque y tomar decisiones ágiles para abordar los desafíos en tiempo real.
- Transferencia de conocimiento: Al trabajar en diferentes roles, el arquitecto puede compartir su experiencia y conocimientos en diferentes disciplinas con el equipo. Esto promueve el aprendizaje y el desarrollo de habilidades en el equipo, mejorando la capacidad general del equipo para abordar desafíos arquitectónicos.
- Mayor eficiencia en la toma de decisiones: Al tener conocimientos y experiencia en diferentes áreas, el arquitecto puede tomar decisiones de manera más eficiente al considerar múltiples perspectivas y evaluar rápidamente las implicaciones de cada opción.
- Mayor visibilidad y reconocimiento: Al asumir roles adicionales, el arquitecto tiene la oportunidad de destacarse y demostrar su capacidad para liderar y contribuir en diferentes áreas. Esto puede llevar a una mayor visibilidad dentro de la organización y reconocimiento por su experiencia y habilidades.
- Mayor satisfacción y motivación: Al asumir roles adicionales, el arquitecto experimenta una mayor diversidad en su trabajo diario, lo que puede resultar en una mayor satisfacción y motivación. Y esto puede conducir a un mayor compromiso y rendimiento en general.\
En resumen, cuando un arquitecto asume otros roles, no solo se beneficia el equipo y el proyecto, sino también el arquitecto mismo. A través de una mayor comprensión, comunicación, adaptabilidad y transferencia de conocimientos, el arquitecto puede maximizar su impacto y contribuir de manera más efectiva al éxito del proyecto.
Conclusiones
- Definir un framework para maximizar el impacto de los arquitectos de software dentro de una organización es un proceso continuo.
- Garantizar la calidad de los sistemas, proporcionar orientación técnica y empoderar a los equipos para tomar decisiones locales son funciones clave de los arquitectos de software.
- La implementación del concepto "Shift Left" permite empoderar a los equipos para tomar decisiones locales al tiempo que se brinda orientación y lineamientos.
- El uso de un Registro de Decisiones de Arquitectura (ADR) ayuda a capturar y justificar las decisiones arquitectónicas tomadas.
- Establecer lineamientos y estándares, realizar mediciones de adopción y brindar acompañamiento y consultas son prácticas recomendadas para maximizar el impacto de los arquitectos de software.
- La comunicación efectiva, la priorización de inversiones y la planificación de recursos son aspectos importantes en el proceso de definición de un framework para arquitectos de software.
- La incorporación de arquitectos en múltiples roles puede tener beneficios en términos de comprensión del contexto, comunicación, agilidad y transferencia de conocimiento.