Agon Newsletter Ausgabe 01 / 2013.

Zurück

Unternehmensweite Serviceorientierte Architektur

Externe Anforderungen an Unternehmen wie Gesetzgebung, unterschiedliche Kommunikationskanäle zu Kunden und Geschäftspartnern sowie Kosten- und Wettbewerbsdruck erfordern zunehmend ein standardisiertes Prozessmanagement und die Fähigkeit, diese flexibel und zeitnah anpassen zu können. Aber was sind die Voraussetzungen für eine schnelle und flexible Anpassung der Geschäftsprozesse? Handelt es sich dabei um ein reines IT-Thema oder betrifft es auch die Fachseite? Welches Know-how wird für die Analyse und Umsetzung benötigt?

Eine Serviceorientierte Architektur (SOA) ist die Basis für die gewünschte Flexibilität in Geschäftsprozessen. Dieser Artikel soll eine praxisorientierte Sicht auf die Einführung geben. Dabei kann das gesamte Unternehmen oder auch nur ein Teilbereich im Fokus stehen.

Eine SOA ist per Definition ein Muster für die Bereitstellung und Nutzung verteilter fachlicher Funktionalitäten, die von unterschiedlichen Herstellern / Verantwortlichen bereitgestellt werden. Ein Service ist eine mögliche technische Abbildung einer in sich abgeschlossenen, fachlichen Funktionalität und stellt diese über veröffentlichte Schnittstellen zur Nutzung bereit.

Eine SOA bietet für die Flexibilisierung von Geschäftsprozessen die notwendige Modularisierung von Geschäftslogiken, Geschäftsregeln und Zugriffen auf Unternehmensdaten. Für die Umsetzung eines Geschäftsprozesses sind neben Services, auch Anwendungsmasken und Ablauflogiken modulare Bestandteile. Diese können nach fachlichen Gesichtspunkten und Wiederverwendbarkeit aufgeteilt und als eigenständige technische Komponenten umgesetzt werden. Der Blickwinkel der SOA muss in der Praxis von klassischen Services zu einem umfassenden fachlichen und funktionalen Baukasten erweitert werden.

Dies steht im Kontrast dazu, dass viele Unternehmen monolithische Anwendungssysteme (Silo-Anwendungen) betreiben, die nur begrenzt änderbar, erweiterbar und wartbar sind. Bestehende Funktionen sind nicht flexibel für Geschäftsvorfälle kombinierbar (orchestrierbar). Anstatt einer integrierten Oberfläche und einem medienbruchfreien Ablauf bestehen sie meist aus Teilvorgängen der einzelnen Anwendungen und erfordern manuelle Datenübernahmen. Eine Gesamtübersicht oder Steuerung der Geschäftsprozesse sind nicht oder nur eingeschränkt möglich. Änderungen und Erweiterungen sind kosten- und zeitintensiv.

Was ändert sich in der Praxis bei der Einführung einer unternehmensweiten serviceorientierten Architektur?

 

1) Konzeption und Umsetzung von Geschäftsprozessen, Services und Anwendungsfrontends

Zunächst betrachten wir die Vorgehensweise bei der rein fachlichen Konzeption von Geschäftsprozessen. Im ersten Schritt werden bereits standardisierte Geschäftsprozesse mit Prozessschnittstellen in einer Prozesslandkarte dargestellt. Kernprozesse eines Unternehmens werden hervorgehoben, da diese bevorzugt zu unterstützen sind und eine Flexibilisierung hier den größten Nutzen bringt. Ergänzend zerlegt man den einzelnen Geschäftsprozess in Teilabläufe mit fachlichen Zwischenergebnissen. Zwischen diesen Teilabläufen werden Schnittstellen bestimmt.

Im zweiten Schritt wird die sogenannte Top-Down-Methode angewandt: Ausgehend von Geschäftsprozessen werden benötigte fachliche Funktionen, Geschäftslogiken, Geschäftsdaten, Geschäftsregeln und Oberflächenmodule identifiziert und aus der Sicht des Geschäftsprozesses Schnittstellen festgelegt. Nach fachlicher Gruppierung ergeben sich Ansätze für neue Komponenten.

Hierbei wird geprüft, ob beispielsweise Funktionen, Daten oder Geschäftsregeln bereits in vorhandenen Komponenten enthalten sind und diese genutzt oder inhaltlich erweitert werden können. Schließlich vergleicht man mehrere (Teil-)Geschäftsprozesse bezüglich einer möglichen Wiederverwendbarkeit der identifizierten Komponenten – ggf. mit Erweiterung oder Modifikation.

In einer klassischen SOA werden Services in mehrere Kategorien, z.B. Geschäftslogik, Datenzugriff, Geschäftsregeln, etc. unterteilt. Ein Unternehmen sollte hierzu seine eigenen Kategorien festlegen und die Einsatzbereiche definieren. Wie vorher schon erwähnt, müssen Komponenten-Kategorien für beispielsweise Anwendungsmasken oder Abläufe ergänzt werden, die ebenfalls aus fachlicher Sicht wiederverwendbar sind.

Je häufiger ein Service bzw. je allgemeiner eine Komponente aus Sicht der Geschäftsprozesse nutzbar ist, desto größer ist ihr geschäftlicher Nutzen und die Flexibilität, sie in einem anderen Kontext wieder einzusetzen. Daher sollte man versuchen auf eine hohe Spezialisierung, umfangreiche Funktionalitäten und umfangreiche Schnittstellen zu verzichten. Ein Kompromiss zwischen Spezialisierung und Wiederverwendbarkeit bzw. Flexibilität können zusätzliche Schnittstellen oder parametergestützte Varianten der Schnittstellen darstellen.

Ein wesentlicher Aspekt bei der Aufteilung in fachliche Bausteine bzw. Komponenten ist die Berücksichtigung, idealerweise Vermeidung, von fachlichen/inhaltlichen, technischen, zeitlichen oder anderen Abhängigkeiten – man spricht hier vom Prinzip der „losen Kopplung". Beispielsweise darf die Änderung einer Datenstruktur nicht die Schnittstellen der darauf aufbauenden Services beeinflussen, sodass diese Service mit ausgetauscht werden müssen.

Lassen sich Abhängigkeiten nicht vollständig vermeiden, muss auch die Änderungshäufigkeit einzelner Komponenten betrachtet werden, damit bei Releasewechseln nicht diverse abhängige Komponenten angepasst und mit eingesetzt werden müssen. Dabei ist es sinnvoll, Komponenten nach Änderungshäufigkeit zu kategorisieren und ihre Abhängigkeit bzgl. aufrufenden bzw. abhängigen Komponenten zu reduzieren.

In Summe erhält man eine Grobspezifikation von Geschäftsprozessen und Komponenten, die mit Hilfe einheitlicher IT-Standards in technische, ausführbare Komponenten überführt und verfeinert werden.

 

2) Organisatorische Änderungen

Unternehmen, die bereits ein Prozessmanagement eingeführt haben, vergeben Verantwortlichkeiten für Geschäftsprozesse oder Teilprozesse. Meist stimmen sich diese mit den vorhandenen Verantwortlichen der bestehenden Anwendungssysteme ab. Mit Einführung einer unternehmensweiten SOA werden zusätzliche Verantwortliche bzw. Rollen für alle fachlichen Bausteine bzw. deren technische Abbildung als Komponente benötigt.  Diese Unterscheidung ist durchaus sinnvoll, da sie unterschiedliche Sichten wie Wiederverwendbarkeit einer Komponente über mehrere Geschäftsprozesse im Gegensatz zum fachlichem Kontext oder zur Durchlaufzeit (=Reduktion der Anzahl aufzurufender Schnittstellen) eines Geschäftsprozesses berücksichtigen.  

Verantwortlichkeiten für Komponenten (in der klassischen SOA unterschiedliche Service-Kategorien) werden meist in einem fachlichen Kontext, sogenannten Domänen, zusammengefasst. In der Praxis hat es sich bewährt, Services, Datenhaltungen und Oberflächen in einer fachlichen Domäne zu gruppieren. Somit können Komponenten aller Architekturschichten von einem Expertenteam fachlich konzipiert, entwickelt und betrieben werden.

Für den unternehmensweiten Einsatz einer SOA ist weiterhin ein Kernteam von IT-Experten, üblicherweise Architekten, erforderlich. Diese sind verantwortlich für die technischen Standards bzgl. Architektur, Design, Entwicklung und Betrieb und unterstützen die Projektarbeit aktiv durch Erstellung von Prototypen und durch Coaching.

 

3) Zentrale Dokumentation

Für die Erstellung und Änderung der Geschäftsprozesse ist eine zentral verfügbare Dokumentation (Repository) der Geschäftsprozesse und aller Komponenten notwendig. Ergänzend sind unternehmensweit eine einheitliche Sprache und eine einheitliche Vorgehensweise für Konzeption, Entwicklung und Betrieb erforderlich. Verantwortlich ist das zentrale Expertenteam.

 

4) Unterstützung der IT

Bisher wurden die technischen Rahmenbedingungen für eine unternehmensweite SOA nur partiell betrachtet.

Hier sind eine einheitliche Entwicklungs-, Test- und Produktionsumgebung für alle Komponentenkategorien sowie eine einheitliche Vorgehensweise der Entwicklung von Komponenten zu nennen.

Bezüglich der Laufzeitumgebungen sind Aspekte wie Verteilung, Sicherheit, Skalierbarkeit und Ausfallsicherheit zu berücksichtigen. Ein sicherer und stabiler Betrieb für eine teilweise unbekannte Anzahl an Konsumenten der Komponenten ist sicherzustellen. Gegebenenfalls sind neue Laufzeitumgebungen (Komponentencontainer, Portale, Rules Engine, Process Engine) und Middleware in Form von Message-Systemen oder ein Enterprise Service Bus erforderlich, um den fachlichen Baukasten in Form technischer Komponenten betreiben zu können.

 

Fazit

Mit einem fachlichen Baukasten bietet eine unternehmensweite SOA ideale Voraussetzungen für eine  schnelle, flexible Erstellung und Optimierung von Geschäftsprozessen. Sie steht in starkem Kontrast zu starren, monolithischen Silo-Anwendungen, die keine funktionale Modularität, keine integrierten Anwendungfrontends und keine Steuerung/Auswertung der Geschäftsprozesse erlauben.

Eine unternehmensweite SOA ist kein reines IT-Thema oder das Thema eines Projektes (Guerilla-SOA). Sie erfordert die Akzeptanz und Unterstützung des Managements und die enge Zusammenarbeit von Fachseite und IT.

Notwendig sind Rollen/Verantwortlichkeiten für fachlich wie technisch wiederverwendbare Bausteine, eine zentral verfügbare fachliche und technische Dokumentation aller Komponenten und ein zentrales Experten- und Service-Team.  

Nicht zuletzt sind einheitliche technische Rahmenbedingungen die Voraussetzung für einheitliche Konzeption und Entwicklung sowie stabilen und sicheren Betrieb der Komponenten.