Im ersten Teil unseres Blogs haben wir Ihnen die Begriffe der Geschäftsprozessanalyse (GPA) und serviceorientierter Architektur (SOA) in unserem Blogkontext vorgestellt. Wir haben Ihnen gezeigt, auf welcher Ebene die Geschäftsprozesse nach SOA geschnitten werden können, um Services zu erhalten, die als Dienstleistung einer anderen Organisationseinheit angeboten werden können. Desweiteren sind wir kurz auf die Beschreibung der Geschäftsanwendungsfälle eingegangen.
Im zweiten Teil dieses Blogs werden wir auf die Identifikation und Beschreibung von Services und auf die Notwendigkeit eines zentralen Managements von Services eingehen.
Identifikation und Beschreibung von Services
Services können im Grunde genommen durch zwei unterschiedliche Arten identifiziert werden. Einerseits entsteht ein Service durch das Bedürfnis eines Service-Nutzers, der seine Anforderungen an einen Service stellt und diese an den Service-Anbieter richtet, um einen ihm zugeschnittenen Service zu erhalten. Andererseits kann ein Service auch durch einen Service-Anbieter entstehen, der beim Prozess der Optimierung von Geschäftsprozessen seine Services nach den Kriterien der SOA (Wiederverwendbarkeit und flexible Kombinierbarkeit) so schneidet, dass er diese als in sich abgeschlossene Dienstleistungen anbieten kann. Hier besteht allerdings die Gefahr, dass nicht alle Anforderungen eines zukünftigen Service-Nutzers abgedeckt sein können.
Jeder Service nach SOA hat für den Service-Nutzer eine Black-Box-Service-Beschreibung, in der die Rechte und Rollen, Ein-/Ausgabeparameter und die Service-Level-Agreements (SLA) definiert sind. Für die White-Box-Beschreibung, die für den Service-Anbieter relevant ist, müssen darüber hinaus noch die service-internen Abläufe definiert werden.
Die SLA beschreiben die Vereinbarung zwischen einem Service-Nutzer (Auftraggeber) und einem Service-Anbieter (Dienstleister). In einem SLA sind zugesicherte Leistungen (z.B. Verfügbarkeit, Reaktionszeit) festgehalten, die der Service gegenüber einem Service-Nutzer einhalten muss. Ebenso enthalten die SLA ein Mengengerüst, das z. B. die Anzahl der Datenauswertungen pro Tag für einen Service-Nutzer festlegt. Die Rechte und Rollen geben an, welche Berechtigungen (eventuell gegeben durch die Rolle) ein Anwender besitzen muss, um den Service in Anspruch nehmen zu können. Und schließlich beschreiben die Ein- und Ausgabeparameter die Daten (und deren Form), die dem Service zur Verfügung gestellt werden müssen, und welche Daten dieser erzeugt.
Für den Service-Anbieter ist zusätzlich die Beschreibung der internen Abläufe eines Services interessant. Wie im Falle der Modellierung der Geschäftsanwendungsfälle können wir auch hier die BPMN oder EPKs zur Modellierung einsetzen.
Notwendigkeit eines zentralen Managements
Das Anbieten (durch Service-Anbieter), als auch das Fordern (durch Service-Nutzer) eines Services kann durch ein zentrales Management (sog. SOA-Board) gesteuert werden.
Sowohl der Service-Anbieter als auch der Service-Nutzer sollten Ihre Anfragen an das SOA-Board zur Prüfung vorlegen. Das SOA-Board prüft in beiden Fällen, ob ein gleicher oder ähnlicher Service bereits existiert oder nicht. Sollte solch ein Service nicht vorhanden sein, so prüft das SOA-Board, ob die Funktionalität ein wiederverwendbarer Service ist. Bei positiver Beurteilung wird die Anfrage akzeptiert. Somit kann der Service-Anbieter seinen eigenen Service entwickeln oder der Service-Nutzer seinen geforderten Service an einen zuständigen Service-Anbieter zur Entwicklung weiterleiten. Bei negativer Beurteilung wird die Anfrage für diesen Service abgelehnt, und der Service-Nutzer muss die geforderte Funktionalität selbst implementieren. Sollte ein ähnlicher Service bereits vorhanden sein, so kann das SOA-Board entscheiden, dass dieser bestehende Service leicht verändert wird, um den neuen Bedürfnissen gerecht zu werden. Man beachte: Diese Entscheidung betrifft auch die SLA, die auf Ähnlichkeit und ggfls. Erweiterbarkeit geprüft werden müssen.
Neben der zentralen Aufgabe die Services zu beurteilen, kann das SOA-Board für weitere Aufgaben verantwortlich sein:
- Erstellung und Pflege eines sog. SOA-Repositories, das alle Services enthält, die als Dienstleistung angeboten werden
- Redundante und namentlich-identische Services identifizieren und beseitigen
- Namen und ID´s für Services zentral vergeben und diese zeitnah in dem SOA-Repository pflegen
- Zentraler Ansprechpartner für Fragen bezüglich der Inhalte des SOA-Repositories
In unserem zweiteiligen Blog haben wir Ihnen einen Überblick zur „SOA in Geschäftsprozessen“ gegeben. Dabei haben wir uns auf einige wichtige Themen beschränkt, andere Themen wie zum Beispiel die Versionierung von Services außen vor gelassen. Für Fragen zu den vorgestellten und weiterführenden Themen stehen die SOPHISTen Ihnen gerne zur Verfügung.