TOGAF 9: Más Allá del Certificado
Por qué TOGAF es una metodología práctica, no solo un examen
Muchos profesionales obtienen el certificado TOGAF 9 y lo añaden a su LinkedIn. Pocos lo usan realmente en su día a día.
Este post es sobre cómo pasar de «tengo el certificado» a «practico arquitectura empresarial con TOGAF».
El Problema con TOGAF
TOGAF tiene un problema de percepción: muchos lo ven como un framework académico, demasiado pesado para el mundo real,
más orientado a generar documentación que a generar valor. Y en parte tienen razón, si lo aplicas mal.
El examen de certificación no ayuda. Memorizas las 8 fases del ADM, recitas los principios de arquitectura,
entiendes la diferencia entre Business, Application, Data y Technology Architecture. Apruebas el examen.
Y luego llegas a tu empresa y piensas: «¿Y ahora qué?»
💡 La Verdad Incómoda
TOGAF no es un framework que «implementas». Es un lenguaje común que adoptas para que todos en la organización
hablen de arquitectura de la misma manera. Si esperas un manual de implementación paso a paso, te decepcionarás.
Lo que TOGAF Sí Te Da (y es Valioso)
1. Un Lenguaje Común
Cuando hablas de «Business Capability Model», «Application Portfolio», o «Target Architecture»,
cualquier arquitecto certificado TOGAF sabe de qué estás hablando. Esto no es trivial en equipos
globales o en consultoras donde rotan constantemente profesionales.
2. Estructura para Pensar
El ADM (Architecture Development Method) no es un checklist de tareas. Es una estructura mental para
abordar problemas de arquitectura. ¿Necesitas definir una estrategia cloud? ADM te recuerda: primero
entiende el negocio (Business Architecture), luego mira tus aplicaciones actuales (AS-IS), diseña el
objetivo (TO-BE), y planifica la transición.
3. Repositorio de Patrones y Artefactos
TOGAF viene con una biblioteca de artefactos (plantillas de documentos, vistas arquitectónicas,
catálogos, matrices) que puedes adaptar. No tienes que inventar desde cero cómo documentar tu
arquitectura de aplicaciones o cómo representar dependencias entre sistemas.
4. Gobierno y Compliance
TOGAF te da frameworks para Architecture Governance: cómo establecer un Architecture Board,
cómo evaluar que los proyectos cumplan con la arquitectura objetivo, cómo gestionar excepciones.
Sin gobierno, tu arquitectura es solo PowerPoint.
Cómo Usar TOGAF en el Mundo Real
Después de años usando TOGAF en organizaciones reales, esto es lo que funciona:
✅ Adopta el Lenguaje, No Todo el Framework
No necesitas implementar las 8 fases del ADM al pie de la letra. Pero sí deberías usar los conceptos:
- Documenta tu arquitectura actual (AS-IS)
- Define tu arquitectura objetivo (TO-BE)
- Identifica gaps y prioriza el roadmap
- Establece principios de arquitectura que guíen decisiones
✅ Empieza con Mapas, No con Documentos
El valor de TOGAF no está en generar 200 páginas de documentación. Está en crear visibilidad:
un mapa de aplicaciones, un catálogo de servicios, una matriz de dependencias. Empieza visual,
luego detalla si hace falta.
✅ Itera, No Cascades
El ADM es cíclico, no lineal. No tienes que completar la fase de Business Architecture antes de tocar
Application Architecture. En proyectos reales, iteras constantemente entre capas. Define un MVP de
arquitectura, valídalo con stakeholders, refina.
✅ Establece Gobierno Ligero
No necesitas un Architecture Board formal de 15 personas que se reúne mensualmente. Pero sí necesitas
algún mecanismo para revisar que las iniciativas tecnológicas van en la dirección correcta. Puede ser
tan simple como un checkpoint de arquitectura en el proceso de aprobación de proyectos.
Los Errores Comunes al Usar TOGAF
❌ Documentación por Documentación
Generar plantillas TOGAF sin preguntarte si alguien las va a leer. La arquitectura no es un entregable,
es visibilidad y decisiones.
❌ Big Bang Architecture
Intentar crear la arquitectura completa de la organización en 6 meses. No funciona. Empieza por un
dominio, una iniciativa, un problema concreto. Crece desde ahí.
❌ Arquitectura en la Torre de Marfil
Diseñar arquitecturas objetivo sin hablar con desarrollo, sin validar con negocio, sin entender
restricciones reales. La mejor arquitectura es la que se implementa.
❌ Ignorar el Contexto Organizacional
TOGAF no funciona igual en una startup de 50 personas que en una multinacional de 10,000. Adapta el
framework a tu realidad, no al revés.
Mi Flujo de Trabajo Práctico con TOGAF
Cuando empiezo en una organización nueva, este es mi enfoque:
Entender el Contexto
Hablar con stakeholders, entender pain points, objetivos estratégicos,
restricciones. Esto es la Fase Preliminar y Vision de TOGAF, pero en lenguaje humano.
Crear Visibilidad (AS-IS)
Mapear aplicaciones, servicios, integraciones. No busco completitud al 100%,
busco una foto suficientemente clara para tomar decisiones.
Definir Principios
Establecer 5-7 principios de arquitectura que guíen decisiones futuras.
Ejemplo: «Cloud-first para nuevas aplicaciones», «APIs antes que integraciones point-to-point».
Diseñar Target Incremental
No diseño la arquitectura objetivo completa. Diseño la arquitectura para
las iniciativas en curso. La arquitectura objetivo emerge de decisiones incrementales coherentes.
Establecer Gobierno Mínimo
Definir cómo se revisan nuevas iniciativas, cómo se escalan excepciones,
cómo se actualiza la arquitectura. Sin proceso, TOGAF muere.
El Verdadero Valor de TOGAF
No es el certificado en tu perfil de LinkedIn. Es tener un lenguaje común para hablar de arquitectura,
una estructura mental para abordar problemas complejos, y artefactos probados que puedes adaptar.
Usa TOGAF como un conjunto de herramientas, no como una religión.
¿Te ha resultado útil este contenido? Conecta conmigo en LinkedIn para más insights sobre arquitectura empresarial.