Modellgetriebene Softwareentwicklung

Worum es geht — eine ehrliche Definition

Modellgetriebene Softwareentwicklung (Model Driven Software Development, MDSD; teilweise auch Model Driven Engineering, MDE) ist eine Vorgehensweise, die das fachliche Modell zur Quelle der Software macht. Aus diesem Modell werden anschließend per Transformation lauffähige Artefakte erzeugt — Klassen, Datenbankskripte, REST-APIs, Web-Oberflächen, Tests, Dokumentation. Das Modell ist nicht Beiwerk, sondern Hauptdarsteller.

Genau hier liegt der wichtigste Punkt der Abgrenzung. „Wir nutzen UML zur Dokumentation" ist keine modellgetriebene Entwicklung. „Wir haben ein Klassendiagramm im Confluence" ebenfalls nicht. MDSD bedeutet, dass das Modell maßgeblich ist — wenn das Modell sich ändert, ändert sich der Code automatisch. Wer den generierten Code danach manuell anpasst, hat die Methode missverstanden.

Historisch gesehen sind zwei Lager entstanden. Auf der einen Seite die Model Driven Architecture (MDA) der Object Management Group: schwergewichtig, theoretisch fundiert, mit einem zweistufigen Transformationsmodell (Plattform-unabhängiges Modell → plattformspezifisches Modell → Code). Trotz aller Eleganz hat sich MDA im Markt nie durchgesetzt — die Komplexität war für die meisten Projekte zu hoch. Auf der anderen Seite die pragmatische, oft unter dem Etikett MDA-Light zusammengefasste Variante: aus einem fachlichen Modell direkt Programmcode erzeugen, ohne den theoretischen Zwischenschritt. Dieser Artikel beschreibt die praxistaugliche Variante, die heute in den meisten Unternehmen anzutreffen ist.

Ein zweiter Begriff, der häufig im selben Atemzug fällt, ist Domain Specific Language (DSL). Eine DSL ist eine speziell für eine Domäne konstruierte Sprache — textuell oder grafisch, mit eigener Notation und Semantik. Sie ist das Mittel, mit dem das Modell formuliert wird. Hochsprachen wie Java oder C# sind, streng genommen, ebenfalls DSLs — DSLs für das Programmieren als Domäne. MDSD treibt diesen Gedanken konsequent weiter, indem es für jede Anwendungsdomäne ihre eigene Sprache zulässt.

Das magische Dreieck — und warum klassische Entwicklung darin gefangen ist

Jedes Softwareprojekt bewegt sich in einem Spannungsfeld aus drei konkurrierenden Zielen: Zeit, Kosten und Qualität. Dieses Spannungsfeld lässt sich als Dreieck darstellen, dessen Ecken die drei Ziele markieren. Jede Bewegung in Richtung einer Ecke entfernt das Projekt von den anderen beiden. Das ist nicht eine theoretische Behauptung, sondern empirische Beobachtung aus Jahrzehnten Softwareentwicklung.

Der Mechanismus ist einfach. Will man die Qualität ohne Zeitverlängerung steigern, braucht es mehr Personal — also höhere Kosten. Will man die Qualität ohne Mehrkosten steigern, dauert das Projekt länger. Will man Kosten senken ohne den Zeitrahmen zu strecken, sinkt zwangsläufig die Qualität, weil weniger Tests, weniger Reviews, weniger Refactoring stattfinden. Das Dreieck heißt „magisch", weil keine der drei Ecken sich verschieben lässt, ohne dass die anderen reagieren.

Klassische Prozessmodelle — Wasserfall, V-Modell, RUP, selbst die meisten agilen Spielarten — sind in dieser Logik gefangen. Sie können das Dreieck besser oder schlechter handhaben, aber sie können es nicht aufbrechen. Iteratives Vorgehen reduziert das Risiko, dass im falschen Quadranten gebaut wird; Code-Reviews und automatisierte Tests erhöhen die Qualität bei gleichem Zeitaufwand. Aber die grundlegende Konkurrenz der drei Ziele bleibt bestehen.

Genau hier setzt die modellgetriebene Softwareentwicklung an. Sie führt einen vierten Hebel ein: Automation. Wenn ein erheblicher Teil des Programmcodes nicht manuell geschrieben, sondern aus einem fachlichen Modell generiert wird, verschieben sich Zeit, Kosten und Qualität gleichzeitig in die gewünschte Richtung. Automation reduziert manuelle Fehler (Qualität ↑), beschleunigt die Implementierung (Zeit ↓) und senkt den Personalbedarf (Kosten ↓). Das Dreieck wird nicht aufgehoben, aber sein Wirkungsraum verschiebt sich nach außen — vorausgesetzt, in die Plattform und den Generator wurde zuvor investiert.

Diese letzte Bedingung ist der Schlüssel und der Grund, warum MDSD kein Selbstläufer ist. Im ersten Produkt einer Produktlinie zahlt MDSD drauf — die Plattform-Investition ist hoch. Erst ab dem dritten, vierten Produkt beginnt sich das Bild zu drehen. Wer ein einzelnes Produkt baut, sollte über MDSD nicht nachdenken. Wer eine Familie ähnlicher Produkte plant, kann sich den Bann des Dreiecks tatsächlich brechen.

Vom Maschinencode zur Domänensprache — eine kurze Evolution

Die Geschichte der Programmiersprachen ist die Geschichte zunehmender Abstraktion. Jeder Schritt zielte darauf, den Entwickler von technischen Details zu befreien und ihn näher an das fachliche Problem zu rücken. MDSD ist der konsequente nächste Schritt in dieser Linie.

Auf der untersten Ebene steht die Maschinensprache — einzelne Registerbefehle in Form von Opcodes. Direkt darüber kam der Assembler, der hardwarenahe Befehle in menschenlesbarer Form anbot. Mit der Verbreitung von Hochsprachen wie C, später Java und C#, verschwanden die meisten Hardware-Belange aus dem Quellcode. Entwicklerinnen konnten sich auf algorithmische und fachliche Aspekte konzentrieren, der Compiler übernahm die Übersetzung in die maschinennahe Welt.

Konkretes Beispiel: Eine simple Addition zweier Zahlen.

// In C — drei lesbare Zeilen
int addiere(int summandLinks, int summandRechts) {
  int lokal = summandLinks + summandRechts;
  return lokal;
}

// In x86-Assembler — neun Befehle
addiere(int, int):
  push rbp
  mov rbp, rsp
  mov DWORD PTR [rbp-20], edi
  mov DWORD PTR [rbp-24], esi
  mov edx, DWORD PTR [rbp-20]
  mov eax, DWORD PTR [rbp-24]
  add eax, edx
  mov DWORD PTR [rbp-4], eax
  ret

Der Sprung von C nach Assembler erhöht den Detaillierungsgrad erheblich, ohne neues fachliches Wissen hinzuzufügen. Genau das ist der Punkt: Hochsprachen abstrahieren das Wie und lassen den Entwickler beim Was. Sie sind, streng genommen, bereits DSLs — nur für eine sehr allgemeine Domäne (das Programmieren als solches).

MDSD führt diesen Gedanken zu Ende. Eine domänenspezifische Sprache abstrahiert nicht nur die Hardware, sondern auch generische Programmierkonzepte. Eine DSL für ein ERP-System spricht von „Kunde", „Vertrag", „Rolle" — nicht von „Klasse", „Attribut", „Methode". Der Generator übernimmt die Übersetzung in eine Hochsprache, die wiederum in Maschinencode kompiliert wird. Die Abstraktionsleiter wird um eine Stufe erweitert.

Das Ergebnis: Fachexperten ohne tiefe Programmierkenntnisse können fachliche Probleme analysieren, beschreiben und in Grenzen sogar implementieren. Die Kluft zwischen Fachbereich und Entwicklung — das alte IKIWISI-Phänomen, „I'll know it when I see it" — schrumpft, weil das Modell selbst lesbar wird. Anforderungen lassen sich gegen ein lauffähiges Modell-Artefakt diskutieren, nicht gegen eine Prosa-Spezifikation.

Die drei Bausteine: Modell, Metamodell, Generator

Wer MDSD ernsthaft betreibt, braucht drei Artefakte. Sie hängen voneinander ab und definieren gemeinsam, was möglich und was unmöglich ist.

Das Modell — die fachliche Beschreibung

Ein Modell beschreibt das fachliche Problem auf einer höheren Abstraktionsebene als der Programmcode. Es kann textuell oder grafisch sein, statisch (Daten, Strukturen, Beziehungen) oder dynamisch (Zustandsmaschinen, Abläufe, Workflows). Wichtig: Ein Modell ist nicht „dieselbe Information in hübscher Form", sondern eine Verdichtung, die ausschließlich fachliche Belange enthält und auf technische Details verzichtet. Eine Schnittstelle nach SAP gehört nicht ins Modell — der Generator weiß, wie das gemacht wird.

Das Metamodell — die Grammatik der Modelle

Das Metamodell ist die formale Definition dessen, was ein Modell überhaupt enthalten darf. Es legt die Sprache fest: welche Konzepte existieren, welche Beziehungen sie eingehen können, welche Regeln gelten. Für ein ERP-Metamodell wären das etwa Konzepte wie User, Relation, Domänenlogik; das konkrete Modell instanziiert diese Konzepte für einen Anwendungsfall (Kunde, Mitarbeiter, Ansprechpartner-Relation).

In der Praxis baut man selten ein Metamodell von Null. Statt dessen erweitert man UML um Stereotypen — sogenannte UML-Profile. Aus dem Stereotyp «User» wird eine eigene Bedeutungsschicht über dem generischen UML-Konzept „Class". Das Tooling existiert, die Lernkurve ist überschaubar, und das Metamodell bleibt portabel. Wer noch tiefer einsteigen will, definiert sein Metamodell mit der Meta Object Facility (MOF) oder mit Werkzeugen wie EMF (Eclipse Modeling Framework) oder Xtext.

Der Generator — die Transformation

Der Generator ist die ausführende Komponente. Er nimmt das Modell als Eingabe und erzeugt Artefakte: Klassen, Datenbankskripte, REST-Endpunkte, Web-Oberflächen, Testcode, Dokumentation. Er kapselt das Wissen darüber, wie in einer bestimmten Plattform gebaut wird — Spring Boot mit Hibernate, ASP.NET mit Entity Framework, Quarkus mit Panache. Wenn das Team später die Plattform wechselt, ändert sich nicht das Modell, sondern der Generator.

Genau dort liegt einer der größten wirtschaftlichen Hebel der modellgetriebenen Entwicklung: Plattformwechsel, die in manueller Entwicklung Jahre verschlingen würden, lassen sich auf Wochen verkürzen, weil das fachliche Wissen unangetastet bleibt.

Domain Engineering und Application Engineering

Anders als klassische Softwareentwicklung kennt MDSD zwei Prozesse, die nebeneinander laufen: einen, der die Werkzeuge baut, und einen, der die Anwendungen baut.

Domain Engineering — die Vorarbeit

Das Domain Engineering beantwortet die Frage: Was ist diese Domäne, und wie bauen wir eine Plattform, mit der man Produkte dieser Domäne effizient herstellt? Drei Schritte:

1. Domänenanalyse — das Domänenwissen wird systematisch erhoben. Welche Begriffe gibt es, welche Konzepte wiederholen sich, welche Regeln gelten domänenweit. Hier entsteht das Vokabular, das später im Metamodell auftaucht.
2. Domänenentwurf — Referenzarchitekturen und Lösungsstrategien für die Domäne werden entwickelt. Welche Plattform-Bausteine sind nötig, welche Bibliotheken, welche Middleware. Es entsteht der Bauplan für die spätere Produktlinie.
3. Domänenimplementierung — die Plattform wird tatsächlich gebaut: Komponenten, Bibliotheken, der Generator, die DSL. Das Ergebnis ist eine sogenannte Softwareproduktionsstraße, auf der spätere Produkte hergestellt werden.

Application Engineering — die eigentliche Anwendung

Das Application Engineering baut konkrete Produkte auf der Plattform auf. Auch hier drei Schritte:

1. Anforderungsanalyse — was soll dieses spezifische Produkt leisten. Eine Versicherungsgesellschaft etwa braucht eine Police für die Kraftfahrzeug-Sparte und eine andere für die Lebensversicherung; beide Produkte gehören in dieselbe Produktlinie, unterscheiden sich aber in den fachlichen Details.
2. Produktkonfiguration — das Modell wird auf Basis der Plattform und der DSL spezifiziert. Hier sitzt der eigentliche Mehrwert: Fachexperten arbeiten mit einer Sprache, die ihre Welt beschreibt, nicht mit einer Programmiersprache.
3. Integration und Test — der Generator erzeugt die Artefakte, sie werden integriert und gegen die Anforderungen getestet.

Domäne, Plattform, Produkt

Die drei Begriffe lassen sich in einem klaren Verhältnis zueinander darstellen. Eine Domäne definiert das Wissensgebiet — etwa „Verwaltung kommunaler Bürgeranträge". Sie wird durch ein Metamodell beschrieben. Die Plattform ist das technische Fundament — Middleware, Bibliotheken, Komponenten, Aspekte —, das die Domäne unterstützt. Sie ist das Ergebnis des Domain Engineering. Das Produkt schließlich ist die konkrete Anwendung — ein Bürgerportal für die Stadt Musterstadt — die auf der Plattform aufsetzt und über das Modell konfiguriert wird. Mehrere Produkte derselben Domäne bilden eine Produktlinie, die ihren wirtschaftlichen Hebel aus der gemeinsamen Plattform zieht.

MDSD und agile Vorgehensmodelle — kein Widerspruch

Ein häufiges Missverständnis: MDSD klinge nach „Wasserfall durch die Hintertür", weil der Aufbau einer Plattform Zeit braucht. In der Praxis ist die Kombination aus agilem Vorgehen und modellgetriebener Entwicklung sogar besonders fruchtbar. Modelle erhöhen die Abstraktions­ebene des Informations­austauschs zwischen Auftraggeber und Entwicklung — sie sind kundenorientierter als Klassen­diagramme und gleichzeitig formaler als Prosa-Anforderungen. Wer in Sprints arbeitet, profitiert davon doppelt: Anforderungs­änderungen lassen sich am Modell diskutieren, und der Generator produziert zwischen zwei Sprints eine lauffähige Variante, die im Review-Termin vorgeführt werden kann.

Notations­standards wie BPMN (Business Process Model and Notation) verstärken diesen Effekt zusätzlich, weil sie ohne Programmier­kenntnisse interpretierbar sind. Fachanwender lesen ein BPMN-Diagramm und reagieren auf das, was sie sehen — nicht auf eine Vermutung, was hinter einem User-Story-Text stecken könnte. Genau dieses Vorgehen kennen wir aus der Bauindustrie: Bauherren diskutieren Pläne und Modelle, nicht Tabellen mit Stahltragwerksberechnungen. MDSD bringt dieselbe Mechanik in die Software.

Wirtschaftliches Potenzial — wann der Break-Even kommt

MDSD lohnt sich, das ist die These der Methode. Aber unter welchen Bedingungen, und ab welchem Punkt? Die Antwort hängt entscheidend davon ab, ob die Plattform und der Generator eigens für die Produktlinie entwickelt werden — der „klassische" MDSD-Aufbau — oder ob ein fertiges Open-Source- bzw. kommerzielles Werkzeug zum Einsatz kommt. Beide Szenarien stellen wir der klassischen Entwicklung gegenüber.

Die Logik ist überschaubar. Bei der traditionellen Entwicklung kostet jedes Produkt einer Produktlinie ungefähr denselben Betrag — wir nennen ihn C_T. Nach fünf Produkten sind 5·C_T ausgegeben. Bei der MDSD mit Eigenbau-Generator fallen zunächst hohe Initialkosten an: die Plattform muss gebaut, der Generator entwickelt, die DSL entworfen werden. Diese Investition wirkt wie ein fixer Sockelbetrag, oft in der Größenordnung von zwei klassischen Produkten. Jedes folgende Produkt kostet dann allerdings nur noch C_MDSD — typischerweise 30 bis 50 Prozent von C_T. Bei der MDSD mit fertigem Generator schrumpft die Initialinvestition auf den Adoptions- und Lizenzaufwand; die Kosten pro Produkt liegen in derselben Größenordnung wie beim Eigenbau, gelegentlich etwas höher, weil das Werkzeug nicht perfekt auf die Domäne passt.

Die Folge: Im Eigenbau-Szenario verliert MDSD bei einem einzelnen Produkt klar. Beim zweiten Produkt ist die Methode noch hinten. Bei drei Produkten liegen beide Ansätze etwa gleichauf. Ab dem vierten Produkt zieht MDSD davon, und der Vorsprung wächst mit jedem weiteren Produkt. Im Szenario mit fertigem Generator entfällt diese Hürde fast vollständig — MDSD ist bereits ab dem ersten Produkt günstiger, und der Vorsprung wächst danach kontinuierlich. In Branchen mit großen Produktfamilien — Versicherungen, Banken, kommunale Fachverfahren, Energie-Abrechnungssysteme — kann der Vorsprung im Lebenszyklus einer Plattform-Generation spürbare Millionenbeträge betragen.

Zwei Vereinfachungen seien hier ausdrücklich eingestanden. Erstens kostet in der Realität nicht jedes Produkt einer Produktlinie denselben Betrag C_T — frühe Produkte sind in der Regel teurer, weil das Team die Domäne erst durchdringt und Bibliotheken erst noch entstehen; spätere Produkte profitieren von Wiederverwendung und Plattform-Reife. Zweitens gilt dasselbe für C_MDSD: die ersten Produkte tragen noch Werkzeug-Kinderkrankheiten und Generator-Iterationen, spätere laufen runder. Dazu kommt die Komplexitäts­streuung — manche Produkte sind aus Domänen­sicht trivial, andere haben Sonderwünsche, die einzelne Linien sprengen. Die Break-Even-Rechnung bleibt als Größenordnung tragfähig; sie ersetzt aber keine Produkt-für-Produkt-Schätzung in einer konkreten Roadmap.

Eigenbau-Generator versus fertige Werkzeuge

Die Investitionsrechnung sieht je nach Werkzeugwahl deutlich anders aus. Im Eigenbau-Szenario — Plattform, DSL und Generator werden eigens für die Produktlinie entwickelt — gilt die oben skizzierte Logik: hohe Initialinvestition, Break-Even typischerweise beim dritten Produkt. Diese Variante lohnt sich nur, wenn die Domäne so spezifisch ist, dass kein Werkzeug am Markt sie ohne erhebliche Verbiegungen abdeckt, oder wenn die Plattform selbst zum strategischen Differenzierungsmerkmal werden soll.

Im Szenario mit fertigem Generator ändert sich die Rechnung grundlegend. Im Open-Source-Bereich existieren ausgereifte Werkzeuge wie JHipster, Spring Roo, Yeoman, JetBrains MPS, Eclipse Acceleo oder Sirius. Im kommerziellen Bereich decken Plattformen wie OutSystems, Mendix, Microsoft Power Platform, ServiceNow App Engine oder branchen­spezifische Low-Code-Lösungen (auch unsere eigene) den Großteil des Generators und der Plattform ab. Der Initial­aufwand schrumpft von „zwei C_T" auf „Adoptions­zeit plus Lizenzkosten" — und der Break-Even kann bereits beim ersten Produkt erreicht werden, oft schon innerhalb der Pilotphase.

Die Konsequenz für die Entscheidung ist klar: Wer eine ausgereifte Generator-Plattform am Markt findet, die zur Domäne passt, sollte sie nutzen. Die Einsparung gegenüber dem Eigenbau ist erheblich, das Risiko deutlich geringer, und das Werkzeug wird durch externe Hersteller oder die Open-Source-Community gepflegt — die Plattform veraltet nicht innerhalb der eigenen Mannschaft. Ein eigener Generator ist die Ausnahme, nicht die Regel — und sollte mit derselben Strenge begründet werden, mit der man eine Make-versus-Buy-Entscheidung für jedes andere strategische Werkzeug trifft.

Wichtige Voraussetzungen für diese Rechnung:

• Mindestens drei bis fünf ähnliche Produkte sind tatsächlich geplant — nicht nur vage gewünscht.
• Die Domäne ist stabil genug, dass das investierte Domänenwissen über mehrere Jahre Bestand hat.
• Das Team hat die Disziplin, die Plattform sauber zu halten — keine Sonder-Hacks im generierten Code, keine schleichende Erosion des Metamodells.
• Bei Eigenbau-Generatoren trägt die Unternehmensführung die initiale Investitionsphase mit, auch wenn der ROI erst in 18 bis 24 Monaten sichtbar wird. Bei fertigen Generatoren entfällt dieser Punkt weitgehend — der ROI kann bereits in der Pilotphase sichtbar werden.

Wer eine dieser Bedingungen nicht erfüllt, sollte ehrlicherweise klassisch entwickeln.

Asymptotisches Verhalten — warum MDSD-Vorteile mit der Zeit schrumpfen

So überzeugend die Investitionsrechnung ist, sie blendet eine zweite Dynamik aus, die in jedem MDSD-Projekt zum Tragen kommt: Die Kosteneffizienz der modellgetriebenen Entwicklung nähert sich über die Projektlaufzeit asymptotisch der Kostenkurve der jeweiligen Zielplattform an — also genau der Programmiersprache und Laufzeitumgebung (Java mit Spring Boot, C# mit .NET, TypeScript mit Node, Python mit FastAPI), in die der Generator schreibt.

Der Mechanismus ist intuitiv. Ein Generator deckt am Anfang etwa siebzig bis achtzig Prozent eines Produkts ab — die wiederkehrenden Strukturen, die typischen Fachverfahren, die häufigen Sonderfälle. Mit jeder Woche Betrieb tauchen aber neue Anforderungen auf, die das Metamodell so nicht vorgesehen hatte: ein exotisches Berechnungs­verfahren in der Sozialhilfe, eine ungewöhnliche Schnittstelle zu einem Drittsystem, eine fachliche Sonderregel, die nur für eine einzige Kommune gilt. Diese Spezialfälle landen im User Code — also in der Zielplattform, manuell programmiert.

Je länger das Projekt läuft, desto mehr User Code sammelt sich an. Das Verhältnis zwischen generiertem und manuell geschriebenem Code verschiebt sich. Die Effizienz, die zu Beginn durch den Generator entstand, schrumpft — nicht weil die Methode versagt, sondern weil die Realität fachlicher Anforderungen reichhaltiger ist, als jedes Metamodell sie a priori abdecken kann. Im Grenzfall — sehr lange Laufzeit, viele Sonderfälle, schlecht gepflegtes Metamodell — landet ein MDSD-Projekt fast auf der Kostenkurve einer klassischen Entwicklung in Java oder C#. Die Plattform-Investition hat sich dann nur in der Anfangsphase ausgezahlt.

Strategisch heißt das: MDSD ist keine Einmal-Investition, sondern eine Dauer-Disziplin. Drei Gegenmaßnahmen verschieben die Asymptote nachhaltig nach unten:

• Generator und Metamodell regelmäßig pflegen. Wenn dieselbe fachliche Sondersituation in zwei oder drei Produkten auftaucht, gehört sie ins Metamodell — nicht in den User Code. Sonst frisst sich das User-Code-Wachstum durch jede Plattform-Iteration.
• User Code begrenzen und klar markieren. Klare Regeln, was generiert wird und was nicht. Generierte Bereiche werden durch eindeutige Marker geschützt, User-Code-Bereiche bleiben getrennt. Wer diese Trennung aufweicht, verliert die Wiederholbarkeit des Generators bei der nächsten Modell-Iteration.
• Plattform aktiv weiterentwickeln. Eine Plattform, die nicht gepflegt wird, veraltet — und der Vorsprung gegenüber klassischer Entwicklung schrumpft schneller, als ihn fachliche Spezialfälle verkleinern. Patch-Hygiene, Bibliotheks-Updates, Refactoring der Generator-Regeln gehören in jeden Release-Zyklus.

Wer diese drei Disziplinen einhält, sieht die MDSD-Kostenlinie langsamer auf die Zielplattform zulaufen — der Vorsprung bleibt über Jahre erhalten. Wer sie vernachlässigt, sieht ihn innerhalb von zwei bis drei Jahren wegschmelzen, und die ursprüngliche Plattform-Investition rechnet sich nicht mehr in der gehofften Größenordnung. Genau dieser Effekt ist der Grund, warum auch ausgereifte Low-Code-Plattformen kontinuierlich gepflegt werden müssen — nicht weil sie defekt sind, sondern weil die Realität fachlicher Anforderungen schneller wächst, als ein eingefrorenes Metamodell sie abbilden kann.

Informationsgehalt versus Detaillierungsgrad

Ein zweiter Blick auf die Wirtschaftlichkeit lohnt sich, weil er einen anderen Aspekt betont: Bei klassischer Entwicklung wachsen Informationsgehalt und Detaillierungsgrad gleichzeitig — anfangs sehr schnell (Analyse), später nur noch der Detaillierungsgrad (Implementierung). Der Aufwand für ein Software­projekt entspricht ungefähr der Fläche unter dieser Kurve. Die Implementierungs­phase trägt dabei kaum noch zum Informations­gehalt bei; sie produziert lediglich Detail, das die Hardware versteht.

Bei MDSD wird ein hoher Informations­gehalt schon in der Modellierungs­phase erreicht. Der Generator hebt anschließend den Detaillierungs­grad sprunghaft auf ein produktives Niveau, ohne dass die Entwicklerinnen jede Zeile manuell schreiben müssen. Das Einsparpotenzial ist genau die Fläche zwischen den beiden Kurven — und es ist nicht klein. Mit jedem zusätzlichen Produkt einer Plattform wächst dieses Potenzial, weil derselbe Generator wiederverwendet wird.

Vorteile im Detail — jenseits der reinen Kostenrechnung

Die wirtschaftliche Argumentation ist die naheliegende — aber MDSD wirkt darüber hinaus auf mehrere Ebenen, die in der Investitionsrechnung schwer fassbar sind. Sechs Effekte, die in der Praxis regelmäßig auftreten.

Reduktion der Implementierungszeit

Wiederkehrende Aufgaben sind in jedem Enterprise-Projekt das Brot-und-Butter-Geschäft: CRUD-Operationen, Datenbankzugriffe über OR-Mapper, REST-Endpunkte, Validierungen, Listenansichten, Bearbeitungsmasken. Diese Aufgaben kosten in der manuellen Entwicklung erstaunlich viel Zeit — und sind die Hauptquelle für Tippfehler, Inkonsistenzen und Copy-Paste-Bugs. In einer MDSD-Umgebung sind sie Sache des Generators, und Entwicklerinnen wenden ihre Zeit auf das, was wirklich fachlich anspruchsvoll ist: Geschäftsregeln, Workflows, Sonderfälle.

Stringentes Programmiermodell

In klassischen Projekten entstehen Big Balls of Mud — Codebasen ohne erkennbare Struktur, in denen die Handschrift verschiedener Generationen von Entwicklern ablesbar ist. MDSD verhindert das auf eine elegante Weise: Der vom Generator vorgegebene Rahmen erzwingt eine konsistente Struktur. Der manuelle Anteil, der User Code, baut auf dieser Struktur auf und ordnet sich ein. Das Ergebnis: Code, der über Jahre wartbar bleibt, weil sein Aufbau im Generator dokumentiert ist und sich nicht beliebig ändern kann.

Strategischer Geschäftsvorteil

In einer softwaregetriebenen Geschäftswelt sind Unternehmen im Vorteil, die ihre Produktlinien schnell an neue Anforderungen anpassen können. Eine neue regulatorische Vorgabe — etwa eine Datenschutz-Erweiterung, eine neue Berichtspflicht, ein zusätzliches Vertrauensniveau bei der Bürgeranmeldung — lässt sich mit MDSD oft auf einer Ebene umsetzen, die alle Produkte der Linie gleichzeitig erfasst. In manueller Entwicklung müsste dieselbe Änderung in jedem Produkt einzeln nachgezogen werden, oft mit Inkonsistenzen zwischen den Produkten.

Wann sich MDSD lohnt — und wo Low-Code andockt

MDSD ist kein Universalansatz. Eine ehrliche Einordnung, in welchen Konstellationen die Methode trägt und wo sie nicht hingehört.

Klar lohnenswert:

• Produktlinien mit mehreren ähnlichen Anwendungen — Versicherungsprodukte unterschiedlicher Sparten, Banken­produkte über Kunden­segmente hinweg, kommunale Fachverfahren über mehrere Kommunen, OZG-Online­dienste über mehrere Lebenslagen.
• Stabile Domänen, in denen Fachwissen über Jahre konserviert werden kann. Branchen mit hoher Regulierungsdichte sind klassische Kandidaten, weil die Regulierung selbst Stabilität in die Domäne bringt.
• Unternehmen, die mehrere Generationen Technologie-Wechsel überstehen müssen — Versicherungen, die seit den Achtzigern Cobol-Bestände migrieren; Behörden, die alle zehn Jahre vor einer Plattform-Frage stehen.
• Teams, die Architektur-Disziplin als Wert anerkennen und nicht jede Stunde mit Feature-Druck verbuchen müssen.

Kaum lohnenswert:

• Einzelprodukte ohne erkennbare Wiederverwendung. Eine Anwendung, deren Lebensdauer in Monaten gemessen wird, sollte klassisch gebaut werden.
• Stark wechselnde Domänen, in denen die Plattform schneller veraltet, als sie sich amortisiert. Wer eine Anwendung für eine neue Branche baut, die sich gerade selbst erfindet, sollte mit klassischer Entwicklung beginnen und MDSD später nachziehen, wenn sich die Domäne stabilisiert hat.
• Kleine Anwendungen, in denen der Setup-Aufwand für Metamodell, Generator und Plattform die ganze Anwendung übersteigt.
• Teams, die unter akutem Lieferdruck stehen und keine Kapazität für eine Investitionsphase haben.

Die Verbindung zu Low-Code

Eine Beobachtung, die wir in den letzten Jahren häufig gemacht haben: Wer eine reife Low-Code-Plattform aufmacht, sieht im Kern eine MDSD-Plattform. Die grafische Modellierungs-UI ist die DSL — nur in optischer Form. Die Module der Plattform sind die Bausteine im Sinne des Domain Engineering. Der Code, der hinter den Klicks entsteht, ist das Ergebnis eines Generators. Was MDSD theoretisch fordert, leben Low-Code-Plattformen technisch.

Umgekehrt gilt: Eine Low-Code-Plattform, die ihre eigene Architektur nicht entlang sauberer MDSD-Prinzipien strukturiert, wird ab einer mittleren Größe unwartbar. Die Module verwischen, das Metamodell wird unklar, jeder Release-Zyklus wird zur Rätselrunde. Wir sehen Low-Code daher nicht als „MDSD light", sondern als die zugänglichste Form, in der MDSD-Prinzipien in den Alltag der Anwendungsentwicklung gelangen — und die Investitionshürde, die MDSD historisch hatte, deutlich senken.