Aufgabe: Geschäftsprozessanalyse
Diese Aufgabe identifiziert die Designelemente einer serviceorientierten Lösung hinsichtlich der Services und Partitionen und dokumentiert die erste Spezifikation dieser Services.
Zweck
  • Die Designelemente einer serviceorientierten Lösung hinsichtlich der Services und Partitionen identifizieren.
  • Die erste Spezifikation von Services dokumentieren.
  • Die Abhängigkeiten und die Kommunikation zwischen Services bestimmen.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung

Für diese Aufgabe werden Geschäftsprozessmodelle als Arbeitsvorgabe verwendet. Ziel dieser Aufgabe ist es, eine Gruppe geeigneter Services zu identifizieren, die in das Serviceportfolio des Projekts aufgenommen werden können. Diese geeigneten Services müssen ggf. noch verfeinert werden. Die hier angegebenen Schritte beschreiben jedoch einen effektiven Weg zur Erstellung einer Ausgangsgruppe von Servicespezifikationen.

Schritte
Geeignete Services anhand des Geschäftsprozesses identifizieren

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.

Im Kontext beschriebene Abbildung

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.

 Illustration des Tabellenformats



Eigenschaften
Vorgänger
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen