Confronto
MapleSpire o Structurizr: quale regge la governance di una grande azienda?
Structurizr e MapleSpire si basano entrambi sul modello C4 e su un vero modello, non su disegni. Divergono su una questione decisiva per una grande organizzazione: dove vivono i metadati condivisi e chi può tenerli aggiornati.
Structurizr dà il meglio quando l’architettura è codice, scritto e revisionato in Git da team di ingegneria. MapleSpire punta a un repository governato: un unico insieme di cataloghi di tag e tecnologie per tutta l’organizzazione, modificabile visualmente da chiunque ne abbia il diritto.
Due filosofie di modellazione
Structurizr è uno strumento di “modelli come codice”: l’architettura si scrive in un DSL testuale, si versiona in Git e si pubblica su un server che genera i diagrammi. La documentazione consiglia un workspace per sistema software, affidato al team che lo costruisce.
MapleSpire è un modello visuale condiviso: oggetti, relazioni e viste vivono in un database, si modificano insieme in tempo reale e restano disponibili offline. I cataloghi di tag e tecnologie sono entità dell’organizzazione, non testo copiato in ogni file.
Nessuno dei due approcci è migliore in assoluto. La differenza emerge quando crescono il numero di team, di sistemi e di persone che contribuiscono.
Assegnare i metadati: tag, tecnologie, versioni, gruppi
| Metadato | Structurizr | MapleSpire |
|---|---|---|
| Tag | Testo libero per elemento (tags "A,B"); stili legati al testo del tag | Tag e gruppi di tag definiti una volta per l’organizzazione, referenziati per identificativo |
| Rinominare o unire un tag | Trova e sostituisci in ogni workspace | Rinomina, ricolora, unisci o archivia: applicato ovunque, in tutti i landscape |
| Tecnologie | Testo libero (technology "Java") | Catalogo gestito: alias, icone chiare e scure, link alla documentazione |
| Ciclo di vita di una tecnologia | Non modellato | Attiva, deprecata, dismessa o unita; le nuove voci passano per un’approvazione |
| Versione in uso | Da aggiungere a mano nel testo o in properties | Versione registrata su ogni utilizzo di una tecnologia |
| Gruppi e domini | Gruppi visuali dichiarati nel DSL | Gruppi che possono portare tag e tecnologie; domini gerarchici |
| Proprietà personalizzate | properties e perspectives (coppie chiave-valore libere) | Previste nel modello, non ancora modificabili nell’interfaccia |
In Structurizr un elemento si descrive con le parole chiave tags, technology, properties e perspectives. Sono stringhe libere, digitate elemento per elemento. Gli archetypes forniscono valori predefiniti e gli stili si agganciano ai tag, ma non esiste un registro centrale che definisca che cos’è un tag o una tecnologia valida.
In pratica, “PostgreSQL”, “Postgres” e “postgresql 16” possono convivere in workspace diversi. Rinominare un tag significa fare un trova-e-sostituisci in tutti i repository coinvolti, e nulla impedisce di usare una tecnologia che l’organizzazione ha dismesso.
In MapleSpire un oggetto non memorizza il testo di un tag: memorizza un riferimento a un tag definito una sola volta per l’organizzazione. Le tecnologie provengono da un catalogo gestito, con alias, icone e un ciclo di vita.
E i responsabili?
La titolarità di un elemento (quale team ne risponde) è spesso il primo metadato richiesto da un processo di governance. In Structurizr finisce in una proprietà libera, per esempio una chiave owner, senza alcun legame con un elenco dei team.
MapleSpire gestisce già i team per il controllo degli accessi e il suo modello prevede di assegnare team responsabili agli oggetti. Questa assegnazione però non è ancora disponibile nell’interfaccia: preferiamo dirlo chiaramente piuttosto che prometterla.
Aggiornare una volta, per tutti
Per una vista aziendale, Structurizr suggerisce un percorso in tre passi: riunire i sistemi software in un catalogo DSL condiviso tramite URL, far estendere quel catalogo a ogni workspace di team, poi generare un landscape complessivo. Quel landscape lo produce un amministratore che scarica tutti i workspace, esegue il generatore e pubblica il risultato. È una copia: va rigenerata per riflettere le modifiche successive.
In MapleSpire tag e tecnologie vivono nel database dell’organizzazione. Una modifica fatta nella console di amministrazione è visibile subito in tutti i landscape, senza alcun passaggio di pubblicazione. All’interno di un landscape ogni oggetto esiste una sola volta e ogni diagramma vi fa riferimento.
Due precisazioni, per correttezza. In MapleSpire il modello dettagliato resta circoscritto a ciascun landscape; solo i cataloghi sono condivisi in tutta l’organizzazione. Inoltre ogni utilizzo di una tecnologia conserva la revisione del catalogo con cui è stato registrato, così una modifica al catalogo non riscrive mai la storia in silenzio.
Controllo degli accessi e revisione delle modifiche
Il nucleo open source di Structurizr server non ha autenticazione né controllo degli accessi basato sui ruoli: i workspace sono pubblici. Ruoli, SAML, LDAP e l’API di amministrazione arrivano con i binari precompilati sotto licenza. La sua grande forza sta altrove: poiché il modello è codice, ogni modifica può passare da una pull request, una revisione e una validazione automatica in CI.
Il codice AGPL-3.0 di MapleSpire include ruoli di organizzazione, team con permessi di lettura o scrittura per landscape, single sign-on OIDC con Google o Microsoft e un registro di audit delle azioni amministrative. Le modifiche si preparano in bozze, con un elenco delle modifiche e un merge che rileva i conflitti.
Limite attuale: le bozze di MapleSpire non hanno ancora un passaggio formale di approvazione prima del merge. Se la tua governance richiede la revisione obbligatoria di ogni modifica, il flusso a pull request di Structurizr oggi è più rigoroso.
Quale scala meglio?
| Criterio | Structurizr | MapleSpire |
|---|---|---|
| Vocabolario coerente tra i team | Dipende da disciplina e revisioni | Garantito da cataloghi unici |
| Persone che non sviluppano | Devono imparare il DSL e Git | Modifica visuale, multiutente, in tempo reale |
| Quadro d’insieme aggiornato | Landscape rigenerato su richiesta | Cataloghi condivisi in tempo reale; modello dettagliato per landscape |
| Revisione obbligatoria delle modifiche | Pull request e CI | Bozze e merge, per ora senza approvazione formale |
| Controllo degli accessi e SSO | Binari sotto licenza | Inclusi nel codice open source |
| Alta disponibilità | Dipende da archiviazione e licenza scelte | Per ora la sincronizzazione gira su una singola istanza |
Se la tua sfida è far parlare a tutta l’organizzazione la stessa lingua (gli stessi tag, tecnologie e versioni) e coinvolgere architetti, responsabili di prodotto e team che non vivono in Git, MapleSpire scala meglio per la governance.
Se la tua architettura è già gestita come codice, chi contribuisce sono sviluppatori e la governance passa dalla revisione delle pull request, Structurizr resta un’ottima scelta.
Migrare, o usarli entrambi
MapleSpire importa un workspace Structurizr DSL e genera i diagrammi C4 corrispondenti. Esporta anche verso Structurizr DSL, Mermaid, JSON, CSV, SVG, PNG e Markdown, quindi puoi provare MapleSpire su un workspace esistente senza rinunciare ai tuoi file.
Fonti
Le affermazioni su Structurizr si basano sulla sua documentazione ufficiale, consultata il 12 ottobre 2026. Le funzionalità di MapleSpire descritte qui sono quelle del codice pubblicato.