Vergleich
MapleSpire oder Structurizr: Welches Werkzeug trägt Governance im Unternehmensmaßstab?
Structurizr und MapleSpire bauen beide auf dem C4-Modell auf und auf einem echten Modell statt auf Zeichnungen. Sie unterscheiden sich in einer Frage, die für eine große Organisation entscheidend ist: Wo liegen gemeinsame Metadaten, und wer kann sie aktuell halten?
Structurizr glänzt, wenn Architektur Code ist, der von Engineering-Teams in Git geschrieben und geprüft wird. MapleSpire zielt auf ein verwaltetes Repository: ein einziger Satz von Tag- und Technologiekatalogen für die ganze Organisation, visuell bearbeitbar für alle, die die Berechtigung dazu haben.
Zwei Modellierungsphilosophien
Structurizr ist ein „Models as Code“-Werkzeug: Architektur wird in einer textuellen DSL geschrieben, in Git versioniert und auf einen Server übertragen, der die Diagramme erzeugt. Die Dokumentation empfiehlt einen Workspace pro Softwaresystem, verantwortet von dem Team, das es baut.
MapleSpire ist ein gemeinsames visuelles Modell: Objekte, Beziehungen und Ansichten liegen in einer Datenbank, werden gemeinsam in Echtzeit bearbeitet und bleiben offline verfügbar. Tag- und Technologiekataloge sind Entitäten der Organisation, kein Text, der in jede Datei kopiert wird.
Keiner der beiden Ansätze ist an sich besser. Der Unterschied zeigt sich, wenn die Zahl der Teams, Systeme und Beitragenden wächst.
Metadaten zuweisen: Tags, Technologien, Versionen, Gruppen
| Metadaten | Structurizr | MapleSpire |
|---|---|---|
| Tags | Freitext pro Element (tags "A,B"); Styles hängen am Tag-Text | Tags und Tag-Gruppen einmal für die Organisation definiert, per ID referenziert |
| Tag umbenennen oder zusammenführen | Suchen und Ersetzen in jedem Workspace | Umbenennen, umfärben, zusammenführen oder archivieren: überall wirksam, in allen Landschaften |
| Technologien | Freitext (technology "Java") | Gepflegter Katalog: Aliase, helle und dunkle Icons, Links zur Dokumentation |
| Lebenszyklus einer Technologie | Nicht modelliert | Aktiv, veraltet, ausgemustert oder zusammengeführt; neue Einträge durchlaufen eine Freigabe |
| Eingesetzte Version | Selbst im Text oder in properties ergänzen | Version bei jeder Verwendung einer Technologie erfasst |
| Gruppen und Domänen | In der DSL deklarierte visuelle Gruppen | Gruppen, die Tags und Technologien tragen können; hierarchische Domänen |
| Eigene Eigenschaften | properties und perspectives (freie Schlüssel-Wert-Paare) | Im Modell vorgesehen, in der Oberfläche noch nicht bearbeitbar |
In Structurizr beschreibt man ein Element mit den Schlüsselwörtern tags, technology, properties und perspectives. Das sind freie Zeichenketten, Element für Element eingetippt. Archetypes liefern Standardwerte und Styles hängen an Tags, aber es gibt kein zentrales Verzeichnis, das festlegt, was ein gültiger Tag oder eine gültige Technologie ist.
In der Praxis können „PostgreSQL“, „Postgres“ und „postgresql 16“ in verschiedenen Workspaces nebeneinander bestehen. Einen Tag umzubenennen heißt, in jedem betroffenen Repository zu suchen und zu ersetzen, und nichts hindert jemanden daran, eine Technologie zu verwenden, die die Organisation ausgemustert hat.
In MapleSpire speichert ein Objekt nicht den Text eines Tags, sondern einen Verweis auf einen Tag, der einmal für die Organisation definiert ist. Technologien stammen aus einem gepflegten Katalog mit Aliasen, Icons und einem Lebenszyklus.
Und die Verantwortlichen?
Die Zuständigkeit für ein Element – welches Team dafür geradesteht – ist oft das erste Metadatum, das ein Governance-Prozess verlangt. In Structurizr landet sie in einer freien Eigenschaft, etwa einem owner-Schlüssel, ohne Verbindung zu einem Teamverzeichnis.
MapleSpire verwaltet Teams bereits für die Zugriffskontrolle, und sein Modell sieht vor, Objekten verantwortliche Teams zuzuordnen. Diese Zuordnung ist in der Oberfläche aber noch nicht verfügbar: Wir sagen das lieber offen, als es zu versprechen.
Einmal aktualisieren, für alle
Für eine Unternehmenssicht schlägt Structurizr ein dreistufiges Vorgehen vor: Softwaresysteme in einem per URL geteilten DSL-Katalog sammeln, jeden Team-Workspace diesen Katalog erweitern lassen und dann eine Gesamtlandschaft erzeugen. Diese Landschaft erstellt ein Administrator, der alle Workspaces abruft, den Generator ausführt und das Ergebnis veröffentlicht. Sie ist eine Kopie: Für spätere Änderungen muss sie neu erzeugt werden.
In MapleSpire liegen Tags und Technologien in der Datenbank der Organisation. Eine Änderung in der Administrationskonsole ist sofort in jeder Landschaft sichtbar, ohne Veröffentlichungsschritt. Innerhalb einer Landschaft existiert jedes Objekt genau einmal, und jedes Diagramm verweist darauf.
Zwei Einschränkungen, der Genauigkeit halber. In MapleSpire bleibt das detaillierte Modell auf die jeweilige Landschaft beschränkt; nur die Kataloge werden organisationsweit geteilt. Außerdem behält jede Verwendung einer Technologie die Katalogrevision, mit der sie erfasst wurde, sodass eine Katalogänderung die Historie nie stillschweigend umschreibt.
Zugriffskontrolle und Prüfung von Änderungen
Der Open-Source-Kern von Structurizr server hat weder Authentifizierung noch rollenbasierte Zugriffskontrolle: Workspaces sind öffentlich. Rollen, SAML, LDAP und die Admin-API gibt es mit den lizenzierten, vorgefertigten Binärdateien. Seine große Stärke liegt woanders: Weil das Modell Code ist, kann jede Änderung einen Pull Request, ein Review und eine automatisierte Prüfung in der CI durchlaufen.
Der AGPL-3.0-Code von MapleSpire enthält Organisationsrollen, Teams mit Lese- oder Schreibrechten pro Landschaft, OIDC-Single-Sign-on mit Google oder Microsoft und ein Audit-Log der Administrationsaktionen. Änderungen werden in Entwürfen vorbereitet, mit einer Änderungsliste und einem Merge, der Konflikte erkennt.
Aktuelle Grenze: Entwürfe in MapleSpire haben noch keinen formalen Freigabeschritt vor dem Merge. Wenn Ihre Governance eine verpflichtende Prüfung jeder Änderung verlangt, ist der Pull-Request-Ablauf von Structurizr heute strenger.
Welches skaliert besser?
| Kriterium | Structurizr | MapleSpire |
|---|---|---|
| Einheitliches Vokabular über Teams hinweg | Hängt von Disziplin und Reviews ab | Durch zentrale Kataloge sichergestellt |
| Beitragende ohne Entwicklerhintergrund | Müssen die DSL und Git lernen | Visuelle Bearbeitung, mehrere Personen, in Echtzeit |
| Aktuelles Gesamtbild | Landschaft wird bei Bedarf neu erzeugt | Live geteilte Kataloge; detailliertes Modell pro Landschaft |
| Verpflichtende Prüfung von Änderungen | Pull Requests und CI | Entwürfe und Merge, noch ohne formale Freigabe |
| Zugriffskontrolle und SSO | Lizenzierte Binärdateien | Im Open-Source-Code enthalten |
| Hochverfügbarkeit | Hängt von gewähltem Speicher und Lizenz ab | Synchronisation läuft vorerst als einzelne Instanz |
Wenn Ihre Herausforderung darin besteht, die ganze Organisation dieselbe Sprache sprechen zu lassen – dieselben Tags, Technologien und Versionen – und Architekten, Produktverantwortliche und Teams einzubinden, die nicht in Git zu Hause sind, skaliert MapleSpire für die Governance besser.
Wenn Ihre Architektur bereits als Code verwaltet wird, die Beitragenden Entwickler sind und Governance über Pull-Request-Reviews läuft, bleibt Structurizr eine ausgezeichnete Wahl.
Migrieren oder beide parallel nutzen
MapleSpire importiert einen Structurizr-DSL-Workspace und erzeugt die passenden C4-Diagramme. Es exportiert außerdem nach Structurizr DSL, Mermaid, JSON, CSV, SVG, PNG und Markdown, sodass Sie MapleSpire mit einem bestehenden Workspace ausprobieren können, ohne Ihre Dateien aufzugeben.
Quellen
Die Aussagen zu Structurizr beruhen auf seiner offiziellen Dokumentation, abgerufen am 12. Oktober 2026. Die hier beschriebenen Funktionen von MapleSpire sind die des veröffentlichten Codes.