SOA leistet Integration auf Prozessebene
Auch Integration rechtfertigt sich nur dann, wenn sich damit die Unternehmensprozesse verbessern lassen, nicht allein durch Kosteneinsparungen.
Es folgen die ‘Wie-Fragen’. Wie wird eine SOA organisatorisch eingeführt und umgesetzt? Wie sieht das Management der Services aus? Erst dann kommt es zur Bildung von funktionalen Clustern. Man beschäftigt sich mit der Struktur und der Integration von Anwendungen. Das Ergebnis ist eine Landkarte, die preisgibt, an welchen Stellen lose, möglichst asynchron zu koppeln ist. Danach lassen sich die Softwarefragen klären, zum Beispiel welche Komponenten sich für die Wieder- beziehungsweise Mehrfachverwendung eignen.
Gebot Nr.3 schreibt Transparenz vor
Ein solches Vorgehen findet sich jedoch höchstens in 5 Prozent aller Fälle, schätzt der St. Gallener Professor. Wahrscheinlicher ist, dass SOA auf der Software-Ebene beginnt. Hier seien Services ein “wohlverstandenes Design-Prinzip”. Offen sei lediglich, inwieweit sich die technisch neue Gestaltung überhaupt in eine Rekonfiguration der Geschäftsprozesse verwandeln lasse.
Wie Elke Jung ausführt, ist ein evolutionäres Vorgehen zwar möglich und sogar notwendig. Allerdings lässt sie keinen Zweifel daran, dass es sich hierbei um Fragen der Umsetzung handle, nicht jedoch der Unternehmensstrategie. Die Fachfrau gestaltet bei der HypoVereinsbank (HVB) im Bereich Organisation, Prozess- und IT-Management die IT-Architektur und Strategie der AG und der HVB-Gruppe. Hier weichen seit zwei Jahren schon fachliche Einteilungen in Säulen wie ‘Konto’ oder ‘Wertpapier’ Prozessdefinitionen, mit dem Ziel, diese Prozesse zu optimieren.
Die Folge für die DV: Die IT-getriebene Software-Entwicklung soll sich aus den Geschäftsprozessen ableiten. SOA ist dabei für Jung ein Zwischenschritt zur Event Driven Architecture (EDA), zur regelbasierten, weitgehend automatisch gestalteten Steuerung und Überwachung der Prozesse. Eine der zentralen Fragen jedoch war und ist laut Jung: “Wie lassen sich die geschäftlichen Anforderungen mit der Technik zusammenbringen und darstellen?” Immerhin verbergen sich Löwenanteile der Bankprozesse im Cobol-Code von Großrechneranwendungen.
Andererseits zählt die Bank alleine etwa 20 Varianten einer Kontoeröffnung. Da erscheint es wahrscheinlich, dass es funktionale Überschneidungen gibt. Um diese wie insgesamt die Prozessabläufe und -zusammenhänge sichtbar zu machen, hat das Jung-Team ein Portal aufgesetzt. In diesem sind mittlerweile rund 80 Prozent aller Bankprozesse dokumentiert, in unterschiedlicher Granularität, Sichtweise und Abstraktionsstufen. So gibt es ein Geschäfts- und ein Prozessmodell, aber auch eine Applikations- und Integrationsebene. Doch reicht die Darstellung von Teil- und Parallelprozessen nicht. Deshalb sind sie mit Funktionsblöcken, so genannten “Building Blocks”, hinterlegt. Zum Beispiel gehört die “Abwicklung Wertpapiere” und “Abwicklung Geld und Devisen” in den Bereich “Transaktionsbank”, in dem Performance, hoher Datendurchsatz zählt. Einen weiteren Block bilden die Partnerstammdaten. Er wird fast in jedem anderen Baustein gebraucht. Deshalb setzt hier ein SOA-Pilotprojekt auf.
Gebot Nr.4: Mit Wundern ist nicht zu rechnen
Navigation durch das Architekturmodell lässt die Zusammenhänge und Abhängigkeiten zwischen den Systemen, aber auch zwischen den Prozessen sowie zwischen Prozessen und Systemen erkennen. “Es entsteht eine unglaubliche Transparenz”, sagt Jung. Diese sowie die Etablierung eines übergreifenden Prozessdenkens aber seien längst nicht jedem recht. Zum Beispiel waren Host-Applikationen bisher nahezu unantastbar. Doch zur HVB-Intention gehört es, die IT-Landschaft zu konsolidieren. Die Monolithen sollen aufgebrochen werden.
Schon jetzt biete das HVB-Architekturmodell einen Software-Bebauungsplan, so Jung. Der Test mit den Stammdaten habe gezeigt, dass sich der Aufwand von Ist-Analysen in IT-Projekten um 10 bis 90 Prozent reduzieren lasse, zum Beispiel wenn es um Technologiewechsel und komplexe Systemzusammenhänge gehe. Zudem konnte die HVB einen Prozess auslagern. Den Zahlungsverkehr wickelt nun die PAS GmbH ab, eine HVB-Tochter. Was jetzt noch fehle sei ein Meta-Modell für Services beziehungsweise ein Service-Repository sowie eine EAI-SOA-Referenzarchitektur.
IT-Leiter Eigelsperger von der HVB-Tochter FMS gehört zu den Skeptikern einer allumfassenden SOA-basierten IT-Architektur. So hätten die 20 Ausprägungen einer Kontoeröffnung vermutlich ihren Sinn. “Building-Blocks gibt es nicht”, sagt er. “Sie sind nur ein abstraktes Ordnungskriterium. Es existieren ausschließlich diverse Prozesse und Applikationen. Außerdem behaupte ich, dass 80 Prozent der Applikationen bereits in saubere Module gegossen sind.” Schließlich hätten Abstimmungsbedarf und ungeklärte Fragen der Verantwortung für die künftigen Services das Potenzial, jeden SOA-Ansatz scheitern zu lassen.
Tatsächlich hätte Eigelsperger bei den EAI-Forums-Besuchern vermutlich ein vielfaches Echo gefunden. So bestätigt Winter, dass die meisten Unternehmen weder organisatorisch auf SOA vorbereitet seien, noch dass entsprechende Verrechnungsmodelle existierten. Die HVB-Strategin Jung rechnet mit einer Amortisation des Architekturmodells frühestens nach drei bis vier Jahren. Analysten jeglicher Couleur gehen davon aus, dass sich erst das dritte oder vierte SOA-Projekt rechnet. Demnach dürfen die Träger des ersten Projekts mit erheblichen Kosten, die der Folgeprojekte jedoch mit dem Nutzen rechnen.
Lösungen gibt es nicht auf Rezept. So hat das Standardisierungskonsortium OASIS erst Anfang Mai ein Projekt ins Leben gerufen, das ein SOA-Referenzmodell entwickeln soll. Mitglieder sind etwa Boeing, Booz Allen Hamilton, Fujitsu und General Motors. Doch hilft vielleicht eine Reduktion aller Fragen auf einige wesentliche. TU-Professor Krcmar macht es vor. Ein IT-Verantwortlicher müsse sich heute vor allem an drei Kriterien messen lassen: “Bewältigen Sie die Komplexität des Zusammenspiels von Geschäftsführung, Nutzer, Nutzung, Infrastruktur, Anwendung und Daten durch Integration oder Entkopplung? An welchen Leistungen wollen sie sich messen lassen, eher an Kostenverursachung oder Ermöglichung des zuverlässigen Zugriffs zu relevanten Informationen? Welchen Wertbeitrag jenseits von Betriebs- und Kosteneffizienz kann beziehungsweise soll Wissensmobilisierung für das Unternehmen haben?”
