Von CW-Redakteur Wolfgang Herrmann

Viele SOA-Projekte werden spektakulär scheitern." Das prognostizierte Anne Thomas Manes vom US-amerikanischen Beratungsunternehmen Burton Group auf der "SOA Days 2006 Technology Conference" in Bonn. Schuld daran seien nicht die Technik, sondern kulturelle und politische Probleme. Nachhaltigen Erfolg bringe nur eine strategische Planung. Nach ihrer Einschätzung gehören dazu eine Enterprise-Perspektive, ein starkes Governance-Programm und eine robuste Runtime-Infrastruktur.

Business und IT entkoppeln

Um das komplexe Vorhaben einer Service-orientierten Architektur in den Griff zu bekommen, sollten sich Unternehmen des weiter gefassten Konzepts der Enterprise Architecture (EA) bedienen, empfahlen etliche Referenten: "Nutzen Sie EA-Elemente, um Governance und Business-Modelle aufzusetzen", riet etwa Michael Herr, Chef des Post-eigenen IT-Dienstleisters Sopsolutions. Er verwies auf die rund siebenjährige Erfahrung, die die Post bereits in SOA-Projekten gesammelt habe. Ein Schlüssel zum Erfolg liege in der Entkopplung von Business- und IT-Elementen mittels einer logischen Schicht.

Die Notwendigkeit einer Enterprise Architecture illustrierte der unabhängige IT-Berater Gernot Starke anhand einer Architekturpyramide, deren Spitze die Unternehmensstrategie mit der Business-Architektur bildet (siehe Grafik "Architekturpyramide"). Die unterste Schicht repräsentiert die Basisinfrastruktur mit Hardware und systemnaher Software, darüber liegt die Softwarearchitektur mit den Applikationen. In vielen Unternehmen sind lediglich die oberen und unteren Enden der Pyramide ausgeprägt, so Starke. Dazwischen aber klaffe eine Lücke, die das Zusammenspiel zwischen Technik- und Geschäftsstrategie, sprich "Business-IT-Alignment", erschwere.

Schließen sollen die Lücke so genannte Enterprise-Architekten, die sowohl über IT- als auch über Business-Know-how verfügen. In der Praxis sind solche Experten Mangelware. Starke erntete für seine Empfehlungen denn auch nicht nur Zustimmung von den Konferenzbesuchern. Unklar blieb insbesondere, woher die Unternehmen solcherart qualifizierte Kräfte nehmen sollen. Da es keine dedizierten Ausbildungswege für Enterprise-Architekten gebe, gelte es, diese Spezies zu "züchten", entgegnete der IT-Berater. Aus seiner Sicht eigneten sich Softwarearchitekten am ehesten; allerdings müssten sie zusätzliche Qualifikationen erwerben, um die Akzeptanz der Fachabteilungen zu gewinnen.

Wo sind die Architekten?

In Fachkreisen ist diese Sicht umstritten. Joachim Schelp und Robert Winter von der Universität St. Gallen beschreiben den Architekten im Kontext von Enterprise Architecture Management (EAM) als eine Art Tausendsassa: Er kommuniziere sowohl mit Fachabteilungen als auch mit Entwicklern, verstehe Geschäftsprozesse und technische Details und besitze noch dazu die Fähigkeit, ein Konzept "leitend wie auch durchführend umsetzen zu können". In der Summe ergebe sich ein Anforderungsprofil, das kaum ein Mitarbeiter allein abdecken könne. Die Experten raten deshalb zu gemischten Architektenteams aus IT- und Fachabteilungen.

Fachliche Services

Johannes Helbig, CIO des Post-Konzernbereichs Brief, verwies in diesem Zusammenhang auf die Bedeutung fachlicher Services. Im Rahmen einer Enterprise Architecture erforderten SOA-Initiativen eine dedizierte Verwaltung des Serviceportfolios, verbunden mit einem konsistenten Service-Lifecycle-Management. Die Deutsche Post setze dabei auf ein fachliches Domänenmodell, das die Grundlage der SOA bildet. Auf diesem Weg lasse sich die "semantischen Integration" bewerkstelligen, die aus seiner Sicht zu den Kernelementen einer SOA gehört. Helbig: "Das liefert kein Hersteller." Seine persönliche SOA-Definition lautet: "SOA = Semantic Integration + Loose coupling + Managed Evolution."

Vom Modell zum Service

Die Post geht diese Art der Integration über ein Enterprise Service Model an, das fachliche Domänen wie "Kunde" und Fachklassen (zum Beispiel "Erreichbarkeit") definiert. Wie sich daraus mit Hilfe von Software-Tools ausführbarer Programmcode generieren lässt, erläuterte Alexander Scherdin, Senior Professional Service Design, in Helbigs Team. Im Rahmen einer "Service-Design Toolchain" folgt das Bonner Unternehmen dabei einem MDA-Ansatz (MDA = Model Driven Architecture). Die automatische Codegenerierung erspare einen großen Teil der Arbeiten, die früher aufwändig per Hand erledigt werden mussten, so Scherdin. Seit dem Start der Toolchain vor zirka 18 Monaten habe die Post damit rund ein Dutzend Softwareservices generiert und in den Livebetrieb genommen.

Auf technischer Ebene kristallisierten sich Registries als "Single Point of Truth" für SOAs heraus, berichtete Helbig. Sie bieten ein Verzeichnis aller verfügbaren Software-Services und spielen für die Verwaltung Service-orientierter Architekturen eine wichtige Rolle. Allerdings reichen Registries bei weitem nicht aus, um das vielschichtige Thema SOA Governance abzu- decken, wie Burton-Expertin Manes erläuterte. Unabdingbar sind aus ihrer Sicht auch Repositories auf verschiedenen Ebenen, die etwa das Policy-, Metadaten- oder Contract-Management ermöglichen. Die Vorstellung, ein zentrales Registry-Repository-System könne die komplette SOA steuern, hält sie für unrealistisch.

SOA-Stacks in der Kritik

Bei der komplexen Aufgabe, eine SOA aufzubauen und zu verwalten, helfen die Angebote der IT-Anbieter nur bedingt weiter, warnte die Beraterin: "Softwarehersteller wollen eine ‚komplette SOA-Plattform‘ verkaufen. Doch die gibt es nicht." Per Definition handele sich bei einer SOA-Infrastruktur um eine Multivendor-Umgebung, also eine Kombination aus Produkten unterschiedlichster Anbieter, gepaart mit eigenentwickelten Systemen. Technik allein garantiere ohnehin keinen Erfolg, so Manes. Sie stelle lediglich die Tools und Rohmaterialien bereit. Es liege an den Anwendern, diese effektiv zu nutzen: "SOA ist wie körperliche Fitness. Sie erfordert einen veränderten Lebensstil und Disziplin."(wh) u