Discutir
Se reúnen las partes involucradas — stakeholders y áreas que participan de la dinámica en cuestión — para examinar una capa, un dominio, un subdominio.
Cómo aplicar el framework
Clara/EA no empieza con un modelo ya hecho traído de afuera. Empieza en blanco — incluso cuando la empresa ya existe — y evoluciona en ciclos sucesivos, en espiral, hasta que capas, dominios, entidades, procesos y relaciones son entendidos de la misma forma por quienes viven la operación.
El punto de partida
No se importa un modelo ya hecho de otra empresa, ni se llena una plantilla genérica. Clara/EA se construye junto con quienes viven la operación — esto vale tanto para mapear una empresa que ya existe como para discutir la creación de una nueva.
En el uso defensivo, la página en blanco es deliberada: incluso donde ya existe documentación, se empieza desde cero para que el modelo refleje la operación real, no lo que quedó registrado años atrás. En el uso greenfield, la página en blanco es literal — las capas se definen antes de construir cualquier sistema, sirviendo de plano para el crecimiento.
"Lo más importante no es llenar una plantilla. Es construir, con las personas correctas en la sala, una visión común de lo que la empresa es."
El método
Clara/EA no se aplica en una única secuencia de pasos, de principio a fin. Se aplica en varias iteraciones sucesivas — en espiral — que recorren las capas repetidas veces, cada pasada revisando y profundizando lo que la anterior ya había planteado.
Se reúnen las partes involucradas — stakeholders y áreas que participan de la dinámica en cuestión — para examinar una capa, un dominio, un subdominio.
La discusión busca una sola cosa: que todos vean de la misma forma las entidades, los procesos y las relaciones de esa capa — no la opinión de quien habla más fuerte.
Todo lo que se entiende en común se registra — hoy, en EA/CMDB. No para burocratizar la conversación, sino para que la próxima iteración empiece donde esta se detuvo, no desde cero.
En cada nueva vuelta de la espiral, lo que ya fue registrado se revisa a la luz de lo que se aprendió después — y se adapta cuando es necesario. Por eso el modelo es evolutivo, no definitivo.
El ciclo se repite capa a capa, dominio a dominio — cada pasada más rápida que la anterior, porque parte de lo que ya fue validado, no de cero.
Donde el negocio encuentra la tecnología
Al llegar a la arquitectura de TI, el punto de partida no es una lista de sistemas existentes. Es la arquitectura de negocio ya mapeada: los dominios y subdominios de TI se identifican a partir del análisis de los productos y servicios y de los procesos involucrados en su ciclo de vida — porque las soluciones existen para soportar esos procesos, no al revés.
Es esa cadena — no el inventario técnico — la que determina cómo deberían agruparse e integrarse los sistemas.
Convención de diseño
La misma convención vale para cualquier sector — los Casos de mercado lo demuestran. A la izquierda, los dominios orientados a clientes. En el centro, los dominios que nacen del ciclo de vida del producto, en el orden en que se estructura, vende y liquida. A la derecha, los dominios de fuentes externas — lo que abastece al negocio. En la base, los dominios de soporte y gestión, comunes a cualquier producto.
← Clientes
Canales digitales
App, banca por internet y APIs de Open Finance
Atención
Sucursales, central de atención y chat
Relación
Alta y KYC, segmentación y ofertas
Productos y ciclo de vida
Esteras de originación
Propuesta, análisis de crédito, niveles de aprobación, formalización
Productos y servicios
Cuentas, tarjetas, crédito, inversiones y seguros
Liquidación financiera
Pagos instantáneos, transferencias, boletas, compensación y tarjetas
Fuentes externas →
Funding y tesorería
Captación, ALM y gestión de liquidez
Infraestructuras de mercado
Sistemas de pago, bolsa, registradoras y redes de tarjetas
Bureaus y socios
Bureaus de crédito, corresponsales y datos
Base
Soporte y gestión
Gestión
Riesgo, compliance y MIS
Contable, fiscal y regulatorio
Contabilidad estatutaria, tributos y envíos regulatorios
Administrativos
RRHH, compras y legal
Ejemplo ilustrativo inspirado en el sector bancario — no refleja la arquitectura real de ninguna organización específica.
Modelo de madurez
Cinco niveles para evaluar en qué punto está una empresa — y hacia dónde la lleva el método, iteración tras iteración.
Decisiones bajo presión, sin modelo explícito. Cuando la arquitectura existe, vive en la cabeza de pocas personas.
Primeros mapeos registrados, aislados por área. Todavía no hay visión común entre negocio y tecnología.
Capas y dominios mapeados de forma consistente, con método repetible y un repositorio vivo.
Negocio y tecnología comparten la misma visión en grafo. El impacto de un cambio se analiza antes de que ocurra.
La arquitectura evoluciona en ciclos cortos, con intención. La empresa cambia por decisión, no por reacción.
La meta no es rigidez — es la capacidad de cambiar con intención y rapidez. ¿En qué nivel está su empresa hoy?
Para cerrar
Cada vuelta de la espiral deja a la empresa más cerca de la visión común y más alto en el modelo de madurez. Para facilitar este proceso, o para conocer dónde queda todo registrado, siga adelante.