=Paper=
{{Paper
|id=Vol-537/paper-5
|storemode=property
|title=Anwendungslandschaften und ihre Verwendung durch exemplarische Geschäftsprozessmodellierung verstehen
|pdfUrl=https://ceur-ws.org/Vol-537/D4F2009_Paper03.pdf
|volume=Vol-537
}}
==Anwendungslandschaften und ihre Verwendung durch exemplarische Geschäftsprozessmodellierung verstehen==
https://ceur-ws.org/Vol-537/D4F2009_Paper03.pdf
Anwendungslandschaften und ihre Verwendung durch
exemplarische Geschäftsprozessmodellierung verstehen
Stefan Hofer
Universität Hamburg, Departement Informatik, Arbeitsbereich Softwaretechnik
und
C1 WPS GmbH
Vogt-Kölln-Str. 30
22527 Hamburg
stefan.hofer@c1-wps.de
Abstract: Projekte zur Umgestaltung komplexer Anwendungslandschaften erweisen
sich in der Praxis als Herausforderung für Unternehmen. Die laufende Anpassung an
sich ändernde fachliche und technische Gegebenheiten ist für die Zukunftssicherheit
einer Anwendungslandschaft unverzichtbar. Dieser Artikel schlägt einen Modellie-
rungsansatz vor, der Anwendungslandschaften zum Gegenstand eines von allen Betei-
ligten gestalteten Veränderungsprozesses macht. Durch die ineinandergreifende Mo-
dellierung von technischer Architektur und Geschäftsprozessen wird Verständnis für
jene Zusammenhänge geschaffen, welche die Umgestaltung so herausfordernd ma-
chen.
1 Einleitung
Unternehmen fordern heutzutage integrierte IT-Systemen, die anwendungsübergreifende
Geschäftsprozesse unterstützen. Dadurch rücken Anwendungslandschaften in den Mittel-
punkt der Unternehmens-IT. Um eine zukunftssichere Anwendungslandschaft konzipie-
ren und betreiben zu können, benötigt man nicht nur langlebige IT-Systeme. Zusätzlich
müssen sich Unternehmen mit dem stetigen Anpassungsdruck auseinandersetzen, dem die
Landschaften ausgesetzt sind. Sich ändernde technische und fachliche Gegebenheiten er-
fordern die häufige Umgestaltung von Anwendungslandschaften. Die Notwendigkeit ihrer
strategischen Planung und die Beschäftigung mit den dafür nötigen Modellen hat sich
in Wissenschaft und Praxis unter den Begriffen IT-Unternehmensarchitektur [Kel07] und
Software-Kartographie [MW04] etabliert. Die Durchführung entsprechender Umgestal-
tungsprojekte bleibt jedoch eine große Herausforderung für Unternehmen, wie folgendes
Beispiel verdeutlicht:
Eine Bank wechselt aus technischen Gründen das Betriebssystem aller Client-Server-
Anwendungen und muss deswegen ihre Anwendungslandschaft anpassen. Eigenentwick-
lungen werden portiert, Standardanwendungen mit aktuellen Versionen ersetzt und einige
Anwendungen wie das System für den Wertpapierhandel eingestellt, weil ihre Funktio-
nalität als externe Dienstleistung zugekauft wird. Für die Umsetzung dieser Änderungen
muss die Anwendungslandschaft im Kontext ihrer Verwendung betrachtet und verstanden
werden, da sonst viele relevante Fragen unbeantwortet bleiben. Bezogen auf die Verände-
rungen im Wertpapierhandel sind dies beispielsweise:
• Welcher Ausschnitt der Anwendungslandschaft ist von den Veränderungen im Wert-
papierhandel betroffen?
• Kommt es durch die neue Anwendung zu Redundanzen in der Datenhaltung, so dass
Daten aus mehreren Beständen synchronisiert werden müssen?
• Wie wirken die komplexen IT-gestützten und manuellen Arbeitsprozesse zusam-
men, die den Geschäftsprozess „Wertpapierhandel“ ausmachen?
• Welche dieser Arbeitsprozesse müssen angestoßen werden, um die neuen und geän-
derten Schnittstellen in der Anwendungslandschaft testen zu können?
In diesem Artikel wird untersucht, wie die gemeinsame Betrachtung von Anwendungs-
landschaften und ihrer Verwendung Umgestaltungsprojekte unterstützen kann (siehe Ab-
schnitt 2). Als Grundlage für diese Analyse dienen Projekte der C1 WPS GmbH, in wel-
cher der Autor als Berater tätig ist. Mit der an der Universität Hamburg entwickelten
exemplarischen Geschäftsprozessmodellierung (eGPM, siehe Abschnitt 3) steht ein pra-
xiserprobter Ansatz zur Verfügung, um Anwendungslandschaften und ihre Verwendung
ineinandergreifend zu modellieren. In mehreren Projekten der C1 WPS wurden positive
Erfahrungen mit eGPM gemacht. In einem Abgleich mit bestehenden Modellierungsan-
sätzen für Anwendungslandschaften und Geschäftsprozesse (siehe Abschnitt 4) zeigt der
Artikel, dass die vorgeschlagene Sichtweise auf Anwendungslandschaften bisher wenig
beachtete Themen beleuchtet. Abschließend fasst Abschnitt 5 die bisherigen Erkenntnisse
zusammen und zeigt weiteren Forschungsbedarf auf.
2 Umgestaltung von Anwendungslandschaften
2.1 Begriffe
Unternehmen betreiben nicht länger einzelne, isolierte Softwaresysteme, sondern eine
große Zahl teilweise von einander abhängiger Anwendungen. Die Gesamtheit dieser An-
wendungen wird zusammen mit ihren Abhängigkeiten als Anwendungslandschaft eines
Unternehmens bezeichnet [Der03]. Änderungen im Geschäft und technische Gründe wie
schlecht zu wartende IT-Systeme erfordern die laufende Anpassung von Anwendungsland-
schaften. Um sie umgestalten zu können, ist die Kenntnis ihrer Architektur genauso wich-
tig wie die Abstimmung mit den von ihr zu unterstützenden Arbeits- und Geschäftspro-
zessen. Dieser Artikel folgt der Definition der ANSI und versteht unter Architektur den
Aufbau einer Anwendungslandschaft, verkörpert durch ihre Bestandteile und deren Bezie-
hungen untereinander, sowie die Grundsätze ihres Entwurfs und ihrer Evolution [ANS00].
Als Geschäftsprozesse fasst man koordinierte Aktivitäten zur Erreichung von Geschäfts-
zielen zusammen [Wes07]. Umgesetzt werden diese abstrakten Aktivitäten durch konkrete
manuelle und IT-gestützte Arbeitsprozesse.
Ohne ein Verständnis der Architektur können die Auswirkungen der Anpassung einer An-
wendungslandschaft nicht eingeschätzt werden, während eine fehlende Abstimmung mit
den Prozessen den Sinn der Änderungen in Frage stellt. Zu einer ähnlichen Einschätzung
kommen Conrad et al., die für das Gebiet der Enterprise Application Integration (EAI)
die beiden Problembereiche „technische Realisierung“ und „organisatorische/soziale Inte-
gration“ identifizieren [CHKT06, S. 5]. EAI kann als Teilbereich der Umgestaltung von
Anwendungslandschaften aufgefasst werden, weil das Einführen neuer Anwendungen, die
Anpassung von Schnittstellen zwischen Anwendungen und das Abschalten von Anwen-
dungen die wesentlichen Möglichkeiten darstellen, um eine Anwendungslandschaft zu
verändern. Die in diesem Artikel vorgeschlagene Unterstützung für die Umgestaltung von
Anwendungslandschaften basiert daher auf der Unterstützung dieser Veränderungsmög-
lichkeiten.
2.2 Herausforderungen in der Praxis
Dieser Abschnitt fasst die Erfahrungen zusammen, welche die C1 WPS GmbH in Umge-
staltungsprojekten gesammelt hat. Neben Beratung zur IT-Strategie der Kunden und der
Modellierung von Ist- und Soll-Anwendungslandschaften unterstützte sie die Umsetzung
der erarbeiteten Pläne. Dabei traten immer wieder zwei grundlegende Fragen auf, deren
Beantwortung die gemeinsame Betrachtung der Architektur der Anwendungslandschaften
und der von ihnen unterstützten Prozesse erforderte:
• Was muss man über die Anwendungslandschaft und ihre Verwendung wissen, um
sie umgestalten zu können?
• Welche Auswirkung hat die Umgestaltung auf die Anwendungslandschaft und ihre
Verwendung?
Anhand eines fiktiven, aber realistischen Beispiels aus der Versicherungsbranche werden
im Folgenden drei Kontexte vorgestellt, in denen diese Fragen auftauchen:
Eine Versicherung verwendet Vorgangsmappen, um die arbeitsteilige Abar-
beitung von Schadensfällen zu koordinieren und den Bearbeitungsstatus ei-
nes Falls nachvollziehen zu können. Die einzelnen Arbeitsschritte der Sach-
bearbeiter werden bereits durch IT-Systeme unterstützt. Hingegen ist die Vor-
gangsmappe eine nicht formal festgelegte, lose Kombinaton von E-Mails, Da-
teien und Papierdokumenten. Um die Bearbeitungsgeschwindigkeit zu erhö-
hen, sollen die Vorgangsmappen durch ein Workflow-Management-System
(WfMS, vgl. [zM04]) umgesetzt werden.
Fachliche und technische Integration
Nur mit Detailwissen über die IT-Unterstützung der betroffenen Akteure können Schnitt-
stellen zwischen Anwendungen auf technischer und fachlicher Ebene ermittelt und eine
sinnvolle Integration erreicht werden. Im Beispiel:
Um herauszufinden, wie das WfMS und die bestehenden Anwendungen sinnvoll integriert
werden können, müssen die Arbeitsprozesse der Sachbearbeiter und die vorhandene IT-
Unterstützung modelliert werden.
• Welche Arbeitsgegenstände (eingescannte Dokumente, Anträge auf Papier etc.) ver-
wenden die Sachbearbeiter?
• Welche Arbeitsschritte erledigen sie IT-gestützt und mit welchen Anwendungen?
Tauschen diese untereinander Daten aus? Wie wird die Kommunikation angestoßen?
• Welche Anwendung ist führend bei der Verwaltung welcher Daten?
Migrationsplanung
Unternehmen setzen große Änderungen in ihren Anwendungslandschaften oft in kleinen
Schritten um, sodass die Landschaft und die von ihr unterstützten Prozesse auf dem Weg
vom Ausgangs- zum Zielzustand mehrere produktive Zwischenzustände durchlaufen. In
jedem dieser Schritte müssen die Veränderungen in der Landschaft gut abgestimmt und
von Fachabteilung und IT verstanden werden, um den reibungslosen Betrieb aufrecht er-
halten zu können. Im Beispiel:
• In welcher Reihenfolge sollen die Arbeitsprozesse der Sachbearbeiter im WfMS
abgebildet werden?
• Wie verändern sich die Prozesse in der Abteilung für Schadensfälle und die Schnitt-
stellen in der Anwendungslandschaft durch das WfMS? Wie sehen sie nach dem
ersten, zweiten, dritten etc. Migrationsschritt aus?
Testszenarios
Anwendungsübergreifende Tests entlang fachlicher Prozesse mindern das Risiko, das neue
und geänderte Schnittstellen für die Verwendung einer Anwendungslandschaft darstellen.
Passende Testszenarien zu identifizieren und konkrete Testfälle aufzustellen erfordert die
detaillierte Kenntnis der Zusammenhänge zwischen technischer Architektur der Anwen-
dungslandschaft und den von ihr unterstützten Arbeitsprozessen. Im Beispiel:
• Welche anwendungsübergreifenden Arbeitsprozesse führt ein Sachbearbeiter aus?
• Gibt es manuelle Schritte in diesen Arbeitsprozessen, die Kommunikation zwischen
Anwendungen auslösen?
• Welche Abhängigkeiten zwischen Anwendungen sind rein fachlich und nicht tech-
nisch (z.B. Nachbearbeitung von eingescannten Dokumenten)?
3 Exemplarische Geschäftsprozessmodellierung – eGPM
Dieser Abschnitt stellt einen Ansatz zur Geschäftsprozessmodellierung vor, der sich in der
Praxis als Hilfsmittel zur Beantwortung der oben genannten Fragestellungen erwiesen hat.
Da eine ausführliche Beschreibung des Ansatzes den Umfang dieses Artikels sprengen
würde, wird er nur im Überblick dargestellt.
3.1 Kurzvorstellung
Ursprung der exemplarischen Geschäftsprozessmodellierung (vgl. [BKS06, Bre03]) ist
die Analyse der Unterstützung kooperativer Arbeit durch Software – speziell der Aspek-
te Kommunikation, Kooperation und Koordination (vgl. [TSMB95]). Die Modellierung
findet in diesem Ansatz typischerweise in Workshops statt, in denen z.B. Vertreter aus
Fachabteilung und IT ihr Wissen und ihre unterschiedlichen Sichten in gemeinsame Mo-
delle einbringen. Das ermöglicht unmittelbare Rückkopplung, ob die Darstellung des mo-
dellierten Gegenstandsbereichs zutreffend ist. Da eine Werkzeugunterstützung für diese
Vorgehensweise sehr nützlich ist, wurde eGPM in Zusammenarbeit mit der BOC Group1
als Modellierungsmethode für das Geschäftsprozessmanagement-Werkzeug ADONIS im-
plementiert.
eGPM besteht aus mehreren Modelltypen, die in ein gemeinsames Metamodell eingebettet
sind. Durch die Werkzeugunterstützung können Modelle verschiedener Typen auf Ebene
von Modellelementen verknüpft werden, was eine konsistente Modellierung erleichtert.
Zusätzlich stehen Überblicks- und Begriffsmodelltypen zu Verfügung, die einen Über-
blick über zusammengehörige Modelle verschaffen bzw. Begriffe und Konzepte des mo-
dellierten Gegenstandsbereichs zueinander in Beziehung setzen. Nur die beiden für diesen
Artikel wichtigsten Modelltypen werden im Folgenden näher beschrieben.
Kooperationsbilder
Das Kooperationsbild ist der zentrale Modelltyp der eGPM und baut auf den Arbeiten von
Krabbel, Wetzel et al. (siehe u.a. [KWR96a, KWR96b]) auf. Kooperationsbilder stellen
Kommunikation, Kooperation und Koordination zwischen Akteuren graphisch dar. So-
wohl Menschen als auch IT-Systeme können als Akteure eine aktive Rolle übernehmen.
Dadurch machen Kooperationsbilder die IT-Unterstützung von Geschäftsprozessen auf der
Ebene einzelner Arbeitsschritte sichtbar. Akteure sind durch typisierte Pfeile mit anderen
Akteuren und Gegenständen (z.B. „Geschäftsobjekte"wie in [BELM08]) verbunden. Diese
1 www.boc-group.com
Relationen beschreiben folgende Aktivitäten:
• Akteure bearbeiten Gegenstände (siehe Abbildung 1a)
• Akteure geben Gegenstände untereinander weiter (siehe Abbildung 1b)
• Akteure geben Informationen über ein Medium (E-Mail, Telefon usw.) weiter (siehe
Abbildung 1c)
(a) Akteur bearbeitet Gegenstand (b) Akteur gibt Gegenstand weiter
(c) Akteur informiert mit Medium
Abbildung 1: Relationen zwischen Akteuren und Gegenständen im Kooperationsbild
Den Kooperationsbildern liegt keine ablaufsteuernde, algorithmische Denkweise zu Grun-
de. Stattdessen zeigen sie einen konkreten Ablauf eines Prozesses aus der Sicht der betei-
ligten Akteure. Die einzelnen Aktivitäten des Prozesses werden dazu in eine exemplari-
sche Reihenfolge gebracht. Auf die Darstellung von Fallunterscheidungen wird verzichtet
– Kooperationsbilder „erzählen“ Szenarios (vgl. [Car00]).
Wie sich im Praxiseinsatz gezeigt hat, ist eGPM durch die grafische Darstellung der Ko-
operationsbilder und den Verzicht auf Fallunterscheidungen so verständlich, dass die an
den Workshops teilnehmenden Personen auch selbst Modelle erstellen können, während
ein geschulter Modellierer die Rolle des Moderators annimmt. Dieser achtet unter ande-
rem darauf, dass das gewählte Szenario durch klare Randbedingungen von anderen Fällen
abgegrenzt wird (z.B. Schadensfall Privathaftpflichtversicherung ohne Zusatzdeckungen,
Schadenssumme unter 10.000A C, Schaden wird vollständig gedeckt). Abbildung 2 stellt
den fiktiven Geschäftsprozess „Bearbeitung eines Schadensfalls“ mit den beschriebenen
Rahmenbedingungen als Kooperationsbild dar. Dieses Beispiel ist im Vergleich zu realen
Prozessen stark vereinfacht und verwendet nicht alle graphischen Elemente des Modell-
typs. Anhand der Nummern kann der Ablauf des Szenarios nachvollzogen werden.
Abbildung 2: Bearbeitung eines Schadensfalls als Kooperationsbild
IT-Landschaft
Der Modelltyp IT-Landschaft2 stellt die Zusammenhänge mehrerer IT-gestützter Prozes-
se dar. Es handelt sich dabei um ein Begriffsmodell, das IT-Systeme zueinander in Be-
ziehung setzt. Ein geschulter Modellierer erstellt auf Basis der aus den Kooperationsbil-
dern gewonnenen Informationen über die IT-Unterstützung ein Modell des relevanten Teils
der Anwendungslandschaft. Dieses Modell wird gegebenenfalls in Workshops mit der IT-
Abteilung um technische Aspekte ergänzt und von Widersprüchen bereinigt. Kooperati-
onsbilder können auf IT-Landschaften Bezug nehmen, in dem die Anwendungen mit de-
nen der IT-Landschaft verknüpft werden. Das Modell der IT-Landschaft dient dem mit der
Auswahl der Szenarien verbundenen Zweck – etwa der Herausarbeitung von technischen,
fachlichen und organisatorischen Berührungspunkten einer Anwendungslandschaft zu ei-
nem neu einzuführenden Workflow-Management-System. Abbildung 3 zeigt den für die
Schadensbearbeitung relevanten Teil der IT-Landschaft vor der Einführung des WfMS.
Ein solches Modell führt die technikbezogenen Informationen mehrerer Kooperations-
bilder (u.a. dem in Abbildung 2) zusammen. Auch diese Abbildung ist im Vergleich zu
2 „IT-Landschaft“ ist in eGPM ein Oberbegriff für „Anwendungslandschaft“, der zusätzlich Hardware- und
Software-Infrastruktur mit einschließt.
echten IT-Landschaften stark vereinfacht und enthält nur einige wenige der möglichen
Darstellungsmittel. Zu sehen sind ausgewählte IT-Systeme, für welche Daten sie führend
zuständig sind und welche Daten von ihnen aus anderen Anwendungen importiert (grauer
Pfeil), an andere Anwendungen gesendet (schwarzer Pfeil) und mit anderen Anwendungen
synchronisiert (schwarzer Doppelpfeil) werden.
Abbildung 3: Beispiel einer fiktiven IT-Landschaft
3.2 Unterstützung der Umgestaltung durch eGPM
Dieser Abschnitt beschreibt unsere Erfahrungen beim Einsatz der eGPM in Umgestal-
tungsprojekten. Er zeigt, mit welchen Eigenschaften eGPM den in Abschnitt 2.2 aufgelis-
teten Herausforderungen begegnet.
Gemeinsames Verständnis schaffen
Die Umgestaltung einer Anwendungslandschaft involviert viele Personen mit unterschied-
lichen Fähigkeiten und Hintergründen, beispielsweise Mitarbeiter aus Fachbereichen und
IT sowie externe Dienstleister. Diese Personen haben direkt mit der Umgestaltung zu tun,
verfügen aber über verschiedene Sichten auf die Anwendungslandschaft. Selbst wenn be-
reits Informationen zu den einzelnen Anwendungen vorliegen und in ein Modell verdichtet
wurden, heißt das nicht, dass die Beteiligten über ein gemeinsames Verständnis verfügen.
Dieses ist aber wegen der nötigen Abstimmung in solchen Projekten (siehe z.B. die Frage
nach der Planung produktiver Zwischenschritte im Abschnitt 2.2) von großer Bedeutung.
Die eGPM leistet mit ihren für alle Beteiligte verständlichen Darstellungsformen einen
Beitrag zur Schaffung eines gemeinsamen Verständnisses einer Anwendungslandschaft.
Beim Erstellen der Modelle erarbeiten sich die Beteiligten außerdem ein gemeinsames
Begriffsmodell. Daher kann der Modellierungsprozess der eGPM als „Verständnisprozess“
aufgefasst werden, in dessen Verlauf die Beteiligten explizit Informationen einbringen und
unterschiedliche Sichten verbinden.
Einfordern von Fragen zur Anwendungslandschaft
Viele der Fragen aus Abschnitt 2.2 beschäftigen sich mit Kommunikation, Koordination
und Kooperation. Im Kontext von Anwendungslandschaften spielen diese Aspekte sowohl
in der Zusammenarbeit von IT-Systemen untereinander als auch zwischen Anwendungen
und ihren Benutzern eine Rolle. Daher greifen rein technisch motivierte Modelle zu kurz.
Die Kooperationsbilder der eGPM stellen unter anderem dar, wer - was - womit - wo-
zu bearbeitet und wer - wen - mit welchen Mitteln informiert. Dadurch fordert sie von
den Modellierern, explizit Fragen zur IT-Unterstützung von Kommunikation, Koordinati-
on und Kooperation zu stellen. Die Antworten zu diesen Fragen gehen in das Modell der
Anwendungslandschaft ein.
Umgang mit Unvollständigkeit
In der Praxis kann kaum eine vollständige Modellierung einer Anwendungsanlandschaft
erreicht werden: Zum einen wären die zu erhebenden Daten extrem umfangreich und nicht
aktuell zu halten. Zum andern verfügen viele Unternehmen nicht über die Möglichkeit,
die Vollständigkeit der Modellierung z.B. anhand der vom Lizenzmanagement erfassten
Anwendungen zu überprüfen.
Eines der Kernkonzepte der eGPM ist die Fokussierung auf Szenarios. Diese auszuwählen
und dabei Wesentliches von Unwesentlichem zu trennen bedeutet, die Unvollständigkeit
von Modellen zu thematisieren und einen konstruktiven Umgang damit zu suchen. Die
Szenarios werden anhand des konkreten Ziels (vgl. „Pragmatisches Merkmal“ in [Sta73])
eines Umgestaltungsprojekts (z.B. Einführung eines Workflow-Management-Systems) ge-
wählt. Die bisherigen Erfahrungen beim Einsatz der eGPM zeigen, dass dadurch genügend
Informationen für die Modellierung der betroffenen Teile der Anwendungslandschaft er-
hoben werden können.
4 Abgleich mit bestehenden Ansätzen
Dieser Abschnitt stellt andere Ansätze vor, die sich mit der Modellierung von Anwen-
dungslandschaften und ihrer Einordnung in einen unternehmensweiten Kontext befassen.
4.1 Unternehmensarchitektur
Als Unternehmensarchitektur werden unternehmensweite, integrierte Modelle von Ge-
schäftsstrategie, Geschäftsprozessen, Anwendungen und Infrastruktur verstanden [Kel07].
Es handelt sich also um die Beschreibung der existierenden Strukturen von Unternehmen.
Das Modell einer Anwendungslandschaft ist Teil einer Unternehmensarchitektur.
Unternehmensarchitekturen sind nicht als Hilfsmittel für die detaillierte Planung und Durch-
führung von Änderungen in Anwendungslandschaften gedacht. So wird in [ARW08] und
[WF06] gefordert, Unternehmensarchitekturen auf aggregierten Informationen aufzubau-
en und sie strategisch auszurichten. D.h. Unternehmensarchitekturen bestehen aus grob-
granularen Informationen über alle Aspekte eines Unternehmens hinweg statt vertiefender
Detailinformationen zu den einzelnen Aspekten. Winter und Fischer empfehlen, speziali-
sierte Architekturansätze für die operativen Aufgaben in Teilbereichen des Unternehmens
einzusetzen [WF06]. Die eGPM ist ein solcher spezialisierter Ansatz.
4.2 Softwarekartographie
Dieser Ansatz stellt Anwendungslandschaften in Form von Softwarekarten [LMW05] dar.
In [BELM08] werden die Darstellungskonzepte (beispielsweise verschiedene Kartenty-
pen) und die damit verbundenen Einsatzmöglichkeiten in Form von Mustern zusammen-
gefasst. Ziel dieses Musterkatalogs ist, bestehende Ansätze zur Beschreibung von Unter-
nehmensarchitekturen (siehe Abschnitt 4.1) zu ergänzen. Dazu wurden in der Praxis häufig
auftretende Fragestellungen gesammelt und passende Lösungsansätze beschrieben, die aus
Handlungsanweisungen, dafür benötigten Informationen und geeigneten Darstellungsfor-
men für diese Informationen bestehen.
Der Großteil dieser Fragestellungen (Concerns) betrifft strategische Themen wie die lang-
fristige Planung von Anwendungslandschaften. Zwar gibt es zwischen den Fragen und den
Einsatzzwecken der eGPM einige Überschneidungen (etwa „Concern C-51: Which busi-
ness objects are used or exchanged by which business applications or services?“ [BELM08,
S. 34]), doch unterscheiden sich die Modelle für deren Beantwortung. Sofwarekarten ba-
sieren auf der Visualisierung von im Vorfeld (z.B. per Fragebogen) erhobenen Daten und
sind nicht das Resultat eines Modellierungsprozesses im Sinne der eGPM. Die eGPM
bindet die betroffenen Akteure in den Prozess mit ein und macht ihre Aufgaben zum
Bestandteil von Kooperationsbildern, wodurch die Zusammenhänge zwischen Anwen-
dungslandschaft und Geschäftsprozessen auf Ebene von Arbeitsprozessen (siehe Abschnitt
2.1) dargestellt werden. Softwarekarten zeigen diese Zusammenhänge auf Ebene von Ge-
schäftsobjekten (siehe z.B. Viewpoint 48 im Katalog) oder direkt auf Geschäftsprozes-
sebene (siehe z.B. Viewpoint 17). Ein weiterer Unterschied besteht im Umgang mit der
(Un-)Vollständigkeit von Modellen (siehe Abschnitt 3.2).
4.3 Geschäftsprozessmodellierung
Im Gebiet der Geschäftsprozessmodellierung dominieren Ansätze, die Prozesse als Kon-
trollflüsse [KNS92] beschreiben. Als Vertreter dieses Konzepts führt Weske unter anderem
die Business Process Modeling Notation und ereignisgesteuerte Prozessketten auf (vgl.
[Wes07]). „Anwendungen“ spielen in diesen Ansätzen eine untergeordnete Rolle. Bei-
spielsweise bietet der verbreitete Ansatz der ereignisgesteuerten Prozessketten [KNS92]
lediglich die Möglichkeit, Informationsobjekte im Sinne von Datenquellen oder Speicher-
orten in einem Geschäftsprozessmodell zu verwenden.
5 Zusammenfassung und Ausblick
Anwendungslandschaften rücken immer mehr in den Blickwinkel von Unternehmen und
stehen aus fachlichen und technischen Gründen unter ständigem Änderungsdruck. Zu-
kunftssicher können Anwendungslandschaften daher nur sein, wenn sie immer wieder
durch Umgestaltungsprojekte an neue Gegebenheiten angepasst werden. In solchen Pro-
jekten werden Modelle von Anwendungslandschaften für die Planung und Umsetzung ver-
wendet, jedoch stellt dabei die Verknüpfung von technischer Architektur und Arbeitspro-
zessen eine von der Informatik noch wenig beachtete Herausforderung dar. Eine solche
Sicht auf Anwendungslandschaften ist aber für viele Aufgaben in Umgestaltungsprojek-
ten hilfreich, etwas für die Konzeption fachlich und technisch passender Schnittstellen, für
die detaillierte Migrationsplanung und für die Erarbeitung von Testszenarios.
Mit der exemplarischen Geschäftsprozessmodellierung steht ein vielversprechender und
praxiserprobter Ansatz zur Verfügung, um Anwendungslandschaften und die von ihnen
unterstützten Prozesse ineinandergreifend zu modellieren. Er bildet die Grundlage für das
Promotionsvorhaben des Autors, in dessen Verlauf die eGPM weiter für den Einsatz in
Umgestaltungsprojekten optimiert werden soll. Dazu werden die Darstellungsmittel der
eGPM weiter verbessert und eine passende Modellierungsmethode ausgearbeitet. Ergän-
zend werden Muster für die Anwendung der Methode bereitgestellt.
Ein weiterer, noch zu erforschender Aspekt ist die Einordnung der eGPM in eine Unter-
nehmensarchitektur. Die Verbindung des Metamodells der eGPM mit dem Metamodell
eines Ansatzes für die Modellierung von Unternehmensarchitekturen könnte eine Brücke
zwischen strategisch ausgerichteten, stark aggregierten Darstellungen von Anwendungs-
landschaften und operativ ausgerichteten, detaillierten Darstellungen schlagen.
Literatur
[ANS00] ANSI/IEEE Computer Society. ANSI/IEEE-Standard-1471. IEEE Recommended Prac-
tice for Architectural Description of Software-Intensive Systems, 2000.
[ARW08] Stephan Aier, Christian Riege und Robert Winter. Unternehmensarchitektur. Literatur-
überblick und Stand der Praxis. Wirtschaftsinformatik, 4:292–304, 2008.
[BELM08] Sabine Buckl, Alexander M. Ernst, Josef Lankes und Florian Matthes. Enterprise Ar-
chitecture Management Pattern Catalog. Technical Report TB 0801, Technische Uni-
versität München, Lehrstuhl Software Engineering betrieblicher Informationssysteme,
Februar 2008.
[BKS06] Holger Breitling, Andreas Kornstädt und Joachim Sauer. Design Rationale in Exempla-
ry Business Process Modeling. In Alen H. Dutoit, Ray McCall, Ivan Mistrik und Bar-
bara Paech, Hrsg., Rationale Management in Software Engineering, Seiten 191–208.
Springer-Verlag, 2006.
[Bre03] Holger Breitling. Integrierte Modellierung von Geschäftsprozessen und Anwendungs-
software. Treffen der Fachgruppe 2.1.6. Requirements Engineering der GI, November
2003.
[Car00] John Carroll. Making Use. Scenario-Based Design of Human-Computer Interaction.
MIT Press, 2000.
[CHKT06] Stefan Conrad, Wilhelm Hasselbring, Arne Koschel und Roland Tritsch. Enterprise
Application Integration. Elsevier, 2006.
[Der03] Gernot Dern. Management von IT-Architekturen. Vieweg, 2003.
[Kel07] Wolfgang Keller. IT-Unternehmensarchitektur. Von der Geschäftsstrategie zu optimalen
IT-Unterstützung. dpunkt.verlag, Heidelberg, 2007.
[KNS92] G. Keller, M. Nüttgens und A.-W. Scheer. Semantische Prozeßmodellierung auf der
Grundlage Ereignisgesteuerter Prozeßketten (EPK). Forschungsberichte des Instituts
für Wirtschaftsinformatik,, Heft 89, 1992.
[KWR96a] Anita Krabbel, Ingrid Wetzel und Sabine Ratuski. Objektorientierte Analysetechniken
für übergreifende Aufgaben. In Jürgen Ebert, Hrsg., GI-Fachtagung Softwaretechnik
’96, Seiten 65–72, September 1996.
[KWR96b] Anita Krabbel, Ingrid Wetzel und Sabine Ratuski. Participation of Heterogeneous User
Groups: Providing an Integrated Hospital Information System. Proceedings of the Par-
ticipatory Design Conference, PDC 96:241–249, 1996.
[LMW05] Josef Lankes, Florian Matthes und André Wittenburg. Softwarekartographie: Systema-
tische Darstellung von Anwendungslandschaften. In Otto K. Ferstl, Elmar J. Sinz, Sven
Eckert und Tilman Isselhorst, Hrsg., Wirtschaftsinformatik Proceedings 2005, Seiten
1443–1462. Physica-Verlag, 2005.
[MW04] Florian Matthes und André Wittenburg. Softwarekarten zur Visualisierung von An-
wendungslandschaften und ihren Aspekten - Eine Bestandsaufnahme. Technical report,
Technische Universität München, sebis, 2004.
[Sta73] Herbert Stachowiak. Allgemeine Modelltheorie. Springer, 1973.
[TSMB95] Stephanie Teufel, Christian Sauter, Thomas Mühlherr und Kurt Bauknecht. Computer-
unterstützung für die Gruppenarbeit. Addison-Wesley, Bonn, 1995.
[Wes07] Mathias Weske. Business Process Management. Springer, Berlin, 2007.
[WF06] Robert Winter und Ronny Fischer. Essential Layers, Artifacts, and Dependencies of
Enterprise Architecture. In EDOC Workshop on Trends in Enterprise Architecture Re-
search, Seiten 30–38. IEEE Computer Society, 2006.
[zM04] Michael zur Muehlen. Workflow-based Process Controlling. Logos Verlag, 2004.