Same Old Architecture 3.0: OO

Mittelpunkt von SOA (Service Oriented Architecure) sind, wie der Name andeutet, Services. Ein Service ist eine weitgehend unabhängige, kontext- und seiteneffektfreie Funktionalität mit einer wohldefinierten Schittstelle. Dank dieser Eigenschaften können Services für die Realisierung IT-gestützter Geschäftsprozesse ganz einfach kombiniert, hoppla orchestriert werden.

Es geht hier also um prozedurale Programmierung: um Funktionen, Prozeduren, Operationen, Services oder wie auch immer man diese Einheiten nennt, die mit einem Namen und einer Menge von Parametern aufgerufen werden.

Die Qualität der Services im Sinne von SOA bemisst sich daran, in welchem Maße die Services wirklich kontext- und seiteneffektfrei einsetzbar sind. Der Traum des simplen Zusammensteckens und Kombinierens von Services zu Geschäftsprozessen, also einer schönen heilen IT-Welt, wird jäh gestört, dadurch dass diese Services sich immer wieder sperren, außerhalb ihres ursprünglichen Kontextes sauber zu funktionieren. Zumindest sperren sich solche Services, deren Funktionalität nicht komplett neu entwickelt wurde, sondern mit denen nur existierende Funktionalität aus Altsystemen gekapselt wird.

"Kapselung" bestehender Funktionalität ist der Versuch, dieser von Einflüssen der Umgebung unabhängig zu machen. Wenn die Altsysteme dabei nicht wirklich massiv restrukturiert werden, gelingt die Kapselung nicht. Was bleibt, ist nur ein neuer Begriff ("Service") und eine weitere Architekturschicht. Die Probleme bleiben unverändert. Same Old Architecture.

Für das eigentlich immer noch dringend notwendige Aufräumen in den Altsystemen (wegen des bedeutungsvolleren Klanges auch Reengineering genannt) wurden bereits in den vergangenen Jahren in vielen Unternehmen große Summen ausgegeben. Manchmal wurden (und werden) Altsysteme dafür komplett neu geschrieben, beispielsweise in Java. Je größer die Vorhaben dieser Art sind, desto tragischer ist in der Regel das Ergebnis. Die neuen Anwendungen sind viel teurer als die alten Cobol-, PL/1 und C-Systeme, stellen dafür aber viel zu wenig neue Funktionalität bereit und sind noch vor dem Projektende ebenso schlecht wartbar und undurchschaubar wie die Altsysteme. Ich beziehe mich hier auf größere Projekte mit 40 bis 200 Mitarbeitern, mehreren Jahren Laufzeit und der Ablösung von geschäftskritischen Kernsystemen in Großunternehmen.

Vor diesem Hintergrund ist die Idee von SOA richtig und wichtig, denn es geht immer noch darum, diese verdammten Abhängigkeiten in und zwischen den Anwendungen zu minimieren. Klare, saubere Services sind ein vernünftiger Lösungsansatz. Da die Begriffe strukturierte Programmierung, prozedurale Entwicklung oder Spaghetticode schon in den 1980er Jahren verbraucht wurden, Reengineering auch durch ist, ist es nun "SOA". Dagegen ist nichts zu sagen, denn Begriffe ohne Kraft, ohne Motivations- und Begeisterungsfähigkeit helfen uns auch nicht weiter. Vor allem können wir mit ihnen beim IT-Vorstand kein frisches Geld locker machen. Deswegen also SOA.

SOA ist heute nicht mehr so neu. Es wurden viele völlig überzogene Versprechungen gemacht und jetzt, also 1 - 2 Jahren nach dem SOA-Hype, wird deutlich, dass diese nicht eingelöst werden können. Ein paar einzelne saubere Services rechtfertigen den Aufwand nicht. Nur sehr wenige Unternehmen haben überhaupt eine Basis geschaffen, um unter dem Schlagwort SOA substanzielle Vebesserungen in ihrer IT-Architektur zu ermöglichen.

SOA ist also auch verbraucht. Gartner, Oracle und andere propagieren deswegen seit einigen Wochen SOA 2.0. Was bei der neuen Version hinzukommt sind echtzeitfähige Services. "Event-Processing-Tools können Muster erkennen, die traditionelle Werkzeuge nicht sehen", sagt Roy Schulte von Gartner. Die zeitnahe Reaktion auf Ereignisse sei wichtig, beispielsweise die Überwachung von Lieferketten, wo Störungen im Warenfluss eine sehr schnelle Reaktion erfordern, sagt Thomas Kurian von Oracle. Vielleicht geht es also doch nur darum, wieder neue Werkzeuge zur Lösung der so hartnäckigen Probleme zu verkaufen.

Also ehrlich: "SOA 2.0" finde ich etwas schwach. Einfach nur neue Versionsnummern an einen Hype ranzuhängen, finde ich billig. Wir brauchen richtig neue, vor allem ultimative Lösungen. Ich hätte da auch eine Idee:

Eine typische Herausforderung bei der Arbeit mit Services ist der Umgang mit Zuständen. Der prozedurale Ansatz macht es schwer, die Services mit einem Daten-Gedächtnis zu versehen. Wenn sich ein Service etwas merkt, heißt dies ja, dass er in Abhängigkeit vom Gedächtnisinhalt anders reagiert. Da ein Service andererseits eine Kapsel ist, ich also nicht sehen kann, welchen Daten im Servicegedächtnis sind, ist die Funktionalität für den Servicebenutzer nicht immer vorhersagbar. Es treten also zustandsgetriebene Seiteneffekte auf. Zustandsinformationen sollten also vielleicht besser immer explizit über die Service-Schnittstelle mitgeliefert werden, um dies zu vermeiden. Diese Trennung von Daten und Prozeduren (Services) ist leider nicht sehr elegant. Meine Idee wäre daher, die Services mit ihren Daten zusammenzufassen und zu kapseln. Diese Art von Service nenne ich "Objekt". Jedes Objekt repräsentiert dabei einen geschäftlichen Gegenstand, beispielsweise einen Auftrag, einen Kunde etc. Diese Services bzw. Objekte können auch direkt untereinander agieren, beispielsweise könnte ein Kundenobjekt ein neues Bestellpositions-Objekt an das Auftrags-Objekt senden. Dieses Konzept, ich möchte hier sogar von einem neuen Paradigma sprechen, nenne ich Objektorientierung.

Mein Vorschlag zur Lösung aller Architekturprobleme heißt also Objektorientierung. Objektorientierung ist der legitime Nachfolger von Serviceorientierung (SOA).

Zufällig habe ich dazu auch ein Buch geschrieben: "Objektorientierte Softwareentwicklung - von der Analyse bis zur Spezifikation", Oldenbourg-Verlag, München 1995. Leider ist es seit einiger Zeit vergriffen, Sie müssen daher die aktuelle 8. Auflage mit dem Titel Analyse und Design mit der UML 2.1 - Objektorientierte Softwareentwicklung kaufen. Es richtet sich an Softwareentwickler. Für die mehr an den Geschäftsprozessen interessierten Leser hätte ich noch Objektorientierte Geschäftsprozessmodellierung aus dem Jahre 2003 (dpunkt-Verlag) anzubieten. ()