Mythos 1: Agilität

Der Einsatz von SOA steigert die Agilität von Unternehmen und ermöglicht so sehr viel kürzere Produktzyklen. So oder so ähnlich lauten die Versprechen der SOA-Befürworter. Doch stimmt dies wirklich?

Die Agilität eines Unternehmens ist dessen Fähigkeit, schnell auf Veränderungen des Markts zu reagieren. Die Schlüsselelemente für diese Fähigkeit sind eine flexible Organisation und flexible Kernprozesse. Wenn ein Unternehmen nicht organisatorisch und prozessgetrieben in der Lage ist, sich auf Veränderungen einzustellen, so wird ihm auch eine SOA nicht helfen können. Wirklich flexible Unternehmen sind so konzipiert, dass sie viel stärker einer virtuellen Organisation ähneln als einem traditionellen hierarchischen Unternehmen. Erst dann kann eine Organisation wirklich agil sein.

Trotzdem müssen auch herkömmliche Unternehmen sich verändern und tun dies auch, allerdings meist in längeren Zeitskalen als vergleichbare virtuelle Organisationen. Die Veränderung in den Unternehmen betrifft zunächst die Prozesse. Eigentlich sollten sich die Verantwortlichen auf den Kernprozess der Organisation konzentrieren, damit eine maximale Verbesserung erzielt werden kann. Allerdings sind solche Kernprozesse in aller Regel sehr komplex und stark durch manuelle Tätigkeiten bestimmt. Außerdem sind Kernprozesse fast immer sehr dynamisch. Sie haben wenig mit Technologie zu tun, aber viel mit Organisation! Insofern sollten alle Versprechen bezüglich Agilität und Effizienz, die auf Grund von Architekturen oder Werkzeugen gemacht werden, mit großer Vorsicht betrachtet werden.

Ein Ziel des heutigen Business Process Rengineering ist, dass Unternehmen unterschiedliche, aber ähnliche operative Prozesse in einer einzigen Umgebung zusammenbringen möchten. Damit soll die Effizienz steigen. Eine Konsequenz daraus ist die heute stark vorherrschende Sicht auf datenzentrische Systeme und geschlossene EAI-Systeme (EAI = Enterprise Application Integration). Die meisten "neueren" Applikationen in großen Organisationen haben sich auf die "harte Verdrahtung" von Transaktionen und Subprozessen konzentriert, mit der Folge, dass die Orchestrierung oder Choreographie sehr schwer geworden ist. Der Weg von einer herkömmlichen Architektur zu einer Service-basierenden ist schwer, da hier sehr viel stärker von konkreter Technologie abstrahiert werden muss und ein grobgranulareres System entsteht.

Es ist recht aufwändig zu bestimmen, ob eine bestimmte Implementierung eines Geschäftsprozesses angemessen ist: Trotzdem sollte man versuchen, dies zu bewerten. Je einfacher und einsichtiger eine Implementierung ist, desto besser. Auf der anderen Seite gilt aber auch: Je agiler die Servicelandschaft, desto besser. Agilität geht oft einher mit sehr feiner Granularität, die eine erhöhte Komplexität zur Folge hat. Umgekehrt führen grobgranulare Services zu geringerer Agilität. Daher hat der konsequente Einsatz einer SOA zur Folge, auf der Softwareseite entweder agil und sehr komplex zu sein - mit allen innewohnenden Risiken - oder einfach und weniger agil, damit aber auch weniger flexibel.

Agilität ist das Ergebnis einer Organisations- und Prozessform, nicht das Resultat einer Softwarearchitektur! Wenn ein Unternehmen die dafür nötige Struktur besitzt, dann macht der Einsatz einer entsprechenden Softwarearchitektur Sinn und nicht umgekehrt. Der zweite Weg, zuerst die Technik, dann die Organisation, ist für IT-Experten immer wieder verlockend, führt aber in die Irre. Software ist bis zu einem gewissen Grad ein Abbild der Kommunikationsstruktur und Verantwortlichkeiten in einem Unternehmen. In Legacysystemen werden diese beiden Strukturen "hart" codiert. Wenn aber die Struktur des Unternehmens hierarchisch ist, lässt es sich nur über eine Reinterpretation von Verantwortlichkeiten und Rollen in eine Software abbilden. Diese permanente geistige Leistung erzeugt jede Menge Stress und Konflikte, so dass schließlich die Organisation ein Abbild ihrer selbst in der Software erzwingt. Außerdem ist eine technisch konzipierte SOA keine wirkliche Abbildung der fachlich notwendigen Services. Es sind aber gerade diese fachlichen Services, die agil sein müssen. Folglich nützt eine technikgetrieben Implementierung nichts.

In der Regel ist die Situation noch prekärer: Technische Services werden heute aus Sicht der Implementierung gebaut und dem Unternehmen wie auch dem Markt übergestülpt. Solche Services finden wenig Akzeptanz und sind nicht auf den Markt ausgerichtet. Gute Services sind stets kundenzentriert; das heißt, der Leistungsumfang und die Struktur entspricht den Problemen des Kunden und nicht der Phantasie des Providers. Veränderungen auf dem Markt werden durch geändertes Kundenverhalten ausgelöst. Das wiederum führt zur Forderung nach neuen Services. Wenn diese aber nicht aus Kundensicht konzipiert werden sondern wiederum nur aus der technischen Providersicht entstehen, ist es müßig, nach der Agilität zu fragen, da der Service de facto nicht angenommen wird.

Der heute oft gehörte Vorwurf, die IT sei nicht agil und könne sich nicht schnell genug auf Wünsche der Fachbereiche einstellen, hat andere Gründe als die Architektur. Die Entwicklung neuer Funktionen oder die Veränderung bestehender dauert einfach zu lange. Die Ursache dafür liegt neben veralteten und behäbigen Vorgehensmodellen in mangelnder Kenntnis der Fachlichkeit auf Seiten der IT. Dies soll durch SOA plötzlich besser werden? Nur weil es Services gibt, lassen diese sich schneller ändern? Wenn es so einfach wäre, könnten Entwicklungsabteilungen das heute schon. Denn es ist genauso einfach, an Stelle eines Services ein Unterprogramm zu ändern - und schon müsste es funktionieren. Die Praxis zeigt aber, dass es offensichtlich nicht so einfach ist.

Fazit: Eine SOA erzwingt keine Agilität. Wenn sie technikgetrieben entsteht, kann sie Agilität sogar massiv behindern.