Los 5 componentes clave de TOGAF.

En nuestra publicación anterior exploramos los fundamentos de TOGAF y cómo este marco puede ser una guía sistemática para construir una arquitectura empresarial. En este post vamos a profundizar en algunos de los conceptos clave que forman el núcleo de TOGAF, analizaremos en detalle el Repositorio de Arquitectura, el Enterprise Continuum, así como los entregables y artefactos más importantes que se generan a lo largo del proceso de definición e implementación de una Arquitectura Empresarial con este framework.

Estos elementos no solo son esenciales para la implementación efectiva del framework, sino que también son cruciales para asegurar la alineación entre la visión estratégica y las soluciones tecnológicas en una organización.

Deliverables (entregables)

Cuando trabajas con TOGAF, los entregables son parte de los hitos que marcan el progreso de un proyecto de arquitectura.

¿Qué son? Son los documentos y productos que se generan durante el desarrollo de la arquitectura y sirven para transmitir claramente la información a todas las partes involucradas. Tanto los documentos como los productos son revisados formalmente y firmados contractualmente por los stakeholders.

Estos entregables están ligados a las fases específicas del método de desarrollo de arquitectura (ADM) y aquí te presentamos algunos de los entregables más comunes:

• Architecture Vision: Este es el punto de partida. Durante la fase de visión de la arquitectura se definen las metas y objetivos principales del proyecto y los factores clave que lo impulsan.
• Business Architecture Document. Creado en la fase de business architecture, este documento detalla la estrategia de negocio de la organización, los procesos clave y la estructura organizativa.
• Data Architecture Document. Durante la fase de arquitecturas de sistemas de información, este entregable define los activos de datos, los recursos de gestión y los modelos de datos tanto lógicos como físicos.
• Application Architecture Document. También parte de la fase de arquitecturas de sistemas de información, aquí se describe la estructura de las aplicaciones, incluyendo sus componentes, interfaces y cómo se relacionan entre sí.
• Technology Architecture Document. En la fase de arquitectura tecnológica, este entregable especifica la infraestructura tecnológica, los estándares y la configuración de hardware y software que se utilizarán.
• Implementation and Migration Plan. Durante la fase de oportunidades y soluciones se elabora un plan para guiar la transición desde el estado actual hacia la arquitectura deseada mediante hitos intermedios y arquitecturas de transición.
• Architecture Roadmap. Documento de alto nivel creado en la fase de oportunidades y soluciones que proporciona un calendario para ejecutar los cambios de arquitectura.. Es la guía para llevar el plan a la acción.
• Architecture Contract. Elaborado en la fase de gobierno de la implementación, este entregable establece los acuerdos y expectativas entre los equipos de desarrollo de arquitectura y los equipos de implementación. Es como el acuerdo de "reglas del juego" para asegurar que todos estén alineados.
• Architecture Repository. Donde se guardan y gestionan todos los artefactos arquitectónicos, bloques de construcción y otra información crítica, es el centro de control de todo lo relacionado con la arquitectura. Puede considerarse como una base de datos analítica que permite representar y analizar la información sobre la arquitectura

Estos entregables no solo organizan el proceso, sino que también aseguran que todas las partes involucradas estén en la misma página a lo largo del desarrollo de la arquitectura. Además, es importante recalcar dos aspectos:

• La lista anterior refleja los entregables más importantes, pero la selección de los mismos puede variar según las necesidades específicas de la organización y el proyecto.
• Cada entregable puede estar conformado por varios artefactos, veremos a continuación qué son y qué aportan.

Artifacts (artefactos)

¿Qué son? Son los productos arquitectónicos que describen un aspecto específico de la arquitectura. Algunos de los artefactos más comunes son:

• Modelos de arquitectura. Desde procesos de negocio hasta modelos de tecnología, estos diagramas visualizan los diferentes componentes que forman parte de una arquitectura sólida.
• Diagramas. Ya sea un diagrama de flujo de datos, de red o de componentes, estos esquemas nos ayudan a entender cómo se interconectan los elementos arquitectónicos.
• Matrices. Herramientas que muestran las relaciones y dependencias entre distintos componentes.
• Escenarios de negocio. Historias detalladas que explican cómo la arquitectura apoya procesos y objetivos empresariales específicos.
• Casos de uso. Representaciones de cómo los usuarios interactúan con el sistema y cómo este responde a sus necesidades.
• Documentos de requisitos. Los lineamientos esenciales que aseguran que la arquitectura cumpla con todas las expectativas y restricciones. Aunque, operativamente hablando, lo habitual es que no se representen en documentos sino herramientas de gestión como Jira.
• Normas y directrices. La brújula que orienta el diseño hacia las mejores prácticas y asegura la coherencia y calidad del proyecto.

Building blocks

¿Qué son? Los componentes básicos que forman la arquitectura empresarial. Son las piezas fundamentales que, al combinarse, crean sistemas o soluciones más grandes y complejas. Estos bloques pueden incluir desde software y hardware hasta estructuras de datos. En TOGAF, los bloques de construcción se dividen en dos categorías clave:

1. Architecture Building Blocks (ABBs). Estos son los componentes reutilizables de tu arquitectura. Representan capacidades necesarias para apoyar la estructura general de la organización como procesos, datos y aplicaciones. Son como los ingredientes básicos que necesitas para cocinar tu receta de arquitectura.
2. Solution Building Blocks (SBBs). Estos bloques son utilizados para construir soluciones específicas. Se desarrollan a partir de los ABB y representan las soluciones específicas que implementan una capacidad, es decir, el hardware, software, servicios o productos que se necesitan para disponibilizar una capacidad concreta.

En TOGAF, el Continuum Empresarial y el Repositorio de Arquitectura son dos conceptos importantes que juegan un papel significativo en el desarrollo y la gestión de las arquitecturas empresariales. Veamos a continuación lo que son.

Enterprise Continuum

¿Qué es? La forma de clasificar y organizar los activos y artefactos arquitectónicos. Se trata de un mapa que te ayuda a ver dónde encajan en el panorama general y cómo evolucionan con el tiempo las piezas dentro de la arquitectura.

Abarca desde principios fundacionales hasta implementaciones específicas, ofreciendo un espectro que se alinea con las necesidades cambiantes de la empresa.
El Enterprise Continuum no solo ayuda a organizar y clasificar los activos arquitectónicos, sino que también facilita la reutilización y asegura que las soluciones se alineen con los estándares de la industria y las metas de la organización.

Asociado a él, introduce dos conceptos esenciales que actúan como marco de referencia: Architecture Continuum y Solutions Continuum. Estos continuos proporcionan un enfoque estructurado para el desarrollo y la implementación de activos arquitectónicos, ofreciendo una hoja de ruta para las organizaciones que buscan claridad y eficiencia en su entorno de IT.

Architecture Continuum

¿Qué es? Una forma coherente para categorizar los activos arquitectónicos a lo largo del tiempo. Representa la evolución de dichos activos categorizando las soluciones desde un nivel genérico, pasando por estándares de la industria, hasta llegar a soluciones específicas para una compañía en concreto.

El Continuo de Arquitectura es una herramienta útil para descubrir elementos comunes, eliminar redundancias innecesarias y tener una forma sistematizada para estructurar los Building Block de Arquitectura (ABBs). Las categorías que representan esta estructuración son:

• Foundation architectures: soluciones genéricas o estándar que sirven de base para el desarrollo de la arquitectura.
• Common systems architectures: soluciones que siguen siendo relativamente genéricas pero que pueden adaptarse en cierta medida a las necesidades específicas de una organización.
• Industry architectures: soluciones que se ajustan a las normas y mejores prácticas específicas del sector.
• Arquitecturas específicas de la organización: soluciones personalizadas para una compañía y que reflejan no solo los requisitos si no la estrategia propia de la empresa.

Solution Continuum

¿Qué es? Una forma coherente de describir y comprender la implementación de los activos definidos en el Continuo de Arquitectura. Es decir, es llevar los planos y convertirlos en realidades tangibles que materializan la visión de la arquitectura.

Este continuo define lo que está disponible en el entorno organizativo como Solutions Building Blocks (SBB) reutilizables, los cuales son el resultado de acuerdos entre entre todas las partes involucradas.

Juntos, estos continuos (Architecture Continuum y Solution Continuum) proporcionan un enfoque holístico de la arquitectura, guiando a las organizaciones a través del intrincado proceso de conceptualización, evaluación e implementación de la arquitectura empresarial.

A continuación se detalla un ejemplo práctico muy sencillo que muestra cómo ambos conceptos se aplican en un proyecto de modernización o transformación.

Contexto del ejemplo: una empresa de telecomunicaciones decide modernizar su infraestructura tecnológica para mejorar la experiencia del cliente, aumentar la eficiencia operativa y reducir costos. Este proyecto abarca la implementación de un nuevo sistema de gestión de relaciones con clientes (CRM), la migración y adopción de la nube y la automatización de procesos.

Architecture Continuum

Como se ha explicado antes, el Architecture Continuum representa una progresión de arquitecturas desde abstracciones genéricas hasta soluciones específicas detalladas para la organización. Aquí se incluyen cuatro niveles: fundaciones, arquitecturas comunes, arquitecturas de sistemas y arquitecturas de la organización.

1. Fundaciones (foundations)

• Ejemplo: se adoptan estándares tecnológicos como TCP/IP para redes y HTTPS para comunicaciones seguras, así como marcos de trabajo como ITIL para la gestión de servicios de TI. También se consideran principios generales de arquitectura, como la modularidad y la interoperabilidad.

2. Arquitecturas comunes (common systems architectures)

• Ejemplo: se selecciona un conjunto común de servicios empresariales que pueden ser utilizados en diferentes divisiones de la empresa, como servicios de autenticación unificada, bases de datos comunes, y plataformas de integración. Estas arquitecturas son comunes para toda la organización y se adaptan a los distintos sistemas, también conocidos como patrones de arquitectura.

3. Arquitecturas de sistemas (industry architectures)

• Ejemplo: la empresa de telecomunicaciones adopta una arquitectura específica del sector, como TM Forum Framework, que define procesos y arquitecturas comunes en la industria de telecomunicaciones. Esto puede incluir modelos de datos específicos para la facturación y la gestión de clientes.

4. Arquitecturas de la organización (organization architectures)

• Se trata de las arquitecturas de referencia de la compañía. Ejemplo: la empresa desarrolla una arquitectura específica para su sistema de CRM, ajustada a sus procesos de negocio únicos y a las necesidades de sus clientes. Esto podría incluir la personalización de módulos de CRM para ajustarse a las estrategias de marketing y ventas de la empresa.

Solutions Continuum

Como se ha indicado anteriormente, el Solutions Continuum se refiere a la implementación práctica de las arquitecturas, comenzando desde soluciones genéricas hasta soluciones completamente específicas y personalizadas para la organización. Veamos un ejemplo sencillo:

1. Soluciones genéricas (foundation solutions)

• Ejemplo: se selecciona un conjunto de herramientas y plataformas genéricas, como Amazon Web Services (AWS) para la nube, Microsoft Dynamics para CRM, y plataformas de desarrollo como Java o .NET.

2. Soluciones comunes (common systems solutions)

• Ejemplo: implementación de servicios comunes en toda la organización, como un sistema unificado de autenticación (SSO), una plataforma de integración basada en API, y servicios de bases de datos en la nube. Estas soluciones son configuradas para cumplir con las necesidades básicas de toda la organización.

3. Soluciones de la industria (industry solutions)

• Ejemplo: despliegue de un módulo específico del CRM que se adapta a las mejores prácticas de la industria de telecomunicaciones, como la gestión de servicios y clientes. Esto podría incluir la integración con sistemas de facturación específicos del sector y servicios de red.

4. Soluciones de la organización (organization-specific solutions)

• Ejemplo: personalización del CRM para incluir flujos de trabajo específicos, integraciones con sistemas legados, y dashboards personalizados para la alta dirección. Esta solución final está completamente adaptada a las necesidades y estrategias únicas de la empresa.

Repositorio de arquitectura

El repositorio de arquitectura es el gran archivo central de los activos y datos arquitectónicos, es decir, la fuente de la verdad que te ayuda a mantener todo en orden. Es un componente muy relevante ya que, con el tiempo, los artefactos que define TOGAF y los numerosos entregables se convierten en recursos que deben gestionarse y controlarse, especialmente con vistas a su accesibilidad y reutilización.

Las áreas o secciones más importantes que estructuran el repositorio de arquitectura son los siguientes:

• Architecture metamodel
  Es el esquema maestro de la arquitectura, brindando una estructura clara de modelar todos los aspectos de la misma.
• Architecture capability
  Define los parámetros, estructuras y procesos que soportan el gobierno del repositorio de arquitectura asegurando que el repositorio esté bien administrado y sea eficiente
• Architecture landscape
  Este componente te da una vista completa de los building blocks actuales de una compañía. Te muestra qué tienes y cómo está organizado en diferentes niveles de detalle y desde diferentes puntos de vista, aplicaciones o sistemas.
• Standards Information Base (SIB)
  Captura los estándares con los que deben cumplir las nuevas arquitecturas, es decir, contiene todas las normas y directrices. Incluye estándares del sector, productos seleccionados, y servicios ya implementados. Es la guía para cumplir con las mejores prácticas.
• Reference library
  Proporciona directrices, plantillas, patrones y otras formas de material de referencia que pueden aprovecharse para acelerar la creación de nuevas arquitecturas para la empresa. Es la caja de herramientas para los arquitectos.
• Governance log
  Proporciona un registro de la actividad de gobernanza en toda la empresa, es decir una bitácora. Contiene todas las actividades de gobernanza relacionadas con el desarrollo y gestión de la arquitectura. Desde decisiones y aprobaciones hasta cambios a lo largo del ciclo de vida de la arquitectura, aquí está todo documentado. Es la bitácora de referencia para ver el registro de todas las decisiones y cambios.
• Requirements repository
  Proporciona una vista de todos los requisitos de arquitectura que han sido acordados durante todo el proceso.

Las relaciones entre estas áreas del repositorio de arquitectura son las siguientes:

Es habitual que en la práctica ninguna plataforma implementa de manera completa y eficiente todo el repositorio, es habitual emplear varias herramientas especializadas para cada parte del repositorio.

Relación entre todos los componentes

Todos los componentes que hemos descrito se relacionan entre sí y dichas relaciones pueden verse gráficamente en el siguiente diagrama:

Un ejemplo sería el siguiente:

El documento de definición de arquitectura es un entregable que documenta una descripción de arquitectura. Este documento contendrá una serie de artefactos complementarios que son vistas de los building blocks relevantes para la arquitectura.

Llevándolo a la práctica, se puede crear un diagrama de flujo de procesos (artefacto) para describir el proceso de gestión de llamadas de (building block). Este artefacto también puede describir otros componentes básicos como los actores implicados en el proceso (por ejemplo, un representante de atención al cliente).

Relación entre todos los componentes

En esta serie de post hemos querido hacer una inmersión rápida en el framework y entender sus conceptos básicos y como conclusión nos gustaría resaltar lo siguiente:

• TOGAF es un framework para implementar una arquitectura empresarial, pero no el único.
• Permite alinear la arquitectura empresarial con los objetivos estratégicos de la empresa.
• Proporciona una metodología integral que facilita la planificación, diseño y gestión de arquitecturas complejas, garantizando que todos los componentes de la empresa trabajen en armonía.
• Su capacidad para adaptarse a diversos contextos y necesidades específicas hace que su implementación no solo mejore la eficiencia operativa, sino que también impulse la innovación y la agilidad.
• Los componentes no solo ayudan a planificar y diseñar, sino que también facilitan la comunicación y la implementación exitosa de tu arquitectura empresarial.

Si quieres profundizar o saber más, te dejamos a mano la documentación oficial de su última versión.