Software Architecture
Explica cómo estructuras de comunicación, ownership y carga cognitiva influyen en la arquitectura mediante Conway y los principios de Team Topologies.
La arquitectura de software es sociotécnica: sus límites, dependencias y velocidades de cambio están condicionados por cómo se comunican los equipos, qué poseen y cuánta complejidad pueden comprender y operar.
Un diagrama puede separar servicios con líneas perfectas, pero si cinco equipos deben reunirse para cambiar una funcionalidad, la independencia es ficticia.
estructura organizacional
↕
patrones de comunicación
↕
ownership y responsabilidades
↕
arquitectura del sistemaLa relación funciona en ambas direcciones. La organización influye en el sistema y la arquitectura obliga a determinados patrones de coordinación.
La ley de Conway observa que las organizaciones tienden a producir sistemas que reflejan sus estructuras de comunicación.
Si frontend, backend y base de datos son silos separados, es probable que cada funcionalidad necesite pasar por tres colas. Si cada equipo posee un flujo de valor completo, el sistema puede evolucionar alrededor de esas capacidades.
No significa que el organigrama determine mecánicamente cada componente. Significa que los canales de comunicación ejercen una fuerza persistente sobre el diseño.
Muchos problemas atribuidos a tecnología son problemas de ownership y coordinación:
Una arquitectura que no puede ser mantenida por la organización real se degradará, aunque sea técnicamente elegante.
Una frontera saludable suele alinear:
capacidad de negocio
→ módulo o servicio
→ datos y contratos
→ equipo owner
→ operación y evoluciónCuando estas unidades no coinciden, aparecen handoffs y coordinación.
Ejemplo:
Pedidos: equipo A desarrolla lógica
Inventario: equipo B modifica la misma tabla
Plataforma: equipo C despliega
Soporte: equipo D investigaNadie posee el resultado completo.
Consiste en diseñar o ajustar la estructura de equipos para favorecer la arquitectura deseada.
Si se busca que Pagos evolucione de forma independiente, no basta con extraer un servicio. Debe existir:
Crear el servicio antes de crear estas condiciones distribuye complejidad sin obtener autonomía.
Team Topologies propone tipos de equipo y modos de interacción para reducir carga cognitiva y mejorar flujo. No debe aplicarse como organigrama rígido; es un lenguaje para diagnosticar responsabilidades.
Posee un flujo de valor o capacidad de negocio y puede entregar cambios con pocas dependencias externas.
Ejemplos:
Un equipo alineado al flujo necesita suficiente capacidad para desarrollar, probar, desplegar y operar su ámbito.
No significa duplicar cada especialidad. Puede apoyarse en plataforma y equipos facilitadores.
Proporciona capacidades internas como producto para reducir carga cognitiva:
La plataforma debe ofrecer una experiencia autoservicio y comprensible. Si cada uso requiere abrir un ticket, funciona como silo, no como plataforma efectiva.
La plataforma no debe absorber lógica de negocio para “centralizar”. Su objetivo es facilitar capacidades comunes.
Ayuda temporalmente a otros equipos a adquirir una capacidad:
No se convierte en dueño permanente de todo lo difícil. Facilita aprendizaje y luego reduce su participación.
Posee un subsistema que exige conocimiento especializado y que aumentaría demasiado la carga cognitiva de un equipo de flujo.
Ejemplos posibles:
No debe usarse para separar cualquier código complejo. La especialización tiene que ser genuina y estable.
Dos equipos trabajan estrechamente durante un periodo para descubrir un límite o resolver incertidumbre.
Es intensiva y debe ser temporal. Colaboración permanente indica que los límites todavía no permiten autonomía.
Un equipo consume una capacidad mediante un contrato estable y autoservicio.
Ejemplo: un equipo utiliza pipeline y observabilidad de la plataforma sin coordinar cada cambio.
Requiere buena documentación, soporte y expectativas claras.
Un equipo ayuda a otro a aprender o adoptar una práctica sin asumir ownership.
Los modos pueden cambiar con el tiempo. Durante una migración puede existir colaboración; después, servicio estable.
La carga cognitiva es la cantidad de conocimiento que un equipo necesita para realizar su trabajo.
Complejidad esencial del dominio.
Complejidad accidental: tooling inconsistente, despliegues manuales, APIs confusas.
Conocimiento que permite mejorar el sistema y su modelo mental.
La arquitectura debe reducir carga extrínseca y mantener el ámbito dentro de una capacidad razonable.
Un equipo responsable de veinte servicios, cinco brokers, tres bases y múltiples dominios puede tener ownership nominal, pero no comprensión efectiva.
Microservicios prometen despliegue y evolución independientes. Para obtenerlos se necesitan:
Con un solo equipo, dividir en numerosos servicios suele añadir:
No crea paralelismo organizacional que no existe.
Un monolito modular puede alinear responsabilidades y conservar opción de extracción futura.
Poseer un componente implica más que aprobar pull requests.
Incluye:
You build it
+ you run it
+ you evolve it
+ you communicate its contractEl ownership puede compartirse temporalmente durante una migración, pero necesita límites y fecha.
Además de APIs técnicas, los equipos necesitan una interfaz organizacional:
Una API técnica estable con un equipo inaccesible sigue produciendo fricción.
Cada dependencia organizacional introduce espera.
análisis → frontend → backend → DBA → plataforma → seguridadAunque cada etapa tarde poco en trabajar, la espera acumulada puede dominar el lead time.
La arquitectura y los equipos deben reducir handoffs para cambios frecuentes. No todos los especialistas tienen que pertenecer a cada equipo; plataforma, estándares y facilitación permiten compartir capacidades sin crear tickets constantes.
En una etapa inicial con un equipo pequeño, una estructura coherente podría ser:
DomiSys application
├── Identity & Tenancy
├── Catalog & Inventory
├── Sales & POS
├── Orders & Delivery
├── Purchasing
└── Reporting projectionsLos módulos tienen boundaries y ownership conceptual, pero se despliegan como una unidad.
¿Por qué?
Señales para cambiar:
La futura extracción debe seguir límites ya probados, no inventarlos durante la separación.
Un equipo pequeño crea un “platform team” de una persona que controla Docker, CI, bases y despliegues. Todos los demás abren tickets.
Consecuencias:
Alternativa inicial:
Los patrones de comunicación pueden diseñarse.
Reducen coordinación síncrona para interacciones estables.
Comparten estándares sin centralizar ownership.
Permiten revisar decisiones amplias y conservar contexto.
Útiles para boundaries nuevos o migraciones.
La comunicación cero no es autonomía. La meta es comunicación apropiada: intensa durante descubrimiento, baja y contractual durante operación estable.
Señales útiles:
No uses estas métricas para castigar equipos. Sirven para detectar fricción sistémica.
Un departamento no siempre representa un bounded context. Puede crear silos técnicos.
Sin plataforma, equipos y escala equivalentes, se copian costos pero no beneficios.
Asignar un nombre no entrega permisos, tiempo, conocimiento ni operación.
Centraliza decisiones y crea tickets en lugar de autoservicio.
Si cada cambio requiere varias reuniones, revisa boundaries o contratos.
Demasiados servicios y herramientas reducen calidad y velocidad.
La arquitectura necesita relaciones estables para acumular conocimiento. Reorganizaciones frecuentes crean boundaries huérfanos.
Pregunta:
Build vs buy y dependencias estratégicas analiza cuándo una capacidad debe construirse, comprarse o consumirse como servicio y cómo controlar el riesgo de dependencia.