Die Post rief, und die Crème der deutschsprachigen Unternehmen kam: In diesem Jahr dominierten Praxisberichte die bereits traditionellen SOA Days im Bonner Post-Tower. "Gab es vor zwei Jahren noch hauptsächlich Absichtserklärungen, so sind die Unternehmen in diesem Jahr schon deutlich weiter", resümierte Johannes Helbig, der als CIO der Deutschen Post AG den Gastgeber spielte.
Statt der bisherigen Zweiteilung in eine technische und eine Business-Konferenz gaben die Post AG und der Veranstalter Euroforum heuer einem kombinierten Event den Vorzug. Naturgemäß standen dabei organisatorische und wirtschaftliche Fragen im Vordergrund.
Hier lesen Sie …
wo die Analogien zwischen der Autoherstellung und einer SOA liegen;
weshalb die Credit Suisse immer noch Corba einsetzt;
wie schwierig es ist, eine wirklich globale Architektur zu bauen;
was die IT-Architektur der Zukunft leisten muss.
Das Ziel: Synergien durch Wiederverwendung
Ein früher Höhepunkt der Konferenz war der Vortrag von Michael Gorriz, dem frisch gebackenen CIO der Daimler AG. Er zog Parallelen zwischen dem Fahrzeugbau und der Erstellung einer Unternehmensarchitektur. Motivation für die Einführung einer Service-orientierten Architektur sei die Grundannahme gewesen, dass in einem Konzern, der schwerpunktmäßig Fahrzeuge herstelle, Synergien durch Wiederverwendung erzielbar seien. So modular, wie Daimler - auf der Grundlage einer Fahrzeugarchitektur - seine Autos produziere, sollten sich mit Hilfe einer Service-orientierten Architektur auch die benötigten IT-Anwendungen zusammensetzen lassen.
Gorriz stellte dem Auditorium eine SOA-Roadmap vor, die vier Aspekte umfasst:
Organisation, Steuerung und Governance,
Methoden und Vorgehensmodelle,
Architektur und Technologie sowie
Geschäftsprozesse.
Der Zeitrahmen spannt sich von der Entwicklung erster Services im Jahr 2006 bis zur angestrebten Erstellung "optimierter Business-Services" mit kontrollierten Key-Performance-Indikatoren (KPI) im Jahr 2010.
SOA funktioniert auch mit antiker Technik
Deutlich länger als Daimler beschäftigt sich die Credit Suisse (CS) mit dem Thema SOA. Ihre ersten Aktivitäten datieren aus dem Jahr 1998. Allerdings setzte die Bank ihren"CS Information Bus" auf Softwaretechnik auf, die heute beinahe antik anmutet. Die Basis bildeten die standardisierte Common Object Request Broker Architecture (Corba) und das Messaging-Produkt "MQ Series" von IBM.
"Corba hat sich als die richtige Wahl herausgestellt, weil es mitwächst", beteuerte Claus Hagen, Director Integration Architecture bei der CS, "aber die Technologie ist am Ende des Lifecycle angegelangt." Deshalb müsse die Bank "irgendwann" umsteigen: "Wir wollen ja nicht die Letzten sein, die diese Technik finanzieren." Web-Services sind für Hagen nur in Ausnahmefällen, beispielsweise im Rahmen einer Beraterlösung für kleinere Bankniederlassungen ("Bankboutiquen"), eine Alternative. Generell ließen sich damit die bei der CS anfallenden Volumina noch nicht stemmen.
Aufgrund der langen SOA-Tradition gibt es bei der CS heute keine Applikation mehr, die keine Services anbietet oder bezieht, so Hagen. Da die Services zumeist Bottom-up entwickelt werden, musste der Finanzdienstleister eine strenge SOA-Governance einführen. "Das kostet uns pro Service sechs Personentage", räumt Hagen ein, "und auch wenn wir das Optimierungspotenzial ausschöpfen, wird es unter vier Tagen wohl kaum möglich sein." Aber dieser Aufwand lohne sich.
Monolithische Struktur am Mainframe wird entflochten
Eines der jüngeren CS-Projekte widmet sich dem Entflechten der monolithischen Softwarestruktur auf dem Mainframe. Es wurde 2005 ins Leben gerufen. "Bislang musste bei jedem Release die gesamte Codebasis überarbeitet werden", erläuterte Hagen. Durch die Entkopplung in 80 bis 100 Domänen will die Bank diese Komplexität verringern und bei Softwareänderungen Zeit sparen. Das Gesamtvorhaben soll Ende nächsten Jahres beendet sein; im vergangenen Februar wurde bereits der erste Service nach diesem Prinzip in Betrieb genommen.
Ulrich Gehrke, Leiter des CTO-Kompetenzfelds Softwareengineering bei der Volkswagen AG, rekurrierte auf die Faktoren, die eine Modularisierung der IT und ein EnterpriseArchitecture-Management unabdingbar gemacht hätten. Dazu zählt er
die Zunahme der weltweit verteilten Standorte und der globalen IT-Anforderungen,
die Daten- und Komplexitätsexplosion,
den Innovationsdruck,
die neue Rolle der IT als Werkzeug zur Effizienzsteigerung in den Fachbereichen sowie die
gestiegenen Anforderungen an Prozess- und Betriebssicherheit.
"In der ingenieurmäßigen Industrialisierung ist die Firma deutlich weiter als in der IT", räumte Gehrke ein. Deshalb könne die IT vom Business viel lernen - beispielsweise die Spielregeln, wer und wie etwas freigegeben darf.
Von den Schwierigkeiten, eine wirklich globale Architektur aufzubauen, berichtete Kurt Lermann, Chief Architect Group Functions bei der Zurich Versicherung. In der Schweiz hatte das Assekuranzunternehmen bereits eine SOA mit etwa 300 Services aufgebaut - unter dem Markennamen "Omni" -, aber das Mutterland der Zurich trägt nur ein Zehntel zum Gesamtumsatz des Unternehmens bei. Hingegen wird die Hälfte in den USA erzielt. "Wenn wir sagen würden, Omni ist unser Standard, hätten wir ein Problem", weiß Lermann.
Stattdessen hat der Chefarchitekt im April 2006 ein Expertenteam zusammengeholt, das eine wirklich globale Struktur schaffen sollte. Allein die Planung zog sich über ein ganzes Jahr hin, erst 2007 wurden die ersten Services ausgeliefert, die Implementierung des Governance-Modells dauert an - obwohl hier auf einer existierenden IT-Governance aufgebaut werden konnte.
Eines der bedeutsamsten Themen ist die Roadmap, berichtet Lermann: "Die wichtigsten und deshalb zuerst umgesetzten Services sind die, die einen direkten Business-Effekt erzielen. Und von denen werden bevorzugt die realisiert, die sich auf der IT-Seite einfach implementieren lassen."
Zu den "Lessons learned" zählen für den Chefarchitekten vor allem zwei Erkenntnise: Eine globale SOA-Initiative sei der einzige Weg, um ein Unternehmen wirklich global aufzustellen. Aber das sei bedeutend schwieriger, als es aussehe. Und: Fangen Sie klein an, aber warten Sie nicht, bis jeder Service standardisiert ist!
Vier Imperative - gestern, heute und morgen
Die Sichtweise des Beraters vertrat schließlich Jürgen Laartz, Direktor bei McKinsey & Co. Er habe schon vor Jahren vier SOA-"Imperative" formuliert, die heute sogar verstärkt gültig seien, sagte er. Diese Grundsätze lauten sinngemäß folgendermaßen:
Entscheidend ist, wie Wert abgebildet wird.
Architekturdesign ist mehr eine Business- als eine IT-Disziplin.
Die Governance muss die Interessen von Business und IT ausbalancieren.
Technologientscheidungen können nicht allein technologisch getroffen werden.
Auch einen Blick in die Zukunft eröffnete Laartz den Zuhörern: Die Grenzen zwischen Kunden und Unternehmen verschwimmen, die Wertschöpfungsketten ändern sich, prognostizierte er: "Das hat Auswirkungen auf die IT." Dasselbe gelte für Trends wie das Global Operating Model (GOM). "Welche IT-Strategie erlaubt heute fluide Strukturen?", fragte der Berater das Auditorium. Effizienz und Kosten blieben zwar wichtig, aber Qualität und Risikobetrachtung wanderten - gerade in globalen Strukturen - in den Mittelpunkt des Interesses. Diese Aspekte müsse eine "IT-Architektur 2.0" berücksichtigen. Dass McKinsey ein Framework für Design und Betrieb solcher Architekturen im Angebot habe, wollte Laartz denn auch nicht verschweigen.