scieee Science in your language
[en] (orig)
Modellierung von Service-Aufrufbeziehungen zwischen
prozessorientierten Applikationen
Stephan Buchwald, Thomas Bauer
Group Research & Advanced Engineering, Daimler AG,
{stephan.buchwald, thomas.tb.bauer}@daimler.com
Zusammenfassung: In Unternehmen existiert oftmals eine Vielzahl von heterogenen
Informationssystemen f¨
ur die Bereitstellung und Verarbeitung von Gesch¨
aftsdaten.
Die Integration dieser Informationssysteme stellt eine große Herausforderung dar, ins-
besondere aufgrund fehlender Standardisierung und Detaillierung der Dokumentation
solcher IT-Landschaften. Problematisch ist, dass in vielen Unternehmen die verschie-
denen Applikationen und Gesch¨
aftsprozesse sowie die Abh¨
angigkeiten zwischen ih-
nen (d.h. angebotene Schnittstellen und deren Verwendung) nicht vollst¨
andig bekannt
sind. Dadurch entstehen sehr un¨
ubersichtliche, heterogene und nur schwer erweiter-
bare IT-Landschaften. Dieser Beitrag entwickelt eine Methode zur Modellierung und
Spezifikation der Abh¨
angigkeiten insbesondere zwischen prozessorientierten Applika-
tionen.
1 Einleitung
Infolge der Integration und Konfiguration heterogener und nur wenig standardisierter Sys-
teme weisen IT-Landschaften heutiger Unternehmen eine hohe Komplexit¨
at auf. Aufgrund
der Vielzahl an Applikationen (oft mehrere hundert) sowie der fehlenden oder nur unzu-
reichenden Dokumentation der Beziehungen zwischen ihnen und den im Unternehmen ab-
laufenden Gesch¨
aftsprozessen, entsteht eine nur schwer wartbare IT-Landschaft. Verst¨
arkt
wird dies durch die st¨
andig wachsende Anzahl von Applikationen und dem regen Daten-
austausch zwischen ihnen. Die Kopplung dieser Systeme ist oft entweder unvollst¨
andig
oder sehr heterogen. Auch wird h¨
aufig auf eine solche verzichtet und es findet eine ma-
nuelle Daten¨
ubernahme statt. In Abbildung 1a wird eine sehr vereinfachte Unternehmens-
landschaft dargestellt. Applikationen und Prozesse kommunizieren dabei bspw. ¨
uber einen
Nachrichtenaustausch (per Middleware wie z.B. IBM WebSphere MQ), eine gemeinsame
Datenbank, einen File-Transfer und oftmals auch ¨
uber eine manuelle Daten¨
ubernahme,
was leicht zu inkonsistenten und fehlerhaften Daten f¨
uhrt. Deshalb ist eine einheitliche
Dokumentation aller Informationen ¨
uber die Unternehmenslandschaft essentiell. Im Ein-
zelnen sind das Informationen dar¨
uber, welche Applikationen und Gesch¨
aftsprozesse an
welchen Ereignissen interessiert sind, welche Operationen in Folge eines Ereignisses aus-
gef¨
uhrt werden sollen und wie die Daten hierf¨
ur transformiert werden m¨
ussen. Abbildung
1b zeigt zwei Ereignisse die w¨
ahrend der Ausf¨
uhrung des Entwicklungs- und ¨
Anderungs-
prozesses erzeugt werden: Der Entwicklungsprozess erstreckt sich von der Einreichung ei-
ner Idee zur Verbesserung eines Bauteils bis hin zur abschließenden Bewertung. W¨
ahrend
Produktdaten-
Management-
System
Logging-
System
Entwicklungsprozess
Änderungsprozess
manuelle
Datenübergabe File-
Transfer
Nachrichten-
austausch
a) Systemsicht (Ist-Zustand)
Entwicklungsprozess
Änderungsprozess
Wartet auf
Ereignis
Prozess wird
ausgelöst
durch Ereignis
b) Prozesssicht
1
2
Abbildung 1: Datenaustausch zwischen Prozessen und Applikationen
der Ausf¨
uhrung des Entwicklungsprozesses, wird ein ¨
Anderungsprozess gestartet, um zu
pr¨
ufen, ob die Verbesserungsidee Auswirkung auf andere Bauteile hat. Der ¨
Anderungspro-
zess wird durch ein Ereignis aus dem Entwicklungsprozess gestartet (vgl. 1
in Abbildung
1b). Der Entwicklungsprozess wartet anschließend, bis eine entsprechende Genehmigung
durch einen Verantwortlichen aus dem ¨
Anderungsprozess kommuniziert wird (vgl. 2
in
Abbildung 1b). Diese Abh¨
angigkeiten beschreiben Aufrufbeziehungen zwischen Appli-
kationen und Gesch¨
aftsprozessen, die mittels Ereignissen in Zielapplikationen definierte
Operationen ausf¨
uhren. Damit die verschiedene Applikationen untereinander Daten aus-
tauschen k¨
onnen, ist je Interaktion zwischen zwei Systemen eine Konvertierung der Daten
notwendig. Transformationsregeln m¨
ussen applikationsspezifische Datenobjekte (ASBO)
in globale Datenobjekte (GBO) transformieren, um diese dann in einer einheitlichen Form
anderen Applikationen zur Verf¨
ugung zu stellen. Somit k¨
onnen sich Applikationen und
Gesch¨
aftsprozesse f¨
ur bestimmte Ereignisse registrieren und zugleich ihre Daten entspre-
chend dem GBO transformieren. Um die Modellierung der skizzierten Abh¨
angigkeiten
zu erm¨
oglichen, ist eine werkzeugseitige Unterst¨
utzung erforderlich. Hierbei ist es wich-
tig, bereits dokumentierte Gesch¨
aftsprozessmodelle und Datentypen bei der Modellierung
von Abh¨
angigkeiten weiter verwenden zu k¨
onnen. Außerdem m¨
ussen die in den Syste-
men auftretenden relevanten Ereignissen und die Abh¨
angigkeiten zwischen Ereignisse und
Schnittstellen (Aufruf einer Operation oder Funktion) modellierbar sein.
Dieser Beitrag wurde im Rahmen des Projektes Enproso (Enhanced Process Management
by Service Orientation) erstellt. Dementsprechend liegt der Schwerpunkt auf Gesch¨
aftspro-
zessen und prozessorientierten Applikationen. Der Beitrag beschreibt, wie Ereignisse und
Schnittstellen explizit dokumentiert werden k¨
onnen. Anschließend zeigen wir, wie Aufruf-
beziehungen zwischen Applikationen und Gesch¨
aftsprozessen detailliert modelliert wer-
den. Aus diesen Informationen kann ein Gesamt¨
uberblick der Aufrufbeziehungen zwi-
schen Applikationen und Gesch¨
aftsprozessen abgeleitet werden, welcher als Basis f¨
ur die
Planung der zuk¨
unftigen IT-Landschaft des Unternehmens oder zur Implementierung wei-
terer Applikationen verwendet werden kann. Andererseits kann durch solch eine Doku-
mentation sichergestellt werden, dass ¨
Anderungen an Applikationen und Gesch¨
aftspro-
zessen sowie den zugeh¨
origen Aufrufbeziehungen keine unerwarteten Folgen haben. D.h.
¨
Anderungen sind transparent und nachvollziehbar. Die Gesamt¨
ubersicht dient zudem als
Basis f¨
ur Analysen und Optimierungen der IT-Landschaft des Unternehmens, im Sinne
eines detaillierten Enterprise Architecture Management [MBL07, EHH+08, BELM08].
So geben die modellierten Informationen Auskunft dar¨
uber, welche Personen z.B. bei der
Ver¨
anderung eines Gesch¨
aftsprozesses zustimmen m¨
ussen oder welche laufenden Appli-
kationen dadurch beeinflusst werden. Schließlich kann aus der dokumentierten Informati-
on ein Modell zur Implementierung (z.B. als J2EE-Implementierung), Generierung (z.B.
Message-Broker-Abl¨
aufe) oder Konfiguration einer generischen Integrationsinfrastruktur
(vgl. [Bau05, Buc05]) abgeleitet werden.
In Abschnitt 2 wird ein Anwendungsszenario eingef¨
uhrt. Unterschiedliche Sichtweisen
auf die IT-Landschaft werden in Abschnitt 3 (fachliche Sicht f¨
ur Prozess-Modellierer) und
Abschnitt 4 (IT-Sicht f¨
ur IT-Abteilungen oder IT-Architekten) detailliert. Nach einer Dis-
kussion zur Nutzung der modellierten Information in Abschnitt 5, wird der aktuelle Stand
der Technik betrachtet, bevor dieser Beitrag mit einer Zusammenfassung und einem Aus-
blick schließt.
2 Anwendungsszenario
Wir skizzieren zun¨
achst ein typisches Anwendungsszenario aus der Automobilindustrie,
entlang dessen wir sp¨
ater die Modellierung von Service-Aufrufbeziehungen zwischen pro-
zessorientierten Applikationen diskutieren. Das Anwendungsbeispiel in Abbildung 2 stellt
eine vereinfachte IT-Landschaft dar. Dabei werden Beziehungen zwischen Applikationen
und Gesch¨
aftsprozessen explizit durch Richtungspfeile gekennzeichnet.
Der Entwicklungsprozess erstreckt sich von der Einreichung einer Verbesserungsidee bis
hin zu deren abschließenden Bewertung [HBR08] ( 1
in Abbildung 2). Er wird durch
Einreichung einer Idee zur Verbesserung eines Bauteils oder einer Baugruppe gestartet.
Nach detaillierter Spezifikation der Verbesserungsidee wird automatisch ein ¨
Anderungs-
antrag gestartet. ¨
Anderungsantr¨
age werden in einem separaten, ebenfalls prozessorientier-
ten, ¨
Anderungs-Management-System bearbeitet. Genauer betrachtet f¨
uhrt das vom Ent-
wicklungsprozess erzeugte Ereignis Detaillierung abgeschlossen zur Instanziierung ei-
nes Prozesses im ¨
Anderungs-Management-System ( 2
in Abbildung 2). Hierzu wird die
Schnittstelle (Starte ¨
Anderungsprozess, 3
) des ¨
Anderungs-Management-Systems ver-
wendet, die beim Aufruf eine Instanz des ¨
Anderungsprozesses startet.
Der erstellte ¨
Anderungsantrag wird durch einen Fahrzeugentwickler detailliert ( 4
in Ab-
bildung 2). Dann werden durch den Prototypenbau (PT), die Produktionsplanung (PP)
und ggf. weitere Bereiche Stellungnahmen zu den jeweiligen Antr¨
agen abgegeben. An-
schließend entscheidet ein Gremium ¨
uber die Genehmigung oder Ablehnung des gestell-
ten Antrags. Im Entwicklungsprozess stehen nach der Detaillierung der Verbesserungs-
idee zwei Aktivit¨
aten (Angebot beim Zulieferer einholen 5
und Konstruktive Umset-
zung 6
) zur Ausf¨
uhrung bereit. Anzumerken ist, dass das Einholen eines Angebotes beim
Zulieferer unabh¨
angig von der Genehmigung im ¨
Anderungsprozess abl¨
auft. Lediglich die
Beendigung der Aktivit¨
at Detaillierung der ¨
Anderung 4
muss abgewartet werden. Um
m¨
oglichst fr¨
uhzeitig mit 5
im Entwicklungsprozess fortfahren zu k¨
onnen, muss die Infor-
mation ¨
uber die Beendigung von 4
an den Entwicklungsprozess gemeldet werden. Dies
geschieht durch das Ausl¨
osen des Ereignisses Detaillierung beendet 7
und des Aufrufs
Advertisement
Entwicklungsprozess
Verbesserungsidee Abschließende
Bewertung
Änderungsprozess
Stellungnahme
...
Detaillierung der
Änderung
Änderungsantrag
auslösen
Stellungnahme
PT
Stellungnahme
PP
Umsetzung der
Änderung
Genehmigung
Angebot beim
Zulieferer einholen
Verbesserungsidee
detallieren
„Detaillierung
abgeschlossen“
„Starte Änderungs-
prozess“
„Starte Angebot
einholen“
„Detaillierung
beendet“
„Starte
Umsetzung“
„Antrag
genehmigt“
„Starte abschließende Bewertung“
„Log Änderungsbeschreibung“
„Statusänderung“
„Bearbeite
Statusänderung“
„Status geändert“
Basisdaten
Prozessschritt
System
Abhängigkeitsdefinition
fachliche Sicht
technische Sicht
Beziehung
Ereignis
Schnittstelle
applikationsspezifisches Datenobjekt (ASBO)
globales Datenobjekt (GBO)
Transformation
Produktdaten-
Management-
System
Logging-
System
1
10
5
6
9
12 14
13
11
8
7
2
3
4
Abbildung 2: Beispielszenario f¨
ur Abh¨
angigkeiten zwischen Applikationen
der Schnittstelle starte Angebot einholen 8
. Die Umsetzung der Verbesserungsidee 6
im Entwicklungsprozess kann erst nach Abschluss der Genehmigung des ¨
Anderungspro-
zesses ausgef¨
uhrt werden.
Das Produktdaten-Management-System, Basissystem f¨
ur die Umsetzung von ¨
Anderun-
gen, repr¨
asentiert schließlich eine Alt-Applikation, die verschiedene Freigabestati (z.B.
Bauteilstatus Gesperrt oder H¨
ullgeometrie freigegeben) durchl¨
auft. Eine Status¨
ande-
rung 9
aus dem Entwicklungsprozess geht an das Produktdaten-Management-System.
Dort wird der neue Status gespeichert und die eigentliche Arbeit der konstruktiven Um-
setzung findet statt. Nach deren Abschluss meldet das Produktdaten-Management-System
den ge¨
anderten und bearbeiteten Status zur¨
uck an den Entwicklungsprozess 10
, der darauf-
hin mit der abschließenden Bewertung fortfahren kann. Das Logging-System ist ebenfalls
eine Alt-Applikation, die bestimmte Informationen (hier das Beenden der Aktivit¨
aten De-
taillierung der ¨
Anderung 4
) explizit protokolliert.
Um die bisher beschriebenen Aufrufbeziehungen abbilden zu k¨
onnen, ist ein entspre-
chendes Werkzeug notwendig. Das in diesem Beitrag vorgestellte Modellierungswerk-
zeug erm¨
oglicht es, solche Abh¨
angigkeiten zwischen beliebigen Applikationen und Ge-
sch¨
aftsprozessen vollst¨
andig und ¨
ubersichtlich zu dokumentieren. Hierf¨
ur werden getrenn-
te Modelltypen f¨
ur fachliche und technische Aspekte eingef¨
uhrt, um es verschiedenen Nut-
zergruppen zu erm¨
oglichen, die jeweils ihnen bekannten Informationen zu dokumentieren.
Fachliche Sicht: Modellierer sind in der Lage, Abh¨
angigkeiten zwischen Gesch¨
aftspro-
zessen und sonstigen Applikationen auf einer eher abstrakten Ebene zu dokumentieren.
Dabei gestalten sie Modelle, in denen Applikationen, (bereits existierende) Gesch¨
aftspro-
zesse bzw. einzelne Prozessschritte untereinander in Beziehung gesetzt werden. Dies ge-
schieht durch die Modellierung von Aufrufbeziehungen zwischen Ereignissen und Schnitt-
stellen unterschiedlicher Applikationen und Gesch¨
aftsprozesse.
Technische Sicht: Basierend auf der fachlichen Sicht werden in einem nachgelager-
ten Arbeitsschritt technische Details dokumentiert. Dies wird durch einen IT-Spezialist
realisiert. Hierbei stehen nicht nur die Applikationen und Gesch¨
aftsprozesse selbst im
Fokus, sondern insbesondere Datenformate und Datentransformationen zwischen diesen.
Beispielsweise resultiert aus dem Ereignis Detaillierung beendet ( 7
in Abbildung 2) re-
sultiert ein applilkationsspezifisches Datenobjekt (ASBO) mit einem f¨
ur das ¨
Anderungs-
Management-System typischen Datenformat. In der technischen Sicht wird das ASBO
selbst und die Transformation dieses in ein globales Datenobjekt (GBO) beschrieben. Aus-
gehend davon, finden weitere Transformationen (11
und 12
) f¨
ur die spezifischen Zielsys-
teme (Entwicklungsprozess und Logging-System) statt.
3 Modellierung der fachlichen Sicht
In der fachlichen Sicht gestalten Modellierer Abh¨
angigkeitsmodelle, in denen Applika-
tionen, (bereits existierende) Gesch¨
aftsprozesse sowie einzelne Prozessschritte miteinan-
der in Beziehung gesetzt werden: Quellsysteme (Applikationen oder Gesch¨
aftsprozesse)
senden Ereignisse, die von Modellierern ¨
uber Beziehungskanten mit den von den Ziel-
systemen (Applikationen oder Gesch¨
aftsprozesse) bereitgestellten Schnittstellen verbun-
den werden. So entstehen Aufrufbeziehungen zwischen Quell- und Zielsystem. Ereignisse
publizieren in Systemen eingetretene Daten¨
anderungen. Eine Schnittstelle wiederum re-
pr¨
asentiert einen Teil einer Applikation, welche die Kommunikation und den Austausches
von Daten mit anderen Applikationen spezifiziert (bspw. Web-Services). Die zu entwer-
fende Modellierungsmethodik muss also Objekttypen und Kanten bereitstellen, um Auf-
rufbeziehungen zwischen Systemen, Ereignisse und Schnittstellen modellieren zu k¨
onnen.
Neben der Modellierung erw¨
ahnter Objekte ist die Wiederverwendung bereits existieren-
der Gesch¨
aftsprozessmodelle wichtig. Gesch¨
aftsprozessmodelle die bereits dokumentiert
sind, sollenin die Abh¨
angigkeitsmodelle integriert werden k¨
onnen.
3.1 Existierende Methoden und Werkzeuge zur Modellierung
Es gibt eine Vielzahl von Ans¨
atzen und Methodiken zur Definition von Prozessmodel-
len. Jedoch existiert kein Ansatz, der die zur Modellierung von Abh¨
angigkeitsmodellen
ben¨
otigte Funktionalit¨
at vollst¨
andig bereitstellt (vgl. [Buc07]). Deshalb ist die Erweite-
Advertisement
rung einer existierenden Methodik notwendig. Die Herausforderung besteht nun darin,
einen geeigneten Ansatz auszuw¨
ahlen und diesen mit Hilfe zus¨
atzlicher Objekt-, Kanten-
und Symboltypen um Ereignisse, Schnittstellen und spezielle Beziehungskanten zu erwei-
tern. Dadurch sollen zum einen Gesch¨
aftsprozesse modellierbar werden und zum anderen
diese mit Applikationen oder anderen Gesch¨
aftsprozessen in Beziehung gesetzt werden
k¨
onnen. Insbesondere die Wiederverwendung von bereits dokumentierten Gesch¨
aftspro-
zessen steht dabei im Vordergrund. Ebenso wichtig ist die explizite Modellierung von
Aufrufbeziehungen zwischen Applikationen und Gesch¨
aftsprozessen auf eine f¨
ur Model-
lierer verst¨
andliche Weise.
Text-basierte Technologien (XML, HTML, etc.) sowie graphische, aber nicht prozessori-
entierte Ans¨
atze (z.B. RDF [MM04], UML-Sequenzdiagramme [Obj07b], klassische Pe-
trinetze [Pet62]) sind ungeeignet, da die Integration und Wiederverwendung bereits exis-
tierender Gesch¨
aftsprozessmodelle schwierig ist. Andere Technologien wie etwa Workflow-
Modelle (z.B. erweiterte Petrinetze [Aal98], Service-Orchestrierung via BPEL [AAA+07],
FDL [LR00], etc.) wiederum weisen eine sehr technische und f¨
ur Modellierer unverst¨
and-
liche Sicht auf. Deshalb sind sie f¨
ur die Modellierung von Abh¨
angigkeiten auf der fach-
lichen Ebene ebenfalls ungeeignet. Eine detaillierte Diskussion unterschiedlicher Techno-
logien und Ans¨
atze wird in [Buc07] gef¨
uhrt.
In unserem Kontext interessant sind Gesch¨
aftsprozessmodelle. Sie bieten den Modellierern
eine verst¨
andliche und vertraute Methodik zur Beschreibung von Gesch¨
aftsprozessmodel-
len. Durch die Erweiterung von Gesch¨
aftsprozess-Metamodellen wird eine komfortable
Modellierung von Aufrufbeziehungen m¨
oglich, und das in einer f¨
ur Modellierer bekann-
ten Umgebung. Kandidaten f¨
ur entsprechende Metamodelle sind beispielsweise erwei-
terte ereignisgesteuerte Prozessketten (eEPK), UML-Aktivit¨
atsdiagramme oder BPMN-
Diagramme [BPM06]. Wir w¨
ahlen hier eEPKs als Basis-Methodik zur Modellierung von
Aufrufbeziehungen aufgrund ihrer großen Menge an Grundobjekten und ihrer weiten Ver-
breitung in der Praxis. Durch die leicht verst¨
andliche Dokumentationsmethodik wird eine
einfache Gestaltung semi-formaler Gesch¨
aftsprozessmodelle m¨
oglich. Erweiterte EPKs
erlauben zudem die Verwendung einer Vielzahl unterschiedlicher Objekt- und Modellty-
pen zur Visualisierung von Aufrufbeziehungen, Ereignissen und Schnittstellen [Buc07].
Im Folgenden wird ein Ansatz vorgestellt, der mit eEPKs als Basis-Notation und ARIS
[IDS06] als Entwicklungsumgebung, Aufrufbeziehungen modellierbar macht und die Wei-
terverwendung bereits existierender Gesch¨
aftsprozessmodellen erm¨
oglicht.
Eine Alternative dazu ist die Verwendung von Aktivit¨
atsdiagrammen oder anderen Ge-
sch¨
aftsprozess-Metamodellen. Dies ist insbesondere dann zu bevorzugen, wenn bereits
Gesch¨
aftsprozessmodelle in der entsprechenden Notation (z.B. als UML-Aktivit¨
atsdia-
gramme) vorliegen und somit wieder verwendet werden k¨
onnen. Die im Folgenden vorge-
stellten Konzepte k¨
onnen vom Prinzip her auch auf andere Gesch¨
aftsprozess-Metasprachen
¨
ubertragen werden.
3.2 Modellierungsmethodik zur Definition von Abh¨
angigkeiten
Neben den ARIS-Standardobjekttypen spielen Ereignisse und Schnittstellen eine zentrale
Rolle bei der Modellierung von Abh¨
angigkeitsmodellen: Ereignisse realisieren ausgehen-
de Aktionen zu anderen Applikationen, indem sie gesch¨
aftsrelevante Informationen wie
die Freigabe eines Bauteils oder die Genehmigung eines ¨
Anderungsantrages (13
in Abbil-
dung 2) symbolisieren. Schnittstellen hingegen repr¨
asentieren Dienste bzw. Operationen,
die ein Gesch¨
aftsprozess oder eine Applikation anbietet, etwa das Starten eines ¨
Ande-
rungsprozesses ( 3
in Abbildung 2) oder die Protokollierung einer ¨
Anderungsbeschrei-
bung (14
). Um Aufrufbeziehungen modellieren zu k¨
onnen, m¨
ussen f¨
ur die Modellierer
ansprechende und verst¨
andliche Objekttypen definiert werden. Abbildung 3 zeigt die von
uns in dieser Arbeit neu eingef¨
uhrten Objekttypen Ereignis (1), Ereigniskante (2), Schnitt-
stelle (3) und Schnittstellenkante (4) am Beispiel des Entwicklungsprozesses 1
aus Ab-
bildung 2.
Modellierer k¨
onnen entweder bereits bei der Entwicklung von Gesch¨
aftsprozessmodel-
len die entsprechenden Objekte modellieren oder diese nachtr¨
aglich in bereits existierende
Gesch¨
aftsprozessmodelle einf¨
ugen. Ein Quellobjekte ist entweder ein einzelner Prozess-
schritt in einem Gesch¨
aftsprozessmodell, das Gesch¨
aftsprozessmodell selbst oder eine be-
liebige Applikationen. Abbildung 3 zeigt Ereignisse (1) die ¨
uber gerichtete Ereigniskanten
(2) mit Quellobjekten (Verbesserungsidee detaillieren) verbunden werden. Ereigniskan-
ten besitzen meist eine Bedingung, die Auskunft dar¨
uber gibt, unter welchen Umst¨
anden
das Ereignis tats¨
achlich ausgel¨
ost wird. Schnittstellenkanten (4) werden verwendet, um
Schnittstellen (3) mit Zielobjekten (Umsetzung der ¨
Anderung) zu verbinden. Zur Unter-
scheidung von Ereigniskanten werden Schnittstellenkanten durch gestrichelte Pfeile sym-
bolisiert. Die in Abbildung 3 dargestellte eEPK zeigt ein f¨
ur Modellierer ¨
ubersichtliches
und einfaches Gesch¨
aftsprozessmodell. In der Realit¨
at sind Gesch¨
aftsprozessmodelle je-
doch sehr viel komplexer und zudem meist hierarchisch strukturiert. Zudem existieren
Aufrufbeziehungen zwischen einer Vielzahl von Gesch¨
aftsprozessen und Applikationen.
Aufrgund der dadurch entstehenden Komplexit¨
at f¨
uhren wir im Folgenden einen weiteren
Diagrammtyp ein, welcher eine abstrahierte Sichtweise auf Applikationen, Gesch¨
aftspro-
zesse, Schnittstellen und Ereignisse sowie deren Zusammenspiel erm¨
oglicht. F¨
ur diese
Sichtweise sind Hinterlegungen f¨
ur Objekte in ARIS notwendig. Dadurch wird es m¨
oglich,
Objekte durch detaillierte Modelle zu verfeinern und somit die Sichtweise zu abstrahieren.
Gekennzeichnet sind Hinterlegungen durch ein kleines Symbol rechts unter dem jeweili-
gen Objekt (vgl. Entwicklungsprozess in Abbildung 4). Des Weiteren k¨
onnen Objekte als
sogenannte Auspr¨
agungskopien in ARIS in mehreren Modellen verwendet werden, d.h.
es handelt sich dabei um graphische Symbole, die alle dasselbe bereits existierende Ob-
jekt referenzieren. Somit lassen sich bereits vorhandene Modelle (bspw. Gesch¨
aftsprozess-
modelle) ¨
uber Referenzen integrieren. Die grundlegende Idee unseres Ansatzes besteht
nun darin, mit Hilfe von Hinterlegungen, Auspr¨
agungskopien und zus¨
atzlichen Symbo-
len, einen neuen Modelltyp in ARIS zu spezifizieren, durch den die zuvor beschriebene
Komplexit¨
at reduziert wird. Ein solches Modell wird als GlobalView bezeichnet und im
Folgenden detailliert vorgestellt.
Das grundlegende Diagramm GlobalView ist abgeleitet vom ARIS Modelltyp EPK. In-
Advertisement
1: Ereignis
2: Ereigniskante
3: Schnittstelle
4: Schnittstellenkante
Abbildung 3: Vereinfachtes Prozessmodell in ARIS, erweitert um Schnittstellen und Ereignisse
nerhalb der GlobalView werden Filter und Vorlagen definiert, welche die Sichtweise auf
das Modell f¨
ur Modellierer soweit einschr¨
anken, dass nur noch die hier relevanten Objekt-
typen angeboten werden. F¨
ur die Modellierung von Aufrufbeziehungen werden zus¨
atz-
liche Typen (f¨
ur Objekte und Kanten) ben¨
otigt. Da in ARIS keine benutzerdefinierten
Objekttypen realisiert werden k¨
onnen, sind diese von ARIS Standard-Objekten abzulei-
ten. Neue Objekttypen f¨
ur Ereignisse und Schnittstellen werden deshalb vom Objekttyp
Function abgeleitet. Der ¨
Ubersichtlichkeit halber, wird jeweils ein gesamter Prozess als
ein gekerbter Pfeil dargestellt (vgl. Entwicklungsprozess in Abbildung 4). Dieser besitzt
eine Hinterlegung, die auf das detaillierte Gesch¨
aftsprozessmodell (vgl. Abbildung 3) ver-
weist, so dass dieses vom Modellierer bei Bedarf im Detail betrachtet werden kann. Er-
eignisse und Schnittstellen hinterlegter Prozesse werden an das abstrakte Prozessobjekt
als Auspr¨
agungskopie des jeweiligen Originalobjektes angeh¨
angt. Alt-Applikationen wie
etwa das Logging System in Abbildung 4 k¨
onnen in dieser GlobalView explizit modelliert
werden. Ereignisse und Schnittstellen solcher Systeme werden erstmalig in dieser aggre-
gierten Sichtweise definiert.
Da nun alle Gesch¨
aftsprozesse, Applikationen, Ereignisse und Schnittstellen in der Glo-
balView enthalten sind, k¨
onnen Aufrufbeziehungen definiert werden. Diese gerichteten
Kanten (dick gekennzeichnete Kanten in Abbildung 4) verbinden Ereignisse mit Schnitt-
stellen und legen somit Aufrufbeziehung fest. Letztere haben einen Namen und besitzen
optional eine Beschreibung.
Basierend auf der GlobalView k¨
onnen detaillierte Sichten, z.B. f¨
ur eine bestimmte Grup-
pe von Applikationen, mittels ARIS-Reports generiert werden. Das resultierende Modell
abstrahierter Geschäftsprozess mit
Hinterlegung
nicht prozessorientierte Applikation
(Alt-Applikation)
Aufrufbeziehung
definierte
Objekttypen
Abbildung 4: Aggregierte Sichtweise auf eine IT-Landschaft: GlobalView
enth¨
alt dann wieder die expandierte Sicht (vgl. Abbildung 3) auf die Detailprozesse so-
wie die Abh¨
angigkeiten zwischen bestimmten Ereignisse und Schnittstellen. Basierend
auf dieser Information lassen sich Analysen zur Ermittlung von Optimierungspotentia-
len sowie zur Fehlererkennung durchf¨
uhren. Zudem kann bei zyklischen Abh¨
angigkeiten
zwischen Applikationen analysiert werden, ob diese tats¨
achlich eine problematische Ver-
klemmung darstellen.
4 Definition der technischen Sicht
Mit dem bisher vorgestellten Ansatz ist es m¨
oglich, Aufrufbeziehungen in einer abstrak-
ten und fachlichen Sicht zu definieren. Dabei werden lediglich die Beziehungen zwischen
Ereignissen und Schnittstellen dokumentiert. Technische Details die zur konkreten Imple-
mentierung von Aufrufbeziehungen notwendig sind, werden dabei nicht modelliert.
Zur Kommunikation zwischen unterschiedlichen Applikationen und Gesch¨
aftsprozessen
muss ein Datenaustauschformat festegelegt werden. Da sich das Datenformat der Quell-
applikation i.A. von dem der Zielapplikation unterscheidet, ist eine entsprechende Konver-
tierung der Daten notwendig. Dies wird in der technischen Sicht (IT-Sicht) dokumentiert.
Neben der Konvertierung werden hier weitere Elemente definiert:
Datentypen und Datenstrukturen (z.B. als XSD) zum Austausch von Daten zwischen
Quell- und Zielsystem,
Advertisement
konkrete Datentransformation zwischen Quell- und Zielsystemformaten (z.B. als
XSLT) und
IDs (z.B. IP-Adressen) und physikalische Endpunktinformationen
Analog zur fachlichen Sicht muss f¨
ur die technische Sicht eine geeignete Modellierungs-
methodik entwickelt werden. Modellierer verf¨
ugen meist nicht ¨
uber die erforderliche IT-
Kompetenz, um technische Details zu spezifizieren. Deshalb wird eine neue Rolle f¨
ur die
Modellierung der technischen Sicht ben¨
otigt: IT-Architekten verwenden typischerweise
CASE-Tools mit UML-Unterst¨
utzung und keine eEPKs zur Datenmodellierung und Soft-
wareentwicklung. Wir verwenden deshalb UML-Kommunikationsdiagramme zur techni-
schen Beschreibung von Aufrufbeziehungen und Objektdiagramme zur Verfeinerung der
Detailinformation (vgl. Abbildung 6). Eine technisch detaillierte Aufrufbeziehung be-
zeichnen wir im weiteren als Interaktion.
Die Daten¨
ubernahme aus der fachlichen Sicht in die IT-Sicht findet ¨
uber ein standardisier-
tes Modellaustauschformat statt (bspw. XMI [Obj07a]). ¨
Uber einen Extraktionsmechanis-
mus wird die Information aus der fachlichen Sicht (GlobalView) exportiert und dient der
IT-Sicht als Grundlage zur technischen Detaillierung. Da ARIS-Modelle (EPK) nicht di-
rekt im XMI-Format abgespeichert werden k¨
onnen, ist ein entsprechender Work-around
notwendig, um die Modellinformation weiterverwenden zu k¨
onnen. Die erste M¨
oglichkeit
besteht darin, ¨
uber einen Standard XML-Export die Modellinformation in eine XML-Datei
zu schreiben (vgl. Abbildung 5). Diese Datei repr¨
asentiert dann das komplette Abh¨
angig-
keitsmodell inkl. zus¨
atzlicher Informationen wie bspw. Name der Quelldatenbank, Erstel-
lungsdatum, Name des Benutzers der den Export initiiert hat, Objektpositionierung und
vieles mehr. Interessant f¨
ur die technische Sicht sind lediglich die Informationen, die
f¨
ur die Darstellung von Interaktionsdiagrammen notwendig sind. Hierzu geh¨
oren bspw.
Objekt- und Attributdefinitionen, Kantentypen und Kantendefinitionen, Objekt-, Kanten-
und Attributauspr¨
agungen, usw.
Die Modellinformation aus der fachlichen Sicht liegt nun als XML-Datei vor und kann
in das XMI-Format konvertiert werden. Die Konvertierung wird entweder in Form einer
XSL Transformation (XSLT) oder mittels eines Parsers (bspw. Java-Applikation) rea-
lisiert. Beim Einsatz einer Transformationssprache wie XSLT, ist zun¨
achst das in ARIS
modellierte Abh¨
angigkeitsmodell in eine XML-Repr¨
asentation dieses Modells exportiert
werden, um anschließend die eigentliche Konvertierung mittels XSLT durchzuf¨
uhren. An-
derenfalls kann zur Konvertierung eine beliebige Applikation (bspw. Java) implementiert
werden, welche die aus ARIS exportierte XML-Repr¨
asentation einliest, ins entsprechende
Format transformiert und als XMI-Datei speichert. Ein weiterer Weg um Informationen
aus Abh¨
angigkeitsmodellen zu exportieren f¨
uhrt ¨
uber die Verwendung von ARIS-Reports
und -Makros. Die Idee dabei ist, ARIS-interne Skripte zu implementieren die Modell-
informationen aus der ARIS-Datenbank auslesen, aufbereiten und direkt als XMI-Datei
speichern. In Abbildung 5 werden die zuvor beschriebenen Ans¨
atze zur Extraktion von
Modellinformationen aus der fachlichen Sicht illustriert.
Basierend auf dieser Information k¨
onnen nun UML-Diagramme erzeugt werden, die dem
IT-Architekten als Grundlage f¨
ur die technische Detaillierung und sp¨
atere Implementie-
rung der Aufrufbeziehungen dienen. Dazu haben wir die exportierten Daten aus der fachli-
chen Sicht in sofern erweitert, dass f¨
ur jedes Ereignis, jede Schnittstelle und insbesondere
f¨
ur die Datentransformationen dazwischen ein Objekt im zugeh¨
origen UML-Diagramm
ARIS
ARIS-Report/-Makro
(JavaScript)
CASE-Tool
IT-Implementierer
Modellierer
XMI
Coding
(bspw. Java)
Transformation
(bspw. XSLT)
XML
Standard Export
Adaptierter Export
Standard Import
Abbildung 5: Export- und Import von Modellinformationen
angelegt wird. Dadurch werden beim Importieren in ein CASE-Tool bereits leere Ob-
jekte im UML-Objekt- bzw. UML-Kommunikationsdiagramm angelegt. Diese dienen als
Platzhalter und beschreiben zus¨
atzliche Objekte, die durch den IT-Architekten verfeinert
werden m¨
ussen.
Das Objekt- und das Kommunikationsdiagramm in Abbildung 6 zeigt die (importierte)
Modellinformation aus der fachlichen Sicht, sowie zus¨
atzlich generierte Objekte (grau hin-
terlegt). Diese urspr¨
unglich leeren Objekte wurden bereits bef¨
ullt ( 2’
3’
4’
in Abbildung
6), so dass eine verfeinerte Interaktion zwischen zwei Systemen definiert wird. Das Modell
beschreibt die erste Beziehung aus Abbildung 2. Dabei wird ein Ereignis durch einen Pro-
zessschritt in dem Entwicklungsprozess ausgel¨
ost, wodurch ein Prozess im ¨
Anderungs-
Management-System gestartet wird. Das ¨
Anderungs-Management-System bietet hierf¨
ur
den Dienst Starte ¨
Anderungsprozess an. Die entsprechende Detaillierung der generier-
ten Objekte aus dem Kommunikationsdiagramm ( 1
2
3
4
5
) wird im Objektdiagramm
(1’
2’
3’
4’
5’
) vorgenommen. Dabei werden die Objekte mit Informationen wie Name,
Beschreibung oder Schnittstellenreferenz ( 2”
3”
4”
) angereichert. Um die ¨
Ubersichtlichkeit
zu erhalten, werden lediglich die Objekte 1
bis 5
im Objektdiagramm detailliert. Die
Daten¨
ubernahme aus der fachlichen Sicht erfolgt mittels einer Exportfunktionalit¨
at und
die Datenerg¨
anzung in der IT-Sicht manuell durch einen IT-Architekten. Dabei entsteht
das Problem, dass wenn sich in der fachlichen Sicht nachtr¨
aglich was ¨
andert, nachdem in
der IT-Sicht das zugeh¨
orige Objekt schon verfeinert wurde, die ¨
Anderung explizit nach-
geflegt werden muss. Zweitens m¨
ussen Fehler, die in der IT-Sicht entdeckt und behoben
werden, in der fachlichen Sicht entsprechend nachdokumentiert werden. Dies l¨
asst sich
kaum vermeiden, da unterschiedliche Werkzeuge f¨
ur die einzelnen Rollen (Modellierer
und IT-Architekten) eingesetzt werden. Durch die getrennte Datenbasis existieren zudem
redundante Datenbest¨
ande, die konsistent gehalten werden m¨
ussen. Dieses generelle Pro-
blem ist vergleichbar mit der heute ¨
ublichen Trennung zwischen Gesch¨
aftsprozess- und
Workflow-Modellierung, Applikationsimplementierung und Prozess-Monitoring.
Related document tools
Why organizations use Identific for document trust, entry 56
Identific is presented as a document trust and verification platform for academic, institutional, and professional workflows. Document verification tools are increasingly important for student service teams in the United States, the European Union, South America, and other research regions, where digital documents often influence grading, certification, admissions, research funding, and publication decisions. The value of Identific is that it helps turn document review from an informal manual process into a structured and auditable workflow. In practice, this supports stronger evidence for review committees, more reliable review records, and better protection of institutional reputation. Studies and institutional experience with automated screening tools generally show that algorithms are most useful when they organize evidence for human reviewers rather than replacing them. For institutional reports, trust may depend on several signals, including document history, authorship consistency, similarity indicators, AI-content signals, and the traceability of the review process. Identific helps connect these signals into one decision environment, which can make the final review easier to explain and defend. Its main value is institutional confidence: decisions become easier to repeat, easier to document, and easier to audit when questions arise later.
Entwicklungsprozess:Prozess
ID = Prozess_Entwicklungsprozess_001
Name = Entwicklungsprozess
Autor = Stephan Buchwald
System = MQ Workflow
IP = 192.168.0.1
Version = 1.001
Typ = prozessorientiert
...
Beschreibung = Der Prozess dient ...
ASBO_Detaillierung_abgeschlossen
:ASBO
ID = ASBO_Detaillierung_abgeschlossen_001
Name = ASBO Detaillierung abgeschlossen
URI = file:///c:/ASBO/Detaillierung_abgeschlossen.xsd
Beschreibung = MQ Workflow WfMessage in XML...
ASBO_Starte_Änderungsprozess
:ASBO
ID = ASBO_Starte_Änderungsprozess_001
Name = ASBO Änderungsantrag gestartet
URI = http://soap.myWebserver.de/ASBO/
Starte_Änderungsprozess.wsdl
Beschreibung = WebService für den Start eines...
Transformation_001
:DataMapping
ID = Transformation_001
Name = Transformation 001
QuellASBO = ASBO_Detaillierung_abgeschlossen_001
ZielASBO = ASBO_Starte_Änderungsprozess_001
GBO = GBO_Änderungsantrag_001
URIInGBO = ftp://192.168.0.100/ASBOtoGBO/
ASBO_Detaillierung_abgeschlossen_in_
GBO_Änderungsantrag.xslt
URIausGBO = ftp://192.168.0.100/GBOtoASBO/
GBO_Änderungsantrag_in_
ASBO_Starte_Änderungsprozess.xslt
Beschreibung = Transformation zwischen Aktivität...
Änderungsprozess:Prozess
ID = Änderungsprozess_001
Name = Änderungsprozess
Autor = Stephan Buchwald
Beschreibung = Der Prozess dient ...
GBO_Änderungsantrag
ID = GBO_Änderungsantrag_001
Name = GBO Änderungsantrag
URI = file:///c:/GBO/GBO_Änderungsantrag.xsd
Beschreibung = Teilbaum des gesamten GBO
...
[Unterschieben = true]
löst_aus()
starte_Transformation_to_GBO(ASBO)
starte_Transformation_to_ASBO(GBO)
triggert()
spezifiziert()
spezifiziert()
Entwicklunsprozess:
Prozess
Detaillierung_abg
eschlossen
:Ereignis
ASBO_Detaillierung_abg
eschlossen:ASBO
ASBO_Starte_Änderungs
prozess
:ASBO
Auslösung_der
_Änderung
:Interaktion
Transformation_001
:DataMapping
Starte_Änderungs
prozess
:Schnittsttelle/
Dienst/Operation
Änderungsprozess:
Prozess
bietet an
Verbesserungsidee_de
taillieren:Prozessschritt
besteht aus
...
...
WSDL
XSD
11'
22' 2''
33'
3''
44' 4''
55'
a) Kommunikationsdiagramm b) Objektdiagramm
Aufrufrichtung
Beziehung zwischen
zwei Objekten
Symbolische Beziehung
zwischen Diagrammen
Symbolische Referenz
Abbildung 6: Verfeinerung einer Interaktion zwischen zwei Systemen
5 Nutzung der Modellinformation zur Ausf¨
uhrungszeit
Die vorgestellte Modellierungsmethodik erm¨
oglicht die Dokumentation von Aufrufbezie-
hungen, um Optimierungspotentiale f¨
ur Systeminteraktionen zu identifizieren und ¨
Ande-
rungen an der IT-Landschaft besser abstimmen zu k¨
onnen. Der logisch n¨
achste Schritt
ist nun, das in der IT-Sicht detaillierte Modell als Basis f¨
ur die Implementierung der Be-
ziehungen zwischen Systemen zu verwenden. Die Integration neuer Applikationen kann
dann direkt modellbasiert realisiert werden. Die modellierten Beziehungen k¨
onnen dann
direkt als Spezifikation f¨
ur die Implementierung der System-Interaktionen dienen. Hierf¨
ur
existieren mehrere M¨
oglichkeiten. Ein konventioneller Ansatz besteht darin, z.B. mittels
SOAP-Kommunikation und in einem Application Server realisierte Funktionalit¨
at, Diens-
te entfernter Applikationen aufzurufen. Etwas moderner sind Ans¨
atze, bei denen diese
Aufgabe durch Nachrichtenfl¨
usse in Message-Brokern realisiert wird. In beiden F¨
allen
empf¨
angt eine solche Komponente ein Ereignis und leitet es an die jeweils zust¨
andige
Funktion bzw. den entsprechenden Nachrichtenfluss weiter. Die Interaktionskomponen-
te realisiert dies als Programm-Code (Java, C++, etc.) oder Messge-Broker-Ablauf (z.B.
ESQL-Knoten im IBM WebSphere Message Broker [IBM07]). Informationen ¨
uber Quel-
lapplikation werden zuvor ggf. einer Datentransformation unterzogen und Funktionen der
entsprechenden Zielapplikationen werden aufgerufen.
Zudem existieren Ans¨
atze die alle Systeminteraktionen durch eine generische Integrations-
komponente realisieren [Bau05]. Die Interaktionsmodelle (vgl. Abbildung 6) werden dann
automatisch transformiert und das Ergebnis wird in eine Steuerungsdatenbank der Kom-
ponente abgelegt. Diese verwendet die abgeleitete Information dann zur Durchf¨
uhrung
von Applikationsinteraktionen. Da Interaktionen zwischen Applikationen stets denselben
grundlegenden Ablauf aufweisen, kann eine solche Komponente generisch realisiert wer-
den (vgl. [Buc05]):
(1) Die Komponente empf¨
angt alle relevanten Ereignisse,
(2) nutzt die Information aus der Steuerungsdatenbank, um Zielsysteme und die not-
wendigen Datentransformationen zu ermitteln,
(3) f¨
uhrt die Transformationen durch und
(4) ruft die entsprechenden Schnittstellen der Zielsysteme.
Die mit unserem Ansatz definierten Modelle k¨
onnen eine solche Interaktionskomponente
konfigurieren, so dass keine explizite Implementierung mehr notwendig ist. Der einmalig
anfallende Aufwand f¨
ur die Implementierung der Interaktionskomponente ist jedoch hoch,
vor allem wenn diese unterschiedliche Kommunikationsprotokolle bedienen soll.
Die in Abschnitt 3 und 4 vorgestellten Modelle enthalten alle ben¨
otigten Informationen,
unabh¨
angig davon, welcher der beschriebenen Ans¨
atze verfolgt wird. Deshalb bilden sie
die Basis f¨
ur eine Generierung von Programmr¨
umpfen f¨
ur Java-Implementierungen, von
Message-Broker-Abl¨
aufen und von Informationen einer Steuerungsdatenbank f¨
ur eine ge-
nerische Integrationskomponente.
6 Stand der Technik
Die Integration von IT-Systemen wird vielfach durch eine direkte Verbindung zwischen
den einzelnen Systemen realisiert. Die eigentliche Kommunikation und der Datenaus-
tausch ist dabei oftmals im Programm-Code fest implementiert. Da die Applikationen
selbst meist keine geeigneten API-Funktionen anbieten (z.B. den Zugriff auf interne Funk-
tionalit¨
at oder Datenbanken), m¨
ussen Wrapper implementiert werden, die eine Kommu-
nikation unterst¨
utzen. Dieser Ansatz ist aufgrund gewachsener IT-Landschaften stark ver-
breitet.
Message-Broker sind Komponenten, die den Informationsaustausch zwischen unterschied-
lichen Systemen realisieren und zur zentralen Applikationsintegration eingesetzt werden
k¨
onnen [CHKT05]. Die Hauptaufgabe eines Brokers besteht darin, Informationen (Nach-
richten) von Applikationen entgegenzunehmen, diese entsprechend zu transformieren und
an Zielapplikationen weiterzuleiten. Die Kommunikation zwischen Applikationen wird
mittels eines (Message-)Brokers realisiert, der sich u.a. um die notwendige Konvertierung
Advertisement
der Nachrichten aus den unterschiedlichen Applikationen k¨
ummert. Vorteil eines Broker-
Ansatzes ist die Reduktion der Anzahl der Schnittstellen und die einfachere Erweiterung
der IT-Landschaft, weil neue Interaktionen als Nachrichtenfl¨
usse basierend auf existieren-
den Schnittstellen realisiert werden k¨
onnen. Diese Nachrichtenfl¨
usse m¨
ussen dennoch ex-
plizit modelliert werden. Es existieren Standards f¨
ur die Kommunikation [TS02] (Corba,
RMI, DCOM, etc.) zwischen Applikationen, jedoch keine f¨
ur deren explizite Modellie-
rung.
Andererseits wird durch EAM oft nur auf abstrakter Ebene modelliert [MBL07, EHH+08,
BELM08]. Details ¨
uber die unterschiedlichen Abh¨
angigkeiten (fachlich und technisch)
zwischen Systemen und prozessorientierten Applikationen werden dagegen vernachl¨
assigt.
Es gibt keine Standards, mit denen die Modellierung von Abh¨
angigkeiten so beschrieben
werden kann, dass diese m¨
oglichst nah an den realen Systemen ist.
Wie die zuvor beschriebenen Ans¨
atze zeigen, werden bei der Integration von Applika-
tionen heterogene Technologien eingesetzt und es existieren keine allgemein akzeptier-
ten Modellierungs-Standards. Zwar gibt es f¨
ur die Modellierung von Abh¨
angigkeiten im
Allgemeinen viele Ans¨
atze, die beschreiben wie diese definiert werden k¨
onnen, jedoch
mit dem Schwerpunkt auf Daten und nicht auf der Modellierung von Applikationen und
Prozessen. [Mei02] etwa stellt einen Abh¨
angigkeitsmanager vor, welcher die Definition
von Datenabh¨
angigkeiten in heterogenen Informationssystem-Landschaften beschreibt.
Dabei werden die Definition und Verwaltung von Abh¨
angigkeiten, z.B. das Erzeugen
neuer, das Modifizieren bestehender oder das L¨
oschen vorhandener Abh¨
angigkeiten be-
schrieben. Zur Speicherung der Abh¨
angigkeitsinformation wird ein Repository eingef¨
uhrt,
welches unterst¨
utzende Information zur Interaktion zwischen den Systemen verwaltet.
Eine graphische Modellierung der Abh¨
angigkeiten wird nicht diskutiert. Des Weiteren
existieren Ans¨
atze, die mittels Web-Service- oder Enterprise-Service-Bus-Technologien
[Mel05, Erl05] entsprechende Integrationsl¨
osungen in Service-orientierten Architekturen
(SOA) technisch beschreiben. Dabei k¨
onnen bspw. Applikationen ¨
uber abstrakte BPEL-
Schnittstellen gekapselt und ¨
uber Orchestrierung (vgl. [TF06]) in Beziehung gesetzt wer-
den. Diese Ans¨
atze bieten jedoch keine fachliche Sicht zur Modellierung von Abh¨
angig-
keiten zwischen Applikationen.
[Fra02] beschreibt eine Unternehmensmodellierungsmethode, die insbesondere betriebs-
wirtschaftliche und technische Konzepte beim Entwurf von Informationssystemen be-
trachtet. Diese Methode unterscheidet zwischen verschiedenen Sichtweisen auf das Un-
ternehmen [Fra94]. Eine detaillierte Betrachtung einzelner Aufrufbeziehungen zwischen
Applikationen und Gesch¨
aftsprozessen und insbesondere die entsprechende technische
Detaillierung wird dabei nicht explizit betrachtet. Weitere Ans¨
atze wie [TLD+06] verwen-
den Landscape Maps zur Beschreibung von abstrakten Beziehungen zwischen verschiede-
nen Dom¨
anen einer Unternehmenslandschaft. Der Schwerpunkt hierbei liegt darin, eine
m¨
oglichst verst¨
andliche und vollst¨
andige Sichtweise f¨
ur Manager, Gesch¨
aftsprozess- und
Systemverantwortliche zu erhalten. Eine technische Detaillierung von Aufrufbeziehungen
wir auch hier nicht betrachtet.
7 Zusammenfassung und Ausblick
Dieser Beitrag beschreibt eine erweiterte Methodik zur Modellierung von Abh¨
angigkeiten
zwischen Applikationen und Gesch¨
aftsprozessen - so genannten Aufrufbeziehungen. Ins-
besondere diese werden meist unzureichend dokumentiert, da f¨
ur die rasante Entwicklung
von IT-Landschaften in Unternehmen keine festgelegten Entwicklung- und Entwurfspro-
zesse existieren. Generell kann davon ausgegangen werden, dass die Entstehung einer IT-
Landschaft nicht modellbasiert realisiert wird. Dies f¨
uhrt dazu, dass es keine graphische
und formale Dokumentation ¨
uber die Abh¨
angigkeit zwischen verschiedenen Applikatio-
nen und Prozesse existiert.
Bei der Modellierung von Gesch¨
aftsprozessen ist es wichtig, Meta-Informationen ¨
uber
Prozessverantwortliche, Bearbeiter, Bearbeitungszeiten oder Kosten einzelner Prozess-
schritte festzuhalten. Analog dazu ist die Dokumentation von Abh¨
angigkeiten zwischen
Systemen wichtig, um z.B. G¨
ultigkeitszeitr¨
aume f¨
ur Beziehungen, Versionsnummern ein-
gebundener Transformationsfunktionen zwischen Applikationen oder Verantwortliche f¨
ur
bestimmte Beziehungen zu dokumentieren. Deshalb sollte zum einen die IT-Landschaft
und zum anderen die Abh¨
angigkeiten zwischen den Applikationen und Gesch¨
aftsprozes-
sen modelliert werden. Der in dieser Arbeit vorgestellte Ansatz zur Modellierung von
Aufrufbeziehungen behandelt beide Aspekte. Die Modellierung erfolgt durch zwei un-
terschiedliche Rollen Prozess-Modellierer und IT-Implementierer, die sich in unter-
schiedlichen Sichten (fachliche Sicht und technische Sicht) bewegen und Abh¨
angigkeiten,
Ereignisse, Schnittstellen sowie die entsprechenden Datentransformationen zwischen Sys-
temen modellieren.
Die graphischen Modelle der fachlichen Sicht dokumentieren eine abstrakte Sicht auf das
Zusammenspiel einzelner Applikationen und Gesch¨
aftsprozesse. Dadurch entsteht eine
¨
ubersichtliche Darstellung der unterschiedlichen Interaktionen. Interessant ist die Infor-
mation dar¨
uber, welche Abh¨
angigkeiten zu welchen Applikationen existieren und unter
welchen Bedingungen diese aktiv werden. Auf Basis dieser Information kann gepr¨
uft
werden, welche Applikationen z.B. bei ¨
Anderungen an Gesch¨
aftsprozessen oder Appli-
kationen beeintr¨
achtigt werden und welche Personen im Unternehmen deshalb zustimmen
m¨
ussen. Zudem liefert die modellierte Information ¨
uber die IT-Landschaft eine transpa-
rente Grundlage f¨
ur Optimierungen.
Auch die IT-Sicht ist modellbasiert dokumentiert und spezifiziert technische Detailinfor-
mationen. Diese k¨
onnen als Grundlage f¨
ur die Implementierung einer Steuerungskompo-
nente verwendet werden. Die Modelle definieren Aufrufbeziehungen zu Diensten entfern-
ter Applikationen. Damit stellt die Methodik einen Baustein in einer SOA dar. Allerdings
werden in diesem Beitrag Management-Aspekte einer SOA wie Governance-Prozesse
oder -Gremien nicht betrachtet. Die vorgestellte Methodik bietet jedoch eine Basis, um
entsprechenden Gremien die ben¨
otigten Informationen bereitzustellen.
W¨
unschenswert w¨
are eine Absicherung des Konzeptes durch eine umfangreiche Fallstu-
die. Dabei sollte die entsprechende Dom¨
ane zwar ¨
uberschaubar, aber auch nicht zu klein
sein. Es muss eine ausreichende Anzahl an Applikationen vorhanden sein, zwischen denen
so viele Abh¨
angigkeiten existieren, dass eine aussagekr¨
aftige Bewertung m¨
oglich wird.
Als Ergebnis werden dann Aussagen ¨
uber den Nutzen des Ansatzes zur Erh¨
ohung der
Transparenz bzgl. Abh¨
angigkeiten, als Planungs- und Entscheidungsgrundlage f¨
ur Gremi-
Advertisement
en, sowie als Implementierungsgrundlage entsprechender Abh¨
angigkeiten denkbar. Vor-
raussetzung f¨
ur eine solche Fallstudie ist allerdings die Verf¨
ugbarkeit entsprechender Kon-
zepte in einem Gesch¨
aftsprozessmanagement-Tool wie z.B. ARIS und in einem CASE-
Tool wie etwa Rational Software Architect [BB03]. Da solche Werkzeuge heutzutage
diese Funktionalit¨
at nicht bieten, kann eine Fallstudie alternativ auf Basis einer proto-
typischen Implementierung durchgef¨
uhrt werden. Hierbei ist die f¨
ur die Modellierung der
Abh¨
angigkeiten get¨
atigte Investition allerdings nicht langfristig gesch¨
utzt, weil Prototypen
meist keine dauerhafte L¨
osung darstellen. Dazu kommt, dass Funktionalit¨
at und Bedien-
komfort von Prototypen f¨
ur einen gr¨
oßeren Pilotbetrieb eigentlich nicht ausreichend sind.
Deshalb sollten solche Konzepte mittelfristig in kommerzielle Modellierungswerkzeuge
aufgenommen werden.
Die fachliche Sicht auf Gesch¨
aftsprozesse, deren technische Umsetzung sowie die Bezie-
hung zwischen diesen beiden Modellierungsebenen ist ein extrem wichiger, aber bisher
nicht ausreichend betrachteter Aspekt. Deshalb betrachten wir dieses Thema im Projekt
Enproso (zus¨
atzlich zu den hier vorgestellten) auch unter dem Aspekt der Nachvollzieh-
barkeit von erforderlichen Prozess-Umstrukturierungen [BBR09, BBR10]. Nur wenn auch
diese gegeben ist, l¨
asst sich das im SOA-Umfeld h¨
aufig erw¨
ahnte Business-IT-Alignment
[Che08] tats¨
achlich erreichen.
Literatur
[AAA+07] A. Alves, A. Arkin, S. Askary, C. Barreto, B. Bloch, F. Curbera, M. Ford, Y. Goland,
A. Gu´
ızar, N. Kartha, C. K. Liu, R. Khalaf, Dieter Koenig, M. Marin, V. Mehta, S. Thatte,
D. Rijn, P. Yendluri und A. Yiu. Web Services Business Process Execution Language
Version 2.0 (OASIS Standard), 2007.
[Aal98] W.M.P. van der Aalst. The Application of Petri Nets to Workflow Management. The
Journal of Circuits, Systems and Computers, 8(1):21–66, 1998.
[Bau05] T. Bauer. Integration von prozessorientierten Anwendungen. In: Proc. Workshop on En-
terprise Application Integration, 2005.
[BB03] M. Boggs und W. Boggs. UML and Rational Rose. Mitp-Verlag, 2003.
[BBR09] S. Buchwald, T. Bauer und M. Reichert. Durchg¨
angige Modellierung von Gesch¨
aftspro-
zessen durch Einf¨
uhrung eines Abbildungsmodells: Ans¨
atze, Konzepte, Notationen. Be-
richt, Universit¨
at Ulm. Fakult¨
at f¨
ur Ingenieurwissenschaften und Informatik, April 2009.
[BBR10] S. Buchwald, T. Bauer und M. Reichert. Durchg¨
angige Modellierung von Gesch¨
aftspro-
zessen in einer Service-orientierten Architektur. In Modellierung’10, Lecture Notes in
Informatics (LNI). Koellen-Verlag, March 2010.
[BELM08] Sabine Buckl, Alexander M. Ernst, Josef Lankes und Prof. Dr. Florian Matthes. Enter-
prise Architecture Management Pattern Catalog Release 1.0, 2008.
[BPM06] BPMI. Business Process Management Initiative, Business Process Modeling Notation
Specification (BPMN), 2006.
[Buc05] S. Buchwald. Konzeption und Realisierung einer Infrastruktur zur prozessorientierten In-
tegration von Applikationen in Workflows. Diplomarbeit, Fachhochschule Ulm, 2005.
[Buc07] S. Buchwald. Modellierung von Abh¨
angigkeiten zwischen prozessorientierten Applikatio-
nen. Masterarbeit, Hochschule Ulm, 2007.
[Che08] H.-M. Chen. Towards Service Engineering: Service Orientation and Business-IT Ali-
gnment. Hawaii International Conference on System Sciences, Seite 114, 2008.
[CHKT05] S. Conrad, W. Hasselbring, A. Koschel und R. Tritsch. Enterprise Application Integra-
tion: Grundlagen - Konzepte - Entwurfsmuster - Praxisbeispiele. Spektrum Akademischer
Verlag, 2005.
[EHH+08] G. Engels, A. Hess, B. Humm, O. Juwig, M. Lohmann, J.-P. Richter, M. V und
J. Willkomm. Quasar Enterprise: Anwendungslandschaften serviceorientiert gestalten.
dpunkt.verlag, 2008.
[Erl05] T. Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall,
2005.
[Fra94] U. Frank. Multiperspektivische Unternehmensmodellierung: Theoretischer Hintergrund
und Entwurf einer objektorientierten Entwicklungsumgebung, 1994.
[Fra02] U. Frank. Multi-perspective Enterprise Modeling (MEMO) - Conceptual Framework and
Modeling Languages. In HICSS, Seite 72, 2002.
[HBR08] A. Hallerbach, T. Bauer und M. Reichert. Anforderungen an die Modellierung und
Ausf¨
uhrung von Prozessvarianten. Datenbank Spektrum, 2008.
[IBM07] IBM. IBM WebSphere Message Broker: ESQL Version 6, 2007.
[IDS06] IDS Scheer AG. ARIS Platform - Methode 7.0 Toolset Dokumentation. IDS Scheer AG,
2006.
[LR00] F. Leymann und D. Roller. Production Workflow: Concepts and Techniques. Prentice-Hall,
2000.
[MBL07] D. Maurer, P. B¨
uch und M. Linke. From Business Process to Enterprise Architecture,
ARIS Solution for Enterprise Architecture Management, ARIS Expert Paper, 2007.
[Mei02] H. Meinecke. Entwurf und Implementierung eines Abh¨
angigkeits-Managers. Diplomar-
beit, Universit¨
at Stuttgart, 2002.
[Mel05] I. Melzer. Service-orientierte Architekturen mit Web Services - Konzepte, Standards, Pra-
xis. Spektrum Akademischer Verlag, 2005.
[MM04] F. Manola und E. Miller. RDF Primer. World Wide Web Consortium, Februar 2004.
[Obj07a] Object Management Group. MOF 2.0/XMI Mapping Specification, v2.1.1, 2007.
[Obj07b] Object Management Group. UML Superstructure Proposal v2.1.2, 2007.
[Pet62] C. A. Petri. Kommunikation mit Automaten. Dissertation, Institut f¨
ur instrumentelle Ma-
thematik, Bonn, 1962.
[TF06] S. Ross- Talbot und T. Fletcher. Web Services Choreography Description Language: Pri-
mer. World Wide Web Consortium, Working Draft, 2006.
[TLD+06] L. W. N. van der Torre, M. M. Lankhorst, H. W. L. ter Doest, J. T. P. Campschroer und
F. Arbab. Landscape Maps for Enterprise Architectures. In Eric Dubois und Klaus Pohl,
Hrsg., Advanced Information Systems Engineering, 18th International Conference, CAiSE,
Jgg. 4001 of Lecture Notes in Computer Science, Seiten 351–366. Springer, 2006.
[TS02] A. S. Tanenbaum und M. van Steen. Distributed Systems: Principles and Paradigms. Pren-
tice Hall, 2002.
Advertisement