Retten Sie das Anwendungswissen mit MDA! Viele Unternehmen – gerade solche, deren Produkte und Dienstleistungen weitgehend mit digitalisierbaren Ergebnissen zu tun haben – sind in hohem Maße von Software abhängig, die die unternehmensspezifischen Geschäftsprozesse unterstützt. Der Ansatz der Model Driven Architecture (MDA) kann hier entscheidende Vorteile bieten.
Für Versicherungen, Banken, und Telekommunikationsunternehmen, aber auch in anderen Branchen nimmt die Abhängigkeit von Software immer mehr zu. Beispielsweise in der Automobilindustrie, in der ein seit Jahren steigender Anteil von Software am Produkt Automobil dazu geführt hat, dass die Softwareerstellung mittlerweile substanziell zu den Produktionskosten beiträgt. Ähnliches gilt für Versorgungs- und Entsorgungsunternehmen. Hier sind Produkte und Dienstleistungen zwar nicht digitalisierbar, ihre Verwaltung, Tarifierung und der Bereich des Kundenmanagements erfordern aber immer mehr Software. Die Aufwände in all diesen Branchen umfassen zwar durchaus nennenswerte Kosten für Standard-Software (Personalwesen, Rechnungswesen, etc.), sind im Wesentlichen aber immer noch von individueller Softwareentwicklung getrieben. Trotz dieser enormen wirtschaftlichen Bedeutung von Software hat die Softwareentwicklung im Allgemeinen noch kein ingenieurmäßiges, also planbares, zuverlässiges und von definierten Konstruktionsprozessen geprägtes Niveau erreicht. Neue Untersuchungen der Standish Group belegen, dass immer noch ca. 50 % aller Softwareprojekte mit Termin-, Qualitäts-, oder Budgetproblemen zu tun haben und dass ca. 15 % aller Softwareprojekte abgebrochen werden.
Gründe für das Scheitern der Softwareentwicklung
Curtis, Krasner und Iscoe haben schon 1988 untersucht, woran es trotz der enormen wirtschaftlichen Bedeutung von Software und trotz des enormen wirtschaftlichen Verlusts, den verzögerte oder abgebrochene Projekte bedeuten können, immer noch nicht gelungen ist, die Entwicklung von Software so zuverlässig wie andere Produktionsprozesse zu gestalten. Aktuellere Studien, beispielsweise vom Software Engineering Institute in Pittsburg, identifizieren auch heute noch die gleichen Gründe für das Scheitern von Softwareprojekten, nämlich:
– unklare und widersprüchliche Anforderungen an die zu entwickelnde Software,
– Zusammenbruch von Koordination und Kommunikation zwischen den Projektbeteiligten,
– fehlendes Wissen über die Anwendungsdomäne.
Zu dem Phänomen der unklaren und widersprüchlichen Anforderungen tragen unterschiedliche Umstände bei. Zu aller erst ist zu nennen, dass die Entwicklung von Software häufig unter hohem zeitlichen Druck stattfindet. Ob dieser hohe Termindruck dabei selbst gemacht oder sachlich nachvollziehbar ist, spielt keine Rolle. Das Ergebnis ist dasselbe: in kaum einem Projekt findet eine ordentliche Anforderungsanalyse statt, die alle Betroffenen einbezieht, von vornherein klar macht, dass zusätzliche Anforderungen zusätzliches Geld kosten und dass es Widersprüche zwischen Anforderungen unterschiedlicher Beteiligter geben kann, die ausgeräumt werden müssen. Neben dem reinen Termindruck spielt an der ein oder anderen Stelle sicherlich auch die Bequemlichkeit eine Rolle. Bequemlichkeit, die dazu führt, dass Anforderungskonflikte nicht explizit gemacht und nicht gelöst werden. Stattdessen werden die Konflikte verschoben. Und zwar auf das Projektende. Dann werden die Konflikte offensichtlich, lassen sich aber auch nicht mehr so einfach klären wie zu Projektbeginn, denn es gibt ja schon Software, die die eine Anforderung erfüllt und die andere nicht. Jetzt ist Konfliktlösung mit Kosten verbunden, kollidiert mit nahen Terminen. Ein weiterer Beitrag zu unklaren Anforderungen sind die unspezifischen Verweise auf existierende Systeme. Das neue System soll mindestens das Gleiche können wie das Alte, nur in anderer Technologie, es soll mobile und verteilte Geschäftsprozesse unterstützen und dies und das anders machen. So richtig klar ist das eben nicht.
Der Gefahr der unklaren Anforderungen kann mit klar definierten Prozessen aus dem Bereich des Anforderungs-Management, mit horizontalen Oberflächen-Prototypen oder mit so genannten Struktur-Prototypen, die das Zusammenspiel aller zu realisierenden Oberflächen illustrieren, entgegnet werden. Eine weitere Chance besteht darin, dass Modelle, die die Fachlichkeit zum Ausdruck bringen und noch frei von technischen Betrachtungen und Entwurfsentscheidungen sind, während der gesamten Entwicklung verwendet werden und jederzeit einen Überblick über die angestrebte Funktionalität des zu realisierenden Systems geben.
Das Phänomen des Zusammenbruchs von Koordination und Kommunikation findet sich immer seltener, höchstens noch bei sehr hierarchischen Projekten, in denen das Management Entscheidungen trifft, die nicht in den Sachzusammenhängen des Projektes gegründet sind oder in Projekten, in denen das Zusammenwirken von Technik und Fachbereich nicht gefördert wird.
Mit anderen Worten: das erste Phänomen (unklare Anforderungen) tritt noch auf, kann aber immer besser risiko-gemanaged werden. Das zweite (Zusammenbruch der Kommunikation) nimmt an Bedeutung ab, klassische Muster des Projektmanagements reichen, um ihm wirksam zu entgegnen. Dem dritten Phänomen (knappes Anwendungswissen) widmen wir uns im nächsten Abschnitt.
Die wirklich knappe Ressource: Anwendungswissen
Das Phänomen des knappen Anwendungswissens besagt, dass es mit hinreichender Wahrscheinlichkeit schief geht, wenn Softwareentwickler nicht über genügend Wissen in der Anwendungsdomäne verfügen. Dass das nicht so ganz falsch sein kann, zeigt sich daran, dass erfahrene Entwickler aus einer Branche womöglich zu einem anderen Unternehmen der gleichen Branche wechseln, aber nur selten in eine andere Branche. Denn mit einem solchen Schritt würde ihr angesammeltes Anwendungswissen von heute auf morgen entwertet, auf einmal wären sie nur noch erfahrene Cobol- oder PL1-Entwickler. Dass Anwendungswissen wichtig ist, zeigt sich auch daran, dass Software-Häuser oft einen Branchenfokus haben oder ihre Organisation nach Branchen ausrichten. Und das auch dann, wenn alle Entwickler die gleichen technologischen Grundlagen beherrschen müssen, eine technologische Differenzierung also nicht vorliegt.
Aber Anwendungswissen ist nicht nur wichtig, sondern auch knapp. Informatik-Absolventen verfügen trotz aller Studienordnungen, die studiumsbegleitende Nebenfächer vorsehen, trotz aller Praxisarbeiten und trotz der zunehmenden studienbegleitenden Jobs nur selten über Anwendungsdomänenwissen, sondern sind vor allem technisch-wissenschaftlich ausgebildet. Bei Wirtschaftsinformatikern wird die technisch-wissenschaftliche Ausbildung zu Gunsten von mehr betriebswirtschaftlichen Elementen reduziert. Anwendungsdomänenwissen bringt auch das noch nicht.
Damit stellt sich für Software entwickelnde Unternehmen eine ganz zentrale Frage, nämlich die nach dem Aufbau des Wissens in ihrem jeweiligen Anwendungskontext. Nun haben Unternehmen, die ihre Software in der Regel selbst entwickeln (also, zum Beispiel Versicherungen), eine unglaubliche Chance:
1. Sie haben das Dömänenwissen inhouse verfügbar. Die Fachbereiche kennen die Probleme der Domäne, sie kennen die Geschäftsprozesse und in aller Regel auch ganz genau, was verbessert werden könnte, was die wichtigen Anforderungen an Software-Unterstützung sind und was entbehrlich ist.
2. Sie haben Entwicklungsabteilungen, die die Anwendungslandschaften genau kennen, die über Entwicklung und Wartung dieser Anwendungen selbst substanzielles Domänenwissen aufgebaut haben.
Angesichts dieser Ausgangssituation sollten Ansätze des Outsourcing/Offshoring der Anwendungsentwicklung qualitativ und langfristig quantitativ (und nicht nur kurzfristig quantitativ) beurteilt werden. Denn mit dem Outsourcing/Offshoring fallen beide Vorteile auf einmal und sofort weg. Weder sind Anwendungs- und IT-Wissen danach noch in einem Haus verfügbar, noch ist der Zugriff auf Entwickler, die die Anwendungslandschaft kennen, dauerhaft gewährleistet. Lassen wir dieses Argument an dieser Stelle aber einmal beiseite und betrachten die Ausgangssituation des inhouse verfügbaren Wissen in Fachbereichen und IT-Abteilung vor dem Hintergrund der immer schnelleren Innovationsfolge im technischen Bereich.
Nehmen wir weiterhin mal an, dass es disruptive technologische Innovationen gibt, also solche, die nicht darauf hinauslaufen, dass erprobte Methoden und Verfahren angepasst werden, sondern darauf, dass sie durch neue ersetzt werden. Unter dieser Annahme, müssen die erfahrenen Anwendungsentwickler (also die, die das Anwendungswissen internalisiert haben) entweder in die Lage versetzt werden, die neuen Methoden und Verfahren anzuwenden oder sie müssen durch andere Anwendungsentwickler ersetzt werden. Zweitens kommt schon allein deshalb nicht infrage, weil das Anwendungswissen ja die knappe Ressource ist, die de facto kaum wiederbeschaffbar ist. Folglich müssen die erfahrenen Anwendungsentwickler mit den neuen Methoden und Verfahren vertraut gemacht werden. Dies stellt immer wieder ein großes Problem dar, weil viele technologische Innovationen zu Recht kritisch hinterfragt werden. Allzu oft erschöpfen sie sich in Schlagwörtern und Marketing-Strategien, deren Substanz zweifelhaft ist, sodass eine gewisse Skepsis gegen technologische Innovationen weit verbreitet ist. Es ist aber auch deshalb schwierig, neue Methoden, Verfahren, Technologien einzuführen, weil Gewohntes, Erlerntes und erfolgreich Angewendetes nur ungern aufgegeben wird.
Model Driven Architecture
Die Object Management Group verfolgt mit dem Ansatz der Model Driven Architecture (MDA) die Idee, dass Anwendungswissen getrennt von Entwurfsentscheidungen in fachlichen Modellen beschrieben wird und dass die Transformationen der fachlichen Modelle zu technischen Modellen und der technischen Modelle zu plattform-spezifischen Modellen so weit wie möglich automatisch erfolgt. Die Idee der MDA ist, dass die Anwendungsentwickler sich auf darauf konzentrieren können, ihr fachliches Know-how zum Ausdruck zu bringen, ohne sich dabei um Technik kümmern zu müssen. MDA geht mit der Vermutung einher, dass Persistierung, Transaktionsmanagement und Standardanzeigen nicht immer wieder manuell programmiert werden müssen, sondern als grundlegende Services zur Verfügung stehen. Und als solche können sie automatisch zu den fachlichen Services hinzugeneriert werden. Auch wenn die MDA dies nicht zwingend erfordert (sondern ja sogar Plattformabhängigkeit fordert), so geht die MDA-Idee in den meisten Fällen mit einer J2EE-Realisierung einher. Meistens findet sich im Hintergrund also ein J2EE-Applikationsserver, oft werden Komponenten nach dem Komponentenmodell Enterprise Java Beans generiert. Dies alles ist aber nicht im MDA-Ansatz verankert, sondern lediglich die Art der Ausprägung, die man heute am Häufigsten findet. Darüber hinaus sind die Ideen der MDA grundsätzlich eng verknüpft mit UML, die im Bereich der Modellierung von Softwaresystemen – trotz des Fehlens einer präzisen Semantikbeschreibung – als lingua franca der Informatik aufgefasst werden muss. Die Vorschaltung von UML-Modellen vor den eigentlichen Quellcode ermöglicht es, die semantische Spezifikation der Modelle von der Spezifikation der daraus zu generierenden Implementierungen zu trennen.
Die MDA basiert auf Arbeiten verschiedenen Ursprungs. Unbedingt genannt werden müssen an dieser Stelle die Arbeiten von Mellor und Balcer zur Executable Unified Modeling Language. Hier wird beschrieben, wie man die UML so präzise verwenden kann, dass die damit erstellten Modelle ausführbar werden. Ein weiteres wichtiges Konzept ist, die Beschreibungsarten von Ebenen auf der Anwendungs- und Technikebene konvergieren zu lassen. Der bekannteste Vertreter hierfür ist das von Taylor propagierte Convergent Engineering (CE). Die Convergent Architecture (CA) von Hubert ist eine Implementierung dieses Ansatzes. Auch die Arbeiten von Eisenecker liefern einen wichtigen Beitrag. In ihnen wird erörtert, wie mittels Generierung die Gerüste von Softwaresytemen aus fachlichen Modellen erzeugt werden können.
Der MDA-Ansatz steht in der Tradition einiger grundlegender Prinzipien der Softwareentwicklung (beispielsweise der schon Anfang der 70er Jahre von Parnas geforderten Trennung von Spezifikation und Implementierung und des Prinzips der Abstraktion, die jeder Form der Modellbildung zu Grunde liegt). Damit wächst die Zuversicht, dass MDA keine Mode, kein Ergebnis von Marketing-Überlegungen und kein Buzzword, sondern eine nachhaltige Innovation ist.
Fokus Anwendungswissen
MDA hat einen ganz erheblichen Vorteil: Die anwendungserfahrenen Entwickler können ihr Wissen unmittelbar nutzen und in fachliche Modelle umsetzen. Sie werden mehr als je zuvor in die Lage versetzt, ihr Anwendungswissen zum Mittelpunkt des Entwicklungsprozesses zu machen. Sie werden von technischem Standardkram weitgehend entlastet. Damit kann MDA den Umstieg auf eine neue technische Plattform erleichtern, denn die Spezifika der Plattform bleiben den Entwicklern verborgen.
Etwas euphorisch könnte man sagen, dass MDA damit tatsächlich ein Schritt auf dem Weg zu wirklich anwendungsorientierter Softwareentwicklung ist. Zu einer Softwareentwicklung also, bei der Anforderungen und Anwendungswissen im Mittelpunkt stehen, bei der Änderungen an der technischen Infrastruktur keine projektbestimmende Rolle spielen und bei der Architekturdiskussionen, die allzu oft ideologische Formen annehmen, eingehegt werden. Mit anderen Worten: zu einer Anwendungsentwicklung bei der der Anwender konsequent im Mittelpunkt steht.
Was bedeutet diese Einschätzung der MDA für ein Unternehmen, das einen technologischen Umstieg erwägt? Zur Beantwortung dieser Frage sollen eine Reihe alternativer Vorgehensweisen etwas detaillierter betrachtet werden:
1. Kein Umstieg: Kein Umstieg in eine neue technologische Welt ist vordergründig sicherlich die günstigste Lösung. Es entstehen keine Kosten für Qualifizierungsmaßnahmen, für neue Infrastruktur, Softwareprozesse müssen nicht verändert werden. Allerdings lässt diese Betrachtung unberücksichtigt, wie teuer die aktuelle, technologische Situation ist und wie schnell sie noch teurer wird. Auch wenn Infrastruktur- und Softwareprozess-Umgebungen, die über Jahre gewachsen sind, in aller Regel eine erhebliche Reife erreicht haben, müssen in solch gewachsenen Situationen Dinge getan werden, Infrastrukturabhängigkeiten berücksichtigt und Wartungsaufwände akzeptiert werden, die in neuen technologischen Welten geringer sind. Zusätzlich ist zu berücksichtigen, dass die erforderlichen technologischen Skills immer schwieriger zu beschaffen sind.
2. Traditioneller Umstieg – alle lernen neu: Der traditionelle Umstieg hat in den letzten Jahren in der deutschen Versicherungswirtschaft nach Ansicht und Kenntnisstand des Autors nicht funktioniert! Zwar wurden in vielen Häusern erfolgreiche Pilotprojekte durchgeführt. Dies hat zu substanziellem Aufbau von Technikwissen bei einzelnen Experten geführt. Das Problem des breiten Umstiegs wurde jedoch nicht gemeistert. Einerseits liegt das daran, dass die zu wartenden Systeme fast die gesamte Kapazität erfordern und der Mut / die Möglichkeit zu einem Einfrieren der existierenden Systeme angesichts der unglaublich langen Zeiträume für Neuentwicklungen kaum aufgebracht werden kann / kaum realisiert werden kann. Andererseits liegt das auch daran, dass der breite Umstieg inklusive Technikqualifizierung für alle Entwickler zu Kosten und Projektlaufzeiten führen, die wirtschaftlich nicht vertretbar sind, sodass die Alternative „Kein Umstieg“ dann doch die günstigere ist.
3. MDA-basierter Umstieg: Dieser Ansatz wurde im weiter unten beschriebenen Projekt gewählt. Dieses Projekt gehört sicherlich zu den größeren Entwicklungsprojekten der letzten Jahre (Volumen: 55 Mio. €) Der Ansatz des MDA-basierten Umstiegs sieht so aus, dass eine kleine Gruppe von Architekturexperten die technische Architektur festgelegen und einen anwendungsorientierten Entwicklungsprozess definieren. Die Anwendungsentwickler müssen sich mit den Details der neuen Plattform nicht auseinandersetzen, sondern im engen Dialog mit den zukünftigen Anwendern die fachlichen Modelle erstellen. Hierdurch kommt es zu insgesamt erheblich verkürzten Projektlaufzeiten, zu kontinuierlich abstimmbaren Prototypen und insgesamt zu einer Konzentration auf das Wesentliche: die Anwendung!
Fokus Anwendungswissen im Projekt iskv_21C
Im Projekt iskv_21C der ISKV (Informationssysteme in der gesetzlichen Krankenversicherung GmbH) wurde ein Anwendungssystem entwickelt, das alle Geschäftsprozesse einer gesetzlichen Krankenversicherung unterstützt. Dies geschah im Auftrag von ca. 280 Betriebs- und Innungskrankenkassen. Die ISKV war zuvor für Entwicklung und Wartung einer funktional sehr ähnlichen, Großrechner-basierten Anwendung zuständig. Die neue Anwendung mit dem Namen iskv_21C ist J2EE-basiert.
Die ISKV verfügte zu Projektbeginn über ausreichendes Anwendungswissen, nicht aber über Erfahrungen mit der J2EE-Plattform. Eine wichtige, nicht-funktionale Anforderung ist die schnelle Änderbarkeit der Software, da der Gesetzgeber Änderungen an der Fachlichkeit sehr kurzfristig beschließen kann. Zudem bestehen bei den einzelnen Krankenkassen große Unterschiede in der Ausgestaltung der Geschäftsprozesse. Denn obwohl die in den Sozialgesetzbüchern beschriebenen fachlichen Anforderungen prinzipiell gleich sind, sorgt doch alleine schon die variable Größe der Krankenkassen für erhebliche Abweichungen im Detail. Nicht zuletzt aus dem Software-Investitionsvolumen in Höhe von ca. 55 Millionen Euro (Projekte, die auf die Bereitstellung der gleichen Funktionalität abzielen, kalkulieren mit einem Budget, das in etwa das Zehnfache des 21c-Volumens ausmacht!) ergibt sich, dass die Software über einen langen Zeitraum einsetzbar bleiben muss.
Der MDA-basierte Umstieg bei der ISKV hat zu einer klassischen J2EE-Architektur geführt. Klassisch, handwerklich sauber und einfach. Für diesen Teil war ein vergleichsweise kleines, homogenes und J2EE-erfahrenes Team zuständig. Die letztlich generierte Anwendung sieht so aus als wäre sie von erfahrenen J2EE-Entwicklern traditionell – also ohne Einsatz von MDA – entwickelt worden. Die Services, die im J2EE-Kontext zur Verfügung stehen, wurden umfänglich genutzt. Die zahlreichen, Großrechner-erfahrenen Anwendungsentwickler blieben von den technischen Details und Problemen verschont und taten einfach das, was Anwendungsentwickler tun sollen: Anwendungen entwickeln! Und das in einer Art und Weise, die – ganz im Sinne von MDA – fachliche Modelle in den Mittelpunkt des Entwicklungsprozesses stellt und damit die knappe Ressource – das Anwendungswissen – nahezu verlustfrei in eine neue technologische Welt rettet. Die Vorteile der neuen Plattform konnten damit von Anfang genutzt werden (mächtige Infrastruktur-Services, einfache Anpassung von Oberflächen, etc.), ohne dass Umqualifizierungen nötig gewesen wären. Das gesamte Projekt 21c war deshalb von fachlichen Fragestellungen und Debatten geprägt.
Die typischen Anfangsprobleme nach dem Umstieg auf eine neue Plattform (mangelhafte Performanz, schlechte Skalierung, teure – weil grundlegende Refactorings, von der Funktionalität unangenehm überraschte Anwender) konnten vermieden werden, respektive traten in dem Umfang auf, der auch beim Einsatz einer gewohnten Plattform unvermeidlich scheint.
Fazit: Anwendungswissen retten und neue Technologien erschließen
Wie so oft liegt auch beim Einsatz von MDA der Nutzen neuer Technologien gar nicht im primär technologischen Bereich, sondern darin, dass Wissen produktiv einsetzbar wird. MDA zielt durch diesen Effekt auf eines der großen Ziele des Software Engineering ab: Anwendungen zu bauen, die Anwender sinnvoll unterstützen. Und dies in planbarer, mit den Anwendern eng abgestimmter Art und Weise. Im Projekt iskv_21c konnte auf der Grundlage eines pragmatischen MDA-Ansatzes eine große Anwendung auf einer neuen Plattform (J2EE) von einer Anwendungsentwicklungsmannschaft entwickelt werden, die sich mit dieser Plattform recht wenig auskannte.
Zu all dem haben sicherlich eine ganze Reihe von Faktoren und Umständen beigetragen und nicht nur der MDA-basierte Entwicklungsansatz. Für eines ist dieser Ansatz aber verantwortlich: Trotz des Technologiewechsels konnte das Anwendungswissen gerettet und produktiv ein- und umgesetzt werden.
