Mehr Flexibilität durch serviceorientierte Architekturen

Mehr Flexibilität durch serviceorientierte Architekturen (Fortsetzung)

Fachliche Anforderungen sind massgeblich
Die Umsetzung einer SOA ist nicht geprägt durch die Einführung einer bestimmten Schnittstellentechnologie wie http/SOAP. Vielmehr steht die Orientierung der Schnittstellen an den fachlichen Funktionalitäten und dem Prozessschnitt im Vordergrund. Allerdings sollte eine einheitliche Schnittstellentechnologie festgelegt werden, über die dann alle Enterprise Services erreicht werden können.
Eine SOA zeichnet sich durch verschiedene Eigenschaften aus. Zunächst einmal sind die Enterprise Services und Service-Domänen an fachlichen Anforderungen ausgerichtet. Sodann ist die Zugriffstechnik auf alle Enterprise Services einheitlich. Bestehende Assets (etwa IMS- oder CICS-Transaktionen) können durch Kapselung von Legacy-Systemen mit Service-Adaptern weiter genutzt werden. Ein zentrales Repository aller Enterprise Services dient der Unterstützung.
Die Einführung einer SOA in einem Unternehmen erfordert mehrere Jahre. Dabei wird die Architektur schrittweise für unterschiedliche Geschäftsbereiche und Prozesse eingeführt. Technisch folgt die Entkopplung dem Service-Enabling, außerdem wird die Granularität sukzessive verfeinert. Das Service-Enabling stellt zunächst Services einer Prozessgruppe (oder des Unternehmens insgesamt) für andere zur Verfügung. Bei der Entkopplung werden bestehende Verflechtungen zwischen Systemen oder Teilsystemen aufgelöst, um eine größere Flexibilität bei Neuentwicklungen, Systemänderungen oder Re-Integrationsszenarien (Neuzuschnitt der Anwendungslandschaft bei einem Merger) zu haben.

Verrechnungsverfahren erforderlich
Die Durchsetzung dieser Software-Architektur erfordert Management-Unterstützung. Die IT-Strategie muss aus der Business-Strategie abgeleitet werden, um die strategischen Ziele ebenso wie Quick Wins zu erreichen. Teil dieser erforderlichen Management-Unterstützung ist die Einführung eines geeigneten Systems zur Verrechnung der in Anspruch genommenen Leistungen eines Servicegebers. Damit wird die Motivation zur Erstellung allgemeingültiger Enterprise Services hergestellt. Ohne ein Verrechnungssystem tendieren Projekte zur Implementierung projektspezifischer Zugänge, die nicht durch Dritte wiederverwendbar sind.
Eine organisatorische Verankerung unterstützt die Einführung der SOA. Dazu wird ein zentrales Competence Center eingerichtet, dessen Verantwortlichkeit unterschiedliche Ebenen haben kann. Beim Providing geht es darum, Informationen und Schulungen zum Thema serviceorientierte Architektur auszuarbeiten und anzubieten. Der Support unterstützt laufende Projekte aktiv bei der Verwendung von SOA durch Beratung und Mitarbeit im Projekt. Das Managing schließlich betrifft die Planung und Steuerung der SOA-Umsetzung im Geschäftsbereich oder im Unternehmen.

Geschäftsprozesse im Blick
Für die Nutzung einer Process Engine als Bestandteil des Business Process Management (BPM) ist der Zugriff auf die fachlichen Funktionalitäten aus der Engine heraus erforderlich. Das Service-Enabling von Legacy-Systemen ermöglicht diesen Aufruf über Servicefunktionen. Beim Service-Enabling kann die Steuerung der Programmabläufe zunächst unverändert in den Anwendungen fest codiert sein. Wenn das Service-Enabling weit vorangetrieben worden ist und Servicefunktionen einzelnen Aktivitäten in einem Prozess entsprechen, kann der Schritt zur Nutzung einer Process Engine durchgeführt werden. Der Prozess wird dann mit einem Tool modelliert, das zum Beispiel Business Process Execution Language (BPEL) generiert und in einer Process Engine ausgeführt. Die Process Engine ruft im Zuge der Ausführung die Servicefunktionen auf.
Derartige Techniken sind nur ein Teil von BPM, das sich mit der kontinuierlichen Messung und Verbesserung von Geschäftsprozessen auseinandersetzt. Die Umsetzbarkeit dieser Prozessveränderungen wird wiederum durch die SOA erreicht.    g

Thomas Tieke ist Senior Consultant ­Banking Finance bei Mummert Consulting

1. Mehr Flexibilität durch serviceorientierte Architekturen
2. Mehr Flexibilität durch serviceorientierte Architekturen (Fortsetzung)