Geschäftsprozesse nach den Grundsätzen der SOA modellieren und beschreiben – Teil 1

In diesem Blog wollen wir Ihnen zeigen, wie Geschäftsprozesse nach den Grundsätzen der serviceorientierten Architektur modelliert und beschrieben werden können.

Zunächst wollen wir die beiden Begriffe „Geschäftsprozessanalyse“ (GPA) und „serviceorientierte Architektur“ (SOA) in diesem Blogkontext näher erläutern.

Die GPA hat das Ziel, die Wettbewerbsfähigkeit eines Unternehmens zu steigern und dessen betriebswirtschaftlichen Erfolg zu sichern. Durch die transparente Prozessbetrachtung können Geschäftsprozesse optimiert werden, um eine effiziente Arbeitsweise zu gewährleisten. Um komplexe Geschäftsprozesse durch IT-Anwendungen zu unterstützen, müssen auf unterschiedlichen Geschäftsprozess-Ebenen (GP-Ebene, siehe Abbildung 1) alle Geschäftsprozesse identifiziert werden, die durch eine IT-Anwendung optimal unterstützt werden können.

Der Begriff der SOA wird heutzutage sehr unterschiedlich ausgelegt. In diesem Blog wird der Begriff der SOA (aus der IT-Entwicklung) als ein gängiges Konzept definiert, nach dem die IT-Anwendungen eines Unternehmens in Services strukturiert werden. Diese Services sind Dienstleistungen, die innerhalb eines Unternehmens anderen Bereichen (oder Abteilungen) angeboten werden können. Damit andere Bereiche diese Services in ihren eigenen IT-Anwendungen nutzen können, müssen diese Services flexibel kombinierbar und wiederverwendbar sein, um die Entwicklungs-/Wartungskosten zu senken.

Um die gleichen Vorteile aus der IT-Entwicklung (Senkung der Entwicklungs- und Wartungskosten) zu nutzen, können die Prinzipien der SOA (Flexibilität und Wiederverwendbarkeit) für die Beschreibung der Geschäftsprozesse genutzt werden.

Hierzu muss auf jeder GP-Ebene (siehe Abbildung 1) geprüft werden, ob die ermittelten Geschäftsprozesse den beiden Eigenschaften der Wiederverwendbarkeit und der flexiblen Kombinierbarkeit von Services entsprechen. Auf der GP-Ebene 1 können keine Services dargestellt werden, weil die Geschäftsprozesse (hier Auswertungsverwaltung) auf dieser Ebene zu abstrakt sind und die Wiederverwendbarkeit keinen Sinn macht. In der GP-Ebene 3 sind die Geschäftsprozesse (z.B. Daten erfassen) zu detailliert beschrieben, daher genügen sie nicht den Kriterien bezüglich der Wiederverwendbarkeit. Nur die Geschäftsprozesse auf der GP-Ebene 2 (z.B. Auswertung anlegen) entsprechen den Kriterien der Wiederverwendbarkeit und flexiblen Kombinierbarkeit von Services.

Wir können von der Annahme ausgehen, dass die Geschäftsprozesse auf der GP-Ebene 2 (Auswertungen anlegen und bereitstellen) Dienstleistungen sind, die von anderen Bereichen (Kriterium – Wiederverwendbarkeit) in deren Geschäftsprozessen und IT-Anwendungen (Kriterium – flexible Kombinierbarkeit) in Anspruch genommen werden können.

Das Ziel der Beschreibung von Geschäftsprozessen ist die Dokumentation der Tätigkeiten einer ausführenden Rolle innerhalb eines Geschäftsprozesses. Eine mögliche Struktur des Dokuments könnte folgendermaßen aussehen.

1. Allgemeine Einführung in den Geschäftsprozess
2. Ablauf des Geschäftsprozesses
3. Identifizierte Services
   3.1. Service A
   3.1.1.   Beschreibung des Services
   3.1.2.   Rechte/Rollen
   3.1.3.   Ein-/Ausgabeparameter
   3.1.4.   Service-Level-Agreements
   3.2. Service B
   3.2.1.   Beschreibung des Services
   3.2.2.   Rechte/Rollen
   3.2.3.   Ein-/Ausgabeparameter
   3.2.4.   Service-Level-Agreements
4. Nicht-funktionale Anforderungen
5. Glossar

Hierbei könnte im ersten Kapitel eine kurze Einführung in den Geschäftsbereich erfolgen. Im zweiten Kapitel könnte der Gesamtkontext aller Geschäftsprozesse dargestellt (z.B. Einbindung von Abbildung 1) und beschrieben werden, um dem Leser einen Überblick zu verschaffen. Im Kapitel 3 würden die Services beschrieben werden, die als Dienstleistung anderen Bereichen angeboten werden. Kapitel 4 würde alle nicht-funktionalen Anforderungen enthalten und zu allerletzt könnte im Kapitel 5 das Glossar aufgeführt werden.

Um die Services in der richtigen Granularität zu beschreiben (Kapitel 3), sollte frühzeitig eine Kommunikation zwischen allen Projektbeteiligten stattfinden, um unnötige Schleifen zu vermeiden.

Fortführend gibt es weitere Themen, die man in diesem Kontext näher betrachten könnte. Wie entstehen z.B. Services? Oder warum ist die Notwendigkeit eines zentralen Managements für die Verwaltung von Services wichtig? Ebenso ist das Thema SOA unter der Betrachtung der agilen Entwicklung sehr interessant.

Sertac Sirinkaya

Kontaktieren Sie Sertac Sirinkaya

Herr Sertac Sirinkaya ist als Consultant im Bereich Requirements Engineering tätig. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, sowie der Einsatz von verschiedenen Modellierungstechniken (z.B. UML, BPMN).