Arquitectura empresarial y TOGAF: el ADM, los dominios y la gobernanza

La arquitectura empresarial es la práctica de describir las capacidades de negocio, la información, las aplicaciones y la tecnología de una organización como un único conjunto conectado, para que las decisiones de inversión se tomen conociendo sus consecuencias. No es una versión ampliada de la arquitectura de software. Un arquitecto de soluciones responde a «¿cómo deberíamos construir este sistema?»; un arquitecto empresarial responde a «¿debería existir este sistema, qué duplicaría, qué sustituiría y cómo nos acerca a donde el negocio necesita estar dentro de tres años?».

La práctica se justifica en organizaciones lo bastante grandes como para que nadie pueda tener todo el panorama en la cabeza: donde los mismos datos de cliente viven en nueve sistemas, donde dos divisiones están comprando por separado la misma capacidad y donde la decisión de retirar una plataforma tiene consecuencias que nadie es capaz de enumerar del todo. Fracasa, y sale cara, cuando se convierte en un ejercicio de documentación desconectado de las decisiones que se están tomando. TOGAF es el framework más adoptado para este trabajo y, como cualquier framework, es una fuente de estructura de la que tomar lo que sirva, no un proceso que haya que seguir al pie de la letra.

Para qué sirve la arquitectura empresarial

Quitando el vocabulario, los entregables sirven a un puñado de decisiones recurrentes.

• Racionalización del portfolio. ¿Cuáles de nuestras 400 aplicaciones hacen lo mismo, cuáles ya no tienen soporte, cuáles cuestan más de lo que aportan? Responder a esto exige un portfolio de aplicaciones con responsables, estado de ciclo de vida, coste y las capacidades que soporta cada una.
• Priorización de inversiones. Dada una estrategia —entrar en un nuevo mercado, reducir el coste de servicio, cumplir una nueva normativa—, ¿qué capacidades deben mejorar y qué sistemas obliga eso a cambiar?
• Análisis de impacto. Si retiramos esta plataforma, ¿qué se rompe? ¿Qué interfaces, qué procesos, qué informes?
• Estándares y reutilización. Qué tecnologías están aprobadas, cuáles se toleran y cuáles se están abandonando, para que los equipos elijan de forma deliberada y no por preferencia.
• Coherencia en medio del cambio. Veinte programas en marcha a la vez, cada uno sensato por separado, que en conjunto producen tres nuevos patrones de integración y un cuarto maestro de clientes.

Fíjate en que cada una es una pregunta que alguien con presupuesto se está haciendo de verdad. Los artefactos de arquitectura que no responden a ninguna pregunta así son coste sin beneficio, y la forma más rápida de juzgar una práctica de arquitectura empresarial es preguntar qué decisiones ha cambiado en el último año.

Los cuatro dominios de arquitectura

TOGAF organiza la descripción en cuatro dominios, a menudo abreviados como BDAT (Business, Data, Application, Technology). Son vistas de una única arquitectura y no arquitecturas separadas, y el valor está en la trazabilidad entre ellas.

La trazabilidad es lo que hace útil el modelo. Cuando una capacidad falla, puedes ver qué aplicaciones la soportan; cuando se retira una aplicación, puedes ver qué capacidades y procesos se ven afectados y qué entidades de datos necesitan un nuevo hogar. Un modelo con cuatro dominios dibujados de maravilla y sin relaciones entre ellos no puede responder a ninguna de las dos preguntas.

ArchiMate es el lenguaje de modelado que lo acompaña, organizado en capas que coinciden con los dominios, y merece la pena usarlo siempre que modeles, porque da a las relaciones un significado definido —realización, servicio, asignación— en lugar de flechas cuyo significado depende de quién las dibujó.

El ciclo ADM

El Architecture Development Method es el núcleo de TOGAF: un ciclo iterativo para producir y gobernar la arquitectura, con la gestión de requisitos en el centro alimentando todas las fases.

La fase preliminar establece la propia capacidad de arquitectura: qué partes de la organización entran en el alcance, qué frameworks y herramientas se usan, los principios que guiarán las decisiones y cómo funcionará la gobernanza. Los principios de arquitectura son el resultado más duradero de esta fase, y los buenos tienen dientes: un principio que dice «los datos se capturan una sola vez, en su origen» zanja discusiones durante años, mientras que «valoramos la calidad» no zanja nada.

Fase A — Visión de la arquitectura acota un ciclo. Identifica a las partes interesadas y sus preocupaciones, esboza el objetivo a alto nivel, evalúa el valor de negocio y el riesgo, y produce el Statement of Architecture Work que autoriza el esfuerzo. El resultado crítico es el acuerdo sobre el alcance, porque un alcance sin límites es lo que convierte un encargo de arquitectura empresarial en un estudio de dieciocho meses.

Fase B — Arquitectura de negocio describe la situación actual y la objetivo de las capacidades, los flujos de valor y los procesos, y realiza un análisis de brechas entre ambas. Hacerlo bien es lo que impide que la arquitectura se convierta en un plan tecnológico con etiqueta de negocio.

Fase C — Arquitecturas de sistemas de información cubre datos y aplicaciones a la vez, de nuevo con situación actual, objetivo y brechas. Los hallazgos recurrentes son la titularidad de datos maestros duplicada, aplicaciones que soportan capacidades para las que nunca se diseñaron, un catálogo de interfaces que todavía no expone ninguna plataforma de API management e integraciones punto a punto, el problema que SOA y el ESB se propusieron resolver.

Fase D — Arquitectura tecnológica define las plataformas y la infraestructura que materializan la arquitectura de aplicaciones, y los estándares que acotan las decisiones futuras.

Fase E — Oportunidades y soluciones convierte las brechas de B, C y D en paquetes de trabajo, los agrupa en proyectos candidatos e identifica arquitecturas de transición: los estados intermedios por los que pasa la empresa, cada uno de los cuales debe ser un lugar viable en el que quedarse un tiempo, ya que ninguna organización pasa de la situación actual a la objetivo de un solo paso.

Fase F — Planificación de la migración ordena y presupuesta esos paquetes de trabajo en un plan de implantación y migración, negociado con las funciones de portfolio y finanzas en lugar de redactado de forma aislada.

Fase G — Gobernanza de la implantación conecta la arquitectura con la entrega. Los proyectos se revisan frente al objetivo, las desviaciones se registran como excepciones explícitas con responsable y fecha de caducidad, y los arquitectos siguen implicados en lugar de entregar un documento y desaparecer.

Fase H — Gestión del cambio de arquitectura decide qué hacer cuando la realidad cambia: un cambio pequeño se absorbe, uno significativo desencadena un nuevo ciclo. Aquí es también donde se mantiene actualizado el repositorio.

La gestión de requisitos está en el centro, recibiendo y distribuyendo requisitos durante todo el ciclo, porque los requisitos no llegan una sola vez al principio.

Building blocks y repositorio

Los Architecture Building Blocks (ABB) describen la capacidad necesaria en términos independientes de la implementación: «gestión de identidades y accesos que proporciona autenticación, autorización y federación para usuarios internos y de socios». Los Solution Building Blocks (SBB) son las piezas concretas que los materializan: un producto concreto, un servicio concreto, un componente interno concreto. Mantener ambos separados es lo que permite sustituir un producto sin redibujar la arquitectura, y es el mismo instinto que programar contra una interfaz.

El Architecture Content Framework define cuáles son los resultados y cómo se relacionan. Conviene conocer sus tres niveles, porque aclaran buena parte de lo que se dice a la ligera sobre los «entregables»:

• Los entregables (deliverables) son resultados contractuales, revisados y aprobados formalmente: el Architecture Definition Document, el plan de migración.
• Los artefactos son los productos de trabajo individuales que contienen, de tres tipos: catálogos (listas de elementos), matrices (relaciones entre dos listas) y diagramas (vistas visuales).
• Los building blocks son los componentes reutilizables que describen esos artefactos.

El Architecture Repository es donde vive todo ello, y las partes que importan en la práctica son el Architecture Landscape (las descripciones de la situación actual y la objetivo a distintos niveles de detalle), la Standards Information Base (qué está aprobado, qué se tolera y qué se está abandonando), la Reference Library (patrones y arquitecturas de referencia que merece la pena reutilizar) y el Governance Log (decisiones, excepciones y su justificación). El Governance Log es el más infravalorado: un registro consultable de por qué se tomó una decisión evita que la organización vuelva a debatirla cada dieciocho meses.

El Enterprise Continuum es el esquema de clasificación que permite pasar de modelos de referencia genéricos del sector a soluciones específicas de la organización. Es más útil en lo conceptual que utilizado en la práctica.

Mapa de capacidades

De todos los artefactos de arquitectura empresarial, el mapa de capacidades de negocio es el que tiene más probabilidades de usarse de verdad, porque ofrece a las personas de negocio y de tecnología un vocabulario compartido y estable.

Una capacidad es lo que la organización es capaz de hacer, expresado como sintagma nominal e independiente de cómo o de quién lo haga: «alta de clientes», «decisión de crédito», «liquidación de siniestros», «fijación de precios». Las capacidades cambian mucho más despacio que los procesos, las estructuras organizativas o los sistemas, y eso es justo lo que las convierte en una columna vertebral útil. Normalmente se descomponen en dos o tres niveles; más allá, el mapa se convierte en un modelo de procesos y pierde su estabilidad.

Level 1   Customer Management
  L2      Customer Onboarding            importance: HIGH   health: POOR    apps: 4  ← invest
  L2      Customer Data Management       importance: HIGH   health: POOR    apps: 9  ← invest
  L2      Complaint Handling             importance: MED    health: GOOD    apps: 1
Level 1   Product & Pricing
  L2      Product Definition             importance: MED    health: FAIR    apps: 2
  L2      Pricing & Discounting          importance: HIGH   health: FAIR    apps: 3
Level 1   Order to Cash
  L2      Order Capture                  importance: HIGH   health: GOOD    apps: 1
  L2      Invoicing & Collections        importance: MED    health: POOR    apps: 5  ← rationalise

El mapa se gana su sitio con los mapas de calor: superponer valoraciones sobre él. ¿Qué capacidades son estratégicamente importantes? ¿Cuáles funcionan mal hoy? ¿Cuáles se apoyan en sistemas al final de su vida útil, en cinco aplicaciones que se solapan o en ninguna? Donde se cruzan las capas de «estratégicamente crítica» y «mal soportada», tienes un caso de inversión que un directivo sin perfil técnico puede leer en una sola diapositiva, y eso es un uso bastante mejor del esfuerzo de arquitectura que otro diagrama de capas.

Una gobernanza que ayuda

La gobernanza de la arquitectura es el mecanismo que hace real el objetivo, y es donde las prácticas de arquitectura empresarial se convierten con más frecuencia en aquello que todo el mundo esquiva.

Lo que funciona:

• Principios y estándares publicados donde ya están los desarrolladores —en el repositorio, en las plantillas de proyecto, en las comprobaciones del pipeline— en lugar de en un portal que nadie abre.
• Un proceso de desviaciones con registro de decisiones. Los equipos van a necesitar excepciones. Registra la excepción, su justificación, su responsable y su fecha de caducidad. Una práctica de arquitectura que dice que no por defecto acaba siendo esquivada; una que dice «sí, queda registrado, lo revisamos en doce meses» sigue informada.
• Conformidad automatizada donde sea posible. Reglas de dependencias, imágenes base aprobadas, metadatos obligatorios, linting de APIs según las guías de la organización. Una comprobación en el pipeline escala a mil equipos; un comité de revisión, no.
• Revisiones ligeras y a tiempo en los puntos que importan —antes de adoptar una tecnología, antes de establecer un patrón de integración, antes de una decisión de construir o comprar— en lugar de una barrera en cada release.

Lo que no funciona: un comité que revisa cada proyecto cuando el diseño ya está terminado, estándares sin un camino para cumplirlos, arquitecturas objetivo sin una ruta financiada desde la situación actual y un esfuerzo de modelado que supera la disposición de la organización a mantenerlo. Una gobernanza que añade una semana de espera a cada cambio es una de las razones por las que las prácticas DevOps se extendieron como reacción.

Las críticas, expuestas con justicia

El framework recibe críticas duras, y muchas son merecidas.

Es pesado. El estándar completo describe muchos más artefactos de los que cualquier organización debería producir. Leído como una obligación y no como un menú, genera documentos que nadie lee.

Puede desconectarse de la entrega. Una arquitectura objetivo con un horizonte de tres años, elaborada por un equipo central, suele quedar superada por los acontecimientos e ignorada en silencio mientras los equipos de entrega toman las decisiones reales en la sprint planning.

La certificación sustituye a la habilidad. El examen evalúa vocabulario, que es fácil de evaluar y no es lo que exige el trabajo.

Presupone un grado de control central que ya no se corresponde con cómo se construye el software. Los servicios cloud se contratan con una tarjeta de crédito, los equipos de producto eligen su propio stack y una práctica de arquitectura cuyo único instrumento es la aprobación tiene muy poca influencia.

Bien usado, sigue aportando valor real: un vocabulario compartido que evita que la gente discuta sin entenderse, una lista de preocupaciones que previene omisiones evidentes, una estructura repetible para el análisis de brechas y un modelo de gobernanza que se puede intensificar o relajar. El enfoque pragmático consiste en tomar la estructura del ADM y la clasificación del content framework, producir el pequeño número de artefactos que responden a preguntas vivas, automatizar la conformidad, integrar a los arquitectos con los equipos de entrega en lugar de situarlos por encima, y hacer del repositorio la memoria de las decisiones y no un museo de diagramas.

Ideas clave

• La arquitectura empresarial existe para informar decisiones sobre portfolio, inversión, impacto y estándares; los artefactos que no responden a ninguna pregunta viva son puro coste.
• Los cuatro dominios —negocio, datos, aplicaciones y tecnología— son vistas de un único modelo, y la trazabilidad entre ellos es donde está el valor.
• El ADM es un ciclo iterativo que va de la visión a las arquitecturas de dominio y de ahí a oportunidades, migración, gobernanza de la implantación y gestión del cambio, con la gestión de requisitos en el centro.
• Separa los architecture building blocks de los solution building blocks que los materializan, y guarda catálogos, matrices y diagramas en un repositorio con un registro de gobernanza de decisiones y excepciones.
• Un mapa de capacidades de negocio con capas de calor es el artefacto con más probabilidades de cambiar una decisión de la dirección, y se mantiene estable mientras procesos y sistemas no dejan de cambiar.
• Gobierna con estándares publicados, comprobaciones de conformidad automatizadas y un proceso de desviaciones registrado, en lugar de comités que bloquean cada release, y trata TOGAF como un menú: itera con el alcance que necesita cada decisión y mantén a los arquitectos cerca de la entrega.