Referencia de Arquitectura (Arquitecto Empresarial / Autoridad de Diseño)
Para contextos regulados de la UE/Francia (banca, salud, defensa). Los detalles regulatorios evolucionan: cualquier cosa marcada como "verificar" debe ser contrastada con el texto oficial vigente antes de ser utilizada en un entregable.
Índice de referencias
references/togaf-archimate.md— leer al estructurar un esfuerzo de arquitectura (fases ADM, entregables, gobierno, revisiones de cumplimiento) o modelar con ArchiMate (capas, elementos, relaciones, puntos de vista). Ruta completa${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.mdreferences/urbanisation.md— leer al producir o usar mapas del SI franceses (zonas/quartiers/îlots, cartografías), un schéma directeur, evaluación de portafolio de aplicaciones (TIME) o un plan de racionalización/desmantelamiento. Ruta completa${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.mdreferences/adr.md— leer al redactar o revisar un Registro de Decisiones de Arquitectura o una matriz de decisiones (Nygard, MADR, Y-statements, criterios ponderados, ejemplos ficticios). Ruta completa${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md
Plantillas de entregables relacionadas: ${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md, interface-contract.md, flow-matrix.md.
El detalle regulatorio (GDPR, DORA, NIS2, HDS, II 901, IGI 1300…) reside en el skill sector-compliance y sus referencias sectoriales (${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/); este skill cubre solo las implicaciones arquitectónicas.
1. Rol: autoridad de diseño
Posee: principios y estándares de arquitectura; arquitectura objetivo y hoja de ruta; decisiones estructurales (ADRs); coherencia entre dominios y expertos; dispensas (dérogations) con fecha de caducidad; revisiones de cumplimiento de arquitectura; registro de deuda técnica a nivel de arquitectura. No posee: aceptación del riesgo de seguridad (propietario del riesgo de negocio / autoridad de homologación, asesorado por RSSI); decisiones sobre datos personales (responsable del tratamiento, asesorado por DPO); arbitraje de presupuesto/calendario (COPIL); cambios en producción (CAB).
Puertas de revisión
| Puerta | Cuándo | Verificaciones |
|---|---|---|
| G0 Alcance | Note de cadrage | Ajuste con objetivo/hoja de ruta, opciones identificadas, perímetro regulatorio, clase de soberanía de los datos |
| G1 Diseño | Borrador de DAT/contratos de interfaz | Cumplimiento de principios, NFRs cuantificados, patrón de integración, propiedad de datos, arquitectura de seguridad, reversibilidad |
| G2 Pre-construcción | Diseño congelado | ADRs aceptados, dispensas firmadas, matriz de flujo completa, diseño de operaciones/DR |
| G3 Pre-puesta en marcha | Antes del go/no-go | As-built vs DAT, deuda incurrida registrada, DR probado, registro DORA / mapa de dependencias actualizado |
Resultado de una revisión: conforme / conforme con reservas (acciones + fechas) / dispensa (propietario del riesgo + caducidad) / no conforme (bloqueante).
2. Principios de arquitectura
Formato (estilo TOGAF): Nombre — Declaración — Justificación — Implicaciones. Mantener 10-15, cada uno verificable en una revisión. Conjunto predeterminado para contextos de integración regulados:
| # | Principio | Implicación verificable |
|---|---|---|
| P1 | Continuidad del negocio por diseño | Cada función crítica tiene RTO/RPO declarados cumplidos por diseño y probados |
| P2 | Seguridad y privacidad por diseño y por defecto (Art. 25 GDPR) | Datos clasificados (DICT) antes del diseño; mínimo privilegio; cifrado en tránsito y en reposo |
| P3 | Fuente única de verdad por dominio de datos | Cada entidad de datos tiene un sistema maestro y un propietario nombrado; otros mantienen copias gobernadas |
| P4 | Acoplamiento débil a través de interfaces gestionadas | Sin acceso directo a la base de datos de otra aplicación; todos los intercambios a través de APIs, mensajes o archivos contratados |
| P5 | Reutilizar antes que comprar antes que construir | Plataformas compartidas existentes (MFT, API gateway, IAM, planificación) utilizadas a menos que un ADR indique lo contrario |
| P6 | Estándares y formatos abiertos | Protocolos / formatos abiertos preferidos; propietario solo con un plan de reversibilidad |
| P7 | Reversibilidad y salida | Cada servicio externo tiene un plan de salida; datos exportables en formatos documentados |
| P8 | Operabilidad es un requisito | Monitorización, registros, planificación, reinicio y DEX diseñados con la solución |
| P9 | Trazabilidad y auditabilidad | IDs de correlación de extremo a extremo; pistas de auditoría retenidas según requisitos legales |
| P10 | Residencia y soberanía de datos por clasificación | Elección de alojamiento derivada de la clase de datos (ver §6) |
| P11 | Simplicidad y racionalización | Nuevo componente solo si ninguno existente encaja; desmantelamiento planificado con cada reemplazo |
| P12 | Automatizar la cadena de entrega | Infraestructura y despliegues como código, entornos reproducibles |
3. Arquitecturas objetivo vs. transición
- Línea base (as-is), Objetivo (to-be en el horizonte, típicamente 3-5 años), Arquitecturas de transición (mesetas: estados intermedios estables y operables que aportan valor), Análisis de brechas (qué se añade, elimina, cambia), Hoja de ruta (paquetes de trabajo, dependencias, fechas de desmantelamiento).
- Cada transición debe ser operable por sí misma (soportada, monitoreada, con cobertura de DR, documentada) — el proyecto puede detenerse allí.
- Los puentes de coexistencia (sincronización temporal, evitación de doble escritura, capas de anticorrupción) son componentes de primera clase: propietario, costo, fecha de fin, entrada de deuda.
- "Temporal" sin una fecha de fin se vuelve permanente: rechazarlo en G1.
- Preferir la migración incremental (strangler fig: enrutar funcionalidad progresivamente al nuevo sistema detrás de una fachada) sobre el reemplazo big-bang cuando el legado es grande y está mal documentado.
4. Arquitectura de integración (nivel macro)
El diseño detallado pertenece al experto en integración; el arquitecto establece el patrón y las reglas.
| Patrón | Adecuado para | Evitar cuando | Precauciones |
|---|---|---|---|
| Punto a punto | ≤ pocos flujos estables, táctico | Muchos consumidores, cambios frecuentes | Espagueti (n² enlaces), sin monitoreo central |
| Hub & spoke / EAI / ESB | Muchos sistemas heterogéneos, transformaciones, gobernanza central | Hub se convierte en cuello de botella/monolito de lógica de negocio | Mantener la lógica de negocio fuera del bus |
| Transferencia de archivos vía MFT | Batch, alto volumen, intercambios con socios, legado (muy común en banca/IBM i) | Necesidades en tiempo real | Controles de integridad, nomenclatura, horas de corte, reenvío, cifrado, no repudio |
| API-led (capas de sistema / proceso / experiencia) | Servicios reutilizables, canales digitales, APIs de socios | Movimiento de datos masivo | Gestión de API, versionado, cuotas, OAuth2/mTLS |
| Orientado a eventos (pub/sub, event streaming, CDC) | Reacciones desacopladas, propagación en tiempo real, muchos consumidores | Se requiere consistencia transaccional fuerte entre sistemas | Ordenación, idempotencia, evolución de esquema, reproducción, propiedad de eventos |
| Plataforma de datos (DWH, lake, lakehouse, data mesh) | Analítica, informes regulatorios, ML | Integración transaccional operativa | Linaje, calidad, retención, segregación de datos sensibles |
| MDM / référentiels | Datos maestros compartidos (cliente, producto, organización, identidad del paciente) | Datos con un único propietario natural | El esfuerzo de gobierno y administración es el costo real |
Reglas generales: llamadas síncronas solo cuando el llamante realmente necesita la respuesta ahora; asíncrono por defecto entre dominios; diseñar cada flujo para fallar (reintento con backoff, cola de mensajes fallidos, reproducción, consumidores idempotentes); usar el patrón outbox en lugar de escrituras duales; modelos de datos canónicos solo dentro de un alcance limitado (los modelos canónicos a nivel empresarial rara vez sobreviven); versionar cada contrato; un ID de correlación de extremo a extremo.
5. Requisitos no funcionales
Cuantificar cada NFR; "alta disponibilidad" no es un requisito.
| Categoría | Métricas / preguntas | Trampas |
|---|---|---|
| Disponibilidad | % durante un período, horas de servicio, tiempo de inactividad planificado permitido | Ignorar la cadena de dependencias; medir la infraestructura no el servicio |
| Continuidad | RTO / RPO (DMIA / PDMA) por función de negocio, MTPD | RPO 0 prometido con replicación asíncrona; reinicio por lotes ignorado |
| Rendimiento | Rendimiento, latencia p95/p99, ventana de batch, factor pico, crecimiento | Probar el promedio no el pico; picos de fin de mes olvidados |
| Escalabilidad | Volúmenes en el horizonte, elasticidad | Modelos de licencia que escalan el costo de manera no lineal |
| Seguridad | Clasificación DICT, IAM, cifrado, registro, segregación | Seguridad añadida después del diseño |
| Operabilidad | Monitorización, alertas, registros, reinicio, planificación, automatización | DEX escrito después de la puesta en marcha |
| Observabilidad | Trazas, métricas, registros, correlación, KPIs de negocio | Sin vista de extremo a extremo a través del middleware |
| Reversibilidad | Plan de salida, formatos de exportación, tiempo y costo de salida | Solo contractual, nunca probado |
| Interoperabilidad | Estándares (p. ej., ISO 20022 en pagos, HL7 FHIR en salud — verificar mandatos sectoriales) | Dialectos locales de estándares |
| Cumplimiento / residencia | Ubicación de datos, retención, retenciones legales, auditoría | Copias de seguridad y registros almacenados fuera de la zona acordada |
| Mantenibilidad | Cadencia de actualización, fechas de soporte del proveedor | Fin de soporte a mitad del proyecto |
| Sostenibilidad | Eficiencia de recursos (directrices de ecodiseño RGESN en Francia — verificar estado) | Entornos de no producción sobredimensionados |
Hoja de trucos de disponibilidad (por año): 99 % ≈ 3.65 días; 99.5 % ≈ 1.83 días; 99.9 % ≈ 8.76 h; 99.95 % ≈ 4.38 h; 99.99 % ≈ 52.6 min; 99.999 % ≈ 5.3 min. Cadena en serie: A = A1 × A2 × … ; par redundante: A = 1 − (1 − A1)(1 − A2) (asume fallos independientes — raramente completamente cierto). Coherencia RPO/RTO: RPO está limitado por el modo de replicación y la frecuencia de las copias de seguridad; RTO incluye detección, decisión, conmutación por error, reparación de datos, puesta al día por lotes y resincronización de socios — no solo el tiempo de conmutación técnica.
6. Estrategia de nube y soberanía
Clasificar primero, luego alojar: la clase de datos determina la opción de alojamiento.
| Clase de datos / sistema | Opciones de alojamiento típicas (verificar contra las reglas vigentes) |
|---|---|
| Público / interno, no sensible | Nube pública aceptable con controles estándar |
| Datos personales (GDPR) | Alojamiento en la UE preferido; transferencias fuera del EEE necesitan una base del Capítulo V y una evaluación de impacto de la transferencia |
| Datos personales de salud (Francia) | Proveedor de alojamiento certificado HDS requerido (Código de Salud Pública, Art. L.1111-8); el referencial HDS reciente añade requisitos de localización de datos en el EEE — verificar la versión actual y las fechas de transición |
| Datos de particular sensibilidad (données d'une sensibilité particulière) de servicios del Estado, operadores del Estado y GIP listados | Oferta calificada SecNumCloud, o una certificación de la UE/EEE que ANSSI reconozca como equivalente: Ley SREN Art. 31 (2024), decreto n° 2026-272 (14 de abril de 2026), orden del 12 de agosto de 2026; la doctrina "cloud au centre" (2021, actualizada en 2023) extiende la expectativa a otros SI del Estado — régimen de exención en esos textos |
| Diffusion Restreinte (DR) | Sistemas acreditados según II 901; restricciones de alojamiento específicas — verificar |
| Clasificado (Secret / Très Secret, IGI 1300) | Infraestructura acreditada dedicada; nube pública generalmente excluida |
| Funciones críticas o importantes bancarias | Permitido con requisitos de terceros de DORA, reglas de externalización (directrices EBA) y notificación al supervisor cuando sea necesario — verificar |
SecNumCloud: Cualificación ANSSI de proveedores de servicios en la nube contra el référentiel d'exigences v3.2 (8 de marzo de 2022; la versión aprobada por la orden del 12 de agosto de 2026). Más allá de los requisitos técnicos de seguridad, su §19.6 protege contra leyes extraterritoriales no pertenecientes a la UE: proveedor establecido en la UE, accionistas no pertenecientes a la UE limitados al 24 % individualmente y al 39 % colectivamente, datos almacenados y el servicio administrado y supervisado desde la UE. Las etiquetas de marketing "soberano" no son cualificación: solicitar el certificado de cualificación y su alcance exacto de servicio. Exposición extraterritorial: evaluar el riesgo de acceso legal no perteneciente a la UE (p. ej., US CLOUD Act, FISA s.702) contra la clase de datos; el cifrado con claves controladas por el cliente (HSM/BYOK/HYOK) reduce pero no siempre elimina el riesgo. Cláusulas de reversibilidad (contrato + arquitectura): plan de salida y período de asistencia; exportación de datos y metadatos en formatos abiertos documentados a un costo no prohibitivo; certificado de eliminación; exportación de documentación y configuración; continuidad del servicio durante la salida; períodos de notificación; lista de subprocesadores; derechos de auditoría. La Ley de Datos de la UE (Reglamento (UE) 2023/2854, Capítulo VI) se aplica desde el 12 de septiembre de 2025: los proveedores deben apoyar el cambio y solo pueden facturar sus costos reales de cambio/salida hasta el 12 de enero de 2027, ninguno después de esa fecha. Habilitadores de arquitectura: cargas de trabajo portátiles (contenedores, IaC), bases de datos estándar o rutas de migración documentadas, evitar el acoplamiento profundo a PaaS propietario para funciones principales a menos que un ADR lo acepte, prueba de salida periódica (al menos exportación + restauración en otro lugar). Opciones de migración a la nube (6R/7R): retirar, retener, reubicar, reubicar, replatformizar, refactorizar, recomprar — decidir por aplicación a partir de la evaluación del portafolio (ver referencia de urbanización).
7. Gestión de deuda técnica
- Tipos: arquitectura (patrón incorrecto, acoplamiento), obsolescencia (versiones sin soporte), código, datos (calidad, duplicados), operacional (pasos manuales), documentación, seguridad (correcciones diferidas).
- Registro: elemento, tipo, ubicación, causa (deliberada a través de ADR / accidental), interés (costo o riesgo por período), principal (costo de arreglo), propietario, fecha límite, enlace a ADR/dispensa.
- Calendario de obsolescencia: fechas de fin de soporte del proveedor para SO, BD, middleware, runtimes, versiones de ERP, versiones de IBM i; marcar cualquier cosa que termine dentro de los 24 meses.
- Financiación: reservar capacidad explícita (comúnmente citado 15-20 % de la capacidad de entrega — específico de la organización); la deuda de una dispensa de proyecto se costea en ese proyecto.
- La deuda que afecta funciones críticas es un riesgo TIC: reportarlo en el marco de riesgos, no solo en los backlogs de TI.
8. Riesgo TIC de DORA desde una perspectiva de arquitectura
Reglamento (UE) 2022/2554, aplicable desde el 17 de enero de 2025, completado por RTS/ITS. Los números de artículo a continuación son indicativos: confirmarlos en EUR-Lex antes de citarlos en un entregable.
| Tema DORA | Contribución de la arquitectura |
|---|---|
| Marco de gestión del riesgo TIC (Art. 6) | Principios de arquitectura, estándares y arquitectura objetivo como controles documentados |
| Identificación (Art. 8) | Inventario de activos TIC y activos de información; mapeo de los procesos de negocio soportados, dependencias (internas, externas, proveedores), clasificación de criticidad |
| Protección y prevención (Art. 9) | Arquitectura de seguridad (defensa en profundidad, segmentación, reglas de flujo), controles de integridad de datos, planes de continuidad y DR |
| Detección (Art. 10) | Capacidades de monitorización en tiempo real, gestión de registros, análisis de anomalías, alertas de seguridad (desde la arquitectura, no la herramienta) |
| Respuesta y recuperación (Art. 11) | Planes de respuesta a incidentes, procedimientos de recuperación, comunicación, planes de continuidad, pruebas (mesas de simulación, ejercicios) |
| Aprendizaje y evolución (Art. 12) | Lecciones aprendidas de incidentes, mejora continua de los controles arquitectónicos |
| Comunicación (Art. 13) | Notificaciones a autoridades, a clientes afectados (desde un punto de vista arquitectónico: qué datos, qué momento, qué canal) |
Aportaciones arquitectónicas clave a los requisitos DORA:
- Pruebas de resiliencia operativa (Art. 24-27): el arquitecto define los escenarios de prueba (fallo de un componente principal, interrupción del proveedor, ciberataque) y asegura que el diseño soporte la reanudación dentro de los parámetros objetivo. La prueba real (TLPT para los financieros designados) la ejecuta el equipo de pruebas, pero la capacidad de ser probado está en el diseño.
- Gestión del riesgo de terceros TIC (Art. 28-44): el arquitecto evalúa las dependencias de los proveedores (acoplamiento, reversibilidad, intercambio de datos) y asegura que los contratos incluyan SLA de seguridad/resiliencia, derechos de auditoría y planes de salida. Los acuerdos de nivel de servicio (SLA) de disponibilidad deben ser verificables desde la arquitectura (sin puntos ciegos).
- Registro de información (Art. 8(3)): la arquitectura debe proporcionar el mapeo de dependencias (flujos de datos, sistemas de soporte, proveedores externos) que alimenta el registro. La matriz de flujo de la arquitectura debe ser mantenida como parte del diseño.
9. Lista de verificación de coherencia entre expertos (puerta de diseño G2)
Antes de congelar el diseño, verificar que todas las perspectivas de los expertos son coherentes. Para cada elemento a continuación, confirmar que los expertos de los dominios enumerados han firmado:
| Perspectiva | Expertos involucrados | Preguntas clave de coherencia |
|---|---|---|
| Seguridad | Experto en seguridad / RSSI | Clasificación DICT concuerda con el diseño del alojamiento (sincronizar con datos, §6); los flujos de autorización coinciden con las reglas de seguridad; el modelo de amenazas cubre la superficie de ataque expuesta por la arquitectura |
| Datos | DPO, propietario de datos, administrador de datos | La clasificación de datos (personal, salud, DR, etc.) coincide con la opción de nube y el diseño de cifrado; la retención y la auditoría están presupuestadas en el almacenamiento; los flujos transfronterizos identificados y justificados |
| Operaciones | Operaciones, SRE, experto en DR | Las plataformas de monitorización y registro existen para las tecnologías elegidas; el runbook de reinicio cubre el batch; el DR está presupuestado (réplicas, failover, prueba) — no solo dibujado |
| Aplicaciones | Arquitecto de aplicaciones / líder técnico | La interfaz contrato es estable y versionada; las dependencias de bibliotecas y tiempos de ejecución están dentro del soporte; el código se despliega de forma reproducible |
| Integración | Arquitecto de integración | El patrón de integración elegido está presupuestado para el throughput; la cola de mensajes fallidos tiene un propietario; los formatos canónicos están versionados en el registro de contratos |
| Proveedores | Compras, legal, proveedor | Las cláusulas de reversibilidad, los SLA y la continuidad están en el contrato; la arquitectura del proveedor es compatible con las restricciones de datos (Art. 28 GDPR, SecNumCloud); el plan de salida es verificable |
| Regulatorio / Cumplimiento | Oficial de cumplimiento, supervisor (si corresponde) | La arquitectura soporta los requisitos de informe (normas de informes DORA, informes regulatorios); las pistas de auditoría son suficientes; los controles de acceso están documentados |
Controversias: si dos expertos no están de acuerdo (p. ej., seguridad solicita aislamiento completo, operaciones solicita paneles compartidos), no resolver por correo electrónico: redactar un ADR que documente ambas opciones, los criterios sopesados y la decisión. El ADR debe ser firmado por el arquitecto jefe y, si es necesario, escalado al COPIL.
Apéndice A: Cómo utilizar este skill
- Activar con: "necesito diseñar la arquitectura objetivo para [dominio / proyecto] en un contexto regulado" o "revisa esta ADR contra los principios de arquitectura" o "verifica la coherencia entre expertos para el diseño de [proyecto]".
- Leer el índice de referencias y cargar el que sea relevante (TOGAF/ArchiMate, urbanización, ADR) según la tarea.
- Seguir la puerta de revisión apropiada (G0-G3) y ejecutar los puntos de verificación.
- Para la estrategia de nube, comenzar con la clasificación de datos en §6, luego elegir la opción de alojamiento.
- Para riesgos DORA, mapear las contribuciones de la arquitectura (§8) contra las funciones relevantes.
- Para decisiones controvertidas, redactar un ADR (ver referencia ADR).