Mythos 6: Wiederverwendung
Zu den Standardargumenten für eine SOA gehört die mögliche Wiederverwendung schon bestehender Services. Unternehmen sollen damit langfristig Kosten sparen können.
Kernaussagen
Wiederverwendung entsteht nicht durch eine Architektur.
Wiederverwendung wird erreicht, wenn für Wiederverwendung gebaut wird.
SOA und Corba ähneln sich hinsichtlich der Wiederverwendung und bei dem Ausbleiben derselben.
Die SOA-bezogene Wiederverwendung verhält sich analog der Komponentenwiederverwendung, die sehr selten stattgefunden hat.
Das SOA-Paradigma steht mit dieser Behauptung in einer langen Tradition in der Softwareentwicklung. Seit mehr als 30 Jahren dient die Wiederverwendung als Standardargument für jede neue Technik und Methodik, um daraus eine vermeintliche Kostenersparnis abzuleiten und das Thema besser verkaufen zu können:
Die strukturierte Analyse versprach Wiederverwendung durch die Nutzung schon bestehender Funktionen (am besten durch ein Case-Tool), indem der alte Code nochmals genutzt wurde. Fand Wiederverwendung in großem Maße statt? Nein.
Die Protagonisten einer unternehmensweiten Datenmodellierung sagten die Wiederverwendung durch Nutzung eines globalen Modells voraus. Fand sie statt? Nein.
Die Objektorientierung wollte Wiederverwendung durch Vererbung und Interfaces sicherstellen. Gab es großflächige Wiederverwendung? Nein. Nur im Bereich der technischen Klassenbibliotheken taucht so etwas in der Praxis auf, nicht jedoch in der fachlichen Welt.
Die komponentenbasierende Softwareentwicklung versprach ebenfalls eine hohe Wiederverwendung. Fand sie statt? Nein.
Verteilte Systeme, speziell Corba, vermittelten das Bild eines ganzen Universums von öffentlich zugänglichen und damit wiederverwendbaren Objekten und Funktionen. Gibt es dieses Universum heute? Nein.
Die Verfechter der SOA-Idee behaupten in dieser langen Tradition das Gleiche: Mit SOA lasse sich eine massive Wiederverwendung erreichen. Erstaunlicherweise werden dabei, speziell im Umfeld der Web-Services, die alten Corba-Marketing-Argumente munter aufgewärmt. Ist vor diesem Hintergrund eine großflächige Wiederverwendung zu erwarten? Nein!
Aus technischer Sicht ist Wiederverwendung schon sehr lange möglich. Sowohl die Objektorientierung als auch die Komponentenbauweise haben sie stets als ihr hervorstechendes technisches Merkmal bezeichnet. Warum hat de facto trotzdem fast nie eine Wiederverwendung stattgefunden? Die Softwareentwickler haben sich nie bemüht, die Wiederverwendung zu ermöglichen! Der Aufwand zu bestimmen, was eine vorhandene Software leistet und wie sie eingesetzt werden kann, ist aus der subjektiven Sicht des Entwicklers deutlich größer als die erforderliche Energie, einfach ein neues System zu bauen. Verstärkt wird diese Annahme durch die modernen integrierten Entwicklungsumgebungen. Typischerweise unterschätzen Softwareentwickler stets die Größe einer völlig neuen Aufgabe und tendieren dazu, sich zu überschätzen - ein Verhaltensmuster ähnlich den Autofahrern: Laut einer Umfrage zählen sich 80 Prozent der schwedischen Autofahrer zu dem Drittel der besten Autofahrer. Das führt häufig zu einer großen Unterschätzung des nötigen Aufwands. Diese psychologische Barriere hat zur geringen Wiederverwendung in großen Softwaresystemen beigetragen.
Aus Sicht der heute implementierten Systeme dient die Serviceorientierung primär zur Wiederverwendung bestehender Applikationen. Dies wird sich in der Zukunft ändern, weil neue Systeme a priori aus Services ohne den Umweg über Applikationen entwickelt werden müssen. Nur so besitzen sie die notwendige Granularität und Stabilität, um langfristig einsatzfähig zu bleiben.
Auf Services lässt sich das Prinzip des Softwaredarwinismus anwenden. Der Begriff ist der Darwinschen Evolutionstheorie entlehnt. Wird die gesamte Software einer Organisation als ein Pool von potenziell wiederverwendbaren Services angesehen, so lassen sich Beobachtungen ähnlich denen Darwins anstellen. Softwareentwickler müssen sich aus diesem Pool von Services einige zur Wiederverwendung aussuchen und andere dabei vernachlässigen. Ein mehrfach verwendeter Service kann sich selbst, dadurch dass er aktiv genutzt wird, "weitervererben" und damit seine Chancen auf zukünftige Wiederverwendung erhöhen. Die Folge dieses Softwaredarwinismus ist, dass Services, die der Softwareentwickler nicht attraktiv findet, nicht genutzt werden. Sie verschwinden in der Versenkung. Zu den treibenden Kräften hinter dem Softwaredarwinismus gehören:
Verfügbarkeit - Ist ein Service nicht verfügbar, so wird er nie genutzt werden. Genutzte Services haben stets eine höhere Verfügbarkeit, weil sie offensichtlich vorhanden sind. Die mentale Verfügbarkeit oder die häufige Verwendung eines Services erhöht die Chancen, den Service wiederzufinden und damit auch die Chancen des Services, sich weiter im Gedächtnis zu erhalten. Außerdem bedarf es einer Anstrengung, aktive Services aus ihrem Kontext zu entfernen.
Verständlichkeit - Ist ein Service unverständlich, so wird er auch nicht verwendet werden. Insofern ist Verständlichkeit eine treibende Kraft zur Wiederverwendung im Softwaredarwinismus.
Im Umkehrschluss aus dieser Betrachtung muss Wiederverwendung explizit den Softwaredarwinismus in Betracht ziehen: Die Services sind so zu entwickeln, dass Softwareentwickler sie wiederverwenden wollen. Daher müssen wiederverwendbare Services so konzipiert sein, dass sie sofort und ohne Veränderung einsetzbar sind.
Werden in der Softwareentwicklung bestehende Serviceimplementierungen wiederverwendet, so gibt es zwei grundsätzliche Vorgehensansätze:
Development with Reuse - Einem Design der Softwarearchitektur folgt eine genaue Spezifikation der zur Entwicklung benötigten Services. Dann wird nach passenden Serviceimplementierungen gesucht, die - eventuell nach einiger Anpassung - ins System integriert werden.
Reuse-driven Development - Hier wird die Spezifikation des zu entwickelnden Systems und das Design der Architektur bereits von den vorhandenen und wiederverwendbaren Services beeinflusst. Verglichen mit " Development with reuse" kann ein höherer Grad der Wiederverwendung erzielt werden.
Wenn das Softwaredesign auf bereits bestehenden Services basiert, dann folgt es eher dem Bottom-up als dem Top-down-Prinzip. Die bestehenden Services werden solange komponiert, bis weitere Komposition keine zusätzliche Übersicht schaffen würde. Mit dem Grad der Abstraktion eines wiederverwendeten Services nimmt das Maß an eingesparter Entwicklungsarbeit zu, jedoch nimmt die Häufigkeit der Wiederverwendung ab.
Grundvoraussetzung für eine effiziente Wiederverwendung sind Services, die in Bezug auf Allgemeingültigkeit, Qualität, Dokumentation und Zuverlässigkeit hohen Ansprüchen genügen. Der Einstieg in die Wiederverwendung setzt eine Managemententscheidung voraus. Denn bis die entwickelten Services wirklich wiederverwendbar sind, müssen sie, nach den Erfahrungen aus der Objektorientierung, etwa vier- bis fünfmal genutzt werden. Erst dann beginnen sich die Investitionen in die Wiederverwendung auszuzahlen. Ein solcher Grad ist in der Praxis aber vermutlich nie zu erreichen.
Das Prinzip des Softwaredarwinismus hat überhaupt nichts mit Serviceorientierung an sich zu tun, sondern greift bei jeder Form von Entwicklung. Daher liefert SOA keinen echten Beitrag zur Wiederverwendung, der über Corba oder Kompontenentwicklung auf magische Weise hinausgehen würde.
Fazit: Eine SOA braucht Wiederverwendung, erzwingt sie aber nicht!