Standardwerkzeuge lösen keine Spezialprobleme

Das Herzstück vieler Custom Tools ist eine domänenspezifische Sprache (DSL): eine Notation, in der Experten in ihrem eigenen Vokabular arbeiten. Regeln und Best Practices werden nicht dokumentiert sondern strukturell durchgesetzt. Wissen, das heute in den Köpfen Ihrer Experten sitzt, wird im Metamodell kodiert und damit implizit verfügbar.

DSLs definieren das Vokabular und kodieren dabei sogar die Methodik selbst. Welche Konzepte in der Sprache existieren, welche Beziehungen erlaubt sind, welche Constraints gelten: Das ist die Methode, in ausführbare Sprachkonstrukte überführt. Eine gut gestaltete DSL macht es strukturell einfach, methodisch korrekt zu arbeiten, und strukturell schwierig, es falsch zu machen.

Domänensprachen können textuell, tabellarisch oder grafisch sein — entwickelt mit spezialisierten Language Workbenches wie Xtext oder JetBrains MPS, oder über das Language Server Protocol in moderne Integrationsplattformen wie VS Code eingebettet.

Auch Standard-Tool-Erweiterungen sind Custom Tools

Nicht jedes Custom Tool beginnt auf der grünen Wiese. Viele Standardwerkzeuge (z.B. Enterprise Architect, Rhapsody, Capella) bieten Erweiterungsmechanismen, über die zusätzliche Funktionalität integriert werden kann, ohne das Tool zu ersetzen. Auch solche Erweiterungen sind Custom Tools: maßgeschneidert, domänenspezifisch und den Prozessen angepasst.

Dasselbe Prinzip gilt für die Modellierungssprache selbst: Generische Sprachen wie die UML müssen nicht durch eine neue DSL ersetzt werden, wenn sie sich über Profile präzise genug an eine Methodik anpassen lassen. Stereotypen definieren domänenspezifische Konzepte, Tagged Values strukturieren Metadaten, Constraints erzwingen methodische Regeln, ohne das Basiswerkzeug zu ersetzen. In einem Automotive-Tier-1- und einem Medtech-Projekt haben wir nach der Domain-Analyse bewusst von einer eigenen DSL abgeraten und stattdessen UML mit projekteigenem Profil eingesetzt. Das Ergebnis war eine methodisch präzise Umgebung mit minimalem Werkzeugwechsel.

Wann Custom Tools sich lohnen und wann nicht

Custom Tools sind kein Allheilmittel. Sie lohnen sich dort, wo eine kleine Gruppe hochspezialisierter Experten mit Konzepten arbeitet, die kein Standardwerkzeug adäquat abbildet. Für große, heterogene Nutzergruppen mit generischen Anforderungen sind Standardprodukte meist die bessere Wahl.

Die Kernfrage: Passen die Abstraktionen und Funktionen eines bestehenden Werkzeugs gut genug zu Ihrer Domäne? Wenn ja, nutzen Sie es. Wir empfehlen unseren Kunden auch eigene Produkte wie itemis CREATE oder itemis ANALYZE, wo diese besser passen als ein Custom Tool.

In über 20 Jahren haben wir gelernt: Nicht jede Domäne braucht eine eigene Sprache. Bei einem Automotive-Tier-1-Zulieferer und einem Medtech-Unternehmen haben wir nach der Domain-Analyse bewusst von einer eigenen DSL abgeraten, da UML ausreichend war. Stattdessen haben wir das UML Tool erfolgreich in die jeweilige Toollandschaft integriert.

Strukturelle Vorteile auf einen Blick: Domänenwissen im Tool · Validierung beim Tippen · Konsistente Generierung · Integrierte Simulation · Keine Vendor-Roadmap-Abhängigkeit · Wissen bleibt im Unternehmen

Custom Tool Development ist kein Single-Stack-Thema. Die Wahl hängt von zwei Fragen ab: Welches Werkzeug eignet sich für das Design der Domänensprache? Und wo soll das Tool laufen: in der IDE, im Browser, als Erweiterung eines bestehenden Werkzeugs? Wir denken beide Achsen zusammen.

Language Workbenches: das Fundament des Sprachdesigns

Language Workbenches liefern alles, was für den Bau einer Domänensprache benötigt wird: Editor-Support, Validierung, Code-Generierung und Modellverarbeitung. Zwei Paradigmen dominieren:

Xtext steht für textuelle DSLs: die Modelle liegen als Text vor, sind damit diff- und mergebar und lassen sich nahtlos in CI/CD-Pipelines integrieren. itemis zählt zur Entstehungs-Community von Xtext (seit 2006) und stellt aktive Committer.

Langium ist der modernere, TypeScript-native Weg zu textuellen DSLs: ohne Java-Stack, von Grund auf auf das Language Server Protocol ausgelegt und damit direkt in VS Code und dessen Derivaten sowie im Browser lauffähig.

JetBrains MPS ermöglicht projektionale Editierung: Notationen, die kein Textformat abbilden kann: Tabellen, mathematische Ausdrücke, grafische Elemente. Besondere Stärke: mehrere Domänensprachen lassen sich sauber kombinieren. itemis ist Hauptmaintainer zentraler MPS-Extensions (iets3, mbeddr) und JetBrains-Partner mit 10 Jahren Erfahrung mit dieser Technologie.

Deployment-Kontext: wo das Tool läuft

VS Code & Language Server Protocol: leichtgewichtig, modern, niedrige Einstiegshürde. Der Language Server läuft unabhängig vom Editor und lässt sich in jede LSP-fähige Umgebung integrieren. Unser empfohlener Stack für Greenfield-Projekte.

Web & Cloud — für verteilte Teams und browserbasierte Kollaboration: vollwertige Modellierungsumgebungen im Browser, z.B. auf Basis des etablierten Cloud-IDE-Frameworks Eclipse Theia oder mit Modelix (beide Open Source).

Eclipse RCP: bewährt für die Erweiterung bestehender Eclipse-basierter Toolchains und Migrationsprojekte. Für Greenfield allerdings nicht empfohlen.

Erweiterungen von Standardwerkzeugen: EA, Rhapsody, Capella: Viele Standard-Tools bieten Erweiterungsmechanismen (Add-In APIs, Plugin-Frameworks), über die Custom Tools integriert werden, ohne das bestehende Werkzeug zu ersetzen. itemis hat mit der EA-Bridge ein eigenes Produkt für die Verarbeitung von Enterprise-Architect-Modellen entwickelt.

Welcher Stack passt wann?