SOA-Serie Teil II: Die Architektur

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 OutsourcingOutsourcing, 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. Alles zu Outsourcing auf CIO.de

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.