Diseño de soluciones de arquitectura: consideraciones.

Este artículo forma parte de una serie de artículos sobre el diseño de soluciones de arquitectura. Si te has perdido alguno, te los dejamos a mano para que les eches un vistazo:

1. El diseño de soluciones de arquitectura, ¿qué es y para qué sirve?
2. Diseño de soluciones de arquitectura: anatomía de un modelo de solución
3. Diseño de soluciones de arquitectura: el contexto es clave
4. Diseño de soluciones de arquitectura: arquitectura funcional
5. Diseño de soluciones de arquitectura: arquitectura técnica
6. Diseño de soluciones de arquitectura: la infraestructura

Con este artículo finalizamos la serie para describir una metodología de diseño de soluciones de arquitectura. Nos centraremos en las consideraciones que deberían quedar documentadas para explicar y justificar la solución diseñada.

Esta información es relevante cuando el modelo de solución lo lee alguien que no ha estado involucrado en el proceso o ha pasado tiempo desde su diseño, sobre todo para dar perspectiva de las decisiones tomadas en su contexto.

No planteo un contenido cerrado, ni hay que tratar de cubrir todos los puntos. Solo son algunas sugerencias del contenido que podemos incluir y utilizar de forma pragmática para justificar el diseño y las decisiones tomadas.

En lugar de incluir el contenido en el propio modelo de solución, podemos incluir enlaces a otros documentos de trabajo que tengan el detalle necesario y evitar esfuerzos innecesarios para duplicar la información.

Dudas y puntos pendientes

Nuestra principal herramienta de gestión a la hora de hacer un modelo de solución es un inventario de las dudas y puntos pendientes que vayamos identificando durante los análisis.

Nos va a permitir ser sistemáticos a la hora de resolverlos para que no se olviden. También podremos ser más eficientes agrupando todos los temas relacionados con los referentes cuando vamos a pedir información o establecer un orden del día claro en las reuniones.

El inventario de puntos pendientes puede ser un documento gestionado por el propio perfil de arquitectura de soluciones para liderar su resolución como responsable del diseño de arquitectura, o puede integrarse como parte de la gestión del equipo de proyecto.

Una propuesta de estructura de dudas y puntos pendientes puede ser la siguiente:

Es muy útil que esté recogido en un documento aparte y compartido con responsables del proyecto y referentes, ya que da una buena visión del estado de análisis y de cuáles son las cuestiones de arquitectura que quedan por resolver para cerrar una solución. Si podemos incluir filtros en las columnas será una herramienta de gestión bastante potente.

Además, una vez finalizado el diseño, esta información queda como log que permite entender las principales cuestiones que van a aparecer en el entendimiento del proyecto a modo de FAQs.

Valoraciones de productos

En el diseño de arquitectura técnica, hemos incluido las tecnologías y productos seleccionados y una justificación breve de la decisión. Pero, según el momento de conceptualización o ejecución del proyecto en el que estemos, hemos podido necesitar evaluaciones de productos, comparativas o POCs y sería recomendable enlazar este contenido para que sea fácil de localizar y asociar desde el modelo de solución.

En nuestro caso práctico, hemos necesitado realizar varias valoraciones de productos. En un proyecto real, estos productos deberían aparecer en un listado como el que mostramos a continuación, con los enlaces correspondientes a cada documento:

• Tecnología para desarrollar la nueva web
• Producto de API Manager
• Bus de eventos
• Identity provider
• Orquestador de contenedores

Análisis de alternativas

Durante el proceso de diseño nos encontraremos en numerosas ocasiones con varias alternativas de solución, globales o de aspectos concretos, y tendremos que tomar decisiones.

Si una toma de decisiones es compleja y requiere de análisis más detallados podemos incluirlos o enlazarlos en este análisis.

Podemos hacer el clásico análisis de pros y contras de cada alternativa. Personalmente, creo que es más objetivo enumerar los requisitos o aspectos clave de la decisión y evaluar cómo los cubre cada alternativa, descartando las que no cumplen mínimamente alguno de los requisitos importantes.

Podemos refinar más la decisión asignando pesos a los requisitos o haciendo gráficas comparativas con la valoración de cada uno de los requisitos.

Por ejemplo, en nuestro caso de estudio, de forma simplificada, puede quedar así:

El coste de implementar los procesos planificados por eventos es mayor porque requiere implementar servicios adicionales para la gestión de errores. El desarrollo como proceso batch también tiene un sobre coste ya que requiere el desarrollo con un framework de desarrollo adicional, pero es inferior a la alternativa.

Modelar visualmente cada una de las alternativas también es muy útil para evaluar la complejidad o impacto que tienen y, sobre todo, hacerlo visible a los stakeholders a la hora de justificar las decisiones.

En nuestro caso práctico, hemos modelado ambas alternativas para decidir cómo implementar los procesos planificados como parte del propio diseño técnico.

Riesgos

Durante la elaboración del modelo y en las sesiones de trabajo, identificamos riesgos que podrán ocurrir durante la ejecución del proyecto como, por ejemplo, cuando se utilizan tecnologías nuevas o poco conocidas por el equipo, cuando han quedado puntos pendientes sin resolver o las volumetrías son muy altas o variables.

Es importante dejarlos identificados para que las personas responsables del proyecto puedan incluirlos en su gestión. A veces puede parecer que lo que hacemos es poner problemas sobre la mesa, pero realmente estamos ayudando a estar mejor preparados.

Según los riesgos identificados, podemos llegar incluso a plantear que la mejor solución a la que se ha llegado no sea viable técnicamente y se deba reenfocar el proyecto. El perfil de arquitectura también puede proponer medidas de contingencia para que el equipo gestione los riesgos.

En el caso práctico podemos indicar algunos riesgos más evidentes:

• El diseño de la aplicación requiere la implementación de nuevas tecnologías que no conoce el equipo. Se recomienda la inclusión en el proyecto de personas con perfil especialista en las tecnologías planteadas y la formación del personal de TI del hospital. Además, se plantea implementar POCs cuanto antes con los componentes clave para validar su funcionamiento correcto.
• El despliegue y puesta a punto de los componentes basados en nuevas tecnologías puede llevar algún tiempo y retrasar el proyecto. Se recomienda avanzar con el desarrollo funcional de prototipos y MVPs en paralelo al despliegue de la infraestructura.

Descargas de responsabilidad

Otra información relevante que podemos incluir son las tomas de decisiones asumidas con las que no estamos de acuerdo como arquitectos, pero que quedaron impuestas de forma ejecutiva o en negociaciones en las que no hubo puntos de encuentro.

Podemos enlazar también las actas de reunión o correos en los que se cierran estas decisiones.

Esta parte tiene un interés más político que analítico, pero ayuda a entender mejor el contexto de la solución, especialmente a posteriori si hay quejas o problemas. Este punto es bastante delicado y es recomendable usarlo solo cuando nos veamos obligados a dejar constancia.

Deuda técnica

Durante el cierre de la solución puede haber partes que el equipo de desarrollo no quiera o pueda asumir con sus condicionantes. Las negociaciones a veces desembocan en soluciones tácticas que, en muchas ocasiones, no van del todo alineadas con la estrategia o que generan riesgos en el funcionamiento y operación de las aplicaciones.

Se debe buscar el compromiso para subsanar las deficiencias cuanto antes, pero posteriormente a la puesta en producción de la fase actual o al proyecto. Para que no se olvide este compromiso, lo dejamos documentado como deuda técnica y lo comunicamos a la dirección y la gestión de la demanda como requisitos pendientes de implementar.

En el caso práctico podemos identificar algún ejemplo:

La aplicación de gestión de empleados está basada en tecnología legacy que no permite la integración mediante servicios REST, necesitando transformaciones en el API Manager. Puesto que la estrategia es mantenerla, sí queda pendiente subir las versiones de su framework para permitir exponer sus servicios mediante REST.

Costes

Cuando estamos elaborando el modelo de solución como parte de la definición estratégica de la arquitectura o en una fase de conceptualización del proyecto antes de lanzarlo, uno de los objetivos que se quieren alcanzar es estimar el coste del proyecto para analizar su viabilidad económica.

También puede ser importante, en la fase de análisis de los proyectos, revisar los costes para levantar riesgos asociados a costes que no estaban previstos.

El modelo de solución de arquitectura es una herramienta muy buena para estructurar y evidenciar los principales componentes, licencias e impactos que tendrá el proyecto y, con esta información, facilitar las estimaciones de costes:

• Catálogo de los componentes impactados a desarrollar o modificar.
• Adquisición de licencias asociadas a productos nuevos o incremento de usuarios, ya sean de la arquitectura de ejecución o de desarrollo.
• Formación o servicios de soporte / consultoría para el uso de tecnologías nuevas.
• Adquisición o redimensionamiento de infraestructura hardware y servicios Cloud.
• Crecimiento de los equipos estructurales de soporte técnico.
• Homologación o certificación de los componentes o nuevas tecnologías.
• Pruebas de seguridad, contingencia, rendimiento y estrés que se consideren necesarias.

El proyecto tendrá más costes que los enunciados, pero es un buen soporte para complementar las estimaciones que suelen hacer los equipos de desarrollo. En función del coste, podremos evaluar si el proyecto es viable económicamente con la solución propuesta, y podremos iterar para refinarla y optimizarla.

Podremos enfocarnos en simplificar la solución, utilizar servicios o tecnologías alternativas más baratas o aplicar técnicas de FinOps en fase de diseño para optimizar el rendimiento y coste de la infraestructura, especialmente de los servicios cloud.

Asociado al coste, podemos apoyarnos también en el cumplimiento de la sostenibilidad de la solución, evaluando el impacto ambiental y buscando alternativas más sostenibles si fuese necesario. Esta información es especialmente relevante si los sistemas deben cumplir con determinadas certificaciones, y el diseño nos permitirá estimar su cumplimiento.

Últimamente, los servicios cloud facilitan información sobre la huella de carbono, que podemos incluir en el diseño.

Generalmente, el impacto de la huella de carbono va asociado al rendimiento de las aplicaciones, por lo que la optimización de los recursos de computación debería mejorar la sostenibilidad de la arquitectura que diseñamos.

En nuestro caso de uso podemos estimar los siguientes costes. El detalle de dimensionamiento y configuración será el detallado en el modelo de solución de arquitectura:

Al analizar el coste del proyecto podría ocurrir que es demasiado elevado para el presupuesto.

Si hubiese que simplificar la solución tecnológica, podríamos priorizar los costes más elevados en infraestructura o desarrollo, probablemente las máquinas para el cluster de Kubernetes. Dada la volumetría de carga que esperamos de los usuarios, podríamos desplegar la aplicación frontal en los servidores actuales de la aplicación de forma estática.

Si necesitamos ir más allá, podríamos no renovar técnicamente el frontal de la aplicación y mantenerlo en la tecnología actual, eliminando también la necesidad del API Manager.

En este caso, no plantearía eliminar la parte de gestión de eventos y notificaciones porque sí supone una mejora en eficiencia e información importante para los usuarios, y el coste de la infraestructura por uso en Azure es muy bajo.

Roadmap

Si el proyecto se ejecuta en varias fases, el modelo de solución debería centrarse en una de las fases para enfocar de forma práctica lo que necesita el equipo de desarrollo, pero no debe perder de vista la estrategia y pasos a dar para llegar a la solución final.

En esta sección podemos describir a alto nivel el roadmap de arquitectura, estableciendo los diferentes hitos o fases del proyecto y las soluciones asociadas a cada uno. Esta forma de describirlo permite ver la evolución de los sistemas con sus soluciones paralelas, réplicas de datos temporales, situaciones de contingencia…

Si podemos describir los diferentes aspectos de la arquitectura (funcional, técnica, infraestructura) en un solo diagrama de alto nivel, puede ser viable incluirlo en esta sección del documento, pero lo normal es que el proyecto sea lo suficientemente complejo para necesitar varias vistas específicas para cada fase. Esto puede hacer que en un documento ofimático sea difícil de representar el roadmap de arquitectura.

Podemos optar por hacer una representación del roadmap en herramientas visuales con un lienzo “infinito”, que permitan agrupar múltiples diagramas y secuenciarlos por hitos. Otra alternativa sería hacer un modelo de solución completo de cada fase y enlazarlos aquí. Los modelos hasta la fase actual serán más completos y específicos, y los modelos de fases futuras serán de más alto nivel y con más puntos abiertos o incertidumbres.

En nuestro caso práctico podemos recordar que el responsable del hospital tenía mucha prisa por disponer cuanto antes de una herramienta que calculase la planificación de turnos automáticamente. El resto de requisitos no son tan urgentes, por lo que podemos establecer una priorización de requisitos y plantear un roadmap incremental de evolución de la arquitectura.

Primera etapa: proceso batch de cálculo de planificación

En esta primera etapa implementamos solamente el proceso batch, que es la prioridad del proyecto y sus dependencias, así como la integración con los servicios de gestión de empleados para obtener la información que necesita.

En esta fase se planificará el proceso y tendrá impacto también creando nuevas entidades para la planificación de sanitarios.

Los equipos tendrían que seguir coordinando manualmente las tareas de gestión y comunicación con los sanitarios.

No tendría impacto en las aplicaciones actuales de Servicios de RRHH ni de Gestión de empleados.

Segunda etapa: app web de servicios de RRHH

En esta segunda etapa, implementamos la aplicación web con las funcionalidades nuevas que permiten gestionar de forma autónoma y distribuida las tareas de revisión de la planificación y cambios de turnos entre sanitarios. Esta mejora debería reducir también mucho los tiempos de coordinación y gestión de la información de los sanitarios.

Estas funcionalidades requieren de la implementación de los correspondientes servicios de backend en la aplicación actual y las APIs para integrarlos desde el frontal. En la base de datos necesitamos añadir las entidades para gestionar los cambios de turno y previsiblemente haya impactos en las tablas de planificación.

El resto de componentes ya implantados no tendría impactos.

Tercera etapa: eventos y notificaciones automáticos

Por último, incluimos las capacidades de gestión de eventos y notificaciones para mejorar las capacidades de coordinación en tiempo real entre los sanitarios.

Hacer el roadmap de arquitectura plantea el orden en el que sería recomendable realizar la implantación en producción considerando las dependencias técnicas, pero los gestores de proyecto tienen libertad para planificar las tareas del proyecto sin interferir necesariamente en este roadmap, desglosando las etapas en sprints más pequeños, realizando POCs técnicas de otras fases al principio o solapando los desarrollos de diferentes fases por ejemplo.

Otra opción podría ser evolucionar funcionalmente en la segunda y tercera etapa en lugar de tecnológicamente si el equipo ve viable esta posibilidad. Por ejemplo, implementando en la segunda etapa las funcionalidades de revisión de planificación con sus notificaciones automáticas, y en la tercera etapa la gestión de cambios de turno con sus notificaciones automáticas, lo que realmente sería unificar las etapas 2 y 3 de arquitectura con un incremento de funcionalidad iterativo.

Conclusiones

En esta serie de artículos empezamos dando una visión general del diseño de soluciones de arquitectura y la estructura que deberían tener.

Después entramos en detalle en cada uno de las dimensiones de la solución, explorando el diseño desde los objetivos, los casos de uso con sus requisitos no funcionales, la arquitectura lógica funcional y técnica que implementa los casos de uso y la infraestructura necesaria para soportar la implementación de una forma eficiente.

Finalmente, hemos terminado la serie con las consideraciones de diseño que terminan de explicar el contexto y las decisiones de la solución planteada.

El contenido parece extenso para hacer un diseño, y lo es. Son muchos los aspectos a tener en cuenta para diseñar buenas soluciones de arquitectura y tratar de asegurar en lo posible que no haya problemas graves con su implementación. Habrá proyectos en los que algunos de estos aspectos no serán relevantes, y otros en los que otros aspectos no sean los más importantes.

Este contenido es solo una propuesta de todos los análisis que me parecen relevantes y he tratado de hacerla con el foco puesto en el aporte de valor y el pragmatismo, centrando el contenido en los datos y las explicaciones justas. El modelo de solución no debería ser un documento verboso que haya que leer, sino un documento estructurado de datos que se pueden buscar para usar de referencia.

En algunos momentos puede haber redundancia de información entre las diferentes vistas, especialmente con los componentes de aplicación. He tratado de que la redundancia sea la mínima que permita trazar y relacionar los elementos entre las vistas, de forma que el contenido no solo sea una descripción de los sistemas del proyecto, sino una metodología que permita refinar la solución paso a paso desde los objetivos y requisitos hasta la infraestructura de una forma natural, en la que cada vista sea una consecuencia casi trivial de la anterior.

Tú como arquitecto/a tienes la última palabra para seleccionar el contenido que más te aporte valor y personalizar tus modelos de solución. Te animo a probarlo y comentar los resultados.

¿Qué opinas de esta forma de hacer los modelos de solución de arquitectura? ¿Hay algún contenido que eches en falta o creas innecesario?