Es klingt beinahe wie ein Auftrag aus Mission: Impossible: „Machen Sie das Business zum Treiber und Gestalter der IT – und erreichen Sie gleichzeitig die Integration Ihrer Anwendungslandschaften.“ Für viele Unternehmen ist das keinesfalls Hollywood-Fiktion, sondern Voraussetzung, um im harten Wettbewerb bestehen zu können. Im Rahmen einer SOA-Strategie bildet eine Service-Architektur die Basis, um genau diesen Widerspruch aufzulösen. Sie ist Bebauungsplan, Management-Werkzeug und konkretes Bindeglied zwischen Business und IT.
Um das zu erreichen, setzt eine Service-Architektur an zwei Punkten an: Sie modularisiert Prozess- und IT-Landschaften nach fachlichen und funktionalen Kriterien. Zwischen den so entstehenden Clustern definiert sie zudem globale Standards für die Ausgestaltung von Konnektivität. In Bezug auf Letzteres macht sich die Service-Architektur ein Prinzip zu Eigen, dass auch bei der stetigen Entwicklung von Städten sichtbar wird: Konnektivität – das heißt Straßen, Bahnlinien und Versorgungswege – ist meist langfristig stabil, in Städten bleibt sie oft über Jahrzehnte, manchmal Jahrhunderte erkennbar. Die umliegende Bebauung – respektive die Applikationen einer IT-Landschaft – befindet sich hingegen in einem permanenten Wandel.
Tatsächlich beinhaltet die Nutzung einer Service-Architektur für Unternehmen einen Perspektivenwechsel. Der Fokus verschiebt sich vom Management einzelner Applikationen hin zu einem Management der Leistungsbeziehungen. Damit einher geht das Bestreben, lose Kopplung und Modularisierung zu erzielen. Dies setzt semantische Integration voraus – also eine Vereinheitlichung von Begrifflichkeiten, die auf der Business-Ebene ansetzt.
Prozess- und IT-Ebene abgekoppelt
Eine Service-Architektur stellt die grundlegende Definition einer SOA auf der Ebene der Enterprise-Architektur dar. Sie besteht aus lose gekoppelten Domänen, die durch eine überschaubare Anzahl von Services miteinander in Beziehung stehen. Sie bildet die fundamentalen Geschäftsbeziehungen eines Unternehmens ab; gleichzeitig repräsentiert sie die IT-Landschaft in struktureller Form. Eine Service-Architektur stellt somit eine Abstraktionsschicht dar, die Prozess- und ITEbene voneinander abkoppelt und als übergreifender Bebauungsplan fungiert.
Gleichzeitig ist eine Service-Architektur auch ein Management-Werkzeug für eine Business-getriebene Gestaltung von IT. Sie ist ausschließlich in Business-Terminologie beschrieben – und stellt somit ein Diskurslevel dar, das es der Fachseite erlaubt, Prozesse und IT gezielt aus den eigenen Anforderungen heraus zu gestalten. Als Spiegel der grundlegenden Geschäftsbeziehungen im Unternehmen ermöglicht eine Service-Architektur zudem, die jeweiligen Geschäftsverantwortungen besser zuzuordnen – und somit die Ownership für die korrespondierenden IT-Funktionen klar zu definieren.
Mit einer Service-Architektur beginnt Architektur-Management auf der Ebene des Business; Integration ist mit SOA folglich ein fachlich getriebener Prozess. Das durchgängige Modell einer Service-Architektur erlaubt zudem eine direkte Transformation von Business-Anforderungen auf die Ebene der IT. Aus einer fachlichen Service-Beschreibung lässt sich die entsprechende technische Spezifikation bruchlos ableiten. Ein nahe liegender Gedanke ist daher, die entsprechenden Service-Tool-Chains weitgehend zu automatisieren – was bei der Deutsche Post seit rund zwei Jahren geschieht.
Hohes Maß an Abstraktion gefragt
Mit diesen unterschiedlichen Aufgaben einer Service-Architektur sind durchaus divergierende Anforderungen an ihre Ausgestaltung verbunden, was in der Phase des Entwurfs berücksichtigt werden muss. So erfordert der Modellcharakter einer Service-Architektur ein hinreichend hohes Maß an Abstraktion. Gleichzeitig haben die getroffenen Entwurfsentscheidungen sehr konkrete Auswirkungen auf die spätere Realisierung, insbesondere auf Effektivität, Kosten und Performance.
Abstraktion und Konkretisierung sind folglich Pole, zwischen denen sich der Entwurfsprozess einer Service-Architektur bewegt. Das Vorgehen ist dabei nicht ausschließlich linear, sondern stark interdependent. Umso wichtiger ist ein systematischer Ansatz, der die Qualität der erzeugten Ergebnisse sicherstellt. Konsequenterweise startet die Entwicklung einer Service-Architektur daher top-down. Ausgehend von den zentralen Geschäftsprozessen werden die fundamentalen Liefer- und Leistungsbeziehungen innerhalb des Unternehmens Schritt für Schritt erfasst.
Im Mittelpunkt der Analyse stehen Geschäftsobjekte – wie zum Beispiel „Kunde“, „Vertrag“ oder „Produkt“– sowie die Betrachtung der dazugehörigen Geschäftslogik, Funktionalität und Daten. Auf Basis der Identifikation der zugrunde liegenden Interaktionsbeziehungen erfolgt dann im Weiteren der Zuschnitt der Service-Architektur in Domänen. Diese konstituieren sich aus logisch eng zusammengehörenden Elementen, die hohe Interaktion aufweisen. Nach außen hin zeichnen sich Domänen hingegen durch lose Kopplung aus – Services beschreiben die verbleibenden Interaktionsbeziehungen.
Wie bei allen Designprozessen gibt es bewährte Heuristiken, dennoch sind Kreativität, Erfahrung und Weitsicht des Business-Architekten unerlässlich. Die Passgenauigkeit eines Domänenschnitts gegenüber spezifischen Unternehmensanforderungen entscheidet sich dabei oft an scheinbaren Detailfragen. So verfügt die Service-Architektur der Deutschen Post zum Beispiel über zwei Domänen, die auf den ersten Blick recht ähnlich scheinen: die Domänen „Kunde“ und „Kundenbeziehungen“. Deren Abgrenzung offenbart sich erst bei genauerer Betrachtung der zugrunde liegenden Geschäftsbeziehungen.
So muss die Domäne Kunde zwar eine umfassende Sicht auf das Geschäftsobjekt Kunde liefern, jedoch sind die erfassten Informationen und deren Nutzung weitgehend eindeutig und zeichnen sich zudem durch eine geringe Änderungshäufigkeit aus. Die Domäne Kundenbeziehungen fokussiert hingegen auf ein deutlich breiteres Anwendungsspektrum. Vom Cross-Selling bis zum Kundenservice gilt es, unterschiedlichste Nutzungsszenarien zu unterstützen. Die in der Domäne enthaltenen Informationen sind zudem häufigen Änderungen unterworfen. So führt etwa jeder Kundenkontakt im Rahmen einer CRM-Strategie oder im Reklamations-Management zu einer Aktualisierung der erfassten Daten.
Auch Faktoren, die zunächst außerhalb der funktionalen Ebene liegen, können einen wichtigen Einfluss auf die Ausgestaltung des Domänenzuschnitts nehmen. So erfordern zum Beispiel strategische Vorhaben des Unternehmens, etwa die Erschließung neuer Märkte oder die Durchführung von Outsourcing, eine erhöhte Aufmerksamkeit beim Zuschnitt der entsprechenden Bereiche der Service-Architektur. Immer müssen außerdem organisatorische und technische Gegebenheiten in den Entwurf mit eingebracht werden.
Die Umsetzung einer zunächst ja nur auf dem Papier existierenden Service-Architektur markiert dann den entscheidenden Schritt zu SOA. Gleichwohl ist dazu kein Big-Bang erforderlich. Vielmehr ermöglicht SOA gerade ein evolutionäres Vorgehen. Top-down- und Bottom-up-Ansätze ergänzen sich dabei. So dient die Service-Architektur dazu, Integrationsbedarf topdown zu identifizieren, der vor dem Hintergrund strategischer Business-Anforderungen hohen Stellenwert besitzt. Ein Abgleich mit der IT-Ebene kann zusätzlich Bottom-up-Ansatzpunkte aufzeigen, wo Abdeckungslücken geschlossen oder redundante Funktionalität ausgejätet werden kann.
Start auf semantischer Ebene
Der Prozess der Umsetzung muss dabei aus dem Business getrieben werden. Integration startet mit SOA auf der semantischen Ebene, bei Geschäftsobjekten und Services. Hier liegt der Fokus der im Rahmen von SOA zu leistenden Integrationsarbeit – und darin auch der Grund, weshalb man SOA nicht aus der Technologie heraus vorantreiben kann. Zur Bewältigung dieser Arbeit bietet die Service-Architektur profunde Werkzeuge: einen übergreifenden Bezugsrahmen, der Einzelinitiativen in den Kontext der Gesamtarchitektur stellt, eine gemeinsame Sprache zwischen Business und IT sowie nicht zuletzt die Möglichkeit, Geschäftsverantwortung klar zu adressieren.
Für die nachhaltige Transformation von Prozess und IT-Landschaften stellt die Service-Architektur sos mit ein Zielszenario dar. Die zunehmende Entkopplung von Prozessen und Anwendungen durch stabile Servicebeziehungen ermöglicht dabei die Durchführung gezielter und lokal begrenzter Eingriffe. Dennoch bedarf es expliziter Management-Prozesse, um langfristige Integrationsziele und kurzfristigen Geschäftsnutzen, im Sinne einer „Managed Evolution“, in Deckung zu bringen. Dabei gilt, dass auch eine Service-Architektur, genau wie Prozess- und IT-Landschaft, einer stetigen Veränderung unterliegt – wenn auch mit weitaus geringerer Geschwindigkeit. Moving Targets existieren weiter, sind aber deutlich besser zu beherrschen.
SOA und Dezentralität – geht
Um an die These zu Beginn des Beitrags anzuknüpfen: Das Erzielen übergreifender Integration und dezentraler, Business-getriebener IT-Entwicklung repräsentiert im Rahmen einer SOA-Strategie keinen Widerspruch, sondern zwei Seiten derselben Medaille. Die Service-Architektur spielt hier die Rolle des strategischen Bebauungsplans, unterstützt dabei, IT vom Business her zu treiben, und ist konkretes Bindeglied zwischen Geschäftsprozessen und IT.
In der strategischen Dimension bietet SOA somit Antworten auf grundlegende Herausforderungen, vor denen Unternehmen heute stehen. In vielen Branchen entwickelt sich IT von der bloßen Unterstützungsfunktion zur strategischen Geschäftsressource. IT- und Business-Verantwortung wachsen in der Folge immer mehr zusammen. Konzepte wie SOA ermöglichen dabei, IT als Business-Thema zu gestalten und somit effektive Antworten auf die Herausforderungen des Wettbewerbs zu geben.
Gleichzeitig besitzt IT nach wie vor eine Dienstleistungsfunktion, die sie gegenüber dem Business effizient erbringen muss. Es gilt, Kosten zu reduzieren und die Time to Market zu verbessern. SOA adressiert dafür das Hindernis Nummer eins, die komplexe und starre Verknüpfung von Prozessen und IT. Eine Service-orientierte Architektur erzeugt somit gleichzeitig Stabilität und Flexibilität: Stabilität im IT-Management durch einen gemeinsam getragenen Generalbebauungsplan – und Flexibilität in der strategischen Anpassbarkeit der Anwendungslandschaft.