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.
Teil 2 Anwendungswissen und MDA
