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

In unserem vorhergegangenen Blog sind wir auf die Modellierung und Beschreibung von Geschäftsprozessen nach den Grundsätzen der serviceorientierten Architektur eingegangen. In diesem Blog werden wir uns mit der Frage beschäftigen, worauf man bei der Erstellung von Services achten sollte und wieso es notwendig ist, ein zentrales Management für die Verwaltung von Services einzuführen.

Im ersten Teil dieser Blogreihe haben wir Ihnen beschrieben, auf welcher Geschäftsprozess-Ebene die Geschäftsprozesse den Prinzipien der Wiederverwendbarkeit und flexiblen Kombinierbarkeit entsprechen können. Auf einer solchen Ebene können aus den Geschäftsprozessen, Services entwickelt werden, die nach außen hin (z.B. anderen Abteilungen) angeboten werden. Doch wie genau entstehen diese Services?

Services müssen zunächst einen betriebswirtschaftlichen Nutzen/Mehrwert haben. Es macht wenig Sinn, einen Service zu erstellen und anzubieten, der nur im eigenen Prozess genutzt wird. Diese Services können von anderen Service-Nutzern nicht angefordert bzw. genutzt werden, weil sie nicht in ihre Geschäftsprozesse eingebunden werden können.

Services, die die Eigenschaft der Wiederverwendbarkeit und flexiblen Kombinierbarkeit besitzen, können sowohl durch einen Service-Anbieter (Eigenbedarf), als auch durch einen Service-Nutzer (Fremdbedarf) genutzt werden. Dabei muss der Service-Anbieter bei der Entwicklung seiner Services die Anforderungen seiner Geschäftsprozesse und die Kriterien der SOA (eben jene Wiederverwendbarkeit und flexible Kombinierbarkeit) beachten. Hier besteht allerdings die Gefahr, dass nicht alle Anforderungen eines möglichen Service-Nutzers abgedeckt werden können. Daher müsste bei Bedarf eines Services der Service-Nutzer seine Anforderungen an den Service-Anbieter richten, um somit einen ihm zugeschnittenen Service zu erhalten.

In einem Umfeld, wo jeder Bereich nur seine eigenen Geschäftsprozesse betrachtet, kann es schnell dazu kommen, dass unterschiedliche Bereiche einen gleichen/ähnlichen Service entwickeln. Um Redundanzen bei der Entwicklung identischer Services zu vermeiden, ist es daher wichtig, das gesamte Umfeld zu betrachten. Vor jeder Entwicklung eines Services sollte zunächst geprüft werden, ob im Umfeld bereits ein gleicher/ähnlicher Service existiert. Sollte solch ein Service existieren, so müsste dieser in Anspruch genommen werden. Doch ohne eine zentrale Verwaltung dieser Services ist es sehr schwierig zu erfahren, welche Bereiche einen bestimmten Service bereits anbieten oder entwickeln. Daher sollte das Anbieten (durch den Service-Anbieter), als auch das Fordern (durch den Service-Nutzer) eines Services durch ein zentrales Management (das sog. SOA-Board) gesteuert werden. Dieses zentrale Management ist für die Verwaltung der Services in einer sog. SOA-Datenbank verantwortlich. Das SOA-Board verwaltet alle Services eines Unternehmens, die als Dienstleistung angeboten werden können.

Das SOA-Board übernimmt in einem Entwicklungsumfeld weitere wichtige Aufgaben. Es prüft, ob  ein neuer Service  den Kriterien der Wiederverwendbarkeit entspricht. Es identifiziert mögliche redundante Services und beseitigt diese. Das SOA-Board vergibt außerdem neuen Services einen Namen und eine eindeutige ID. Des Weiteren ist es der zentrale Ansprechpartner für Fragen bezüglich der Inhalte der SOA-Datenbank.

In diesem Blog wurde Ihnen gezeigt, wie Services entstehen können und wieso es wichtig ist, ein zentrales Management für die Verwaltung von Services einzuführen. Im nächsten Blog werden wir dann auf die Entwicklung von Services in einem agilen Umfeld (z.B. SCRUM) näher eingehen.

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).