Arquitectura composable vs plataforma monolítica

El problema de negocio detrás del tema

Composable y monolítico se presentan como opciones ideológicas. En realidad, la decisión depende de diferenciación, velocidad, madurez técnica, costes de integración y capacidad para gobernar un ecosistema. En las empresas de servicios, la decisión no termina cuando el usuario pulsa “comprar”: la promesa digital debe conectarse con operaciones, atención, datos y rentabilidad. Por eso, este asunto debe tratarse como una decisión de negocio y no como una mejora aislada de marketing o tecnología.

Las dimensiones que conviene resolver

Un enfoque sólido combina cuatro dimensiones. Analizarlas por separado ayuda a detectar fricciones; gestionarlas como sistema permite que el canal directo crezca sin trasladar complejidad al cliente ni a la organización.

1. Diferenciación y ritmo

Composable aporta independencia cuando dominios cambian a ritmos distintos o crean ventaja. Una suite integrada puede acelerar capacidades estándar y reducir decisiones técnicas. La capacidad debe comprobarse con escenarios guionizados, datos representativos y excepciones, no solo con una afirmación de cobertura. La evidencia reduce la ambigüedad comercial.

2. Integración y consistencia

Más componentes requieren contratos, events, identity, observability y ownership. El desacoplamiento técnico puede aumentar acoplamiento organizativo si no hay estándares. También hay que mapear integración, datos, identidad, seguridad, rendimiento y resiliencia. La funcionalidad visible es solo una parte de la solución que deberá operar en producción.

3. Operación y talento

Evaluar product teams, platform engineering, SRE, security, vendor management y soporte. La flexibilidad solo existe si el equipo puede ejercerla. El análisis debe incluir esfuerzo de configuración, soporte, releases, observabilidad y skills internos. Una plataforma flexible puede seguir siendo lenta si la operación es compleja.

4. Economía y opcionalidad

Comparar licencias, implementación, middleware, cloud, testing, incidentes, upgrades y salida. La opcionalidad tiene un coste que debe vincularse a decisiones futuras probables. Finalmente, conviene conectar ownership, TCO, riesgo contractual y salida. La decisión tecnológica es sostenible cuando conserva control sobre coste y evolución.

Una hoja de ruta práctica

La secuencia importa. Empezar por la herramienta o por una lista de funcionalidades suele producir un proyecto costoso y difícil de gobernar. La siguiente hoja de ruta fuerza primero las decisiones y después la implementación.

1. Mapear dominios y change rate. Identificar qué necesita independencia real.

2. Evaluar capability maturity. Medir arquitectura, delivery, operations y governance.

3. Diseñar opciones híbridas. Separar core estable de experience o decision layers.

4. Modelar escenarios de TCO. Comparar build, integration, run y change a cinco años.

5. Tomar decisión por dominio. Evitar una regla única para toda la plataforma.

Cómo medir si funciona

Un cuadro de mando útil no acumula indicadores: conecta comportamiento, economía y ejecución. Conviene revisar las métricas por segmento, dispositivo, mercado y etapa del recorrido para evitar que los promedios oculten el problema.

• Lead time for change: Tiempo neto desde decisión hasta producción.

• Dependency load: Equipos y componentes necesarios por cambio.

• Run cost: Coste de plataforma, integración y operación.

• Incident complexity: Tiempo de detección, diagnóstico y recuperación cross-system.

• Replaceability: Esfuerzo probado para cambiar un componente sin reescribir el sistema.

Errores frecuentes que reducen el impacto

• Elegir composable para parecer moderno sin product operating model.

• Elegir suite por simplicidad ignorando límites de diferenciación.

• Comparar licencia de suite con componentes sin incluir integración.

• Confundir muchos proveedores con ausencia de lock-in.

La señal de alerta es sencilla: si el proyecto puede describirse únicamente con el nombre de una plataforma, una campaña o un rediseño, probablemente todavía no está suficientemente conectado con el resultado de negocio.

Conclusión

La respuesta suele ser híbrida. Conviene comprar capacidades maduras y reservar modularidad para dominios donde el negocio necesita experimentar, diferenciarse o cambiar de proveedor con una frecuencia justificable.