El diseño de soluciones de arquitectura, ¿qué es y para qué sirve?

Tras años realizando diseños de soluciones de arquitectura en varias empresas de distintos sectores, he observado y aprendido los enfoques con que lo trabajan, llegando a mis propias conclusiones sobre cómo debería ser un diseño de soluciones de arquitectura que sea completo y práctico. Te las cuento en este post.

¿Qué es el diseño de soluciones de arquitectura?

Como todo diseño, es un documento, en cualquier formato. Y como solución de arquitectura trata de resolver parte del problema de cómo implementar una necesidad del negocio, centrándose en los aspectos de arquitectura de TI.

Generalmente, la problemática se presenta en el contexto de un proyecto, aunque puede plantearse en momentos anteriores de análisis de las necesidades u objetivos del negocio.

Hacer este diseño tiene varias utilidades:

• Es una herramienta para pensar, que permite ordenar y estructurar la problemática o solución, visualizarla de forma más específica que en la mente, revisar sistemáticamente los detalles, agregar o quitar información, subir o bajar el nivel de detalle, poner el foco en determinados puntos…
• Permite optimizar las soluciones, evidenciando las redundancias, sinergias, cuellos de botella, dependencias, simplificaciones…
• Unifica la visión de la solución, sirviendo de plano de referencia para todos los equipos, en un formato que se puede compartir y divulgar fácilmente.
• Permite definir claramente la estrategia del proyecto: corto, medio y largo plazo
• Permite realizar análisis de impacto cualitativo y cuantitativo.
• Sirve como base para estimar y valorar los costes de los proyectos de alto nivel en momentos tempranos del proyecto en los que aún no están claros todos los detalles.
• Permite identificar rápidamente los equipos de trabajo que deben participar en un proyecto.
• Facilita la estructura del proyecto en partes o fases coherentes y que los participantes tengan claros los puntos de colaboración.
• Visualiza los escenarios de pruebas end to end de forma intuitiva.

Por otro lado, hacer un diseño es complejo y tiene sentido hacerlo solo si realmente aporta valor al proyecto. Si no, es mejor centrarse en otro tipo de diseños funcionales y técnicos más detallados directamente, para evitar que se convierta en un instrumento burocrático que desincentive a los equipos a utilizarlo como herramienta.

El nivel de detalle adecuado para conseguir un buen diseño de solución de arquitectura es el que aporte la suficiente visión global del problema y la solución, pero también el que tenga el detalle suficiente para que resulte útil a los equipos que la deben implementar.

¿Cuándo usarlo?

El diseño va a resultar útil en cualquier momento del ciclo de vida de una iniciativa o proyecto y, más o menos formalmente, es algo que realmente hacemos todos.

Las propuestas de los proyectos suelen contener una solución técnica, generalmente de la arquitectura, que permite explicar fácilmente cómo se plantea resolver la necesidad, estimar el coste del proyecto o identificar dependencias con otros equipos.

Este tipo de análisis es similar cuando se trata de la evaluación temprana de una iniciativa interna de una compañía, cuando valora el desarrollo de una nueva capacidad o solución de un problema, ayudando a determinar si es viable y el coste aproximado.

El modelo de solución permite iniciar el proyecto con una cierta estrategia, ordenando los bloques de trabajo según las dependencias entre componentes o funcionalidades, o identificar las necesidades de infraestructura y logísticas para gestionarlas desde el principio.

Puede facilitar el análisis de los requisitos funcionales y no funcionales más detallados, proporcionando un contexto en el que entender mejor cómo encajan con el resto de piezas, simplificar las discusiones sobre el entendimiento de los mismos y visualizar el alcance del proyecto.

Cuando en el proyecto cada equipo está desarrollando su parte específica, a veces, los desarrolladores no tienen el contexto de para qué lo están haciendo, o cómo encaja su parte con el resto, sobre todo cuando no hay integraciones directas. Entender bien el propósito e integración de cada componente ayuda y motiva al equipo de desarrollo en su cometido.

Cuando llega la fase de pruebas integradas de procesos complejos, el desarrollo de las partes debería ser más coherente, facilitando la integración y reduciendo los tiempos de resolución de problemas de incompatibilidad o malentendidos. Además, a la hora de elaborar los planes de pruebas integradas, facilita la identificación de los posibles escenarios, permitiendo recorrer sobre el modelo los procesos e interacciones entre componentes.

El diseño proporciona un inventario de los componentes a desplegar a alto nivel, que permite ordenar y revisar los artefactos necesarios.

De cara al mantenimiento de la aplicación, el diseño de arquitectura proporciona información muy útil para realizar el traspaso de conocimiento al nuevo equipo, analizar el impacto de cualquier cambio o investigar incidencias que no sean evidentes entre las dependencias de la arquitectura.

Dependencias y resultados

Como todo proceso, diseñar tiene una serie de dependencias para hacerse correctamente, y proporcionará unos resultados.

La primera dependencia para realizar un modelo de solución es tener los objetivos del proyecto o iniciativa claros, para acotar y tener un punto de partida de la problemática que se quiere resolver.

Debemos obtener todos los requisitos posibles, funcionales y no funcionales.

Debemos entender bien el proceso o procesos de negocio en los que debemos resolver la problemática. Ayuda mucho si se dispone de documentación o herramientas que proporcionen información y faciliten su comprensión.

El contexto del proyecto es clave, porque el éxito de la solución puede depender de los intereses de los patrocinadores u otros interesados o participantes que pueden estar ocultos, de las complejidades organizativas que pueden rodear al proyecto, de las relaciones entre las personas, de proyectos anteriores que fracasaron y por qué… Además, nos ayudará mucho conocer la arquitectura existente, o si la empresa ya dispone o no de ciertas tecnologías o las restricciones que pueda haber al respecto.

Los condicionantes de presupuesto y tiempo son claves para realizar propuestas de solución realistas.

Si disponemos de la arquitectura de referencia de la compañía, hay principios y normas de diseño aceptados y existen soluciones de arquitectura modularizadas como patrones podríamos tener gran parte del trabajo de análisis hecho, ya que tendríamos un espacio de soluciones mucho más acotado y habría ya ciertas decisiones predefinidas.

Proceso de diseño iterativo

Si vemos diseñar como una tarea para pensar, es obvio entender que es difícil plantear una buena solución a un problema con la primera idea que tengamos. En ocasiones el tamaño o complejidad del problema serán demasiado grandes para poder tener en cuenta todos los aspectos importantes desde el inicio. Y lo más normal es no tener toda la información o conocimiento necesarios disponibles.

Plantear abordar cada fase del diseño después de que la anterior esté completa se vuelve muy ineficiente, y hacer esperar al equipo de desarrollo a tener un diseño de arquitectura perfecto suele desembocar en parálisis por análisis.

Además, lo normal es que cuando abordemos fases posteriores del diseño cuestionemos las anteriores y haya que replantear la solución desde el principio en algún aspecto.

Otra cuestión a tener en cuenta es que el arquitecto probablemente no tenga todo el conocimiento o contexto necesario, y por mucho que pregunte a los demás equipos, no lo va a obtener con toda la profundidad y matices necesarios para valorar si la solución que plantea es la más adecuada. Un buen diseño de arquitectura es un trabajo en equipo en el que el arquitecto actúa como coordinador y árbitro de las decisiones.

Me parece más adecuado y natural gestionar la elaboración de un diseño de arquitectura de forma iterativa, partiendo de la información inicial que podamos conseguir, sin esperar a resolver dependencias y bloqueos, y avanzando lo que podamos con lo que tenemos. Cada iteración debería ser rápida, con el tiempo adecuado, según la organización lo permita, para obtener la información necesaria y revisar la solución con las personas involucradas.

Con cada iteración no solo proporcionamos más detalle a la solución, sino que corregimos y mejoramos las propuestas anteriores. Pensar varias veces sobre el problema cada vez de una manera diferente debería conducirnos a soluciones mejores.

Veamos los diferentes pasos para elaborar una solución:

1. Analizar la información

El punto de partida es obtener toda la información posible. Normalmente, dispondremos de una descripción del problema y los objetivos más evidentes. Es posible que además dispongamos de una especificación de requisitos más elaborada u ordenada y de documentación adicional que sirva de contexto. En otras ocasiones podemos partir de una reunión en la que nos cuentan el proyecto o iniciativa.

En cualquier caso debemos pedir toda la información que haya disponible en ese momento, además de la proporcionada. Como guía para pedir información podemos utilizar las dependencias planteadas en la sección anterior.

Si la entrada de documentación e información es muy grande, es interesante clasificar los documentos y filtrar la información que no sea relevante para el diseño a nivel de arquitectura. Podemos enredarnos en discusiones que no son de la arquitectura o abrumarnos ante múltiples detalles que para nosotros no son relevantes.

Más allá de entender la información debemos hacer un entendimiento del problema y los objetivos. Para hacer esto hay que ir más allá de la información que nos proporcionan y hacernos preguntas. Muchas preguntas. Las preguntas son nuestra principal herramienta de trabajo para comprender realmente lo que debemos conseguir. Propongo algunos ejemplos: ¿Cuál es el verdadero problema desde el punto de vista del negocio? ¿Cómo de grave o importante es? ¿Cuáles son los beneficios de resolverlo, planteados en términos de dinero o reputación? ¿Cuáles son los aspectos más importantes del problema en cuanto a plazos, presupuesto o calidad de la solución? ¿Cuál es el contexto organizacional, funcional y técnico? ¿Hay otros objetivos secundarios u ocultos? ¿El proyecto es realmente bueno para la compañía? ¿Quiénes apoyarán o entorpecerán el proyecto? ¿Qué dificultades nos podemos encontrar? ¿El planteamiento del problema está planteando ya una solución, sesgando las posibilidades? ¿Podemos cuestionar o replantear la formulación del problema?

Como arquitectos hay un punto clave donde debemos poner foco: los requisitos no funcionales. Nuestro mayor aporte de valor no está tanto en la funcionalidad como en proporcionar al equipo de desarrollo una arquitectura que les permita ejecutar las funcionalidades en condiciones de calidad y facilitar su desarrollo y mantenimiento.

2. Obtener las dudas

Debemos analizar detalladamente toda la información. Al hacerlo, lo normal será que encontremos cuestiones que no entendemos, siglas que no conocemos, aspectos más oscuros en los que falta información, o incluso incoherencias y errores.

Recomiendo hacer un inventario de las dudas encontradas, indicando qué equipo referente puede resolverlas, la importancia que tienen y la resolución de las mismas cuando la obtengamos. Será muy útil durante todo el proceso para no dejar cuestiones sin resolver y aportará información adicional para que otras personas entiendan mejor la solución planteada.

3. Resolver las dudas con los referentes

Es una obviedad, pero para resolver las dudas debemos hablar con los referentes para que nos proporcionen las respuestas.

Los referentes son cualquier persona que tenga la responsabilidad de gestionar la información que necesitamos, o cualquiera que por su experiencia pueda proporcionarla con veracidad. Debemos averiguar quiénes son las personas que nos pueden ayudar, y eso a veces no es tan sencillo.

No siempre estarán disponibles ni tendrán todas las respuestas. Eso no debe pararnos. Resolvemos las que podamos y dejamos solicitadas y pendientes el resto.

4. Elaborar o revisar el diseño

En este punto deberíamos tener ya una cierta base sobre la que trabajar y plantear soluciones al problema.

En la primera iteración tenemos que enfrentarnos al folio en blanco, pero podemos apoyarnos en plantillas o metodologías de diseño de arquitectura que nos ayuden a dar forma a las soluciones. En próximos artículos exploraremos con detenimiento esta etapa, desarrollando una metodología de diseño de soluciones de arquitectura.

Los patrones de arquitectura o modelos de solución ya implementados nos pueden ayudar también en este paso, reutilizando soluciones ya establecidas para problemas similares, o rechazando planteamientos que tuvieron problemas.

La solución no tiene por qué ser completa. Lo importante es que podamos elaborar una propuesta lo más completa posible, evidenciando los puntos que están pendientes de resolver y aclarando que la solución no es definitiva, que permita resolver partes del problema.

5. Revisarlo con los especialistas

Un handicap común en un arquitecto de soluciones, aunque esté especializado en algún ámbito de negocio o técnico, es que tiene que resolver problemas sobre cualquier aplicación, proceso de negocio o tecnología. Es complicado saber todo lo necesario para diseñar una buena solución. Por eso es muy importante que tenga acceso a los especialistas, tanto de negocio como técnicos, para validar que las soluciones planteadas son correctas y viables.

Además, estos equipos pueden utilizar su conocimiento y experiencia para aportar nuevas ideas o enfoques que permitan mejorar las soluciones.

Puede ocurrir que cada experto quiera orientar la solución hacia su ámbito de conocimiento simplemente porque es lo que mejor conoce, y hay que tener cuidado, porque para un martillo todo son clavos. Como arquitectos de soluciones debemos tener criterios globales para no dejarnos llevar por los expertos si plantean llevar las soluciones a su terreno habiendo opciones más adecuadas.

6. Revisarlo con los interesados

Una vez que tengamos ya una propuesta de solución, el siguiente paso es revisarla con los interesados, que normalmente son los sponsors del proyecto, responsables de gestionar el proyecto y equipos de desarrollo de las aplicaciones o infraestructuras involucradas.

Por un lado, los equipos que se encargarán de ejecutar el proyecto deben estar alineados con la propuesta de solución, y, por otro lado, necesitamos la aprobación en cuanto al enfoque, costes y plazos de la solución.

El objetivo de estos dos pasos anteriores es que la solución sea un acuerdo de todas las partes implicadas, y afianzar el apoyo a la solución para evitar problemas futuros por conflictos en su implantación.

Para esta etapa necesitaremos nuestras mejores habilidades personales para negociar y conseguir acuerdos con todas las partes.

7. Analizar el feedback

En esta etapa revisaremos el resultado del paso anterior y determinaremos si tenemos ya una solución completa y acordada con todos, o aún quedan partes o conflictos por resolver.

Si ya lo tenemos, perfecto, pasamos a la siguiente etapa. Si no, debemos valorar si debemos realizar una nueva iteración de diseño con toda la información recogida durante el proceso, o elevar los riesgos en caso de que hayamos agotado las vías para encontrar una solución.

8. Cerrar la versión del modelo de solución

Una vez hemos conseguido llegar a una solución debemos terminar documentarla correctamente para publicarla y divulgarla a todos los interesados.

Lo ideal es disponer de un espacio público y accesible para todos oficial, donde puedan encontrar fácilmente el diseño cuando lo necesiten.

Este proceso lo repetimos las veces que sea necesario, considerando que tenemos varias opciones para terminarlo. Generalmente, las primeras iteraciones son las más lentas, y el resto de iteraciones estarán más orientadas a resolver dudas o realizar correcciones. Es posible llegar a algún punto donde no podamos realizar nuevas iteraciones dado que hemos agotado los puntos de avance y solo quedan puntos abiertos pendientes de resolver que están bloqueados. En ese caso debemos elevar el riesgo para que los responsables puedan gestionar el desbloqueo de estos puntos.

Podemos ver que no se itera para conseguir una perfección en el diseño, sino para conseguir una solución completa y acordada. Llegados a este punto, salvo que identifiquemos algún defecto importante que no se pueda asumir, debemos terminar el diseño.

Trabajar el diseño de esta manera nos permitirá tener una primera versión temprana que, aunque no sea completa, probablemente resuelva la mayor parte del problema. Si conseguimos cerrar parte de la solución, abrimos la posibilidad de que los equipos de desarrollo puedan empezar a trabajar, aunque no esté cerrada la solución al 100%.

Dispondremos de un primer borrador con soporte visual que nos ayude a entender mejor la problemática y resolver las dudas. Los equipos podrán identificar mejoras también más fácilmente sobre el modelo.

El diseño de esta manera no es una propuesta solo del arquitecto, sino que consigue que todos participen en la solución, tengan visibilidad del avance, proporcionen feedback y la hagan suya desde el principio.

Evaluación del modelo de solución

Como con todo, una solución debería ser buena, bonita y barata, pero normalmente no es tan fácil. Suele haber múltiples soluciones posibles, con sus ventajas e inconvenientes. Cuando tenemos una o varias propuestas sobre la mesa, toca evaluar las opciones del modelo de solución y tomar decisiones.

Para hacer una comparativa, lo recomendable es fijar cuáles son los objetivos o características clave más importantes, y evaluar lo más objetivamente posible cómo los cumple cada opción.

Esto se puede hacer más complejo cuando hay múltiples interesados para los que las prioridades son diferentes. Antes de hacer la evaluación sería importante llegar a acuerdos sobre la importancia de los objetivos y fijar pesos que ponderen los resultados si es necesario.

También, para valorar la viabilidad de una solución hay que tener en cuenta no solo la viabilidad técnica de la solución, sino las restricciones más importantes del proyecto: el alcance, el presupuesto, los plazos y la calidad de la solución planteada.

Negociar la calidad de una solución suele tener resultados muy malos. Podemos llegar con toda la funcionalidad, en plazo y tiempo, pero si las aplicaciones se caen, van lentas o corrompen datos, pocos podrán ver un éxito con la implementación de la solución. Este escenario siempre debe incluirse como un riesgo, y quizá pueda tenerse en cuenta en experimentos para los que el negocio pueda estar preparado para que tenga problemas.

Si el foco del negocio está en los plazos y se identifican riesgos para conseguirlo, sería interesante plantear un roadmap de implementación en el que conseguir los principales objetivos dentro del plazo, con soluciones parciales a costa de los requisitos menos importantes, y dejarlos para un despliegue posterior.

Al hablar de roadmaps de implementación suelen aparecer los términos de “solución táctica” y “solución estratégica”. Una solución táctica debe ser una solución parcial de la solución estratégica, con alguna adaptación adicional para que funcione correctamente. Pero no debería ser una solución que avance en una estrategia diferente, ya que sería una inversión que habría que desechar después, o una chapuza que pueda poner en peligro el funcionamiento de los procesos. En cualquier caso, si tenemos una solución final acordada con todos los interesados, cualquier cambio pendiente hasta conseguir implementarla se convertirá en deuda técnica y los responsables de gestionar el proyecto deberán planificarla.

Hay que tener en cuenta que los plazos que necesita el negocio no tienen por qué coincidir con los planificados inicialmente para el proyecto. Puede haber intereses o márgenes adicionales a los del negocio que por el camino influencien a la planificación. Sería interesante conocer los plazos para los que es realmente importante para el negocio cumplir con los objetivos.

También hay que tener en cuenta que cumplir con los objetivos no tiene por qué ser necesariamente la implantación de una serie de funcionalidades en producción. Quizá se necesiten realizar tareas posteriores adicionales que haya que pensarlas desde el punto de vista de arquitectura, como migraciones de datos graduales que requieran soluciones funcionando en paralelo; o quizá con abrirlas en modo pruebas en un entorno preproductivo con acceso de algunos usuarios sea suficiente.

Otra opción puede ser descartar directamente aquellos requisitos que realmente no sean relevantes para cumplir los objetivos. En muchas ocasiones, se aprovechan los proyectos para incluir funcionalidades adicionales, pero si hay poco espacio para implementarlas y no son relevantes para los objetivos principales, se puede negociar descartarlas y dejarlas para otro proyecto.

Si tanto el alcance como el presupuesto y los plazos están ajustados, sin perjudicar fuertemente a la calidad de la solución, hay que buscar detalles de la arquitectura donde podamos buscar optimizaciones. Quizá podamos utilizar productos de software libre o más baratos que cumplan con la funcionalidad, aunque sean menos completos a largo plazo. O podemos buscar sinergias con otros proyectos interesados en las mismas funcionalidades o componentes y acordar compartir presupuesto. Quizá la inversión no se esté valorando con una perspectiva temporal y un ejercicio de amortización de la inversión pueda ayudar a conseguir el presupuesto necesario.

Se da por supuesto que antes de llegar a estas valoraciones antes el arquitecto ha tratado de hacer la solución técnicamente lo más simple y eficiente posible, pero se le puede dar una vuelta adicional y quizá se pueda optimizar un poco más.

Finalmente, si queremos tener un diseño impoluto, podemos elaborar un cuestionario de calidad que deba pasar nuestro modelo de solución, que evalúe si el modelo de solución es completo, y revise los aspectos en los que los arquitectos suelen cometer errores. Este cuestionario dependerá de la metodología de diseño de arquitectura que se utilice.

Elaboración de un roadmap de arquitectura

Cuando la solución de negocio no es abordable en el alcance del proyecto o en los plazos previstos, se puede plantear elaborar un roadmap de arquitectura en el que se identifiquen diferentes etapas de implementación.

Planteo algunas recomendaciones a la hora de elaborar el roadmap de arquitectura:

• Priorizar aquellas partes que se alinean mejor con los objetivos de negocio.
• Priorizar aquellas partes que están mejor definidas y maduras.
• Tener en cuenta las dependencias técnicas entre las distintas partes para ordenar su implementación.
• Encontrar el camino óptimo entre implantar o evolucionar los habilitadores del desarrollo y avanzar en la implementación de los objetivos de negocio.
• Aplazar los hitos que dependan de mejoras tecnológicas o elementos externos, pero plantear pruebas de concepto, prototipos y pruebas de rendimiento cuanto antes para garantizar la sostenibilidad de la solución.
• La implementación de un roadmap debe suponer poca sobrecarga en el coste total. Se debe buscar minimizar la deuda técnica de las soluciones respecto a la solución objetivo.
• Si hay varias soluciones estratégicas a desarrollar en paralelo, deben ser coherentes y formar parte de una solución global objetivo.

Conclusión

Hasta aquí hemos hecho un repaso de las cuestiones planteadas al principio: qué es un modelo de solución de arquitectura, cómo usarlo, cómo elaborarlo y cómo gestionarlo en líneas generales. En próximos artículos, exploraremos con detenimiento cómo elaborar un diseño de solución de arquitectura. ¡Esperamos que os sirva!