Trazabilidad bancaria: del negocio a producción

Un servidor del banco deja de responder a las tres de la mañana. El banco se entera enseguida: salta el monitoreo, entran las primeras quejas al call center, un directivo abre la app y no puede transferir. Enterarse nunca es el problema.

El problema es la pregunta que viene después, y que suele tardar horas: qué dejó de funcionar exactamente, y qué más depende de eso. Funciona igual de mal en las dos direcciones — de la queja al sistema que la causó, y del servidor caído al servicio de negocio que acaba de detenerse.

He visto la misma escena en bancos muy distintos, y llegan a ella por caminos opuestos.

En unos hay una licencia de BIAN, un programa de TOGAF con su ADM impreso en la pared y alguien que mantiene diagramas C4 razonablemente buenos. Tienen todo lo que hay que tener. Y aun así, esa noche nadie puede recorrer la cadena completa.

En otros no hay nada de eso. Hay un core que lleva veinte años funcionando, capas de servicios que se fueron apilando encima —muchas todavía SOAP—, y un equipo que se sabe el sistema de memoria y saca el trabajo adelante apagando incendios. Y funciona. Funciona hasta que alguien pregunta qué se afectó, o hasta que hay que exponer el primer contrato hacia afuera.

Y ese «hacia afuera» tiene fecha. El artículo 76 de la Ley Fintech obliga a las entidades financieras a compartir información mediante APIs estandarizadas, con multas de 15 000 a 75 000 UMA por incumplir. Las disposiciones que harían operativa la parte transaccional siguen pendientes; las de datos abiertos llevan vigentes desde 2020. No se puede exponer lo que no sabes que tienes.

Dos puntos de partida opuestos, el mismo problema al final.

Para los primeros, la lectura fácil es que los estándares no sirven. Para los segundos, que adoptarlos es un lujo de banco grande. Ninguna de las dos es cierta. Los estándares sí conectan entre sí, y el descenso desde una capacidad de negocio hasta el servidor donde se ejecuta está formalizado en documentos publicados que cualquiera puede leer. No hay que inventar nada.

El problema es otro, y es más incómodo. Si tuviera que quedarme con una sola frase de todo lo que sigue:

Un modelo solo gobierna si una compuerta lo consulta.

Lo que separa el gobierno arquitectónico de la documentación muerta no es el rigor del modelo ni la herramienta. Es si algo que puede decir que no consulta ese modelo antes de dejar pasar un cambio. Un banco puede tener todos los estándares y aun así no poder recorrer esa cadena entera, del negocio a producción. Por qué pasa, y qué se hace al respecto.

La cadena existe, y baja hasta el hierro

BIAN no baja a TOGAF directamente. Baja por ArchiMate — y eso no es una propuesta mía: The Open Group publicó el modelo de referencia de BIAN expresado en notación ArchiMate, en el documento G205. Un Service Domain se modela como Capability; las Business Areas, como agrupaciones. Desde ahí, ArchiMate define relaciones formales que atraviesan las tres capas hasta el despliegue.

Ese Artifact resuelve una discusión que he visto repetirse: no hace falta inventar una taxonomía de artefactos tecnológicos. ArchiMate ya la define como tipo de primera clase, y la relación realization la ata al componente aplicativo que la origina.

Así que la cadena está publicada y es completa. El problema empieza en las fechas.

Por qué no gobierna

Las fechas son mantenimiento y se arreglan leyendo con la fecha delante. Lo estructural es peor, y son tres cosas comprobables abriendo el propio estándar.

Uno. Los requisitos están fuera del grafo. En el metamodelo de TOGAF 10, las entidades Requirement, Principle, Constraint, Gap, Assumption y Location no participan en ninguna relación. Cero. Y qué significa eso: que cuando auditoría te pregunte qué componente cumple el requisito regulatorio que firmaste, el modelo no puede contestarlo. Hay que reconstruirlo a mano.

Dos. Las fases que gobiernan no tienen artefactos. Los sesenta y pico catálogos, matrices y diagramas del Content Framework caen todos entre la fase preliminar y la E. Las fases F, G y H —migración, gobierno de la implementación y gestión del cambio— no tienen ni uno. El contenido formal se agota justo antes de que la trazabilidad tuviera que cobrarse: cuando algo va a producción.

Tres. El control de conformidad no consulta el modelo. El Architecture Compliance Review son listas de verificación y entrevistas. La única mención a usar la trazabilidad del modelo para verificarla es una Nota, fuera del proceso numerado, que sugiere que «podría al menos automatizarse parcialmente con herramientas». El marco audita con cuestionarios el grafo que él mismo definió.

Por eso la pregunta de las tres de la mañana tarda horas. No es que falte información —está toda—: es que ninguna de las herramientas que ya tienes está obligada a cruzarla, y alguien acaba haciéndolo a mano mientras las quejas siguen entrando.

Y conviene decirlo con precisión, porque el reproche fácil es injusto: cada marco hace bien su trabajo. BIAN clasifica capacidades. ArchiMate representa relaciones. C4 da visibilidad por niveles, y su autor aclara que las capacidades de negocio quedan deliberadamente fuera de su modelo. OpenAPI y AsyncAPI formalizan el contrato: los diagramas ilustran, los contratos obligan.

Ninguno falla en lo suyo. Lo que no hace ninguno —ni está en su alcance hacerlo— es repartir una identidad común. Cada uno nombra las cosas a su manera: el arquitecto llama a algo «Party Reference Data Directory», el repositorio se llama perfil-cliente-api, la imagen profile-svc y el pod profile-7d9f. Cuatro nombres para una sola cosa, y ningún marco obligado a reconciliarlos. Ahí es donde se corta la trazabilidad: no en los modelos, sino entre ellos.

Lo que falta no es otro marco. Es un nombre.

La reacción instintiva es construir el mapa que reconcilie los cuatro nombres: una matriz que diga que profile-svc es «Party Reference Data Directory». Esa matriz es la junta, y las juntas se pudren. Alguien la mantiene tres meses, cambia un equipo, y a partir de ahí miente en silencio.

La alternativa es no tener junta. Si el nombre técnico se deriva de los atributos arquitectónicos en vez de elegirse, no hay nada que reconciliar: es la misma cadena de caracteres en todas partes.

Esa identidad no la inventa nadie: se calcula a partir de la clasificación que el banco ya tiene —a qué dominio pertenece la capacidad, qué papel cumple el componente, de qué responde—. Dos equipos distintos, partiendo de los mismos atributos, llegan al mismo resultado sin hablar entre ellos. Y lo que no cumple la regla no se queda en una observación de revisión: el pipeline lo rechaza.

Con eso, la pregunta de las tres de la mañana deja de necesitar a nadie despierto que recuerde el mapa. La traza del nodo caído lleva la identidad dentro, y esa identidad resuelve a una capacidad de negocio. La respuesta ya venía escrita en el propio log.

Y funciona en los dos sentidos. Hacia abajo: qué código, qué contrato y qué pod materializan una capacidad. Hacia arriba: qué capacidad de negocio acaba de degradarse. Esa segunda dirección es la que ningún diagrama da, y es la única que importa durante un incidente.

El contrato cierra el círculo. Si cada operación publicada declara la identidad del componente que la implementa, la conformidad deja de ser una opinión y pasa a ser algo que una máquina comprueba o no comprueba. Y conviene separar dos cosas que suelen confundirse: clasificar un componente bajo un Service Domain no significa implementar la API semántica de BIAN. Son dos niveles de alineación distintos, y declararlos por separado evita la discusión estéril sobre si el banco «usa BIAN» o no.

La conclusión fácil es la equivocada

Llegado aquí, la reacción cómoda es: nadie ha ensamblado la cadena, ensamblémosla completa. Sería un error caro, y hay evidencia de sobra.

El programa de arquitectura empresarial del gobierno federal estadounidense gastó más de mil millones de dólares en lo que uno de los autores de la ley que lo ordenó describió como «shelfware inservible». Una auditoría del GAO al Departamento de Defensa reportó al menos 379 millones con una capacidad «limitada» para guiar inversiones. Y en BIAN concretamente: de unos cuarenta bancos miembros, uno solo tiene avances reportados por prensa independiente, que describió al estándar como «lento de implementar en la vida real».

No es que los bancos no lo sepan. Es que el ensamblaje completo ha fracasado donde se intentó completo.

Las tres condiciones

Lo que sí funciona, por lo que he visto, cumple tres:

1. Se ata una capacidad, no el banco. Una sola, elegida porque duele: pagos, originación, alta de cliente.
2. Las aristas que se mantienen vivas se eligen a propósito, y el resto se deja morir. Un grafo completo que nadie actualiza miente más que uno parcial que sí se mantiene.
3. Hay una compuerta. No es un comité que revisa: son comprobaciones que fallan la construcción. Si un componente no declara a qué capacidad sirve, si un contrato publica una operación que no existe en el registro, o si lo que se despliega no se puede rastrear hasta el negocio, el pipeline lo rechaza. Antes de producción, no después del incidente.

Sin la tercera, las otras dos son documentación.

Y si vas a ejecutarlo por tu cuenta, la secuencia de migración está escrita: Migración de core bancario: patrones y secuencia.