Cada plataforma empresarial llega tarde o temprano al mismo momento: hay que cambiar una pieza, y cambiarla implica tocar todo. El CRM que ya no sirve está enredado con la facturación, la facturación con el inventario, el inventario con el portal del cliente. Lo que debería ser una decisión de tres meses se convierte en un reemplazo de plataforma de dos años. La arquitectura componible existe para que ese momento no vuelva a llegar.
La respuesta corta: componible no significa muchas piezas, significa piezas reemplazables. Se logra definiendo costuras donde el negocio realmente cambia, conectándolas con contratos estables y midiendo el acoplamiento con evidencia operativa, no con diagramas. Y hay un momento en que fragmentar es exactamente lo contrario de lo que conviene.
¿Qué es realmente la arquitectura componible?
Es diseñar por capacidades intercambiables, no por módulos dibujados en una lámina.
La unidad de una arquitectura componible es la capacidad de negocio empaquetada: un componente autocontenido que entrega valor de negocio completo y claro por sí mismo, con un contrato explícito hacia afuera. Cotización, facturación, identidad, catálogo y ruteo son ejemplos típicos. La prueba no es cuántas piezas tienes, sino si puedes cambiar una sin negociar con las demás.
El mercado se está moviendo en esa dirección de forma medible. Gartner proyecta que para 2026 al menos el 70% de las organizaciones tendrá el mandato de adquirir tecnología de plataforma de experiencia digital componible en lugar de suites monolíticas, frente al 50% en 2023 [1].
Datos
| Año | Porcentaje de organizaciones |
|---|---|
| 2023 | 50% |
| 2026 (proyectado) | 70% |
¿Componible es lo mismo que microservicios?
No, y confundirlos es el error más caro de esta conversación.
Los microservicios son una decisión de despliegue. Componible es una propiedad del diseño. Puedes tener veinte microservicios que deben desplegarse juntos porque comparten base de datos, y eso no es componible: es un monolito distribuido con factura de nube. Y puedes tener un solo despliegue, un monolito modular, con fronteras internas tan limpias que reemplazar el módulo de cotización es un trabajo de dos semanas.
La investigación de DORA lo dice sin ambigüedad: la arquitectura, no la elección de tecnología, es lo que determina el desempeño de entrega, y el patrón funciona igual en un mainframe que en microservicios [2]. Lo que importa es si los equipos pueden hacer cambios grandes sin permiso externo, probar sin ambientes integrados y desplegar de forma independiente de otros servicios [2].
¿Qué dicen tres posiciones expertas?
Hay un desacuerdo real aquí, y conviene verlo antes de elegir.
Posición 1. Componible como dirección de mercado (Gartner). El análisis de Gartner sostiene que la modularidad componible es un objetivo creciente de arquitectura e inversión, empujado por la demanda de agilidad de negocio, y que la compra empresarial se está moviendo de suites monolíticas a componentes intercambiables [1]. Bajo esta lectura, quien no modularice queda atado al ritmo de un proveedor.
Posición 2. Empieza monolito, no fragmentes al inicio (Martin Fowler). La posición contraria es incómoda y está bien documentada. Fowler escribió que "no deberías empezar un proyecto nuevo con microservicios, incluso si estás seguro de que tu aplicación será lo bastante grande como para que valgan la pena", y observó que "casi todas las historias exitosas de microservicios empezaron con un monolito que creció demasiado y fue partido", mientras que "casi todos los casos de sistemas construidos como microservicios desde cero terminaron en problemas serios" [3]. Su razón de fondo es que incluso arquitectos experimentados en dominios conocidos tienen enorme dificultad para acertar las fronteras al principio, y refactorizar funcionalidad entre servicios es mucho más difícil que hacerlo dentro de un monolito [3].
Posición 3. La costura, no la cantidad (Neo Bernal, co-fundador de MasterDragon.AI).
El patrón más caro que me toca encontrar es siempre el mismo: una plataforma partida en más de diez servicios antes de tener el primer cliente. Desplegar una funcionalidad toma días y exige coordinar a varias personas. El diagrama es hermoso. La operación está trabada. Opino sobre esto no porque tenga una teoría de arquitectura, sino porque el trabajo de desandar esas separaciones se parece siempre.
En esos equipos la pregunta suele ser «¿por qué nos quedó tan lento?», y esa pregunta solo reparte culpas entre quienes dibujaron el diagrama. La que destraba es otra: «¿para qué separamos cada pieza?». Cuando la haces servicio por servicio, la mayoría no tiene respuesta.
Con eso a la vista, Gartner y Fowler dejan de contradecirse: Gartner describe hacia dónde debe evolucionar un sistema maduro, y Fowler describe cómo llegar ahí sin quebrarse en el camino. Lo que resuelve la tensión es cambiar la unidad de medida, y dejar de contar piezas para empezar a medir costo de cambio. En la práctica eso son tres movimientos:
- Arranca modular pero desplegado junto, con fronteras internas explícitas y datos con dueño claro.
- Define una frontera solo donde ya observaste que el negocio cambia a ritmos distintos, no donde el diagrama se ve mejor.
- Extrae una pieza cuando tengas la fricción medida, no cuando la intuyas.
Sin embargo, quiero ser honesto con el límite: esto no te dice cuántas piezas vas a terminar teniendo, y a veces vas a extraer una costura y descubrir a los seis meses que estaba en el lugar equivocado. La regla no elimina el error, solo lo abarata. Una costura correcta se paga sola; una costura prematura se paga dos veces.
¿Dónde van las costuras?
Donde el negocio cambia a ritmos distintos, no donde el organigrama tiene una línea.
Esta es la regla práctica que usamos: dos capacidades pertenecen a piezas distintas cuando cambian por razones distintas y con frecuencias distintas. El catálogo cambia todos los días, la contabilidad cambia con la ley, la identidad casi nunca. Si están en la misma pieza, el ritmo más lento le pone el freno al más rápido.
Tabla 1. Señales para poner o no poner una costura.
| Señal | Poner costura | No poner costura todavía |
|---|---|---|
| Ritmo de cambio | Muy distinto entre las dos partes | Cambian siempre juntas |
| Equipos | Equipos separados con dueños claros | Un solo equipo mantiene ambas |
| Datos | Cada lado es dueño de sus datos | Comparten tablas y transacciones |
| Fronteras del dominio | Ya probadas por meses de cambios | Todavía en descubrimiento |
| Motivo de la separación | Fricción observada y medida | El diagrama se ve mejor |
Fíjate en la última fila. Es la que más dinero cuesta cuando se ignora.
¿Cuál es el peor resultado posible?
El monolito distribuido, y es más común que cualquiera de los dos extremos.
Ocurre cuando partiste el sistema en servicios pero conservaste el acoplamiento: comparten base de datos, se llaman en cadena para completar una operación, y hay que desplegarlos en el mismo orden. Pagas latencia de red, complejidad de operación, observabilidad distribuida y costo de nube, y a cambio no ganas la independencia que justificaba el corte. Es el peor de los dos mundos y suele ser el resultado de fragmentar antes de conocer el dominio, exactamente el riesgo que Fowler advierte [3].
¿Cómo se comprueba que una arquitectura es componible?
Con medidas operativas, no con la lámina de arquitectura.
Un diagrama siempre se ve modular. La evidencia está en cómo trabaja el equipo. DORA propone medir exactamente esto: qué porcentaje de cambios de diseño requiere aprobación fuera del equipo, qué porcentaje de despliegues necesita coordinarse con otros servicios, cuántas horas semanales se van en coordinación entre equipos, y cuántos traspasos hay desde que el código está listo hasta que llega al usuario [2].
Si tu respuesta a "¿puede este equipo desplegar su pieza hoy sin esperar a nadie?" es no, tienes acoplamiento, sin importar cuántas cajas tenga el diagrama.
Cómo lo aplicamos en MasterDragon
Diseñamos para el costo del cambio, no para el conteo de servicios.
En nuestros desarrollos eso se traduce en una secuencia concreta: empezamos modular y desplegado junto, con fronteras internas explícitas y datos con dueño claro; observamos qué partes cambian a distinto ritmo durante los primeros ciclos reales; extraemos una pieza solo cuando la fricción está medida; y dejamos contratos versionados en cada costura para que el reemplazo futuro no requiera negociación. El resultado que buscamos es simple de enunciar y difícil de lograr: que dentro de tres años puedas cambiar cualquier pieza sin pedirle permiso al resto del sistema.
Si estás por comprometerte con una plataforma o rehacer la tuya, habla con nuestros ingenieros de IA antes de fijar las fronteras. Puedes empezar por cómo construimos tu software y revisar nuestro portafolio de productos AI-native ya lanzados. Y si la decisión de fondo es construir o rentar, la desarrollamos en el software a la medida es un activo, no un gasto.
Referencias
- Gartner. (2025, febrero). Magic Quadrant for Digital Experience Platforms, citado por MACH Alliance. https://machalliance.org/insights-hub/composable-comes-of-age-in-the-gartner-dxp-magic-quadrant
- DORA. (2025). Loosely coupled teams: capability overview. Google Cloud. https://dora.dev/capabilities/loosely-coupled-teams/
- Fowler, M. (2015, 3 de junio). MonolithFirst. martinfowler.com. https://martinfowler.com/bliki/MonolithFirst.html