Comparativa
MapleSpire o Structurizr: ¿cuál escala a la gobernanza de una gran empresa?
Structurizr y MapleSpire se basan en el modelo C4 y en un modelo real, no en dibujos. Difieren en una cuestión decisiva para una gran organización: dónde viven los metadatos compartidos y quién puede mantenerlos al día.
Structurizr brilla cuando la arquitectura es código, escrito y revisado en Git por equipos de ingeniería. MapleSpire apuesta por un repositorio gobernado: un único conjunto de catálogos de etiquetas y tecnologías para toda la organización, editable visualmente por todas las personas autorizadas.
Dos filosofías de modelado
Structurizr es una herramienta de «modelos como código»: la arquitectura se escribe en un DSL de texto, se versiona en Git y se publica en un servidor que genera los diagramas. Su documentación recomienda un workspace por sistema de software, en manos del equipo que lo construye.
MapleSpire es un modelo visual compartido: objetos, relaciones y vistas viven en una base de datos, se editan en equipo en tiempo real y siguen disponibles sin conexión. Los catálogos de etiquetas y tecnologías son entidades de la organización, no texto copiado en cada archivo.
Ningún enfoque es mejor en abstracto. La diferencia aparece cuando crece el número de equipos, sistemas y personas que contribuyen.
Asignar metadatos: etiquetas, tecnologías, versiones, grupos
| Metadato | Structurizr | MapleSpire |
|---|---|---|
| Etiquetas | Texto libre por elemento (tags "A,B"); estilos ligados al texto de la etiqueta | Etiquetas y grupos de etiquetas definidos una vez para la organización, referenciados por identificador |
| Renombrar o fusionar una etiqueta | Buscar y reemplazar en cada workspace | Renombrar, cambiar el color, fusionar o archivar: se aplica en todas partes, en todos los paisajes |
| Tecnologías | Texto libre (technology "Java") | Catálogo gestionado: alias, iconos claros y oscuros, enlaces a la documentación |
| Ciclo de vida de una tecnología | No se modela | Activa, obsoleta, retirada o fusionada; las nuevas entradas pasan por aprobación |
| Versión en uso | Añadirla a mano en el texto o en properties | Versión registrada en cada uso de una tecnología |
| Grupos y dominios | Grupos visuales declarados en el DSL | Grupos que pueden llevar etiquetas y tecnologías; dominios jerárquicos |
| Propiedades personalizadas | properties y perspectives (pares clave-valor libres) | Previstas en el modelo, aún no editables en la interfaz |
En Structurizr, un elemento se describe con las palabras clave tags, technology, properties y perspectives. Son cadenas libres que se escriben elemento a elemento. Los archetypes aportan valores por defecto y los estilos se enganchan a las etiquetas, pero no existe un registro central que defina qué es una etiqueta o una tecnología válida.
En la práctica, «PostgreSQL», «Postgres» y «postgresql 16» pueden convivir en distintos workspaces. Renombrar una etiqueta implica buscar y reemplazar en todos los repositorios afectados, y nada impide usar una tecnología que la organización ya ha retirado.
En MapleSpire, un objeto no guarda el texto de una etiqueta: guarda una referencia a una etiqueta definida una sola vez para la organización. Las tecnologías proceden de un catálogo gestionado, con alias, iconos y un ciclo de vida.
¿Y los responsables?
La propiedad de un elemento (qué equipo responde de él) suele ser el primer metadato que exige un proceso de gobernanza. En Structurizr se expresa con una propiedad libre, por ejemplo una clave owner, sin vínculo con un directorio de equipos.
MapleSpire ya gestiona equipos para el control de acceso, y su modelo contempla asignar equipos propietarios a los objetos. Esa asignación todavía no está disponible en la interfaz: preferimos decirlo claramente antes que prometerlo.
Actualizar una vez, para todos
Para una vista de empresa, Structurizr propone un enfoque en tres pasos: reunir los sistemas de software en un catálogo DSL compartido por URL, hacer que cada workspace de equipo extienda ese catálogo y generar después un paisaje global. Ese paisaje lo produce un administrador que descarga todos los workspaces, ejecuta el generador y publica el resultado. Es una copia: hay que regenerarla para que refleje los cambios posteriores.
En MapleSpire, las etiquetas y las tecnologías viven en la base de datos de la organización. Un cambio hecho en la consola de administración se ve de inmediato en todos los paisajes, sin paso de publicación. Dentro de un paisaje, cada objeto existe una sola vez y cada diagrama hace referencia a él.
Dos matices, en aras de la exactitud. En MapleSpire, el modelo detallado sigue siendo propio de cada paisaje; solo los catálogos se comparten en toda la organización. Además, cada uso de una tecnología conserva la revisión del catálogo con la que se registró, de modo que un cambio en el catálogo nunca reescribe la historia en silencio.
Control de acceso y revisión de cambios
El núcleo de código abierto de Structurizr server no tiene autenticación ni control de acceso basado en roles: los workspaces son públicos. Los roles, SAML, LDAP y la API de administración vienen con los binarios precompilados bajo licencia. Su gran fortaleza está en otra parte: como el modelo es código, cada cambio puede pasar por una pull request, una revisión y una validación automática en integración continua.
El código AGPL-3.0 de MapleSpire incluye roles de organización, equipos con permisos de lectura o escritura por paisaje, inicio de sesión único OIDC con Google o Microsoft y un registro de auditoría de las acciones de administración. Los cambios se preparan en borradores, con una lista de cambios y una fusión que detecta conflictos.
Límite actual: los borradores de MapleSpire todavía no tienen un paso formal de aprobación antes de la fusión. Si tu gobernanza exige una revisión obligatoria de cada cambio, el flujo de pull requests de Structurizr es hoy más estricto.
¿Cuál escala mejor?
| Criterio | Structurizr | MapleSpire |
|---|---|---|
| Vocabulario coherente entre equipos | Depende de la disciplina y de las revisiones | Garantizado por catálogos únicos |
| Personas que no desarrollan | Deben aprender el DSL y Git | Edición visual, multiusuario y en tiempo real |
| Visión de conjunto actualizada | Paisaje regenerado bajo demanda | Catálogos compartidos en directo; modelo detallado por paisaje |
| Revisión obligatoria de cambios | Pull requests e integración continua | Borradores y fusión, todavía sin aprobación formal |
| Control de acceso y SSO | Binarios bajo licencia | Incluidos en el código abierto |
| Alta disponibilidad | Depende del almacenamiento y la licencia elegidos | La sincronización funciona por ahora en una sola instancia |
Si tu reto es que toda la organización hable el mismo idioma (las mismas etiquetas, tecnologías y versiones) y que contribuyan arquitectos, responsables de producto y equipos que no viven en Git, MapleSpire escala mejor para la gobernanza.
Si tu arquitectura ya se gestiona como código, quienes contribuyen son desarrolladores y la gobernanza pasa por la revisión de pull requests, Structurizr sigue siendo una opción excelente.
Migrar o usar ambos
MapleSpire importa un workspace de Structurizr DSL y genera los diagramas C4 correspondientes. También exporta a Structurizr DSL, Mermaid, JSON, CSV, SVG, PNG y Markdown, así que puedes probar MapleSpire con un workspace existente sin renunciar a tus archivos.
Fuentes
Las afirmaciones sobre Structurizr se basan en su documentación oficial, consultada el 12 de octubre de 2026. Las funciones de MapleSpire descritas aquí son las del código publicado.