Bei der Erläuterung der geschäftlichen Ausrichtung von Services in der Servicerichtlinie kommt auch die Verbindung zwischen den Geschäftsmodellen und der
Serviceidentifikation zur Sprache. Im Allgemeinen bietet dieser Ansatz eine sehr enge Verbindung zwischen
professionellen Stakeholdern/Anwendern und der IT-Abteilung, die Services implementiert. Die in Prozessmodellen
identifizierten Aufgaben werden über Serviceoperationen direkt unterstützt. Normalerweise konzentrieren sich
Geschäftsprozessmodelle auf Aufgaben, die von Rollen und/oder Ressourcen in einer Organisation ausgeführt werden, um
ein bestimmtes Ziel zu erreichen. Das geschieht in den meisten Fällen, um einer externen Partei, wie z. B. einem Kunden
oder einem Partner, einen Nutzen in Form eines Produkts oder Service zu bringen. Der Gesamtprozess ist somit eine
geordnete Menge von Aufgaben, die möglicherweise in Teilprozesse unterteilt ist. Dem Prozess sind eine Organisation,
eine Ressource sowie Datenmodelle zugordnet, mit denen alle Aspekte des Prozesses erfasst werden können, nicht nur die
Übernahme von Rollen, sondern auch erforderliche bzw. verwendete Ressourcen, eigene Ressourcen, Zuständigkeiten,
Definitionen von Elementen, die in Aufgaben und aus Aufgaben heraus übergeben wurden, usw. Im Konzept Geschäftsprozessdekomposition ist erläutert, wie die Beschreibung eines
Geschäftsprozessmodells ein Niveau erreichen kann, das die Identifikation geeigneter Services ermöglicht. Schauen Sie
sich dazu das folgende Beispiel an. Abhängig vom Grad der Unterteilung des Geschäftsanwendungsfallmodells kann es notwendig sein, die Geschäftsanwendungsfälle weiterzuentwickeln, um eine Dekompositionsstufe zu
erreichen, auf der ein sinnvolles Prozessmodell erzeugt werden kann.
In der folgenden Abbildung wird ein sehr einfaches Prozessmodell mit IBM WebSphere Business Integration Modeler
veranschaulicht.
In diesem Fall repräsentiert jeder horizontale Verantwortlichkeitsbereich eine bestimmt Rolle, die Aufgaben im Prozess
übernimmt. Der Prozess beginnt mit dem grünen Kreis, endet mit dem rot umrissenen Kreis und hat einen Datenfluss
zwischen einigen Aufgaben (in Form einer Kreditanfrage). Dieser Prozess, obwohl trivial und künstlich, gibt einen
groben Überblick über die anstehenden Aufgaben. Sie mögen aus geschäftlicher Sicht unteilbar sein, würden jedoch im
Falle einer Dekomposition bis auf die IT-Ebene eine Reihe von Schritten erfordern. In Allgemeinen würde in der
objektorientierten komponentenbasierten Entwicklung jede einzelne Aufgabe aus geschäftlicher Sicht als Anwendungsfall
in der IT-Sicht behandelt und dann in Gruppen von Komponenten und Klassen aufgeteilt, um die Implementierung des
Anwendungsfalls zu erstellen.
In einer serviceorientierten Lösung wird der Service auf einer ähnlichen Unterteilungsebene identifiziert. Es wird
allgemein angenommen, dass die Operationen in einer Servicespezifikation den unteilbaren Aufgaben in einem
Geschäftsprozessmodell eins zu eins entsprechen. Das ist zwar ein attraktiver Ansatz, der bei entsprechender Sorgfalt
die richtigen Ergebnisse bringen kann, jedoch auch zu der Annahme verleitet, dass einmal identifizierte Services direkt
wie im Prozessmodell beschrieben implementiert werden können. Insbesondere jede Rolle (jeder
Verantwortlichkeitsbereich) wird zu einem benannten Service, bei dem jede Aufgabe im Verantwortlichkeitsbereich als
Operation für den entsprechenden Service erstellt wird. Schauen Sie sich dazu die folgende Abbildung an.
Allerdings lässt dieser Ansatz die nicht funktionalen Anforderungen außer Acht, die sich auf Folgendes auswirken: die
Art des zu entwickelnden Service, die Art und Weise, auf die Operationen für Services identifiziert werden usw. Die
Detaillierungsebene, die von solchen Tools erfasst wird, beinhaltet in der Regel nicht genügend Informationen, um
Richtlinien für Sicherheit, Servicequalität oder Verwaltbarkeit zu erfassen. Durch Umwandlung des Prozesses in eine
Gruppe von Servicespezifikationen für geeignete Services in einem Servicemodell wird ein Ausgangspunkt
geschaffen, von dem aus weitere Analysen durchgeführt werden können, bevor das Designmodell, das die eigentliche
Implementierung beschreibt, entwickelt wird. Der Status solcher Services sollte deshalb generell auf 'geeignet'
('candidate') gesetzt werden, wie Sie in dieser Eigenschaftensicht von Rational Software Modeler sehen können.
Alternative Darstellung
Wo eine mehr dokumentzentrierte Form für das Servicemodell verwendet wird, kann eine Zuordnung von Prozessaufgaben und
Services im Tabellenformat besser geeignet sein. Das folgende Beispiel demonstriert diese Formatierungsmöglichkeit.
|