Die Ursprungskonzepte und frühen Versionen einer Software hinterlassen oft Spuren, die auch nach jahrelanger Weiterentwicklung sichtbar bleiben. Das betrifft auch unsere Enterprise Low Code Plattform A12. Doch wie sahen die Anfänge der Toolentwicklung aus? Welche Kontinuitäten gibt es bis heute? Eine Software-archäologische Werkstattschau.
Für die Modellierungswelt der Enterprise Low Code Plattform A12 markiert das Jahr 2023 einen wichtigen Wendepunkt: Die erste Tool-Generation geht in den Ruhestand. Der SME (Simple Model Editor) bietet nun als zentrales, modulares Werkzeug der neuen Generation die Mittel, um sämtliche A12-Modelle so komfortabel wie noch nie zu editieren. Wir nehmen diesen Meilenstein zum Anlass, um die bisherige Evolution der A12-Modellierungswerkzeuge Revue passieren zu lassen.
Dieser Beitrag ist Teil einer Reihe über die Werkzeugentwicklung von A12:
- Teil 1: Der Herr der Felder erwacht
- Teil 2: Ein erfolgreiches Experiment
- Teil 3: Die Zukunft in der Cloud
Im Gegensatz zu physischen Werkzeugen wie Hammer und Meißel verändern digitale Werkzeuge viel schneller und drastischer ihre Form. Dennoch bleibt häufig ein Kern erhalten. Es gibt Kontinuitäten, die sich von der Ursprungsversion bis in die Gegenwart erstrecken. Dies ist auch bei den Modellierungswerkzeugen der Enterprise Low Code Plattform A12 der Fall, mit denen Business Analysten ohne Programmierkenntnisse Teile einer Anwendung gestalten können.
Wir begeben uns auf Spurensuche und landen zunächst im Jahr 2013. Einer Zeit, in der Papst Benedikt seinen Rückzug verkündete, Edward Snowden die NSA-Affäre enthüllte und Avici mit Wake me up die Charts stürmte. mgm hatte durch ein Softwareprojekt im Steuerumfeld bereits erste Erfahrungen mit der modellbasierten Softwareentwicklung gesammelt und das gewaltige Potenzial dieses Ansatzes für komplexe Geschäftsanwendungen erkannt.
Indem ein wesentlicher Teil der Fachlichkeit in Modellen spezifiziert war und Engines sie interpretierten oder daraus Code generierten, sanken die Aufwände für fachliche Anpassungen der Software drastisch. Ein wesentlicher Aufwandstreiber komplexer Geschäftsanwendungen ließ sich auf diese Weise effektiv zähmen. Ausgehend von dieser Erkenntnis startete mgm eine Entwicklungsinitiative, um die Vorteile der modellbasierten Entwicklung für weitere Kundenprojekte umfänglicher und strukturiert zu erschließen. In diesem Zusammenhang entstanden auch die ersten Modellierungswerkzeuge.
Von händisch erstellten Modellen zu den ersten Editoren
Die ersten Modelle haben wir noch händisch als XML-Dateien bearbeitet
In den Anfängen von A12 waren die Modellierungswerkzeuge eher ein Nischenprodukt. Die im Aufbau befindliche Plattform wurde hauptsächlich von mgm-Mitarbeitenden verwendet. Nahezu alle Menschen, die mit ihr in Kontakt kamen, waren Softwareentwickler:innen, die notwendige Modelle auch ohne spezielle Editoren erstellen konnten. „Die ersten Modelle haben wir noch händisch als XML-Dateien bearbeitet“, erinnert sich Erik Neumann, der früh in die Entwicklung von A12 eingebunden war. „Auch Jahre nachdem es die ersten Modellierungstools gab, haben manche Kolleginnen und Kollegen ihre Modelle lieber direkt in XML editiert“, ergänzt Baschir Jaghoori, der heute das Engine & Client-Team von A12 leitet.
Obwohl die Modellierungswerkzeuge aus Entwicklerperspektive zunächst einen eher optionalen Charakter hatten, war ihre Bedeutung für das Konzept der modellgetriebenen Softwareentwicklung von Anfang an klar. Bereits wenn das Entwicklungsteam auf Modelle setzt und die modellierten Inhalte nicht ausprogrammieren muss, ergeben sich deutliche Produktivitätsvorteile. Wenn dann aber auch die fachlich Verantwortlichen für die Software die Modelle selbst bearbeiten können, entfallen weitere Kommunikations-, Abstimmungs- und Übersetzungsaufwände. Diese Vision, die einige Jahre später im Low-Code-Umfeld durch die Bezeichnung des „Citizen Developers“ popularisiert wurde, motivierte von Beginn an die A12-Toolentwicklung.
Daten- und Formularmodellierung: Ein Tool pro Modell
Im Fokus von A12 stand zunächst die modellgetriebene Umsetzung von Online-Formularen. Es gab zwei Modelltypen. Einer beschrieb, wie das Formular aufgebaut war. Dies war das Formularmodell (Form Model). Ein anderer definierte die zugrundeliegende Datenstruktur und Validierungsregeln, sprich: welche Felder mit welchen Datentypen es gab und welche Werte für diese Felder erlaubt waren. Dieser Modelltyp wurde Dokumentenmodell (Document Model) genannt, da das technische Handling dokumentenorientiert erfolgte. Die Trennung zwischen den Daten und dem Formular wurde auch durch das eingesetzte XForms gefördert – einem W3C-Standard für Online-Formulare.
Wir haben die Tools bewusst sehr ähnlich aufgebaut, damit sich die Nutzer schnell zurechtfinden.
Die anfängliche Tool-Landschaft von A12 folgte dem Prinzip „Ein Tool pro Modell“. „Zuerst entstand der Editor für das Formularmodell, das deutlich komplexer als das Dokumentenmodell war“, sagt Erik. „Danach haben wir eine Kopie des Editors als Grundlage für das Tool zur Bearbeitung von Dokumentenmodellen genommen. Wir haben die Tools bewusst sehr ähnlich aufgebaut, damit sich die Nutzer schnell zurechtfinden.“ Technisch basierten sie auf Eclipse RCP (Rich Client Platform) und konnten dadurch schnell plattformunabhängig realisiert werden – für Linux, Mac und Windows.
Ursprünglich waren die Tools nach Sagengestalten und historischen Persönlichkeiten benannt. Der Editor für Dokumentenmodelle hieß Picus – wie der römische Gott der Felder und des Waldes. Der Formulareditor trug den Namen Melies – in Anlehnung an den französischen Filmpionier Georges Méliès, der 1896 in der Nähe von Paris eines der ersten Filmstudios gründete. Einige Jahre später, als die Werkzeuge im Rahmen von Softwareprojekten vermehrt auch von Externen genutzt wurden, kamen deskriptivere Bezeichnungen zum Einsatz. Aus Picus wurde der Data Modeler und aus Melies der UI Designer.
Blaupause für Modellrepräsentation
Die ersten Versionen der Tools boten noch einen recht übersichtlichen Funktionsumfang. „Man konnte Modell-Elemente anlegen, ineinander verschachteln und das Ganze abspeichern. Und es gab eine rudimentäre Regeleingabeunterstützung“, erklärt Erik.
Der grundlegende Aufbau, wie wir Modelle darstellen, ist bis heute erhalten geblieben – auch wenn es jetzt zusätzliche visuelle Perspektiven gibt.
Doch selbst von diesen ersten Versionen von Picus und Melies bis zur heutigen Tool-Generation – dem Simple Model Editor (SME) – gibt es Kontinuitäten. „Der grundlegende Aufbau, wie wir Modelle darstellen, ist bis heute erhalten geblieben – auch wenn es jetzt zusätzliche visuelle Perspektiven gibt. Wir haben eine Baumansicht für die Modellstruktur. Klickt man Elemente darin an, werden sie editierbar“, sagt Baschir. „Hier wären auch andere Darstellungen und Editiermöglichkeiten denkbar gewesen. Die User fanden und finden diese Struktur aber offenbar sehr übersichtlich und gut bedienbar.“
Funktionsumfang und Nutzerbasis wachsen
In den Jahren ab 2013 war die Entwicklung der beiden Werkzeuge stark von den Anforderungen der Projekte getrieben, die A12 bereits zu dieser Zeit eingesetzt haben. Eine erste bedeutende Erweiterung war die Unterstützung sogenannter Includes. Sie ermöglichen die Einbettung bestehender A12-Dokumentenmodelle in neue A12-Dokumentenmodelle. Dies unterstützt eine modularere Datenmodellierung und reduziert die Fälle von Copy & Paste.
Ab 2015 kam es in A12 zu einem technologischen Umbruch: dem Umstieg von XForms auf JavaScript. Mehr Funktionalität verlagerte sich auf die Client-Seite. Als Folge davon wurden die Modelle in JSON persistiert. Während die händische Bearbeitung der XML-Dateien noch praktikabel war, ist dies beim JSON-Format nicht der Fall. Wer Modelle ohne die Editoren bearbeitete, war ohnehin im Nachteil. Die zunehmend ausgereiften Werkzeuge boten eine Menge Komfortfunktionen und vereinfachten die Modellerstellung – zum Beispiel mit Validierungstests und einer auf Knopfdruck abrufbaren Preview-Funktion für Formulare.
Ein neues Modell – kein neues Tool
Ebenfalls im Jahr 2015 trat ein erstes neues A12-Modell hinzu: Mit Hilfe des Overview-Modells ließen sich nun auch tabellenartige Übersichten modellieren. Im Vergleich zum Formular- und Dokumentenmodell war es jedoch deutlich kleiner und rechtfertigte kein eigenes neues Tool. Die Editiermöglichkeiten des Overview-Modells wurden in Melies bzw. den UI Designer integriert. Damit gab es erstmals ein A12-Tool, das mehrere Modelltypen auf einmal unterstützte – und einen Vorgeschmack auf das, was kommen sollte.
In den folgenden Jahren wurde das Modellierungskonzept von A12 kontinuierlich erweitert – sowohl in Hinblick auf die Datenmodellierung als auch die modellbasierte Gestaltung von Teilen der Benutzeroberfläche. Der Herr der Felder wurde erwachsen und erreichte den Herbst seines Lebenszyklus. Mit dem SME trat ab 2019 ein neues Werkzeug hinzu, das die nächste Tool-Generation einleiten sollte – und um das es im folgenden Teil dieser Reihe geht.
