Empresarial, de transición y de plataforma. Los marcos aparecen al final de cada tema, que es el lugar que les corresponde: sostienen la narrativa, no son la narrativa.
Arquitectura empresarial
Llegar de lo que el banco hace hoy a lo que necesita hacer, pasando por estados que son viables cada uno por su cuenta.
Modelado de capacidades y dominios
Arquitectura baseline
Arquitectura objetivo
Arquitectura de transición
Plateaus
Work packages
Roadmaps de arquitectura
Gobierno de arquitectura
Arquitectura bancaria
La complejidad bancaria se aprende a través de sistemas, fallos, regulación e instituciones a lo largo del tiempo, no en un solo engagement.
BIAN v13 / v14
Arquitectura orientada a dominios
Arquitectura bancaria en capas
Modernización de core
Híbrido cloud / on-premise
Open Banking
Pagos
Dispersión de nómina
Onboarding
Crédito y originación
Fraude
PLD / KYC
Identidad
Seis capas se apilan; la séptima no. Seguridad, identidad y observabilidad atraviesan a todas, y dibujarlas como un peldaño más sugeriría que una capa puede saltárselas.
Gobierno de arquitectura
El gobierno sin autoridad, evidencia y compuertas es ceremonia. Lo que permite que una revisión detenga algo es un instrumento.
Los marcos soportan la narrativa; no son la narrativa. Aparecen aquí como herramienta, no como credencial.
TOGAF
ISO/IEC 42010
ArchiMate
C4
DDD
Activos de arquitectura
Una decisión de arquitectura sin instrumento que la sostenga es una opinión con membrete. Estos son los instrumentos.
A-05
Taxonomía alineada a BIAN y gramática de nombres
Problema
Sin vocabulario compartido, cada integración entre dos sistemas es una traducción hecha a mano, y el número de traducciones crece con cada sistema nuevo.
Mecanismo
Partición de dominios, una gramática de nombres derivada de la clasificación y clasificación de datos sensibles aplicada a la vez.
Por qué importa
La identidad deja de ser una decisión de cada equipo. El mismo nombre se sostiene en contrato, repositorio, despliegue y telemetría, de modo que un componente puede rastrearse hasta la capacidad a la que sirve.
A-01
Catálogo de viewpoints ISO 42010
Problema
Lo que cuenta como documentación completa es implícito, y las revisiones discuten forma en lugar de fondo.
Mecanismo
Diez viewpoints, cada uno con criterios de completitud y comprobaciones de antipatrones.
Por qué importa
Una revisión puede decir qué falta en lugar de qué no le gusta, que es la diferencia entre una compuerta y una opinión.
A-02
Método de decisión AHP + CBAM
Problema
Una recomendación no es defendible si los criterios, la evidencia y la autoridad que la sostienen son invisibles.
Mecanismo
Un modelo ejecutable donde los criterios se fijan antes de puntuar ninguna opción, y la evaluación entera puede volver a correrse cuando cambia un insumo.
Por qué importa
La decisión sobrevive a la reunión. Meses después puede reabrirse contra los mismos criterios en vez de relitigarse de memoria.
A-03
Generador determinista de diagramas
Problema
Los diagramas hechos a mano se separan del modelo que describen, y esa deriva es invisible hasta que alguien se apoya en ellos.
Mecanismo
Geometría calculada con control de colisiones, que produce artefactos versionables regenerados desde el propio modelo.
Por qué importa
El dibujo no puede contradecir a la arquitectura en silencio, porque se deriva de ella en vez de dibujarse al lado.
A-06
Arquetipos de construcción y quality gates
Problema
La calidad varía por equipo cuando cada servicio se diseña desde cero.
Mecanismo
Arquetipos por capa y naturaleza de servicio, cada uno con sus compuertas.
Por qué importa
Los equipos dejan de redecidir lo mismo en cada servicio, y el estándar lo aplica la construcción en lugar de la revisión.
A-07
Toolkit de arquitectura BIAN con recuperación aumentada
Problema
Una automatización que produce artefactos plausibles sin trazabilidad desplaza el problema en lugar de resolverlo.
Mecanismo
Recuperación sobre un corpus BIAN gobernado, con reglas de validación cruzada aplicadas entre fases.
Por qué importa
El artefacto generado arrastra trazabilidad desde la capacidad de negocio hasta la implementación, así que puede revisarse en vez de solo creerse.
341BIAN Service Domains indexedBIAN architecture toolkit
14Architecture artifacts across 5 phasesBIAN architecture toolkit
15Cross-validation rulesBIAN architecture toolkit
A-16
Dictámenes de conformidad basados en evidencia
Problema
La severidad por sí sola no le dice a un programa cuándo parar: un hallazgo medio sobre una decisión irreversible pesa más que uno alto que puede deshacerse la semana siguiente.
Mecanismo
Escalas explícitas, bloqueantes clasificados por irreversibilidad, dueños nombrados, compuertas por ambiente, dispensas y una ratificación de una página.
Por qué importa
La revisión gana autoridad para detener algo antes de construirlo, que es el único momento en que detener sale barato.
Instrumentos de capacidad y entrega
No son activos de arquitectura: sostienen el modelo operativo que la construye.
A-08Tríada de roles SFIA
Enterprise Architect, Solution Architect y Tech Lead definidos contra un marco de capacidad y no contra la costumbre local.
A-09Rúbrica de posicionamiento de perfiles
Vigencia, escasez, relevancia, alcance y evidencia como ejes explícitos, para que la evaluación deje de derivar hacia quien entrevista.
A-10Estándar de propagación de errores
Cómo viaja un fallo entre capas sin perder su causa por el camino.
A-12Modelo de cálculo de estimación
Descomposición por actividad con contabilidad de complejidad y escenarios explícitos: sin eso, las estimaciones de migración son horas inventadas.
A-14Campus de evaluación por procedimiento
Un campus en operación anclado a SFIA, donde la progresión se evidencia en lugar de declararse.
A-15Programa de incorporación de talento junior
Formación, acompañamiento y defensa final, para que la capacidad se transfiera en vez de concentrarse en quien la construyó.