El Modelo de Federación para Sistemas de Diseño es la estructura operativa que decide quién posee el sistema raíz, quién posee los subsistemas de los equipos de producto y cómo se mueven las contribuciones entre ellos. La elección de federación está río arriba de toda decisión de gobernanza de contribuciones, arquitectura de tokens y métrica de adopción que tomará un equipo. Elige el modelo equivocado y la gobernanza de contribuciones se vuelve un cuello de botella o una zona libre; elige el modelo correcto y los límites de propiedad enrutan los conflictos antes de que se vuelvan escalaciones.
Curtis (2015) identificó cuatro modelos canónicos de equipo: solitario (un diseñador mantiene el sistema), centralizado (un equipo dedicado de sistemas posee todo), federado (los diseñadores de los equipos de producto poseen colectivamente el sistema) y cíclico (los equipos de producto rotan a través del trabajo de sistemas). Cada modelo tiene una estructura de costos distinta, un patrón de adopción distinto y un modo de fallo distinto. La elección no es una preferencia; es una función del tamaño de la organización, la superficie de producto y la autonomía de los equipos de producto.
Kniberg e Ivarsson (2014) en Spotify introdujeron el vocabulario de squads-tribes-chapters-guilds que se volvió la referencia canónica de federación organizacional fuera del diseño. Su insight estructural se trasplanta directamente: los chapters son la capa horizontal federada que permite a los squads autónomos compartir estándares, que es el mismo patrón operativo que necesita una federación de sistemas de diseño.
El principio: Nombra el modelo. Dibuja los límites de propiedad explícitamente. Documenta la ruta de escalación antes de que ocurra el primer conflicto.