In the Code: Das Modell als Drehscheibe grosser Softwareprojekte

Die Software-Ingenieure Thomas Heynen und Remo Meier sowie CTO Tom Sprenger von AdNovum schreiben in ihrem Gastbeitrag über den Nutzen modellbasierter Ansätze in der Software-Entwicklung.
 
An der Modernisierung oder Neuentwicklung grösserer Software-Systeme sind heutzutage eine zunehmende Anzahl Firmen und Standorte beteiligt, beispielsweise durch die Anwendung von Nearshoring und Offshoring oder das Einbeziehen von Partnerfirmen an verschiedenen Standorten. Die Konsequenz sind Prozesse und Teams, die sowohl geographisch verteilt, aber auch über organisatorische Grenzen hinweg im Projekt funktionieren müssen. Hinzu kommt, dass die abzulösenden Systeme oft über viele Jahre entstanden sind, in denen sich Anforderungen und Technologien verändert haben und mit verschiedenen Teams entwickelt wurden. Als Konsequenz findet man üblicherweise eine ausgeprägt heterogene Lösungsarchitektur vor.
 
Wird eine Modernisierung oder ein Neubau geplant, ist es daher von zentraler Bedeutung, solche Aspekte zu berücksichtigen. So sollte für alle Parteien nicht nur eine gemeinsame Kollaborations-, sondern auch eine Informations-Plattform geschaffen werden, um eine standort-, firmen- und organisationsübergreifende Zusammenarbeit zu ermöglichen und zu fördern. Teams können zunehmend virtuell organisiert werden und sollen nicht an Standorte gebunden sein. Entwicklern soll die Möglichkeit geboten werden, möglichst Infrastruktur-unabhängig zu entwickeln, allenfalls auch autonom in einer lokalen Umgebung. Neben der Art der Kollaboration sind dafür der Projekt-Setup und die Architektur von entscheidender Bedeutung. Insbesondere bei einem Neubau grosser Systeme möchte man Skalierungs-Effekte nutzen und mit zunehmender Grösse die Effizienz steigern. Die Ausnutzung von Synergien, Gemeinsamkeiten und des Potenzials zur Automatisierung hat oberste Priorität.
 
Model Driven Development: gut gemeint
In diesem Kontext hat man in den letzten Jahrzehnten wiederholt auf Model Driven Development (MDD) gesetzt. Mit MDD werden Applikationen modelliert und der Code dann weitgehend automatisiert generiert. So soll ein durchdachtes einheitliches System entstehen. Leider wurden die hohen Erwartungen nur selten erfüllt, wodurch der MDD-Ansatz in Verruf geriet. Das Ausbleiben des Erfolgs hatte verschiedene Gründe. Zum einen entspricht der Aufwand für die Entwicklung eines System typischerweise nur rund 30 Prozent des gesamten Projektaufwands. Organisation, Analyse, Planung, Testing und Betrieb verursachen ihrerseits erhebliche Kosten. So lange ein Ansatz wie Model Driven Development nur auf die Entwicklung zielt, ist das Sparpotenzial deshalb von marginaler Bedeutung für das Projekt.
 
Ein anderer Grund ist, dass Businesslogik hohe Flexibilität verlangt. Die Möglichkeiten eines Modells oder eines Generators, Businesslogik abzubilden, sind jedoch begrenzt. Das führt dazu, dass entweder Code und Modell auseinanderlaufen oder aber zu viele Aspekte der Implementierung in das Modell einfliessen.
 
Freiheit hat ihren Preis
Auf der anderen Seite ist eine Vielzahl von Entwicklungs-Tools, Libraries und Programmiersprachen verfügbar. Gerade in grossen Projekten mit vielen Teilapplikationen empfiehlt es sich, die Vielfalt über ein stringentes Technologiemanagement im Zaum zu halten. Sind an einem Projekt verschiedene Firmen-, Standort- oder sogar Abteilungskulturen beteiligt, ist dies umso bedeutender und auch herausfordernder. Eine homogene System- und Technologielandschaft ist in jedem Fall erstrebenswert, weil sich die Mitarbeitenden schneller orientieren und dadurch effizienter zusammenarbeiten können.
 
Ausserdem kann nur so die Automatisierung vorangetrieben und verhindert werden, dass bei der Integration ein- und dieselben Probleme immer wieder gelöst werden müssen.
 
Model Driven Design
Hier bietet ein modellbasierter Ansatz Lösungen. Es ist deshalb sinnvoll, die Idee wieder aufzunehmen und als Model Driven Design neu zu denken. Die Modellierung und die Generierung von Code fokussieren dabei auf die Erzeugung der Meta-Artefakte eines Projekts. Das Modell stellt damit einen vom Businesskontext der Applikation unabhängigen Mehrwert für alle Applikationen zur Verfügung. Dazu muss relativ wenig zusätzliche Information im Modell untergebracht werden. Auf Basis eines Modells kann der Generator den Projekt-Setup, die Build-Job-Konfigurationen und Packages generieren. Dadurch wird ein hoher Wiedererkennungsgrad erreicht. Entwickler, aber auch Integratoren und Betrieb können damit bis anhin unbekannte Artefakte beschaffen, bauen, abändern, installieren oder auch Probleme nachvollziehen. Durch den gemeinsamen "Project Contract" können das Ausführen von Unit-Tests und Integrations-Tests, das Bauen und Releasen von Artefakten sowie die Integration in Continuous Build und Quality Assurance Tools uniform über alle Applikationen zur Verfügung gestellt werden.
 
Schon nach der Definition eines neuen leeren Modells für eine Applikation entstehen mit der ersten Generierung neben dem gebauten Software-Artefakt auch gleich der Continuous-Integration-Job sowie das fertig installierbare Package.
 
Grundgerüst wird generiert
Die Modellierung von Services und Daten-Modellen erfolgt beim Model Driven Design ähnlich wie beim Model Driven Development. Die Code-Generierung dagegen beschränkt sich auf Datenmodell, Schnittstellen-Fassaden und Middleware-Integration. Ziel ist, ein konsistentes Grundgerüst mit den entsprechenden Namens-Konventionen als Basis vorzugeben. Die Businesslogik wird danach auf klassische Weise durch Entwickler implementiert.
 
Als nächsten Schritt bildet das Modell die Grundlage für eine konsistente Dokumentation, die den aktuellen Zustand der Software widerspiegelt. Soll die Dokumentation aktuell sein, muss sie laufend generiert werden können. Auch deshalb muss die Generierung einfach sein und darf keine applikationsspezifische Logik enthalten. Dabei werden nur Artefakte generiert, die vollumfänglich über das Modell gemanagt werden können. Aus dem Modell können so Service-Repositories und Datenmodell-Beschreibungen erzeugt werden, die idealerweise online zur Verfügung stehen. So kann projekt-, firmen- und standortübergreifend auf die aktuelle Dokumentation zugegriffen werden. Wird das Modell versioniert in einer Datenbank abgelegt, kann die Dokumentation zu verschiedenen Software-Releases abgefragt und es können Vergleiche zwischen Releases gemacht werden.
 
Auswertungen in Echtzeit
Nach der Pflicht zur Kür: Durch standardisiertes Logging und Tracing von Events an den Schnittstellen der Applikationen können auch Auswertungen automatisiert erstellt werden. Zum Beispiel können automatisch Abfragen zur Verfügung gestellt werden, welche die Performance von Services über eine ganze Systemlandschaft hinweg auswerten. Diese können unmittelbar in die Online-Dokumentation hineingeneriert und dadurch die statische Information mit Auswertungen in Echtzeit angereichert werden.
 
Ist die Service-Schnittstelle im Modell einmal definiert, können danach Fragen wie "Wer braucht meinen Service eigentlich wie oft und wann?" oder "Wie gut ist die Performance meines Services?" jederzeit mit wenigen Klicks beantwortet werden. Zusätzlich können auch Artefakte für Sanity-Checks, weitere Monitoring-Funktionalitäten sowie Runtime-Diagnosen generiert werden.
 
Zentrale Plattform für verteilte Dienste
Ist das Grundgerüst etabliert, so können Dienste, die in mehreren Applikationen genutzt werden, auf gleicher technologischer Basis beschrieben werden. In der Folge können sie direkt zentral den verschiedenen Komponenten zur Verfügung gestellt werden, welche ihren Output konsumieren. Beispiele dafür sind zentrale Konfigurations- und Security-Dienste. Alternativ können solche Dienste dezentral in andere Komponenten eingebunden werden.
 
Ein Beispiel einer dezentral eingebetteten Komponente ist das lokale Auditing. Es besteht aus einem eigenen Daten-Modell mit eigenen Services und läuft im gleichen Kontext respektive in derselben Transaktion wie die Hosting-Komponente. Das lokale Auditing liefert Daten an eine zentrale Auditing-Komponente, die Services über ein User Interface gegen aussen anbietet. Ein System kann so aus einer Vielzahl von Subkomponenten bestehen und diese mit anderen Komponenten teilen. Dabei können die gleichen, zentral beschriebenen Dienste von diversen Systemen eingebunden und angeboten werden. Konsumierende Systeme ihrerseits können ohne weitere Informationen über die anbietenden Systeme deren eingebetteten Dienste nutzen. Dies ist beispielsweise im Kontext der Internationalisierung einer System-Landschaft relevant. Die Entkoppelung von konsumierenden und anbietenden Systemen ermöglicht es, einzelne Systeme mit kleinem Integrationsaufwand auszubreiten oder durch andere Systeme mit gleichen eingebetteten Diensten zu ersetzen.
 
Modell-Ansatz: Fokussierung auf das Wesentliche
Richtig angewendet, kann der Modell-Ansatz für die Modernisierung beziehungsweise Neuentwicklung von Software-Systemen substanziellen Nutzen bringen, insbesondere bei der heute gängigen Entwicklung mit international verteilten Teams und Partnern. Indem man gemeinsame Aspekte und Artefakte über ein Modell zentral definiert und generiert, kann man in einer heterogenen Systemlandschaft Rahmenbedingungen schaffen, die den Projektteams eine Kollaborationsplattform mit hohem Wiedererkennungsgrad bieten. Dies erhöht die Effizienz über das Gesamtprojekt und erleichtert die Automatisierung. Zudem lässt sich mit einem solchen Modell eine stets aktuelle Online-Dokumentation des Projekts generieren, mit integrierten Echtzeit-Auswertungen von Performance und Services über die ganze Systemlandschaft hinweg. Die Entkopplung von anbietenden und konsumierenden Services ermöglicht als weiteren Benefit die Definition zentraler Services.
 
Wichtig bei der Konzeption des Modells ist, dass man nur den Projekt-Setup, die Build-Job-Konfigurationen und Packages sowie den Code für das Datenmodell, die Schnittstellen-Fassaden und die Middleware-Integration generiert und keine Businesslogik.
 
Am Anfang des Projekts wird mit Blick auf den konkreten Nutzen definiert, welche Features über das Modell umgesetzt werden sollen. Hier empfiehlt es sich, im Sinne der 80/20-Regel das Modell möglichst schlank zu halten und die Features bestmöglich zu nutzen. So eingesetzt ist der Modell-Ansatz bei der Entwicklung der heute typischen verteilten und heterogenen Software-Systeme eine wertvolle Option, insbesondere wenn grosse oder mehrere ähnlich gelagerte Projekte mit Wiederverwendungspotenzial in Angriff genommen werden. (Thomas Heynen, Remo Meier, Tom Sprenger)
 
Über die Autoren
Thomas Heynen ist Head of Frontend and Application Development beim Schweizer Softwarehersteller AdNovum. Zudem definiert und bewertet er als Solution Architect Architekturvorgaben für Java-EE-Fachanwendungen und schult Entwicklerteams. Thomas Heynen ist MSc in Informatik ETH mit Vertiefung in theoretischer Informatik.
 
Remo Meier ist Senior Software Engineer bei AdNovum. Als Solution Architect engagiert er sich in Kundenprojekten und wirkt seit kurzem auch in AdNovums Architektur-Experten-Pool mit. Remo Meier hat seinen MSc in Computer Science an der ETH erworben und dort im Bereich Distributed Computing doktoriert.
 
Tom Sprenger ist als CTO seit 2013 für die Technologiestrategie und den Entwicklungsprozess von AdNovum verantwortlich. Davor baute er als CIO die globale IT-Infrastruktur von AdNovum auf und etablierte die strategischen Geschäftsbereiche IT-Consulting und Application Management. Tom Sprenger ist Dipl. Inf.-Ing. ETH und hat im Bereich Informationsvisualisierung doktoriert.
 
(Interessenbindung: AdNovum ist Werbekunde unseres Verlags.)