SOA ist eine Frage der Zeit

Vor allem Grossunternehmen versprechen sich von SOA-Strategien eine Vereinheitlichung der eigenen IT-Umgebung und ein besseres und effizienteres Zusammenspiel mit derjenigen ihrer Klientel. Angesichts des Hype rund um die Webservices stellt sich allerdings die Frage, wofür sich eine SOA eignet und wofür nicht – und wie sie in einem Unternehmen umgesetzt werden soll. Das Thema wurde kürzlich an der Veranstaltung SET 2005 (Software Engineering Today), die in den Räumlichkeiten der Programmierspezialisten von Zühlke in Schlieren stattfand, breit diskutiert. InfoWeek hat sich in diesem Zusammenhang mit Martin Frick, Leiter IT der Winterthur Group, über seinen SOA-Ansatz und seine diesbezüglichen Erfahrungen unterhalten.

InfoWeek: Herr Frick, wann haben Sie sich zum ersten Mal mit dem SOA-Konzept befasst?
Martin Frick: Wir haben Ende der neunziger Jahre damit begonnen, uns mit dem Thema auseinanderzusetzen. Damals ging es um die Definition neuer Prozesse sowie die Erschliessung zusätzlicher Geschäftskanäle – und nicht zuletzt auch um die Ermöglichung neuer Abläufe an der Schnittstelle zum Kunden. Die Frage war, wie wir gewisse Funktionalitäten unserer Mainframe-Systeme den Kunden gegenüber öffnen könnten. Begonnen haben wir mit SOA im Rahmen des Pilotprojekts WincoLink, das anfänglich auf das Kollektiv-Leben-Geschäft fokussiert war.

Was heisst in diesem Zusammenhang «öffnen»?

Das heisst, dass die Leben-Firmenkunden über die Service-Schnittstelle Browser-basiert direkt in unseren Systemen Mutationen vornehmen können. Das ist eigentlich die Idee des E-Business, wie sie ähnlich auch von den Banken entwickelt wurde. Es ging bei WincoLink also darum, die Verwaltung von Stammdaten zu vereinheitlichen und mit den Prozessen in den HR-Abteilungen der Firmenkunden zu verknüpfen. Damit liessen sich die für beide Seiten bis dato langwierigen Abläufe – etwa das Eintippen von Hand bei Änderungen in den Personaldaten – sehr schlank gestalten. So konnten wir eine Effizienz der diesbezüglichen Geschäftsprozesse realisieren, die vorher nicht möglich war.

Wie sind Sie diese Vereinheitlichung angegangen?

Zuerst einmal ging es darum, eine Architektur zu entwerfen, so dass ein sehr kontrolliertes Zugreifen auf die Kernanwendungen möglich war. Letztere sind auch bei uns noch zu einem grossen Teil klassische Mainframe-Legacy-Applikationen, die für den SOA-Einsatz gekapselt werden und dann über die CORBA-basierte Service-Schnittstelle als Dienste verfügbar sind. Diese Modularisierung und Integration der bestehenden Host-Funktionalitäten und die Standardisierung der Schnittstellen haben wiederum eine Reduktion der Komplexität zur Folge, die ihrerseits eine Senkung der Wartungskosten ermöglicht.

Die Kapselung von Legacy-Applikationen ist bekanntlich kein Kinderspiel. Wo liegen hier die Herausforderungen?

Zum einen ist es unabdingbar, dass auf der rein technischen und logischen Ebene eine saubere, klar geordnete Architektur konzipiert wird. Die technische Integration mit CORBA und Nachrichten-orientierter Middleware – und in Zukunft vermehrt auf der Basis von Webservices – ist dann relativ problemlos. Zum andern ist es auch extrem wichtig, die semantischen Zuordnungen genau zu definieren – eben nicht nur in der technischen Semantik, sondern auch in der Business-relevanten inhaltlichen. Bei uns ist es ganz wichtig, dass die Service-Verträge unseren internen Standards entsprechen. Der grösste Aufwand liegt sicher bei den Schnittstellendefinitionen und dem Festlegen von Richtlinien.
Zu diesem Zweck haben wir parallel ein separates Projekt für die SOA-Standardisierung aufgegleist. Darin geht es um die Vereinheitlichung von Datenelementen und Service-Verträgen sowie um den Aufbau der Schnittstellendefinition inklusive Header-Struktur und Fehlererkennung. Ausserdem wurde im Rahmen dieses Projekts ein methodisches Verfahren für die Festlegung und Abnahme von Schnittstellen eingeführt. Und schliesslich legten wir ein Interface-Repository an, das allen Entwicklern jederzeit zugänglich ist. Zudem darf man die Schulung nicht ausser acht lassen. Bis heute haben wir rund 50 Entwickler und Designer in jeweils zweitägigen Kursen in SOA geschult.

Das geht ganz schön ins Geld, nicht wahr?

Ja, das kostet schon einiges. Aber diese Investition ist nachhaltig.

Hatten Sie keine Probleme damit, dies dem CEO und dem Finanzchef schmackhaft zu machen?

Sicher braucht es ein hohes Commitment des Managements – und eine entsprechend aufwendige Überzeugungsarbeit. Wenn man allerdings aufzeigen kann, wie sehr sich eine solche – zugegeben nicht gerade billige – Vorarbeit lohnt, erntet man auch Zustimmung. Schliesslich geht es ja darum, mit einer SOA eine klare Ordnung zu schaffen und gleichzeitig eine hohe Flexibilität zu ermöglichen. Denn der SOA-Ansatz bedeutet ja gerade nicht, dass mit einem Schlag alles geändert wird, sondern dass man zeitlich gestaffelt bestimmte Funktionalitäten als Services konzipieren und zur Verfügung stellen kann. Somit amortisieren sich die Kosten für die aufwendige Vorarbeit relativ schnell.

In welchem Zeitraum konnten die Kosten für Ihr Projekt im Zusammenhang mit WincoLink amortisiert werden?

Eindeutig ist das nicht zu beantworten, weil die SOA-Reise immer noch weitergeht. Für ein einziges Projekt würde sich die Investition auch kaum rechnen. Das tut sie erst dann, wenn man sie auf einen grösseren Teil der IT-Landschaft ausdehnt. Ich schätze aber, dass sich die Investition in eine SOA-Infrastruktur nach vier, fünf Jahren rechnet. Und Sie dürfen nicht vergessen, dass wir 1998 vor der Entscheidung standen, entweder all die umfangreichen und teuren Legacy-Applikationen für viel Geld durch heutige Lösungen zu ersetzen oder eben mittels Kapselung und einer SOA-Schicht Service-tauglich zu machen. Natürlich werden diese alten Kernapplikationen nicht ewig in Betrieb bleiben. Mit dem SOA-Ansatz haben wir aber den Vorteil, dies – und auch die abgestufte Konsolidierung der Hardwaresysteme – sowohl technisch als auch Business-mässig kontrolliert ablaufen zu lassen.

Für welche Geschäftsfelder haben Sie bislang Ihre Applikationen SOA-fähig gemacht?

Zuerst passten wir wie erwähnt die Applikationen für das Leben-Geschäft mit Grosskunden an. Zudem laufen auch die Partnerverwaltung, die Nichtleben-Schadenerfassung und
-abwicklung und die Vertragsverwaltung in der SOA-Umgebung. Gegenwärtig sind wir daran, auch die Einzel-Leben-Systeme Service-tauglich zu machen.

Wenn Sie im Rahmen Ihrer SOA-Strategie alle Abläufe sauber definieren, standardisieren und dokumentieren, könnten Sie dann die Funktionalitäten nicht ebensogut auslagern und Utility-artig nutzen?
Ich sehe diesen Trend sehr wohl im Bereich des Infrastrukturbetriebs – etwa um zu vermeiden, dass Investitionen in Systeme an Peak-Belastungen ausgerichtet werden müssen, die nur ein- oder zweimal im Jahr auftreten. Aber selbst hier ist hohe handwerkliche Konzentration notwendig, um den versprochenen Nutzen zu haben. Grundsätzlich bin ich jedoch nicht dafür, die Verantwortung für Kernanwendungen auszulagern. Ausserdem dürfte es sich mit dem Utility- oder On-Demand-Computing ähnlich verhalten wie mit SOA – dass nämlich nicht alles auf einmal umgestellt werden muss, sondern dass man eine Strategie verfolgt, mit der gezielt bestimmte Leistungen ausgelagert werden. Dies dort, wo der Nutzen hinreichend hoch ist.

Über Martin Frick

Martin Frick ist Leiter IT der Winterthur Group, hat Physik und Mathematik studiert und 1990 an der Ruprecht-Karls-Universität in Heidelberg doktoriert. Danach forschte er in Computational Physics an der Universität Groningen, bevor er bei Thinking Machines in Cambridge, USA, als Application Engineer tätig war. Von 1994 bis 1999 arbeitete er als Manager bei Andersen Consulting (heute Accenture) in München, und von 1999 bis 2002 amtete er als Chief Operating Officer bei der virtuellen Bank Enba in Dublin. Seit 2002 ist Frick Chief Information Officer bei der Winterthur Group.