Arquitecturas de sistemas de información: modelos y casos reales
Pierre Henriet — Una guía arquitectónica que analiza monolitos, SOA, microservicios, sistemas basados en eventos (EDA) y modelos componibles mediante casos reales europeos de 2023 a 2025 (Adyen, Michelin, SNCF Connect, France Travail, NHS, Spotify, Zara).
En la ingeniería corporativa, la arquitectura de software y la arquitectura de sistemas de información (SI) suelen confundirse. La arquitectura de software organiza una aplicación aislada: estructura interna del código, patrones de diseño y rendimiento algorítmico. Por el contrario, la arquitectura de sistemas de información articula el ecosistema tecnológico y organizativo de la empresa: capacidades de negocio, gobierno del dato, sistemas integrados (ERP, CRM, SCM), mainframes históricos, buses de integración y normativas de interoperabilidad en el sector público.
Elegir una arquitectura inadecuada acumula deuda técnica, fricciones operativas y desalineación estratégica. Desde el monolito modular altamente optimizado hasta las mallas dirigidas por eventos y los módulos componibles, cada modelo responde a compromisos de ingeniería concretos. Este artículo analiza las principales arquitecturas de sistemas de información y su ejecución en empresas e instituciones públicas europeas (incluidas Adyen, Michelin, SNCF Connect, France Travail, el NHS, Spotify y Zara) mediante proyectos desarrollados entre 2023 y 2025.
1. Fundamentos metodológicos: ¿qué define la arquitectura de un SI?
Un sistema de información es una estructura socio-técnica orientada a recopilar, procesar, almacenar y distribuir información para fundamentar la toma de decisiones y coordinar la operación. Tres marcos teóricos vertebran los SI modernos:
- El modelo BDAT del estándar TOGAF (10.ª edición): The Open Group Architecture Framework desglosa la arquitectura empresarial en cuatro capas interconectadas:
• Arquitectura de negocio (business): Estrategia, gobierno, organización y modelado de procesos operativos.
• Arquitectura de datos (data): Activos de información, gestión de datos maestros (MDM) y flujos de intercambio.
• Arquitectura de aplicaciones (application): Mapa del catálogo de aplicaciones, contratos de interfaz y soporte a procesos.
• Arquitectura tecnológica (technology): Infraestructura multi-cloud, redes, middleware y perímetro de ciberseguridad. - La ley de Conway y la maniobra inversa: Formulada en 1968 por Melvin Conway: «Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones.» La ingeniería actual utiliza la maniobra inversa de Conway: organizar equipos multidisciplinares autónomos para propiciar de forma natural arquitecturas de software desacopladas.
- El marco de Zachman: Matriz ontológica que cruza seis perspectivas de interesados (planificador, propietario, diseñador, constructor, integrador, operador) con seis preguntas esenciales (qué, cómo, dónde, quién, cuándo, por qué).
2. Matriz comparativa de paradigmas de arquitectura SI
La siguiente tabla resume las características técnicas, operativas y organizativas de los cinco modelos principales:
| Paradigma arquitectónico | Acoplamiento y comunicación | Modelo de gestión de datos | Despliegue y escalabilidad | Compromiso operativo principal |
|---|---|---|---|---|
| 1. Monolito (clásico y modular) | Fuertemente acoplado; llamadas en memoria; ejecución directa | Base de datos única (RDBMS); transacciones ACID directas; esquema compartido | Artefacto binario único; escalabilidad vertical; despliegue integral conjunto | Alta velocidad inicial vs. radio de impacto de fallos y cuellos de botella a escala |
| 2. Arquitectura orientada a servicios (SOA) | Desacoplado por bus de servicios (ESB); SOAP/WSDL; esquemas canónicos XML | Bases de datos heredadas aisladas; mediación y transformación de datos en el bus | Servicios macro distribuidos; ciclos de despliegue coordinados a nivel corporativo | Interoperabilidad empresarial vs. sobrecarga y fragilidad de un bus ESB sobredimensionado |
| 3. Microservicios | Dominios acotados y autónomos (DDD); protocolos ligeros (REST / gRPC); pasarelas API | Base de datos por servicio; persistencia políglota; consistencia eventual | Pipelines CI/CD independientes; escalabilidad horizontal con contenedores (Kubernetes) | Máxima autonomía de equipos vs. complejidad operativa distribuida (trazabilidad, latencia de red) |
| 4. Arquitectura dirigida por eventos (EDA) | Desacoplamiento temporal y espacial; publicación/suscripción; registros distribuidos | Flujos de eventos inmutables; CQRS; vistas proyectadas y almacenes de estado | Escalabilidad independiente de consumidores; procesamiento asíncrono no bloqueante | Respuesta inmediata en tiempo real vs. gestión de consistencia eventual y reenvío de eventos |
| 5. Empresa componible y MACH | API-first; frontales desacoplados (headless); capacidades empaquetadas (PBC); SaaS cloud | Productos de datos de dominio; malla de datos federada; persistencia SaaS | Componentes modulares intercambiables; ciclos de actualización continuos de proveedores | Agilidad de negocio inmediata vs. gobierno multifuente y dispersión de contratos |
3. Análisis en profundidad de arquitecturas y casos de estudio reales
A. El monolito: por qué líderes europeos de referencia siguen apostando por él
Aunque los microservicios acaparan la atención mediática, el monolito sigue siendo una arquitectura eficiente, económica y robusta si se diseña con disciplina. Un sistema monolítico se ejecuta en un único proceso, compartiendo la memoria y una base de datos relacional.
Las organizaciones adoptan con frecuencia el monolito modular: un modelo en el que las fronteras de dominio se aíslan en tiempo de compilación dentro de una sola base de código, suprimiendo la latencia de red de los sistemas distribuidos.
- Caso de estudio europeo — Adyen (Países Bajos, 2023–2024): Líder en tecnología financiera con sede en Ámsterdam, Adyen procesó más de 970.000 millones de euros en 2023 y superó los 1,2 billones en 2024. Adyen opera un monolito central en Java optimizado sobre un clúster de PostgreSQL. Al procesar transacciones en memoria dentro de un único proceso, Adyen asegura consistencia financiera ACID inmediata, latencias de microsegundos y elimina fallos de red en las redes bancarias internacionales.
- Caso de estudio sector público — Government Digital Service (GOV.UK, 2023–2024): Con más de 500 millones de visitas anuales, el portal del gobierno británico utiliza motores monolíticos de publicación. Durante la implantación en 2024 de la identidad One Login, GOV.UK preservó su núcleo monolítico para la difusión legal a fin de garantizar la entrega atómica de contenidos, cumplir los estándares de accesibilidad (WCAG 2.1 AA) y ofrecer un 99,99 % de disponibilidad en emergencias nacionales.
B. Arquitectura orientada a servicios (SOA): integración corporativa y sector público
Surgida en los años 2000, la arquitectura SOA resolvió la fragmentación corporativa interconectando ERPs, mainframes y CRMs. Introdujo servicios de negocio estandarizados mediante protocolos formales (SOAP, WSDL) coordinados por un bus de servicios empresarial (ESB) central.
- Caso de estudio europeo — SNCF Connect y Tech (Francia, 2023–2024): La red ferroviaria francesa conecta sistemas de reservas históricos (Resarail / Amadeus) con el estado del tráfico en tiempo real y la venta móvil de billetes. La SNCF emplea una plataforma SOA y mediación de APIs modernizada que atiende más de 1.300 millones de visitas y 170 millones de billetes anuales, coordinando el inventario de trenes de alta velocidad con distribuidores europeos.
- Caso de estudio sector público — France Travail (Francia, 2024): Creada en enero de 2024 en sustitución de Pôle Emploi, la agencia pública de empleo desplegó el «Réseau pour l'Emploi». Mediante una plataforma de APIs y un bus de mediación SOA, France Travail interconecta bases relacionales con la seguridad social (URSSAF) y FranceConnect para liquidar prestaciones y orientar la búsqueda de empleo en tiempo real.
- Caso de estudio administración europea — Arquitectura de la identidad digital europea (2024–2025): Con la adopción del reglamento eIDAS 2.0 en 2024, la Comisión Europea diseñó una arquitectura de interoperabilidad federada. Este modelo conecta los registros de identidad nacionales, entidades financieras y administraciones públicas de los 27 Estados miembros mediante buses de mediación abiertos y credenciales verificables normalizadas.
- La limitación de la SOA clásica: Los equipos acumularon con frecuencia reglas de negocio complejas en el bus, generando «tuberías inteligentes y extremos pasivos». El ESB se convirtió en un cuello de botella único gestionado por un equipo saturado.
C. Arquitectura de microservicios: autonomía descentralizada de dominios
Los microservicios surgieron para superar la rigidez de los despliegues monolíticos y las demoras del bus ESB. El sistema se divide en servicios pequeños y autónomos alineados con contextos acotados del domain-driven design (DDD) de Eric Evans. Cada microservicio administra de forma exclusiva su base de datos y se comunica mediante protocolos ligeros (REST, gRPC) o eventos asíncronos.
- Caso de estudio europeo — Spotify (Suecia, 2023–2024): Pionero en la organización por squads y microservicios, Spotify consolidó en 2023 y 2024 su enfoque de ingeniería de plataforma para controlar la proliferación de microservicios. Para coordinar miles de servicios entre Estocolmo, Londres y Nueva York, Spotify creó y liberó como código abierto Backstage (proyecto graduado de la CNCF). Backstage centraliza el catálogo de software y la gobernanza de APIs sin frenar la autonomía de los equipos.
- Caso de estudio medios públicos — BBC iPlayer (Reino Unido, 2023–2024): Para absorber picos históricos de retransmisión en directo —como Eurovisión 2023 en Liverpool, la coronación de Carlos III y las elecciones de 2024—, la BBC desacopló su plataforma en microservicios serverless en AWS. La ingesta de vídeo, la personalización y la distribución escalan de forma independiente, atendiendo más de 7.500 millones de solicitudes de streaming en 2023 y 2024 sin cortes de servicio.
D. Arquitectura dirigida por eventos (EDA): reactividad asíncrona en tiempo real
Las cadenas síncronas de solicitud y respuesta (REST/HTTP) crean un acoplamiento temporal crítico: si un servicio se ralentiza, la secuencia completa se degrada. La arquitectura dirigida por eventos rompe este acoplamiento mediante la publicación de eventos inmutables en un registro distribuido (como Apache Kafka, Apache Pulsar o AWS Kinesis).
- Caso de estudio europeo — Michelin (Francia, 2023–2025): Michelin transformó su producción y logística con una arquitectura dirigida por eventos en Apache Kafka. La telemetría de sensores IoT en fábricas europeas de neumáticos, robots de almacén y centros de distribución emite flujos continuos de eventos. Los microservicios procesan inventarios, mantenimiento predictivo y logística en tiempo real, evitando paradas de fabricación.
- Caso de estudio financiero europeo — Banco Central Europeo (BCE) — TIPS (2023–2024): La liquidación de pagos instantáneos en la eurozona exige una ejecución inmediata y no bloqueante. En sintonía con la normativa europea 2024-2025 sobre pagos instantáneos, TIPS opera 24/7/365, liquidando operaciones en dinero de banco central en menos de 0,2 segundos mediante streaming de eventos y mensajería ISO 20022.
E. La empresa componible y la arquitectura MACH
Definida por Gartner, la empresa componible genera ventajas competitivas ensamblando componentes modulares llamados capacidades de negocio empaquetadas (PBC) en lugar de personalizar costosos paquetes monolíticos. Las arquitecturas componibles aplican los principios MACH:
- M — Microservices: Módulos funcionales autónomos e independientes.
- A — API-first: Funcionalidades expuestas mediante APIs estandarizadas (REST, GraphQL).
- C — Cloud-native SaaS: Infraestructura elástica y gestionada en la nube que elimina el mantenimiento de servidores locales.
- H — Headless: Separación total entre interfaces de usuario (web, móvil, terminales) y motores transaccionales de backend.
Caso de estudio europeo — Carrefour (Francia, 2023–2024): Carrefour aceleró su transformación componible desacoplando sus frontales de clientes de sus bases transaccionales. Al combinar una malla de datos (Data Mesh) en Google Cloud con módulos e-commerce headless, Carrefour ensambla capacidades independientes para entrega rápida, fidelización y preparación en tienda, desplegando innovaciones sin alterar la contabilidad central.
Caso de estudio europeo — Inditex / Zara (España, 2023–2024): Inditex gestiona su agilidad operativa global con su plataforma propietaria Inditex Open Platform (IOP). Al interconectar el seguimiento RFID unitario en tienda con APIs de cobro y logística digital, Zara sincroniza el inventario de más de 5.800 tiendas físicas con su venta online, despachando pedidos desde la tienda más próxima en 24 horas.
Caso de estudio sanidad pública — NHS England (Reino Unido, 2023–2025): El servicio de salud pública británico despliega su Plataforma Federada de Datos (Federated Data Platform - FDP). Adjudicado a finales de 2023 y puesto en marcha en 2024 y 2025, el proyecto utiliza el estándar HL7 FHIR y microcapacidades clínicas modulares para interconectar hospitales y centros de salud sin sustituir los registros médicos electrónicos (EPR) existentes.
4. Marco de decisión para el gestor de proyectos de SI y el arquitecto empresarial
La elección de una arquitectura de sistema de información condiciona la organización de los equipos, los costes de inversión y la velocidad de respuesta del negocio. Cuatro criterios orientan la decisión:
- Aplicar el criterio «MonolithFirst» de Martin Fowler: Sin dominios plenamente consolidados y sin un equipo amplio, comenzar directamente con microservicios impone la «prima de complejidad» (trazabilidad distribuida, latencia de red y reconciliación de datos) sin aportar un valor proporcional. Conviene iniciar con un monolito modular riguroso y segregar servicios autónomos solo cuando determinados dominios requieran ciclos de escalado o despliegue independientes.
- Considerar las falacias de la computación distribuida: Formuladas por L. Peter Deutsch y James Gosling en Sun Microsystems, estas ocho suposiciones erróneas afectan a las migraciones distribuidas:
• La red es fiable.
• La latencia es cero.
• El ancho de banda es infinito.
• La red es segura.
• La topología nunca cambia.
• Solo hay un administrador.
• El coste de transporte es cero.
• La red es homogénea.
Cada llamada entre servicios introduce una probabilidad de fallo que exige cortacircuitos (circuit breakers), reintentos con retraso exponencial, consumidores idempotentes y colas de mensajes fallidos. - Ajustar la arquitectura a la estructura de equipos (Team Topologies): Gestionar 50 microservicios con un único equipo transversal resulta inviable. Los microservicios y los sistemas componibles requieren equipos alineados con el flujo de valor (stream-aligned teams) responsables de una capacidad de extremo a extremo, respaldados por equipos de plataforma que suministren herramientas de autoservicio.
- Establecer un gobierno estricto basado en contratos de API: Sin herramientas automatizadas, los sistemas distribuidos derivan en inconsistencias. Es necesario adoptar un enfoque «contract-first» (OpenAPI para REST, Protocol Buffers para gRPC, AsyncAPI para eventos) y automatizar pruebas de compatibilidad hacia atrás en los pipelines de CI/CD.
Transparencia IA
Este artículo ha sido estructurado y redactado por Pierre Henriet con apoyo de herramientas de IA para síntesis documental. Todos los análisis, conclusiones y aprendizajes son verificados por el autor.
Fuentes y referencias :
• The Open Group (2022) — The TOGAF Standard, 10th Edition: Enterprise Architecture Methodology and BDAT Model
• Zachman, John A. (1987) — « A framework for information systems architecture », IBM Systems Journal, Vol. 26, N.º 3
• Conway, Melvin E. (1968) — « How Do Committees Invent? », Datamation Magazine
• Deutsch, L. Peter y Gosling, James (1994–1997) — The Eight Fallacies of Distributed Computing (Sun Microsystems)
• Fowler, Martin (2014) — « Microservices: a definition of this new architectural term » y « MonolithFirst » (martinfowler.com)
• Evans, Eric (2003) — Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley)
• Hohpe, Gregor y Woolf, Bobby (2003) — Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley)
• Skelton, Matthew y Pais, Manuel (2019) — Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution)
• Gartner Research (2020/2023) — Future of Applications: Delivering the Composable Enterprise with Packaged Business Capabilities
• Adyen Engineering (2023/2024) — Architectural Principles: Why Adyen Operates on a Scalable Core Monolith
• UK Government Digital Service (2023/2024) — GOV.UK Architectural Foundations and One Login Architecture
• SNCF Connect y Tech (2023/2024) — Arquitectura de distribución ferroviaria de alta concurrencia y mediación de API
• France Travail (2024) — Réseau pour l'Emploi y arquitectura de API abiertas del servicio público de empleo
• Comisión Europea (2024) — Marco de arquitectura y referencia para la identidad digital europea (eIDAS 2.0)
• Spotify Engineering (2023/2024) — Managing Microservices Complexity with Backstage and Platform Engineering
• BBC Research and Development (2023/2024) — Cloud-Native Serverless Microservices for BBC iPlayer Live Streaming
• Michelin Technology (2023/2025) — Event-Driven Architecture at Scale with Apache Kafka in Manufacturing
• Banco Central Europeo (2023/2024) — Especificaciones técnicas y arquitectura de TIPS (TARGET Instant Payment Settlement)
• Carrefour Tech (2023/2024) — Arquitectura de comercio componible y Data Mesh sobre Google Cloud
• NHS England (2023/2025) — Federated Data Platform (FDP) and HL7 FHIR Interoperability Architecture
• Inditex Tech (2023/2024) — Inditex Open Platform (IOP) Composable Architecture for Global Retail
¿Planeando una evolución en sus sistemas de información?
Hablemos de sus desafíos de alineación estratégica, cumplimiento o despliegue.
Comments (0)