SOA polarisiert. Für viele CIOs sind Service-orientierte Architekturen ein unverzichtbarer Bestandteil des Komplexitäts-Managements, der künftig zum selbst-verständlichen Handwerkszeug eines jeden ITManagers gehören wird. Für andere hat SOA alle Merkmale eines Hypes: Wer nach SOA googelt, erhält 36 Millionen Treffer, viermal so viele wie noch vor einem halben Jahr. Das zeugt von einer stürmisch wachsenden Diskussion, während gleichzeitig breite Erfahrungswerte auf der Anwenderseite auf sich warten lassen.
Die große SOA-Serie im CIO-Magazin soll daher mehr Klarheit in die Diskussion bringen und den Weg zu einem einheitlichen Verständnis von SOA erleichtern. Basis dafür ist der praktische SOA-Erfahrungsschatz der Deutschen Post, den das Unternehmen seit 1999 aufgebaut hat. Als Kernbotschaft wird sich dabei immer wieder herausstellen: SOA beschreibt ein umfassendes Management-Paradigma, das einen neuen Umgang mit der Prozess- und IT-Landschaft von Unternehmen erlaubt. SOA adressiert dabei zwei zentrale Herausforderungen: die Beherrschung dynamischen Wandels und wachsender Komplexität.
SOA berührt viele Ebenen im Unternehmen. Eine erfolgreiche Einführung erschöpft sich nicht in einer Infrastrukturinvestition, sondern umfasst Aspekte der Organisation und IT-Governance, des Architektur-Managements, des Lifecycle-Managements und der Transformationsprozesse. Jedem dieser Aspekte wird sich deshalb ein eigener Artikel der Serie widmen.
Auslöser für SOA-Start bei der Post
Verschärfter Wettbewerb durch globale Expansionen, beschleunigte Produktlebenszyklen und hoher Kostendruck waren für die Deutsche Post Ende der 90er Jahre Auslöser für den Bedarf nach immer engerer Verzahnung von Business und IT. Der Forderung nach flexibler Unterstützung von Geschäftsprozessen und mehr Effizienz stand jedoch eine historisch gewachsene IT-Landschaft entgegen.
Ihre Analyse zeigte, dass mangelnde fachliche Integration vielfache Redundanzen zur Folge hatte. Die starre Verflechtung von Prozessen und IT-Systemen trieb die Komplexität in die Höhe, obwohl paradoxerweise die einzelnen Anwendungen kaum übergreifend in Interaktion treten konnten. Wie bei fast allen Großunternehmen schied jedoch, angesichts der geleisteten Investments und der Anforderungen des laufenden Betriebs, ein Neuanfang auf der grünen Wiese von vornherein aus.
In einem strategischen Landmark-Projekt im Unternehmensbereich Brief wurde daher, unter Führung des Business, die Grundlage für eine zukunftsfähige IT-Landschaft geschaffen. In einem konsequenten Top-Down-Ansatz wurden zunächst die übergreifenden Geschäftsprozesse optimiert und bei Bedarf ergänzt. Auf dieser Basis wurde eine fachliche Service-Architektur entworfen. Sie dient als umfassender Bebauungsplan, der seitdem die Integration auf der fachlichen Ebene forciert und die Grundlage der SOA-Strategie der Post darstellt.
Grundlegende SOA-Prinzipien
Zwei Grundprinzipien kennzeichnen SOA so eng, dass man sie fast als Definition benutzen kann: lose Kopplung und semantische Integration. Lose Kopplung ist als Streben nach Modularisierung und Kapselung natürlich nichts Neues, sondern in sämtlichen Ingenieurdisziplinen vertrautes Handwerkszeug zur Komplexitätsreduktion, so auch in der IT. Aber SOA hebt diesen Ansatz von der Ebene der Systemarchitektur auf die Ebene der Enterprise-Architektur. Wie bei einer Komponentenstrategie in der Automobilindustrie, so zielt auch SOA darauf ab, durch Wiederverwendung von Funktionalität mehr Flexibilität, eine Verbesserung der Time-to-Market sowie Kostenvorteile zu erreichen.
Die Beziehungen zwischen den verschiedenen Komponenten werden im Rahmen einer SOA in Form standardisierter Services abgebildet. Sind diese so gewählt, dass sie die grundsätzlichen Leistungsbeziehungen des jeweiligen Geschäftssystems reflektieren, erzeugen sie eine langfristig stabile Abstraktionsschicht. Diese stellt einen bleibenden Anker und Bezugspunkt dar – im raschen Wandel von Kundenanforderungen und Geschäftsprozessen auf der fachlichen Seite und neuen Anwendungen und Technologien auf der IT-Seite.
Basis für die übergreifende Nutzbarkeit der Services ist jedoch eine vorherige Integration auf der semantischen Ebene. Für viele Unternehmen bleibt dies die größte Herausforderung. Semantische Integration sorgt für eine übergreifende fachliche Klärung und Vereinheitlichung von Begrifflichkeiten. So erfordert zum Beispiel die Realisierung eines Services "Kundendaten", dass ein Unternehmen ein Verständnis von dessen Attributen und Funktionalitäten entwickelt.
Teil II: Service-Architektur
Der erste Schritt zu SOA ist die Erarbeitung einer Service-Architektur, die sich aus den jeweiligen Top-Geschäftsprozessen ableitet. Funktionale Kernelemente, die logisch oder durch Interaktion eng gekoppelt sind, werden dabei in so genannten Domänen zusammengefasst. Die verbleibenden lose gekoppelten Leistungsbeziehungen zwischen den Domänen werden in Form von Services beschrieben.
Die Funktionen einer Service-Architektur lassen sich dabei gut mit der eines Städtebebauungsplans vergleichen. Dieser macht Vorgaben, etwa für die funktionale Aufteilung einer Stadt in Wohn- und Industriegebiete. Sodann wird der Städteplaner sich um die Interaktion in seiner Stadt Gedanken machen und globale Standards für die Ausgestaltung der Infrastruktur festlegen – zum Beispiel für den Straßenverkehr oder die elektrische Versorgung.
In einer Stadt wird dann die eigentliche Bebauung der Gebiete typischerweise nicht mehr zentral gesteuert, sondern in eigener Initiative von Unternehmern, Investoren und Privatleuten vorgenommen. Ganz analog kann nun die Verantwortung für Einzelprojekte im Rahmen der Ausgestaltung von Domänen dezentralisiert werden. Fachbereiche können so Projekte in Eigenverantwortung und nach Maßgabe des erwarteten Geschäftsnutzens vorantreiben. Die Service-Architektur verhindert als Bezugsrahmen, dass die Anwendungslandschaft nicht in einem Spaghetti-Haufen endet. In diesem Sinne wird SOA bei der Deutschen Post als Schlüsselinstrument der IT-Governance eingesetzt.
Teil III: Service-Management
Kernfunktion für den Entwurf und die Entwicklung einer solchen Service-Architektur ist ein etabliertes Service-Management. Der Aufbau der zugehörigen Management-Prozesse, Methoden und Skills ist wichtigster Schritt in der praktischen Umsetzung von SOA. Dabei müssen die wesentlichen Prozesse des Applikationsmanagements nun für die Welt der Services bereitgestellt werden.
Entscheidend für den Nutzwert einer SOA sind initiale Identifikation und Zuschnitt der Services. Insbesondere ist dabei die Frage nach der für ein Unternehmen "richtigen" Anzahl und Granularität von Services wichtig. Auch heute noch ist dies, wie bei vielen Entwurfsleistungen, eine Mischung aus Kunst und Methodik. Systematische Anhaltspunkte können dabei sowohl Top-down aus den Geschäftsprozessen und -objekten als auch Bottom-up aus einer Analyse der Applikationslandschaft gewonnen werden.
Das Service-Design beschreibt einen definierten Prozess von der fachlichen Spezifikation von Services bis hin zu ihrer technischen Realisierung. Die Deutsche Post hat inzwischen Tool-Chains entwickelt, mit denen große Teile dieser Prozesskette automatisiert werden konnten. Ein Service-Lifecycle-Management schließlich gewährleistet, dass funktionale Änderungen und Erweiterungen von Services auf kontrollierte Weise in eine SOA einfließen können.
Teil IV: Plattform
Es sollte bereits deutlich geworden sein, dass die Einführung einer technischen Plattform für SOA bei weitem nicht die Bedeutung einnimmt, die ihre Prominenz in der aktuellen Diskussion oft suggerieren mag. Dennoch hilft eine leistungsfähige technische Plattform bei der Umsetzung der zunächst ja nur abstrakt existierenden Servicestrukturen in die Realität. Sie stellt eine "deploybare" Integrationsinfrastruktur zur Verfügung, gegen die die Anwendungen überprüfbar entwickelt werden können.
Die Anforderungen, die eine SOA-Plattform in einem verteilten und heterogenen Unternehmensumfeld erfüllen muss, sind dabei nicht zu unterschätzen. Vor dem Hintergrund einer permanenten Veränderung der IT-Landschaft muss eine SOA-Plattform langfristige Stabilität und ein Höchstmaß an Flexibilität und Zukunftssicherheit aufweisen. Ein wichtiges Element dafür ist oftmals Herstellerunabhängigkeit. Daher hat sich die Post bereits im Jahre 2000 für den Aufbau der Service Oriented Platform, kurz SOPware, entschieden. Kernkonzepte von SOPware sind Dezentralität und Modularität sowie insbesondere der Einsatz von offenen Standards und Best-of-Breed-Produkten. Das Know-how für die Entwicklung der Plattform hat die Deutsche Post im eigenen Hause aufgebaut, ein zusätzlicher Beitrag, um einen Vendor-Lock-in zu vermeiden.
Teil V: Transformation
Der letzte Teil der Serie führt uns dann wieder zum Ausgangspunkt zurück: SOA-Transformation als Management-Ansatz. Durch die Entkopplung von Einzelprojekten und die Entzerrung der Modifikationszyklen und -geschwindigkeiten in den Domänen ist SOA ein wesentlicher Hebel für die Transforma,tion von Anwendungs- und Prozesslandschaften. Sie ermöglicht diese Transformation in einer schrittweisen aber zielgerichteten und geordneten Form; bei der Deutschen Post hat sich hierfür der Begriff der "Managed Evolution" ausgeprägt.
Die Einführung einer SOA unterliegt dabei genau demselben Prinzip. Es bedarf eines entschlossenen Commitments des Top-Managements und einer klar definierten Roadmap. Diese muss stets kurzfristig erzielbaren Geschäftsnutzen mit langfristigen Integritätszielen der Anwendungslandschaft in Balance halten. Der Einstieg kann dann jedoch fließend und schrittweise erfolgen und erfordert wesentlich weniger Initialinvestments als gemeinhin befürchtet.
SOA macht Wandel beherrschbar
Unternehmen sind heute mehr denn je einem dynamischen Wandel ausgesetzt. Organisation und Prozesse müssen permanent angepasst werden. Die damit verbundenen Veränderungen muss die IT – selbst einer stetigen Evolution unterworfen – schnell und flexibel nachvollziehen. Dabei gilt es insbesondere, Komplexitätsfallen zu vermeiden.
Die Aufgabe eines CIOs bleibt das Management eines Moving Targets. Er ist, in einem viel strapazierten Bild, der Kapitän eines Schiffs, dessen Umbau stets auf hoher See erfolgt. SOA bietet dabei das Konstruktionsprinzip für Schiffe, die hierbei unter Dampf bleiben können und weiterhin auf das Ruder reagieren. Für den Kapitän bleibt dann wieder mehr Zeit außerhalb des Maschinenraums – für die Bestimmung des Kurses.