SOA meets BPM

Bis vor wenigen Jahren wurde das Thema Service orientierte Architekturen nahezu ausschließlich aus IT-Sicht diskutiert. Prägen auch heute noch vor allem große Softwarehäuser ein sehr stark tool-orientiertes, IT-lastiges Problemlösungsdenken, wird der Kern des derzeit wieder heiß diskutierten Architekturparadigmas SOA von der Mehrheit der Marktteilnehmer inzwischen, definitorisch und konzeptionell korrekt, im Zusammenspiel von Geschäftsprozessmanagement („Business“) und Technik und nicht allein in Fortschritten fachlicher Einzeldisziplinen – wie beispielsweise in der Entwicklung neuer Programmierstandards oder Schnittstellenkonventionen – gesehen.

Gerade dieses Interagieren der in vielen Unternehmen organisatorisch oft getrennt aufgestellten Domänen ist es jedoch, das nicht wenigen Konzernen in der Umsetzung Service orientierter Architekturkonzepte so seine Schwierigkeiten bereitet.

Dass das sogenannte „Business-IT-Alignment“ einen wesentlichen Erfolgsfaktor auf dem Weg hin zu einer effizienten Kommunikations-infrastrukturimplementierung darstellt, wird in Fachartikeln und Podiumsdiskussionen sowie Fachforen so häufig propagiert, wie es an Umsetzungspfaden zu dessen Erreichung mangelt. Überraschen kann dies indes nicht, ist doch die Verschaltung zwischen Geschäftsprozess und der als dessen Umsetzungswerkzeug agierenden IT einer der sensibelsten weil „menschlichsten“ Entwicklungsvorgänge, der zudem von Unternehmen zu Unternehmen individuell divergiert.

Inwieweit vor diesem Hintergrund „Studien“, wie jener des Unternehmens Amberpoint, nach der rund 60% der in einer Erhebung befragten CIOs im Rahmen der Einführung Service orientierter Architekturen bereits heute „die meisten ihrer Projekt-Ziele erreicht“ haben, Glauben geschenkt werden darf, bleibt der individuellen Interpretation der hier zugrunde gelegten (Projekt-)Zieldefinition durch jeden Einzelnen überlassen. So lassen nicht zuletzt die fortwährend intensiv geführte Diskussion des Themas sowie die stetig wachsenden IT-Budgets der Unternehmen für Beratung, Konzeption und Implementierung Service-orientierter Architekturen Zweifel aufkommen, ob die erhoffte Weiterentwicklung hin zum „agilen, den Anforderungen der Zukunft gewachsenen Konzern“ tatsächlich erreicht werden konnte.

Sollen auf ganzer Linie die heutzutage das Konzept nahezu ausnahmslos positiv besetzenden Potenziale einer SOA, wie Wiederverwendbarkeit von Diensten, agile, an wandelnde Umweltgegebenheiten sich flexibel anpassende Geschäftsprozesse oder, dadurch bedingt, durchschlagende Kosteneinsparungspotenziale gehoben werden, müssen Unternehmen eine ganze Reihe technischer wie auch organisatorischer und politischer Hürden nehmen. SOA wird zur Change-Management- und Organisationsaufgabe.

Und so lautet die Frage in Zukunft nicht mehr nur, wie eine Service orientierte Architektur zu implementieren ist, sondern auch bzw. vielmehr, wie eine Organisation geschaffen werden kann, welche die effektive Implementierung einer SOA überhaupt zulässt. Bleibt die Beantwortung letzterer Fragestellung jedoch weiterhin unbeantwortet weil unbeachtet, sind suboptimale Projektergebnisse, die am Ende jenen inzwischen gerade deshalb vermehrt laut werdenden Stimmen Nahrung geben, welche SOA als „anbieterorientierte Marketing-Strategie“  oder gar „Geldverschwendung“ verschreien, unvermeidliche Konsequenz.

IT- und Organisationsorchestrierung

Wirft man einen Blick in die Literatur, stellen Serviceorchestrierung und -choreographie zentrale Begrifflichkeiten im Hinblick auf die Philosophie der Prozesssteuerungswahl innerhalb des Themenfeldes Service orientierter Architekturen dar. Dass diese „(Neu)-Orchestrierung“ – oder allgemeiner, dieses neue Zusammenspiel – aller IT-bezogenen Instrumente eines Unternehmens auch ein neues Zusammenspiel der Organisationseinheiten eines Unternehmens, mit all den in ihnen verankerten Kompetenzen und somit nicht zuletzt eine neue Definition der Unternehmenspolitik notwendig macht, wird bislang oft außer Acht gelassen. Wird der konzeptionelle Ansatz einer SOA in Projekten, welche maßgeblich in die vitalen Geschäftsprozesse eines Konzerns eingreifen (und eben nicht irgendwelchen Mickey Mouse Projekten) zur Anwendung gebracht, kommt es zwangsläufig zu weit reichenden, durch eben jenen Verantwortungstransfer induzierten Machtverschiebungen innerhalb des Unternehmens, gegen die sich die vermeintlich unterlegene Partei, bei Wahrnehmung des Machtverlustes, mit den bekannten Mitteln zur Wehr setzen wird.

Dass auch bei zur Zusammenarbeit (zunächst) gewilltem Personal indes im operativen „Doing“ der mit der SOA-Konzeptumsetzung notwendigerweise einhergehenden Geschäftsprozessimplementierung in manchen Fällen Frustration aufkommt, liegt neben unklaren Projektzieldefinitionen oder auch in Einzelfällen nicht optimal ausgebildetem Personal, an in der Persönlichkeit begründeten Charakteristika von Denk- und Handlungsstrukturen der sich bewusst für unterschiedliche Berufsbilder entschieden habenden Charaktere, wie auch nicht selten orthogonal zueinander stehenden Ziel- und Anreizsystemen der betroffenen Fachbereiche.

So ist einerseits zu konstatieren, dass Menschen, die sich für unterschiedliche Berufsbilder entschieden haben – und kaufmännische und technische Stellenprofile divergieren inhaltlich doch deutlich voneinander – unterschiedlich sozialisiert und ausgebildet sind, andere Wertesysteme haben, gar in verschiedenen Wahrnehmungs- und Sprachwelten leben. Und so nähern sich „Process Engineer“ und Systemarchitekt – um nur zwei Stellenprofile prototypisch für beide Lager herauszustellen – Problemen ebenso unterschiedlich wie sie Begrifflichkeiten und Sprache divergent verwenden. Missverständnisse und die aufgrund divergierender Zielsysteme logischerweise entstehende Verfolgung individueller (lokaler) Optima sind die Folge. Gesamtoptima aus Unternehmenssicht können oder sollen nicht verfolgt werden.

Einen sinnvollen, wenn auch – vielleicht durchaus bewusst – inhaltlich sehr eng gefassten Lösungsansatz zu Annäherung beider Welten liefern Vollmar et al.  in ihrem Beitrag zur Governance-Umsetzung, welcher auf der herstellerübergreifenden Informationsplattform der Bitkom soa-know-how.de publiziert wurde. Sie propagieren mit der Etablierung eines „SOA Centers of Excellence“ die Schaffung eines bereichsübergreifenden Gremiums, „welches aus Mitgliedern der Fachbereiche und der IT auf unterschiedlichen Hierarchiestufen zusammengesetzt ist“ und dessen Aufgabe in der Unterstützung von Projekten, dem Durchführen von Architektur-Reviews oder dem Sammeln und Verwalten von Services und deren Metadaten liegt.

Im Gegensatz zu der von vorgenannten Autoren vertretenen Lösung zur Überwindung des „IT-Business Gaps“ sollte die Zusammensetzung dieses Gremiums indes nicht temporärer Natur sein, da sich Zielsystem und kulturell-soziologischer Hintergrund der in diesem vereinigten Individuen nicht innerhalb von Tagen – quasi per Dekret – nachhaltig im Sinne eines für (zumindest größere) SOA-Projekte erforderlichen ganzheitlichen Denkens und Handelns ändern lässt. Mehr noch: Das geschaffene Gremium benötigt einen Moderator zwischen IT und (i.d.R. kaufmännischen) Fachbereichen, der über weit reichende Entscheidungs- und Fachkompetenzen verfügt. Gerade letzteres ist in aller Regel sehr branchenbezogen, da Prozess Know-how, und über dies muss die Instanz zwingend verfügen, nicht nur in methodologischen Aspekten, sondern, zwecks Sicherstellung der Akzeptanz im Unternehmen und Projektzielführungskompetenz, vor allem auch in fachlichen Fragen unabdingbar ist. Letztlich sind die Aufgaben der Moderatorenfunktion vielfältig und reichen so von der zentralen Kommunikationssteuerung über das Prozess-Effizienzmonitoring bis hin zu Übersetzerfunktionen zwischen den unterschiedlichen Sprach- und Begriffswelten und dem hiermit oft verbundenen Konfliktmanagement.

Nur als eigenständige Instanz mit Weisungsbefugnis gegenüber Drittparteien ausgestattet, durch ein starkes Management etabliert und mit außergewöhnlichen kommunikativen Fähigkeiten ausgestattet, lässt sich die zweifelsfrei ebenso außergewöhnliche Herausforderung bewältigen. Vor allem aber bedarf es, wie bereits zuvor angedeutet, eines konsequenten und gut strukturierten Entwicklungsprozesses, Mitarbeiter in jene Position zu entwickeln. Diese Voraussetzung indes zu schaffen, ist Aufgabe des Top-Managements, welches wiederum professionell diesen organisatorisch sehr weit reichenden Wandel zu managen in der Lage sein muss.

SOA heißt daher weniger Tooldenken, weniger Top-Down oder Bottom-Up und ganz sicher zwecks Erzielung gesamtunternehmerischer Optima und Prozess- wie Systemkomplexitätsbeherrschung ein Aufeinanderzubewegen von Business und IT, das jedoch weiter greift, als manchem heute bewusst sein mag. SOA findet nicht per Erlass statt, es ist vielmehr „orchestrierter Entwicklungsprozess“ denn Projekt. Dann und nur dann wird unser Ansicht nach SOA sich auch rechnen.

Bernhard Balkenhol
Oliver Simon
Axel Wiemann
Infinity³