Las Fases B, C y D del Método de Desarrollo de Arquitectura (ADM) de TOGAF® son **cruciales para la elaboración de la Arquitectura de Destino**. Cada una se enfoca en un dominio específico de la arquitectura empresarial, pero todas contribuyen a la definición del estado futuro deseado.
Explora cada fase para entender su propósito, objetivos clave y cómo contribuyen colectivamente a la Arquitectura Objetivo.
La Fase B describe el desarrollo de una Arquitectura de Negocio para respaldar la Visión de Arquitectura acordada. Su propósito, junto con las Fases C y D, es producir un conjunto de arquitecturas de dominio aprobadas por los interesados para el problema que se aborda.
En esta fase se define cómo el negocio operará en el estado futuro deseado, alineado con la visión inicial. Esto incluye la identificación de procesos, estructuras organizativas y capacidades necesarias. Al definir la Arquitectura de Negocio de Destino y compararla con la línea base, se identifican las primeras brechas y se proponen componentes para el mapa vial futuro.
La Fase C describe el desarrollo de las Arquitecturas de Sistemas de Información para respaldar la Visión de Arquitectura acordada. Al igual que la Fase B, contribuye a producir arquitecturas de dominio aprobadas por los interesados. La determinación de los requisitos de interoperabilidad, como la forma en que se compartirán la información y los servicios, está presente en esta fase.
Esta fase detalla cómo los sistemas de información (tanto en términos de datos como de aplicaciones) apoyarán la Arquitectura de Negocio de Destino. Se define la estructura y organización de los datos y las aplicaciones necesarios para el estado futuro. La identificación de brechas en los dominios de Datos y Aplicación y la propuesta de componentes para el mapa vial son resultados clave que alimentan el desarrollo de la Arquitectura de Destino global.
La Fase D describe el desarrollo de la Arquitectura Tecnológica para respaldar la Visión de Arquitectura acordada. Como las fases anteriores, contribuye a un conjunto de arquitecturas de dominio aprobadas por los interesados. Se especifican los mecanismos técnicos apropiados para permitir el intercambio de información y servicios que se identificaron en fases anteriores.
Esta fase se centra en la infraestructura tecnológica subyacente necesaria para soportar las arquitecturas de Negocio y Sistemas de Información definidas. Se especifican los componentes y servicios tecnológicos para el estado futuro. Las brechas tecnológicas identificadas y los componentes del mapa vial propuestos son esenciales para planificar la transición hacia la Arquitectura de Destino completa.
Las Fases B, C y D trabajan de forma **interdependiente** para definir la Arquitectura de Destino en sus respectivos dominios. Aunque se presentan secuencialmente en la representación gráfica del ADM, **no imponen un método "en cascada"**. Más bien, son fases lógicas que agrupan pasos clave para clarificar el flujo de información y entender la relación entre actividades.
La naturaleza **iterativa** del ADM significa que estas fases (y el resto del ciclo) pueden ser visitadas y revisadas continuamente a medida que se obtiene nueva información o cambian los requisitos. El desarrollo de una Arquitectura de Destino requiere considerar la arquitectura completa y el trabajo para cerrar las brechas simultáneamente, lo que implica que estas fases pueden estar abiertas concurrentemente.
El resultado principal de estas fases, en conjunto, es un conjunto de arquitecturas de dominio aprobadas para el estado de destino, una comprensión clara de las brechas existentes para alcanzar ese estado, y una base para definir el trabajo necesario para cerrar esas brechas (Paquetes de Trabajo).
Esta información es fundamental para las fases posteriores del ADM, como la Fase E (Oportunidades y Soluciones) y la Fase F (Planificación de la Migración), donde se consolida el mapa vial y se planifica la transición hacia la Arquitectura de Destino final. La definición de la Arquitectura de Destino no siempre resulta en una única alternativa, y puede implicar la identificación y análisis de múltiples alternativas y compensaciones ("trade-offs") en cada dominio.