Abordar la documentación arquitectónica desde dos perspectivas distintas y complementarias —una de alcance efímero, a nivel de proyecto, y otra de largo recorrido a nivel de empresa— es una distinción fundamental para la gestión efectiva de la arquitectura de una organización. Este enfoque bimodal es el pilar sobre el que se construye una gobernanza de arquitectura robusta y adaptable. Si te preguntas de qué documentación hablamos, cómo se articulan sinergias entre documentos y cómo queda anclada en el TOGAF, estás en el sitio adecuado. ¿Arrancamos?
Pensamiento Dicotómico
La documentación efímera a nivel de proyecto se corresponde con la disciplina de la Solution Architecture (SA). Su enfoque es táctico y se centra en el problema o necesidad planteado por negocio y el conjunto de requisitos específicos dentro del ámbito de un proyecto.
La documentación de largo recorrido a nivel de empresa se identifica con la Enterprise Architecture (EA). Esta disciplina opera a un nivel estratégico, con una visión holística de toda la organización, buscando optimizar continuamente el panorama de TI para alinear las inversiones con los objetivos de negocio.
Es crucial entender que estas dos disciplinas no son mutuamente excluyentes, sino intrínsecamente interdependientes. La EA establece el marco y las directrices, mientras que la SA las aplica y, a su vez, genera nuevos conocimientos que retroalimentan y enriquecen la EA.
Para ilustrarlo, usemos una analogía. El arquitecto de soluciones es como un «detective» que debe resolver un caso (problema de negocio) específico. Su trabajo se enfoca en investigar y diseñar una solución práctica que le lleve a «atrapar al malo». El arquitecto empresarial es el «jefe de policía», cuya responsabilidad es evaluar y optimizar continuamente el panorama de seguridad ciudadana de toda la ciudad (la organización), identificando patrones de riesgo, gestionando recursos (los activos de la EA, como distintos sistemas, microservicios, sistemas de bases de datos, etc) y estableciendo políticas y estándares para reducir la delincuencia a largo plazo.
Ambos roles son esenciales, y su colaboración es lo que permite que una organización (la ciudad y su ciudadanía) prospere.
Arquitectura de Solución: La Táctica
La SA es una disciplina táctica cuyo objetivo es el desarrollo de una solución tecnológica viable para un problema de negocio específico o un conjunto de requisitos dentro de los límites de la EA. Actúa como el puente crítico entre un requisito de negocio concreto y la tecnología necesaria para cumplirlo.
El propósito principal de la documentación que genera, el Software Architecture Document (SAD), es doble: sirve como una hoja de ruta técnica para el equipo de desarrollo y como una herramienta de comunicación, explicando cómo y por qué se construyó la solución al problema de una manera determinada.
Un SAD robusto y exhaustivo es fundamental para garantizar que una solución se entregue dentro del presupuesto, a tiempo y que resuelva el problema planteado. Proporciona una visión general de la arquitectura del producto a desarrollar, presentando su estructura, componentes y diseño desde una perspectiva de alto nivel.
Arquitectura Empresarial: La Estrategia
La EA es un marco estratégico que alinea la estrategia de negocio, los procesos, la información y la tecnología de una organización para alcanzar sus objetivos. La EA opera con una visión de alto nivel y de 360 grados de toda la organización, a diferencia de la SA, que se enfoca en un problema específico, guiando la cartera de proyectos de transformación. Para ello, se evalúa y documenta el «estado actual» de la arquitectura y se define un «estado futuro» deseado, para luego identificar las brechas y crear una hoja de ruta para la transición.
La documentación de la EA aborda las [cuatro perspectivas o pilares principales de la organización](Los pilares de la Enterprise Architecture – Binarius Cogitans).
La System Architecture Document (SyAD) es el componente documental «vivo» de la perspectiva de aplicaciones. Este documento es la fuente única de la verdad para un sistema o aplicación, proporcionando una vista consolidada de, entre otros, sus detalles clave, su valor de negocio o su estado actual y futuro. A pesar de que la SyAD se encuadra en la perspectiva de aplicaciones, incluye información vital del resto de capas del BDAT, en especial la tecnológica y la de información.
Ojo, no nos olvidemos de la seguridad que, si bien no constituye un pilar explícito, debe ser considerada en el diseño de cada capa del BDAT.
La documentación generada en un proyecto, mediante el SAD, se utiliza para crear o actualizar estas SyAD, asegurando que el conocimiento del proyecto enriquezca el repositorio de conocimiento a largo plazo de la organización.
Relación Dinámica, Sinérgica y Jerárquica entre SA y EA
La relación entre la EA y la SA es jerárquica, dinámica y sinérgica. La EA establece el marco general y las pautas, actuando como un paraguas de restricciones para toda la organización. La SA interpreta y aplica estas directrices para un proyecto específico, asegurando que la solución táctica se alinee con la visión estratégica, enfocándose en la implementación del proyecto y en los cambios necesarios en ese momento.
Una comprensión superficial podría sugerir que la relación es unidireccional, con la EA dictando directrices a la SA. Sin embargo, la dinámica es la de un circuito de retroalimentación en el que la SA enriquece a la EA y la EA es el punto de partida de toda SA. Así, la documentación de la SA se convierte en un activo valioso a nivel corporativo y sobrepasa esa barrera de lo efímero.
Este proceso se desarrolla de la siguiente manera:
- Un arquitecto de soluciones diseña una solución para un problema específico. La solución puede significar evolucionar uno o varios sistemas existentes, crear de nuevos, integrarlos, etc. Esto se hace partiendo de una situación actual, expresada principalmente en los SyAD de los sistemas involucrados en la solución. El SAD crea un «delta» o diferencial respecto de la arquitectura actual, constituyendo una arquitectura objetivo.
- Cuando el proyecto se completa, los artefactos de la SA se archivan en el repositorio de la EA y las SyAD se actualizan, y toman como arquitectura actual la que antes era objetivo.
Este proceso transforma la documentación de proyecto en un activo corporativo reutilizable, demostrando que la documentación no es una mera formalidad, sino el principal motor de la sinergia entre las dos disciplinas.
C4 y ArchiMate para la Documentación
Para mí, una de las mejores prácticas para la documentación de sistemas, como las SyAD, es combinar el modelo C4 con ArchiMate. El modelo C4, que ofrece una notación gráfica jerárquica de cuatro niveles (contexto, contenedores, componentes y código), fue diseñado para simplificar la visualización de la arquitectura de software y mejorar la comunicación. En contraste, ArchiMate es un lenguaje de modelado más formal y completo para la arquitectura empresarial que abarca las capas de negocio, aplicaciones y tecnología.
El Modelo C4 proprociona esta distinción entre diseño de alto nivel y de bajo nivel al proporcionar diferentes niveles de detalle que se alinean con ambos conceptos:
- Diseño de Alto Nivel (HLD): Los niveles 1, 2 y 3 del Modelo C4 (Diagramas de Contexto, Contenedor y Componentes) se utilizan para visualizar el HLD. Estos diagramas presentan una visión de la arquitectura con diferentes niveles de granularidad sin perderse en detalles innecesarios. El HLD es el nivel en que un arquitecto documenta.
- Diseño de Bajo Nivel (LLD): El nivel 4 del Modelo C4 (Diagrama de Código) corresponde al LLD. Este diagrama profundiza en los detalles de implementación, como las clases, interfaces y elementos de código que componen cada componente, y está diseñado para ser la guía detallada para el equipo de desarrollo.
La integración de ambos enfoques es poderosa. Los diagramas C4 pueden ser utilizados para crear representaciones claras y concisas de la arquitectura de un sistema, que son perfectas para incluir en las SyAD, ya que facilitan una comprensión rápida y detallada. La clave reside en utilizar el modelo de ArchiMate como la base formal y rigurosa sobre la cual se construyen estos diagramas C4.
Integración con TOGAF: Un Anclaje Metodológico
El marco TOGAF (The Open Group Architecture Framework) ofrece la estructura metodológica necesaria para formalizar y gestionar la documentación de SA y EA de manera cohesiva. Su Architecture Development Method (ADM) y sus conceptos de repositorio y continuum validan y operacionalizan el pensamiento bimodal.
El ADM es el corazón de TOGAF, un proceso cíclico e iterativo que guía el desarrollo y la gestión de la arquitectura. En ADM, los documentos y modelos que capturan la información arquitectónica se denominan artefactos, y el concepto del Continuo Empresarial («Enterprise Continuum») es lo que el Chief Architect necesita para organizar esos artefactos. Es un «repositorio virtual» de todos los activos de arquitectura, tanto dentro de la empresa como en la industria en general.
Este continuum se divide en dos componentes principales:
- Architecture Continuum: repositorio conceptual para los activos arquitectónicos lógicos y reutilizables, organizados desde lo genérico hasta lo específico de la organización.
- Solutions Continuum: repositorio conceptual para los activos de la implementación física y tangible, con los productos, servicios y componentes concretos que se despliegan para resolver un problema de negocio, organizados desde lo genérico hasta lo específico de la organización.
Por lo tanto, el ciclo de vida de la documentación en TOGAF se articula así: el SAD, que es parte del Solutions Continuum, se utiliza para implementar o evolucionar sistemas. Una vez que estos sistemas están en producción, la información relevante se formaliza en los SyAD involucrados, que residen en el Architecture Continuum como un activo de conocimiento a largo plazo para la organización.
ADM se divide en fases, y las que nos interesan en relación con el SAD y el SyAD son:
- Fase E: oportunidades y soluciones. Se usa el repositorio de EA y el Gap Analysis para identificar las diferencias entre el estado actual de la arquitectura y el estado futuro (objetivo) deseado a efectos de determinar los proyectos a ejecutar. Aquí se genera la primera versión del SAD para un proyecto específico.
- Fase H: gestión del cambio. Se actualiza el repositorio de EA con los nuevos artefactos con la finalización del ciclo. El SAD se convierte en un activo histórico que permite la evolución de los SyAD.
TOGAF utiliza un entregable principal llamado Architecture Definition Document (ADD), que sirve como contenedor para los artefactos de arquitectura que se crean en cada ciclo de ejecución de ADM. La relación entre el ADD, el SAD y las SyAD es:
- ADD vs SAD: El ADD es un entregable más amplio que el SAD. Mientras que el SAD se centra primordialmente en el estado futuro o de destino de una solución, actuando como un plano para su implementación, el ADD abarca los cuatro dominios de la arquitectura y describe los estados de la arquitectura de partida, de transición y objetivo. Aunque un SAD detallado puede incluir una referencia al estado actual para contextualizar el diseño, su foco principal es el resultado final. Por lo tanto, el SAD, junto con otros artefactos, se considera un componente o un documento referenciado dentro del ADD.
- ADD vs SyAD: El ADD actúa como el puente formal entre la documentación del proyecto («efímera») y el repositorio de la arquitectura empresarial («de largo recorrido»). Los artefactos contenidos en el ADD se utilizan para alimentar y mantener actualizadas las SyAD una vez que el proyecto se completa y la solución se pone en producción.
Conclusión
La distinción entre una documentación «efímera a nivel de proyecto» y una «de largo recorrido a nivel de empresa» se corresponde directamente con los conceptos de SA y EA, respectivamente. Esta conceptualización es un requisito fundamental para una gobernanza de la arquitectura.
La documentación no debe ser vista como una carga burocrática, sino como el catalizador principal para la sinergia entre la SA y la EA. Un SAD bien elaborado es el vehículo que permite que los activos elaborados en el nivel táctico se conviertan en insumos estratégicos para la empresa.
Al adoptar un enfoque estructurado, la documentación efímera se convierte en un activo de conocimiento corporativo duradero.
Para implementar y gestionar este modelo bimodal te propongo:
- Implementar una fuente única de verdad: Designar un repositorio de EA como el lugar centralizado para toda la documentación.
- Formalizar el proceso de gobernanza: Establecer un proceso claro -puedes inspirarte en ADM-, para que la documentación de SA se revise, se extraigan sus activos y se utilice para actualizar y enriquecer el repositorio de EA.
- Fomentar la colaboración activa: Promover una cultura donde los arquitectos de soluciones y los arquitectos empresariales trabajen de la mano. La documentación debe ser su lenguaje común para asegurar que la ejecución táctica de los proyectos esté siempre alineada con la estrategia corporativa, y que los hallazgos de los proyectos informen la evolución del marco empresarial.