Diseño de soluciones de arquitectura: anatomía de un modelo de solución.

En el artículo anterior proporcionamos una visión global de lo que es un modelo de solución de arquitectura y cómo gestionarlo. En este artículo vamos a entrar en el contenido que debería tener para ser lo más completo y práctico posible.

Dominios de TOGAF

Desde el punto de vista tipo TOGAF una arquitectura se estructura en diferentes dominios como podemos ver en el gráfico:

La arquitectura se puede ver desde diferentes puntos de vista, que son los diferentes dominios de la solución. Para mí no son capas como tales superpuestas unas encima de otras, sino que son diferentes ángulos desde los que puedes abordar y valorar una misma solución.

• Contexto y estrategia. Permite definir el entorno, situación de partida, objetivos, dependencias clave, proyectos relacionados y enfoque estratégico, si está planteado inicialmente, ya sea por la dirección o un plan de arquitectura empresarial.
• Arquitectura de negocio. Define la arquitectura a nivel de capacidades de negocio, organización, procesos de negocio, funciones de negocio más operativas y elementos técnicos que no son de TI.
• Arquitectura de información. Define la arquitectura de datos, tanto en su ciclo de vida y gestión dinámica (interfaces de usuario, servicios, eventos…) como en su almacenamiento y modelo estático (ficheros, bases de datos…). Desde un punto de vista de arquitectura, el nivel de detalle suele ser intermedio, a nivel de entidades de datos y atributos principales, sin entrar en detalles técnicos del diseño de datos.
• Arquitectura de aplicaciones. Define los programas responsables de implementar las funcionalidades y procesos de información. Como en el caso anterior, se queda en un nivel de detalle intermedio, a nivel de pantallas de usuario, funcionalidades y elementos de procesamiento, tales como servicios, transacciones o programas de otra naturaleza.
• Arquitectura tecnológica. Define las soluciones técnicas con las que implementar las aplicaciones, las tecnologías, servicios y productos a utilizar, los elementos de despliegue y la infraestructura necesaria para su funcionamiento.

Modelo 4+1

Otra forma de estructurar el diseño de arquitectura es el Modelo 4+1 de vistas de arquitectura.

En este caso las vistas suelen describir el sistema desde el punto de vista de diferentes interesados, tales como usuarios finales, desarrolladores o directores de proyecto.

• Escenarios: define los casos de uso de negocio, o escenarios. Describen las secuencias de interacciones entre objetos, y entre procesos desde el punto de vista de los usuarios.
• Vista lógica: define las funcionalidades de la solución y la estructura y relaciones de los elementos que las implementan.
• Vista de proceso: trata los aspectos dinámicos del sistema, explicando los elementos de procesamiento y cómo se comunican para implementar los procesos de negocio y los procesos de información de las aplicaciones, pensando en el comportamiento del sistema en tiempo de ejecución.
• Vista de desarrollo: está enfocada en la definición y administración de los artefactos de software pensando desde la perspectiva del programador.
• Vista física: define la topología de componentes de software en la capa física, así como las conexiones físicas entre estos componentes. Esta vista también se conoce como vista de despliegue. Describe el sistema desde el punto de vista de un ingeniero de sistemas.

Estructura del diseño de arquitectura

Basándome en el modelo 4+1, la integración con las vistas de AE y mi propia experiencia propongo la siguiente estructura del modelo de solución, pensando no solo en cómo estructurar técnicamente la solución, sino en la gestión de la solución.

1. Propósito/Objetivos

Esta vista refleja las necesidades de negocio que debemos resolver, los objetivos a conseguir con la solución y una descripción de alto nivel del alcance del problema. Encaja con la vista de Contexto y estrategia de TOGAF.

2. Arquitectura actual

Esta sección documenta la arquitectura actual para el proceso o aplicaciones objeto de la solución. Servirá de referencia de la que partir, ya sea para realizar mejoras o para hacer rediseños de la arquitectura más disruptivos.
No es tanto una vista como la documentación existente que pueda ser relevante. No tiene por qué exponerse en el modelo de solución si se puede enlazar a otra documentación o al repositorio de arquitectura.

3. Casos de uso

Esta vista sería la descripción de los casos de uso de arquitectura o procesos de negocio / operativos según interese, describiendo el funcionamiento que esperamos tener de la solución.

Como consideración, el nivel de detalle de los casos de uso para la arquitectura es más alto que los casos de uso que se suelen utilizar para el diseño de software, quedándose a nivel de funcionalidades de las aplicaciones y las integraciones entre aplicaciones, sin entrar en la lógica interna de las aplicaciones más allá de lo relevante para la arquitectura.

Los elementos que deberíamos analizar en esta vista para cada caso de uso son los siguientes:

• Descripción resumida.
• Usuarios / Roles involucrados.
• Eventos de ejecución del caso de uso (acción de usuario, API, programada…).
  -. Diagramas de secuencia describiendo cada paso del caso de uso.
• Volumetrías de negocio.
• Requisitos no funcionales asociados al caso de uso.

Esta vista agrupa parte de las vistas de arquitectura de negocio y de información de TOGAF y coincide con las vistas de escenarios y procesos del modelo 4+1.

4. Arquitectura funcional

Esta vista describe la estructura lógica de aplicaciones, funcionalidades e integraciones, planteando cuáles son las aplicaciones responsables de cada funcionalidad y cómo deberían comunicarse para implementar los pasos de los casos de uso descritos anteriormente.

El contenido de esta vista sería el siguiente:

• Aplicaciones y funcionalidades involucradas.
• Usuarios y roles asociados a las funcionalidades de las aplicaciones.
• Repositorios y bases de datos, detallando las principales entidades de datos o campos importantes para la solución.
• Integración entre aplicaciones, indicando el tipo de comunicación (síncrona, asíncrona, ficheros…) e interfaces.

Esta vista agrupa las vistas de arquitectura de aplicación con la estructura estática de la vista de información de TOGAF y coincide con la vista lógica del modelo 4+1.

5. Arquitectura técnica

Esta vista sería similar a la funcional, pero con la perspectiva de asignar las funcionalidades a los componentes técnicos de las aplicaciones o artefactos, incorporando detalle tecnológico para el desarrollo de los componentes y las integraciones, y su despliegue en los servidores o dispositivos

El contenido sería el siguiente:

• Aplicaciones estructuradas por componentes técnicos.
• Tecnologías de los componentes.
• Clasificación de cada tipo de componente: Interfaces de usuario, servicios, componentes de integración, de almacenamiento, procesos batch…
• Requisitos de los componentes: Volumen de usuarios potenciales y concurrentes, disponibilidad, rendimiento.
• Software base para los componentes o productos de software.
• Formato de los datos y protocolos de comunicación de las integraciones.
• Autenticación y autorización de las integraciones.
• Volumetría y tamaños de los datos de las integraciones.
• Planificación batch
• Catalogación de servicios, eventos y ficheros.
• Impacto en cada uno de los elementos descritos.

Esta vista describe parte de las vistas de aplicaciones y tecnológica de TOGAF y el detalle más técnico de la vista lógica y parte de la vista de desarrollo del modelo 4+1. Incluye también las funcionalidades a implementar por cada componente, para trazar las vistas técnicas y funcional.

6. Infraestructura

En esta vista describimos los elementos de infraestructura que necesitamos y su configuración en cada entorno para poder desplegar los componentes. El nivel de detalle de configuración es solamente el necesario para asegurar el cumplimiento de los requisitos no funcionales, sin entrar en especificar cómo se realiza.

La información necesaria sería la siguiente:

• Recursos hardware y software para cada entorno.
• Configuración de los recursos en cada entorno (opcional)
• Requisitos de datos: Tamaño de almacenamiento, retención de datos, crecimiento esperado.
• Requisitos de continuidad de negocio: balanceo, clustering, disaster recovery.
• Envíos de ficheros.
• Comunicaciones entre componentes y configuración de red.
• Requisitos de seguridad, en arquitectura de ejecución y arquitectura de desarrollo.
• Requisitos de logs y alertas,
• Monitorización de la infraestructura y alertas.
• Esta vista sería otra parte de la vista tecnológica de TOGAF y coincidiría con la vista física del modelo 4+1.

7. Costes

En este capítulo se puede plantear una estimación de coste de la infraestructura de la solución o de las alternativas si es el caso. Esta estimación servirá para analizar la viabilidad económica del proyecto o para la toma de decisión entre las posibles alternativas.

8. Aspectos clave del diseño

Este capítulo ya no sería una vista de la arquitectura, pero es importante para gestionar adecuadamente el modelo de solución, ya que reflejaremos todas las cuestiones que explican y justifican cómo se ha llegado a cerrar la solución, y proporciona contexto importante que todos los interesados deben conocer.

No tendría una estructura fija, pero algunos ejemplos de información relevante son:

• Información sobre las tomas de decisiones realizadas durante el diseño y por qué o quién se tomaron. Generalmente, se incluyen aquí las comparativas de las diferentes opciones que se han valorado.
• Dudas y puntos pendientes de resolver el diseño, para gestionarlos fácilmente con los responsables.
• Riesgos identificados en la solución.
• Descargas de responsabilidades cuando se han asumido decisiones que vienen impuestas por interesados ajenos.
• El roadmap de arquitectura, cuando se planifican varias fases de desarrollo.
• Las deudas técnicas que se han generado.
• Aclaraciones o consideraciones para ayudar a los equipos de desarrollo.

De primeras parece mucha información y que hacer un diseño de arquitectura es complejo. Efectivamente, es complejo porque son muchos los aspectos a tener en cuenta para hacer bien un diseño de arquitectura. Pero hay que tratar que la complejidad esté en el problema y la solución, no en la elaboración del documento de diseño. El contenido debe ser el justo y necesario para que sea útil, evitando rellenar aquella información que no sea relevante. No es obligatorio rellenarlo todo y queda a criterio del arquitecto qué información es necesaria.

Vistas y nivel de abstracción

En el lenguaje coloquial suele haber bastante confusión cuando se habla de modelar a “alto nivel” y a “bajo nivel”. A veces se relaciona el alto nivel con la definición más funcional o de negocio y el bajo nivel con los detalles de implementación o infraestructura, pero creo que es más apropiado relacionarlo con el nivel de abstracción, describiendo algo de “alto nivel” como muy abstracto y algo de “bajo nivel” como más específico.

De esta manera, podemos utilizar ambas dimensiones para hacer vistas mucho más específicas para el objetivo que persiguen, ajustando la vista o dominio que más nos interese con el nivel de abstracción que aporte más valor.

Un modelo conocido para trabajar con diferentes niveles de abstracción es el modelo C4, que establece 4 niveles de abstracción.

Veamos qué contiene cada nivel:

• Nivel 1 (Contexto). Representa en la vista el sistema objeto del modelo como una caja negra y las relaciones que tiene con su contexto (usuarios y otros sistemas).
• Nivel 2 (Contenedores). Representa las aplicaciones y almacenes de datos que componen el sistema y sus relaciones.
• Nivel 3 (Componentes). Representa los componentes de cada contenedor y sus relaciones con otros componentes o contenedores al nivel de artefactos desplegables.
• Nivel 4 (Código). Describe la arquitectura interna de los componentes con elementos equivalentes al código fuente a desarrollar, utilizando los lenguajes comunes de diseño de software (UML, Entidad-relación…).

El modelo C4 nos permite entender bien el concepto del nivel de abstracción, como una dimensión diferente a las vistas planteadas para el diseño de arquitectura. Pero tal como está descrito está muy orientado a la capa de aplicación, y necesitamos poder aplicar este mismo concepto a otros dominios como el de negocio o infraestructura.

Un diseño de solución va a necesitar modelar diferentes vistas, cada una con un objetivo diferente. Además, en otros ámbitos como en procesos de arquitectura empresarial o en el mantenimiento de los datos o infraestructuras veríamos que necesitamos vistas diferentes a las utilizadas en el diseño de arquitectura para proyectos.

Cuando tratamos de hacer modelos útiles para los equipos nos encontramos con una gran complejidad a la hora de gestionarlos porque cada equipo en cada momento necesita poner el foco en información diferente. Es muy difícil hacer modelos generales que sirvan para muchos interesados. Suelen ser muy complejos si tratamos de que sean completos, o poco reutilizables si son minimalistas.

Lo más adecuado es acordar y fijar con cada equipo cuáles son las vistas y niveles de abstracción que requieren en cada momento del ciclo de vida de los proyectos y de las aplicaciones. De esta manera evitaremos que nos pidan cada vez algo diferente según la necesidad y tengamos que remodelar la documentación existente o mantener actualizado un volumen de modelos desordenados.

Para aclarar con los equipos cómo deben ser las vistas que les interesan me baso en la siguiente matriz, que determina los elementos a representar en cada dominio y nivel de abstracción.

Pero las vistas no tienen por qué restringirse a una sola de estas casillas para representar sus elementos. Es solo una forma de visualizar y poner en común qué es “alto nivel” y qué es “bajo nivel”, no solo en el dominio de aplicaciones, sino en todos los dominios de la arquitectura.

Dentro de esta matriz elegimos qué elementos nos interesa representar en el diseño y hacemos ejemplos para confirmar que efectivamente es lo que queremos.

Por ejemplo, para los diseños a nivel de infraestructura podemos determinar dos vistas: una de más alto nivel para visualizar el alcance del proyecto en el dominio de infraestructura y explicar el proyecto (1), que incluye los elementos de nivel muy alto y también las tecnologías de ejecución del software del nivel alto tecnológico, y otra más detallada para los equipos que gestionan la infraestructura (2) que agrupa elementos de nivel alto y medio tecnológico.

Que podrían representarse con diagramas como estos:

Esta problemática suele presentarse a la hora de mantener un repositorio de arquitectura que dé soporte a todo el gobierno de TI, pero parte del problema son los diseños de solución de arquitectura de los proyectos. La idea es utilizar este marco para definir las vistas del diseño de solución de arquitectura de forma acordada con los interesados de la empresa.

Conclusión

Con lo expuesto anteriormente, podemos tener una idea de alto nivel de los tipos de modelos que necesitamos para desarrollar un diseño de arquitectura de soluciones completo y la información que necesitamos obtener o definir para cada uno de ellos, que podemos modular con el framework propuesto.

En los próximos artículos entraremos en el detalle de una propuesta de contenido para un diseño de solución de arquitectura para un proyecto, entrando en cada vista y cada elemento.