Mythos 7: Entwicklung

Mit einer SOA wird die Governance zum Kinderspiel. Die Softwareentwicklung muss sich nicht mehr um das Kleinklein der Programmierung kümmern, sondern kann sich auf ihre schönen gemalten Modelle konzentrieren. Eine schöne neue Welt durch SOA?

Warum durch eine SOA die Governance der Softwareentwicklung einfacher werden soll, ist unklar. Mit der SOA entsteht ein Geflecht von vielen autonomen Services, die sich unabhängig voneinander entwickeln und verändern. Extrapoliert man die Erfahrungen aus den Problemen der Dynamic Link Libraries (DLLs) unter Windows auf das Gebiet der Services, wird schnell klar, dass völlig andere Formen von Governance in einem deutlich komplexeren Umfeld notwendig sind. Hinzu kommt, dass auch die Einführung einer SOA expliziter Governance-Mechanismen bedarf. Sonst ist ein derartiges Projekt von Anfang an zum Scheitern verurteilt.

Die Vorstellung, mit SOA sei keine Software mehr zu programmieren, setzt voraus, dass genügend Services schon vorhanden sind und dass diese alle möglichen fachlichen Gegebenheiten abdecken. Sind nicht genügend Services verfügbar, muss hingegen sehr wohl eine große Zahl an Diensten implementiert oder mittels Wrapping bestehender Systeme erzeugt werden. Beide Tätigkeiten benötigen ein hohes Maß an Programmierung.

Ist das Ziel des gefüllten Serviceuniversums durch eigene Anstrengungen oder den Zukauf von Services ermöglicht worden, dann braucht es weniger Programmierung. In dieser Vision der SOA-Anhänger wird die Wirtschaft durch große, allgemein zugängliche Servicelandschaften angekurbelt, in denen sich die Servicekonsumenten und –provider tummeln. Das gleiche Szenario wurde schon in den neunziger Jahren formuliert, nur dass sich damals ein Universum aus Corba-Objekten am Horizont abzeichnete. Das aber trat nie ein! Genauso wenig wird die aufgewärmte Idee mit Hilfe von Services greifen. Es ist keine Frage der Technik, sondern eine Frage des Markts und der Machtverhältnisse oder Vertrauensverhältnisse im Markt. Das oft zitierte Bild des Internets als alles durchdringendes Medium zieht nicht, da das Web wie es heute genutzt wird auf Visualisierung und passive Nutzung ausgelegt ist, Services aber Transaktionen und aktive Nutzung brauchen. Die Serviceuniversen unterliegen den gleichen Zwängen wie die Corba-Universen und werden genauso scheitern.

Die andere Option sieht vor, die Services selbst zu bauen. Hört dann die Entwicklung auf? Nein! Neben dem Problem, dass heute die Mechanismen und Vorgehensmodelle für echte Services fehlen, führt die Sättigung mit Services nicht zu einem Ende der Softwareentwicklung. Das Argument der Services lässt sich auf Unterprogramme übertragen: Wenn wir genügend Unterprogramme haben, die alles können, brauchen wird nur noch einen guten Linker und müssen nicht mehr entwickeln.

In der Welt der Services ist die Entwicklung komplizierter geworden. Neben der eigentlichen fachlichen Funktionalität müssen auch noch Servicequalitäten, Autonomie und Transaktionsverhalten berücksichtigt werden. Solche Eigenschaften verlangen zusätzliches Architektur- und Technikwissen.

Auch die Zahl der spezialisierten Tätigkeiten wird stark zunehmen. Beispielsweise sind Rollen wie Servicearchitekt, Application Builder, Systemintegrator, ESB-Spezialist und andere schon abzusehen. Was sich auch noch verändern wird, ist der Schwerpunkt der Entwicklung. Heute konzentrieren sich die meisten Entwickler auf die Abbildung der fachlichen Anforderungen entweder in Modelle oder in Quellcode. Innerhalb einer SOA muss der Code auch Quality of Services verarbeiten können. Außerdem ist im Gegensatz zu heutigen Applikationen nicht sichergestellt, ob ein Service in der gewünschten Version zur Laufzeit tatsächlich existiert. Daher rückt die Behandlung von Ausnahmen und die Suche nach interoperablen Services viel stärker in den Vordergrund als dies heute der Fall ist.

Fazit: Auch in Zukunft wird es Entwickler geben müssen! Und diese müssen noch mehr Detailwissen besitzen und werden in einer deutlich komplexeren Umgebung tätig sein. (wh)