Fünfter und letzter Teil der SOA-Serie

SOA - der lange, steinige Weg

11.07.2007 von Johannes Helbig
Post-CIO Johannes Helbig und Ralph Riemann von der IT-Tochter Senacor erklären ihre weitreichendste Erkenntnis: Service-orientierte Architekturen sind mühsam zu installieren - und die Arbeit hört niemals auf.

Märkte werden globaler, Produktzyklen kürzer, Kunden anspruchsvoller. Gleichzeitig erkennen Unternehmen, dass ihre Prozessarchitekturen und IT-Systeme nicht darauf ausgelegt sind, Produktinnovationen, neue Sourcing-Konzepte oder alternative Geschäftsmodelle schnell und flexibel abzubilden. Insbesondere Veränderungen an der bestehenden IT-Anwendungslandschaft erweisen sich als problematisch: Die zumeist starren Systeme und Insellösungen mit ihren komplexen Schnittstellen können nur mit erheblichem zeitlichen und finanziellen Aufwand angepasst werden. Statt zum Enabler wird die IT zum Engpass bei strategisch notwendigen Veränderungen.

Ralph Riemann, Leiter Business Consulting Industrial Service Group der IT-Tochter Senacor: "Rein architektonisch getriebene Ansätze sollten unbedingt vermieden werden."

Unternehmen, denen es gelingt, die Transformation ihres Business und ihrer IT-Landschaft zu synchronisieren, sind besser gewappnet, um mit innovativen Geschäftsmodellen die Spielregeln ihrer Branche neu zu definieren. SOA kann als geschäftsgetriebener und evolutionärer Ansatz einen wesentlichen Beitrag zur Synchronisierung von Business und IT leisten. Ein Neubeginn auf der oft zitierten "grünen Wiese“ ist für Großunternehmen schlicht keine Option: Neben den immensen Kosten, die mit einem solchen Big-Bang-Ansatz verbunden wären, würde man die bisher getätigten Investitionen - diese erreichen in Summe oftmals Milliardenhöhe - komplett aufgeben und, angesichts der zu bewältigenden Komplexität, ein unüberschaubares Risiko eingehen.

Stichwort Managed Evolution

Kernaufgabe des CIO ist es, die Rahmenbedingungen für einen zielgerichteten und kontrollierten Wandel zu schaffen. Hinter dem Stichwort "Managed Evolution" verbirgt sich, wie in den vorherigen Artikeln bereits ausführlich dargestellt, genau dieser Anspruch: Die Service-Architektur mit ihren Domänen und fachlich geprägten Services dient als Generalbebauungsplan und stellt eine geordnete Vision zur Verfügung. Die Nutzung von Mechanismen wie Entkoppelung und Kapselung entlang stabiler Service-Beziehungen schafft die Möglichkeit, ausgewählte Applikationen ohne Auswirkungen auf die restliche Anwendungslandschaft zu modernisieren oder auszutauschen. Auf diese Weise können die unterschiedlichen Transformations-Anforderungen und -Geschwindigkeiten im Unternehmen bedarfsgerecht durch Business-getriebene Projekte adressiert werden.

Eine Service-Architektur als wesentliches Instrument der IT-Governance erlaubt somit, die Verantwortung für Projekte stark zu dezentralisieren und in die Fachbereiche zu übertragen. So lassen sich Geschäfts- und IT-Transformation in der Praxis synchronisieren und ein rascher Nutzenbeitrag von IT-Initiativen sicherstellen. Die Architekturvision stellt dabei sicher, dass sich die geschäftlichen Einzelinitiativen trotzdem stets zu einem kohärenten Ganzen zusammenfügen.

Think big, start small - dieses Motto gilt auch für den Aufbau von SOA-Instrumenten, -Prozessen und -Ressourcen. Das Wissen im Unternehmen wächst mit der Nutzung von SOA. Entsprechend ist die Hürde für den Einstieg in die Service-Orientierung deutlich niedriger, als viele IT-Manager befürchten. Die Einführung von SOA ist kein zeitlich begrenztes Umstellungsprojekt; vielmehr wachsen die Mechanismen der Service-Orientierung gemeinsam mit dem Service-Portfolio und werden im Laufe der Zeit integraler Bestandteil der IT-Managements eines Unternehmens.

Das komplette SOA-Know-how.

Die drei wesentlichen Dimensionen

Unternehmen, die SOA nutzen wollen, müssen drei wesentliche strategische Dimensionen adressieren. Erstens gilt es, die organisatorischen Voraussetzungen zu schaffen und die wesentlichen Governance-Mechanismen aufzubauen. Zweitens müssen die erforderlichen Fähigkeiten im Unternehmen entwickelt werden. Hierzu zählen insbesondere Prozesse, Instrumente und Ressourcen im Bereich Service-Design und -Management. Und drittens ist es notwendig, Business-Projekte durch die Bereitstellung einer tragfähigen Integrationslösung wirksam zu unterstützen. Alle drei Dimensionen werden schrittweise und bedarfsgerecht im Laufe der Zeit entwickelt.

Wer SOA nutzen möchte, begibt sich auf eine lange Reise. Zwei wesentliche Voraussetzungen müssen erfüllt sein, damit der Start in die Service-Orientierung gelingt. Zum Ersten muss das Top-Management die Initiative unterstützen und an ihr beteiligt sein. Als Management-Prinzip, das auf Dauer im Unternehmen wirken soll, muss SOA nachhaltig verankert werden. Dies erfordert vor allem Ausdauer und Durchhaltevermögen. Beides kann letztlich nur durch die Unterstützung des Top-Managements sichergestellt werden. Darüber hinaus stellt seine Beteiligung die notwendige Priorisierung der geschäftlichen Transformationsaufgaben sicher.

Zum Zweiten ist ein erster Gesamtentwurf der Service-Architektur erforderlich. Sie stellt als Generalbebauungsplan einen stabilen Rahmen für die Durchführung dezentraler Business-Projekte zur Verfügung. Zwar erfährt auch die Service-Architektur im Laufe der Zeit gewisse Anpassungen; Qualität und Stabilität des initialen Entwurfs haben jedoch große Auswirkungen auf seinen Nutzen im Rahmen der Enterprise-Architektur. Entsprechend hat es sich bewährt, die besten IT-Strategen und Business-Architekten des Unternehmens für einige Monate zu einem Team zusammenzuziehen, das den grundsätzlichen Schnitt der Domänen und Services festlegt.

Parallel zu den ersten Projekten entwickeln sich dann die Fähigkeiten der Organisation im Umgang mit SOA und Enterprise-Architektur-Management: Ein wachsendes Service-Portfolio erfordert elaboriertere Governance- und Management-Mechanismen. Gleiches gilt für neue Anforderungen an die technische SOA-Plattform, die typischerweise mit der wachsenden Nutzung von Services im Unternehmen entstehen.

Die Service-Architektur stellt lediglich den Rahmen für langfristige Integrations- und Flexibilitätsziele bereit. Ihre Umsetzung muss anhand geschäftlich motivierter Initiativen mit gleichermaßen hoher Signalwirkung und Nutzenerwartung erfolgen. Die Ergebnisse dieser Projekte sollten eine tragende Bedeutung im Rahmen der Enterprise-Architektur einnehmen. Hierzu zählen vor allem jene Projekte, die Service-Provider für eine höhere Zahl von Consumern bereitstellen. Rein architektonisch getriebene Ansätze sollten unbedingt vermieden werden: Nur wenn SOA einen echten Beitrag zur Lösung priorisierter Probleme leistet, werden Fach- und IT-Bereiche dauerhaft den Ansatz unterstützen.

Lesson learned: SOA ist machbar

Im Rahmen dieser Artikelserie haben wir SOA und seine wesentlichen Merkmale aus Sicht eines Anwenderunternehmens beschrieben, das bereits einige Jahre praktische Erfahrung mit dem Konzept gesammelt hat. Ziel war es, ein wenig mehr Klarheit in die Diskussion zu bringen und so den Weg zu einem einheitlichen Verständnis von SOA zu ebnen. Verkürzt lässt sich unser Verständnis auf die folgende Formel bringen:

SOA = Semantische Integration + Entkoppelung + Managed Evolution

Die in den vergangenen Jahren mit SOA gewonnenen Erkenntnisse der Deutschen Post lassen sich wie folgt charakterisieren:

SOA ist kein Hype - auch wenn das Interesse an diesem Thema so rapide zugenommen hat. SOA fußt vielmehr auf seit langem vertrauten Prinzipien wie Entkoppelung und Kapselung, nun übertragen auf die Ebene der Enterprise-Architektur. Als wichtiges Instrument für die Geschäfts- und IT-Transformation wird uns SOA deshalb auch in Zukunft begleiten und in wenigen Jahren zum selbstverständlichen Handwerkszeug eines jeden IT-Managers gehören, der vor der Herausforderung steht, Komplexität beherrschbar zu machen. Die Beispiele erfolgreicher Anwender zeigen: SOA ist machbar.