GESCHÄFTSPROZESSMANAGEMENT

ALS GRUNDLAGE FÜR SOA

Strategien immer stärker diesem Trend.Während sich beispielsweise IBM alsTechnologielieferant für eine durchgängigeSOA positioniert, bietet SAP mit demKonzept der Enterprise SOA nicht nur dietechnologischen Voraussetzungen für eineservice-orientierte Architektur (z. B. durchdie Werkzeuge im „SAP NetWeaver”), son-dern auch die funktionalen Bausteineinnerhalb der SAP-Systeme, die hinter derservice-orientierten Technologie liegen.SAP liefert somit sowohl die technologischePlattform für eine SOA als auch diebetriebswirtschaftlichen Inhalte in Formvon fertigen Services. Diese können dannbasierend auf der „NetWeaver Platform”verwendet oder an die unternehmensspezi-fischen Anforderungen angepasst werden.Diese Strategie gibt den späteren Anwen-dern eine völlig neuartige Flexibilität.Gleichzeitig ist sie auch der Grund dafür,dass die Integration von Werkzeugen fürdie fachliche Prozessmodellierung (wie bei-spielsweise ARIS) für die Softwareherstellereine entscheidende Rolle spielt.

Von wachsender Bedeutung ist in diesemZusammenhang auch die XML-basierte

Das Thema SOA hat in den letzten Monaten viel Beachtung gefunden. Es wurdejedoch im überwiegenden Maße auf der technischen Ebene diskutiert. Dabei wur-de die eigentliche Aufgabenstellung der IT häufig aus den Augen verloren: dieUnterstützung der Unternehmensprozesse. In diesem Artikel wird dargestellt, wieaufbauend auf Geschäftsprozessen technische Services abgeleitet und im Rahmeneiner SOA orchestriert werden können. In diesem Zusammenhang bildet das„Enterprise Service Repository” der SAP AG einen Meilenstein für eine durchgängi-ge Prozessmanagement-Lösung, von der Betriebswirtschaft bis zur Informations-technik. Das Wissen um die Anforderungen der Fachabteilungen ist Grundvoraus-setzung für eine zielführende Konzeption und Implementierung einer SOA.

m e h r z u m t h e m a :www.aris.dewww.ids-scheer.de

32 33

Eric Brabänder (E-Mail:eric.brabaender@ids-scheer.com) ist beider IDS Scheer AG für das internationa-le Produkt-Marketing der „ARISPlatform” verantwortlich. Er betreutkonzeptionell das Softwareprodukt„ARIS for SAP Netweaver” und dieEntwicklung der in SAP NetWeaverintegrierten ARIS-Lösung.

Jörg Klückmann (E-Mail:joerg.klueckmann@ids-scheer.com) istbei der IDS Scheer AG für das interna-tionale Produkt-Marketing rund um die„ARIS Implementation Platform” ver-antwortlich.

durch SOA, wie die Aberdeen Group ineinem aktuellen IT-Benchmark-Report pro-gnostiziert.

Ein weit verbreiteter Irrglaube ist jedoch,dass SOA zum einen gleichbedeutend mitWeb-Services und zum anderen als Produktkäuflich erwerbbar ist. Das Gegenteil istder Fall. Denn SOA ist in erster Linie einManagement- und Architekturkonzept, daseine IT-Infrastruktur fordert, die flexibelauf veränderte Anforderungen im Unter-nehmensumfeld reagiert. Das dazugehörigeSystemarchitektur-Konzept zerlegt dieUnternehmenssoftware in fachliche Funk-tionseinheiten, die durch kleine Soft-warebausteine ausgeführt werden. DieseFunktionsbausteine können durch modell-gestützte Konfiguration ohne größerenProgrammieraufwand an die unternehmeri-schen Anforderungen flexibel angepasstwerden. Wenn diese fachlichen Funktions-einheiten durch entsprechende Technolo-gien (z. B. WSDL, UDDI, SOAP) automati-siert werden, bezeichnet man diese als„Services”.

Während eine SOA die technologischeBasis für die Realisierung eines agilenUnternehmens ist, wird sehr schnell klar,dass neben der reinen Diskussion um dietechnologische Umsetzung auch der fachli-che Bezug eine stärkere Rolle spielt. Wobisher standardisierte Prozesse als inte-grierte Funktionalität einer Standardsoft-ware ausgeliefert wurden, können dieseProzesse nun wesentlich flexibler gestaltetund somit natürlich auch enger an derUnternehmensstrategie ausgerichtet wer-den. Aus diesem Grund ist das Geschäfts-prozessmanagement eine wesentlicheVoraussetzung für die Übersetzung fach-licher Anforderungen aus Sicht derUnternehmenssteuerung in die IT-Systeme.Die großen Hersteller von Unterneh-menssoftware entsprechen mit ihren

BPM + SOA = AgilitätDer Erfolg eines Unternehmens wird immermehr dadurch bestimmt, wie schnell es aufgeänderte Marktbedingungen mit adäqua-ten Produkten und Dienstleistungen reagie-ren kann. Viele Unternehmen nutzen zurSteigerung ihrer Handlungsagilität bereitsein aktives Geschäftsprozessmanagement(Business Process Management, BPM).Während die fachliche Beschreibung bzw.Anpassung der Geschäftsprozesse mittelsspezieller Prozessdesign- und Analysewerk-zeuge deutlich beschleunigt werden kann,kommt es bei der Umsetzung derGeschäftsprozesse in die unterstützende IT-Landschaft zu teilweise erheblichen Ver-zögerungen.

Die in den letzten Jahren propagiertefeste Verzahnung von Anwendungen undProzessabläufen auf einer zentralen mono-lithischen Applikationsstruktur lässt sichnur unter erheblichem Zeit- und Kosten-aufwand modifizieren. Fehlende Dokumen-tationen und intransparente IT-Land-schaften tragen ihr übriges dazu bei, dasssich die IT ehr zum Bremser als zumBeschleuniger entwickelt hat.

Der Markt für betriebswirtschaftlicheAnwendungssoftware steht nicht zuletztdeshalb vor einem technologischen Para-digmenwechsel. Service-orientierte Archi-tekturen (SOAs) sollen den Einsatz und denNutzen von Software in den Unternehmenrevolutionieren. Der Traum von einerSoftware, die eine agile Unternehmens-steuerung unterstützt, soll so Realität wer-den. Bis zum Jahr 2010 werden lautPrognose der Analysten der Gartner Groupmindestens 65% der großen Unternehmenmehr als 35% ihres Anwendungs-Portfolios auf eine SOA umgestellt haben.Die weltweit größten Unternehmen erwar-ten in den kommenden fünf Jahren Ein-sparungen von bis zu 53 Mrd. US-Dollar

d ie au torenschwerpunk t

5 / 2 0 0 6

schwerpunk t

Sprache Business Process ExecutionLanguage (BPEL), mit der sich technischeServices zu komplexeren Geschäftspro-zessen kombinieren bzw. orchestrieren las-sen. Da der fachliche Leistungsumfang vonAktivitäten und deren zeitlich-logischerAblauf durch Prozesse definiert werden, istein Geschäftsprozessdesign für die erfolg-reiche Entwicklung einer technischen SOAvon essenzieller Bedeutung. Die fachlicheProzessbeschreibung bestimmt auch dieGranularität der zu verwendenden oder zuentwickelnden Services und beantwortetsomit die erste große Frage auf dem Wegzur SOA: „Wie müssen technische Servicesgeschnitten sein?” bzw. „Welche techni-schen Services können z. B. im Rahmeneiner Enterprise SOA zur Realisierung derGeschäftsprozesse verwendet werden?”.Die fachlichen Prozessanforderungen sinddie Leistungsbeschreibungen der techni-schen Services. Ein fachliches BPM stelltsomit die Grundlage für den Entwurf unddie Implementierung einer SOA dar.

Revolutionär ist der Effekt, den SOA inZusammenarbeit mit BPM für den Umgangmit Anwendungssoftware bedeutet. Denndie Kombination von BPM und SOAschließt die Kluft zwischen den Geschäfts-prozessmodellen der Fachabteilungen undden Diagrammen der IT-Abteilungen.Durch die Zusammenführung beiderWelten erfolgen die Anpassung, Opti-mierung und Steuerung der physischenAbläufe in den Softwaresystemen aus derbetriebswirtschaftlichen Perspektive. Ausdem Geschäftsprozessmodell heraus wer-den die entsprechenden technischen

Services identifiziert und gegebenenfallsneu kombiniert. SOA schafft die techni-schen Voraussetzungen für die Integrationund Kooperation von Prozessen über IT-Systemgrenzen hinweg. BPM verhilft derZusammenarbeit der Services zur höchstenEffizienz und Effektivität.

SOA im Lebenszyklusdes Geschäftsprozess-managementsWie in Abbildung 1 dargestellt, bestehterfolgreiches BPM aus vier Schritten:Aufbauend auf der Business Process Stra-tegy (Strategiefindung) erfolgen Design(Prozessmodellierung), Implementierung(Überführung in IT) und Controlling(Messung und Bewertung) von Geschäfts-prozessen. Das Management von Ge-schäftsprozessen darf jedoch keine einmali-ge Aktivität darstellen. Mittelfristig bringtnur ein kontinuierlicher und in sichgeschlossener Geschäftsprozessmanage-ment-Lebenszyklus (BPM-Lifecycle) nach-haltige Wettbewerbsvorteile. Die Ergeb-nisse der Controllingphase dienen dabei alsEingabe für die nächste Iteration, um einekontinuierliche Verbesserung derGeschäftsprozesse zu erreichen. Auch beimDesign, der Implementierung und demControlling einer SOA werden alle Phasendes BPM-Lebenszyklus durchlaufen.

StrategiephaseAuf strategischer Ebene wird festgelegt,welche Ziele durch die gewünschtenProzessveränderungen erreicht werden sol-len, z.B. Einführung neuer Produkte und

Vertriebswege, Konsolidierung verschiede-ner Unternehmensbereiche, kürzereProzesslaufzeiten oder die Senkung vonProzesskosten. Diese fachlichen Ziele sindin dieser Phase des BPM-Lebenszyklusnoch unabhängig von deren Umsetzung inder IT. Ohne eine klare unternehmerischeZielsetzung wird es später jedoch schwerfallen, konkrete prozessbasierte Ziele abzu-leiten. Diese bilden wiederum dieGrundlage für eine technische Unterstüt-zung der fachlichen Prozesse.

DesignphaseSind die strategischen Ziele definiert, kön-nen die fachlichen Geschäftsprozesse unddie unterstützende IT-Landschaft inProzessmodellen dokumentiert werden. ImRahmen einer SOA werden fachliche Pro-zesse als Service-Konsumenten und Soft-wareanwendungen als Service-Anbieterbetrachtet. Eine konsistente Service-Archi-tekturplanung hilft später dabei, denEinsatz redundanter Services zu vermeiden.So können Implementierungs-, Wartungs-und Pflegekosten deutlich verringert wer-den. Die Beschreibung der Prozesse erfolgtbereits in dieser BPM-Phase vor demHintergrund der zukünftigen IT-Archi-tektur. Der Granularitätsgrad der Model-lierung kann so frühzeitig mit der techni-schen Service-Orientierung abgestimmtwerden.

Durch die Ableitung technischer Prozesseaus fachlichen Prozessaufzeichnungen kanndie Informationstechnologie optimal anden geschäftsspezifischen Aufgaben ausge-richtet werden. Gleichzeitig wird eineNormierung erreicht, die die spätereAbleitung und Orchestrierung der Serviceserleichtert.

ImplementierungsphaseIn der Implementierungsphase werden –basierend auf den modellierten fachlichenGeschäftsprozessen – die existierendentechnischen Services orchestriert. In einemersten Schritt wird geprüft, ob es für die zuunterstützenden fachlichen Funktionsbau-steine passende Services gibt. Neben derFrage nach der Granularität der Serviceskommt nun eine weitere große Frage-stellung auf dem Weg zur SOA ins Spiel:„Wie kann ich bei der großen Anzahl tech-nischer Services den Überblick behaltenund die richtigen Services für die Um-setzung der fachlichen Anforderungenidentifizieren?” Die Informationen zu denvorhandenen Services in einem Service-

Abb. 1: BPM-Lebenszyklus

Kreditsumme variieren. Dementsprechendwird der Prozess einem anderen Verlauf fol-gen. Die möglichen Verzweigungen werdendurch Geschäftsregeln definiert. Durch dieexplizite Definition der Geschäftregel undder Herauslösung aus der Prozessdefinitionkann bei einer Änderung der Regel derProzess unangetastet bleiben. Geschäfts-regeln bilden so ein wichtiges Werkzeug,um die Modellierung fachlicher Prozesse zuvereinfachen; gleichzeitig können sie auchals technische Services orchestriert und aus-geführt werden. Durch Wiederverwendungkann eine definierte Regel an verschiedenenStellen im Prozessablauf Entscheidungenfällen.

ControllingphaseIn der Controllingphase wird die Lei-stungsfähigkeit der SOA im Ausführungs-system gemessen. Nur so kann geprüft wer-den, ob die definierten Ziele erreichtwurden. Das Monitoring von Prozessenoder Geschäftsaktivitäten ist wichtig, umden Erfolg des SOA-Projekts bewerten undSchwachstellen in der IT-Architektur iden-tifizieren zu können. Typische Messgrößensind z. B. die Häufigkeit von Service-Aufrufen, die Dauer der Service-Aus-führung und die die Kommunikation derServices untereinander.

Die Geschäftsprozess-architektur als FundamentGeschäftsprozesse werden in Unternehmenin der Regel in einer mehrstufigen Vor-gehensweise modelliert. Ausgehend von derobersten Prozesshierarchie eines Unter-nehmens werden die Prozesse sukzessivedetailliert. Diese Verfeinerung erfolgt in derRegel über drei bis fünf Hierarchieebenen.Im Rahmen des SOA-Ansatzes wird nunparallel zu der fachlichen Prozesshierarchiedie technische Servicehierarchie aufgebaut.Während die fachlichen Prozesse in einemTop-down-Ansatz erarbeitet sind, werdendie bereits existierenden Services in einemBottom-up-Ansatz zu technischenProzessen orchestriert. Die Zusammen-hänge zwischen den beiden Hierarchiensind in Abbildung 2 dargestellt.

Die Geschäftsprozesse werden bis aufeine Granularitätsebene herunter gebro-chen, in der eine fachliche Funktion durcheinen technischen Service ausgeführt wer-den kann. Durch diese technische Anrei-cherung der Prozessbeschreibung mittelseiner Ereignisgesteuerten Prozesskette(EPK) kann eine automatisierte Trans-

34 35

werden. Somit wird bereits frühzeitig klar,welche von SAP angebotenen ServicesVerwendung finden oder welche eventuellzu verändern bzw. neu zu entwickeln sind.Auf der NetWeaver-Technologie basierendkönnen nun die in ARIS beschriebenenfachlichen Prozesse in eine Orchestrierungtechnischer Services überführt und dieProzesse in SAP ausgeführt werden.

Wird ein Service benötigt, der noch nichtvon einem Hersteller angeboten wird, mussder Funktionsbaustein entwickelt werden.Bereits bestehende Artefakte können hier alsEingabe z.B. für eine UML-basierte Service-Implementierung genutzt werden. Hier sindAnsätze wie die Model Driven Architecture(MDA) zunehmend von Bedeutung.

Ein Geschäftsprozess ist in den seltenstenFällen „einspurig”. Meist gibt es Ver-zweigungen, die durch bestimmte Kriteriendefiniert werden. Bei einer Kreditvergabewerden zum Beispiel die betroffenen Frei-gabehierarchien mit der Höhe der

Repository sind meist technisch. Es fälltsomit schwer einzuschätzen, ob der ange-botene Service auch wirklich die An-forderungen der Fachbereiche erfüllt. Indiesem Zusammenhang ist es von entschei-dender Bedeutung, ein Service-Repositoryanzubieten, das technische Service-Be-schreibungen zu den fachlichen Prozess-beschreibungen in Beziehung setzt.

Das „Enterprise Service Repository” derSAP AG folgt genau dieser Zielsetzung. Esenthält sowohl die fachlichen Beschrei-bungen der Service-Komponenten auf Basisder Unternehmensprozesse als auch dietechnische Dokumentation der angebote-nen Services. Zusätzlich werden Referenz-prozesse abgebildet, die sich mit denServices umsetzen lassen. Wenn beispiels-weise bereits klar ist, dass eine „SAPEnterprise SOA” umgesetzt werden soll,können in dieser Phase bereits die von SAPangebotenen Services mit den identifiziertenAktivitäten im Prozessdesign abgeglichen

schwerpunk t

Abb. 2: Hierarchie der Geschäftsservices auf Basis der Hierarchie derGeschäftsprozesse

Abb. 3: Zehn Schritte vom fachlichen Prozess zum Enterprise-Service

5 / 2 0 0 6

schwerpunk t

formation des fachlichen Prozesses in einentechnischen BPEL-Prozess durchgeführtwerden. Nachdem die Transformation aufder Ebene 1 durchgeführt wurde, könnendiese Prozesse auf der Ebene 2 wiederumals technische Geschäftsservices betrachtetwerden. Ein Geschäftsservice kann somiteinen kontextuell abgeschlossenen Prozessaufrufen bzw. zusammenfassen. Durch die-se Schachtelung von technischen Prozessenkönnen später komplexe fachliche Prozesseausgeführt werden. Auf Ebene 3 werdenalle Prozesse der Ebenen 1 und 2 in einemübergeordneten Prozess kombiniert.

Durch die enge Integration der fach-lichen Prozesse mit den technischenServices wird ein Hauptziel einer SOAerfüllt: die flexible und schnelle Anpassungder IT an die sich ständig änderndenGeschäftsprozesse der Organisation.

Zur erfolgreichen Einführung einer SOAempfiehlt die IDS Scheer AG eine 10-Schritt-Methodik, basierend auf demWerkzeug „ARIS SOA Designer” (sieheAbb. 3).

Schritt 1: Service-orientierteProzessmodellierungIn dieser Phase werden die übergeordnetenfachlichen Prozessmodelle modelliert.Diese Prozesse sind meist noch nicht zurAusführung bestimmt. Ausgehend von denProzessen der höchsten Abstraktionsebeneerfolgt die service-orientierte Prozess-modellierung in einem Top-down-Ansatz.Durch die Aufnahme der Wertschöp-fungsabläufe wird ersichtlich, welcheEigenschaften technischen Services aufwei-sen müssen, um die definierten fachlichenAktivitäten zu unterstützen.

In Abbildung 4 ist ein einfacher Sales-Prozess in einer EPK dargestellt. DasProzessmodell beinhaltet unter anderemden Schritt Initiate Production Scheduling(Produktionsplanung starten). DieserFunktionsbaustein soll nun im Rahmeneiner SOA-Initiative durch einen Serviceautomatisiert werden. Die fachliche Akti-vität ist durch Ein- und Ausgabedatengenauer beschrieben. Im Beispiel hat derProzessschritt als Eingabedatum die

Purchase Order (Auftrag) und als Ausgabeden Schedule (Produktionsplan).

Schritt 2: Import undBeschreibung der ServicesDurch den Import von WSDL-Dateien(Web-Services Description Language) kön-nen Beschreibungen von Services in ARISimportiert werden. Die rein technischeService-Definition (Interfaces, Operatio-nen, Parameter, Messages, Datentypen)machen es dem SOA-Architekten jedochschwer, passende Services zu identifizieren.ARIS bietet daher ein automatisiertesMapping von Prozessaktivitäten und geeig-netem Service, basierend auf den fachlichenAnforderungen und den technischenService-Beschreibungen.

Anhand der Ein- und Ausgabedaten desProzessschrittes Initiate ProductionScheduling in Abbildung 4 kann ein geeig-neter Service – soweit dieser vorhanden ist– identifiziert werden. Wird kein entspre-chender Service gefunden, kann dieProzessdefinition angepasst, ein existieren-

Abb. 4: Ereignisgesteuerte Prozesskette

36 37

schwerpunk t

die in einem Service einer höheren Hierar-chiestufe abgebildet werden, einen konkretenGeschäftsvorgang umsetzen. Dabei darf dieDetaillierungsstufe weder zu niedrig (zu hoheKomplexität), noch zu hoch (zu geringe Flexi-bilität) sein. Das Augenmerk sollte immer aufder Wiederverwendbarkeit des Service liegen.

Das Objekt Scheduling in Abbildung 5repräsentiert den Service, der den Prozess-schritt Initiate Production Scheduling auto-matisieren wird. In hinterlegten UML-Diagrammen ist der Service weiter spezifiziert.

Schritt 4: Umwandlung des Prozessesin technischen AblaufNachdem die EPK durch die technischenServices angereichert wurde, kann nun dieTransformation zum BPEL-Prozess gestar-tet werden. Diese Überführung ist notwen-dig, da die Ausführung eines Prozesses ineinem IT-System zusätzliche technischeInformationen erfordert, die dem fach-lichen Prozess fehlen. Dabei wird nicht nurder Ablauf des Geschäftsprozesses übertra-gen, sondern auch die bereits enthaltendenService-Informationen. Gleichzeitig fallenfachliche Prozessinhalte weg, die für dietechnische Ausführung irrelevant sind.

Abbildung 6 zeigt den aus der EPK inAbbildung 4 generierten BPEL-Prozess. Diegrafische BPEL-Modellierungsnotation istBestandteil des ARIS SOA Designers. DasInvoke-Element Initiate ProductionScheduling ist mit einem BPEL-AllocationDiagram hinterlegt, in dem der Aufruf desServices weiter spezifiziert ist.

Schritt 5: Vervollständigungdes Service-DesignsIst die EPK in einen BPEL-Prozess umge-wandelt, kann eine manuelle Nachbear-beitung erfolgen. Zusätzliche technischeInformationen werden im Prozess definiert.Am Ende dieses Schrittes steht eine voll-ständig ausführbare technische Beschrei-bung des Geschäftsprozesses.

Schritt 6: Export des Service-DesignsDer grafische BPEL-Prozess wird durch eineautomatisierte Transformation in eine XML-Datei exportiert. Gleichzeitig wird eineWSDL-Datei generiert, die den erstelltenService beschreibt. Beide Dateien können zuAusführungsplattformen übertragen werden.

Schritte 7-10: Ausführung des ServicesDie gängigen Integrations- und Applika-tionsplattformen haben in den letzten Jahren

Schritt 3: Ergänzung des Prozessesum ServicesIm Geschäftsprozess werden nun die fach-lichen Aktivitäten mit den zugehörigen Ser-vices verbunden. Dabei muss darauf geachtetwerden, dass jede Aktivität durch einen Serviceabgedeckt wird. Gleichzeitig sollten Prozesse,

der Service modifiziert oder ein neuerService implementiert werden. In letzteremFall werden in der Modellierung neueServices definiert. Diese neuen Elementestellen dann die Grundlage für die Neu-entwicklung des fehlenden Service dar.

Abb. 5: Service im Prozessmodell

Abb. 6: Automatisch generierter BPEL-Prozess

1 / 2 0 0 6

schwerpunk t

spezifische Erweiterungen des BPEL-Stan-dards eingeführt. Diese Plattformspezifikamüssen in das technische Prozessdesign aufge-nommen werden. Nachdem die Prozesse umplattformspezische Informationen erweitertbzw. neu implementierte Services installiertwurden, müssen die abschließenden Test- undFehlerbehebungsaktivitäten durchgeführtwerden. Der Geschäftsservice ist nun für dieAusführung bereit.

Ein Repository fürBusiness- und IT-LogikAlle beschriebenen Elemente einer SOAspielen zusammen – angefangen vom fach-lichen Prozessmodell, über die abgeleitetentechnischen Services, die UML-basierteService-Entwicklung, bis hin zur Regel-ausführung durch Business Rules Services.Wird der fachliche Prozess modifiziert, hatdies zwangsläufig Auswirkungen auf dietechnische Service-Orchestrierung. Werdendie technischen Service-Aufrufe ungünstigverändert, wird der entsprechende Fach-bereich in seiner Wertschöpfung beein-trächtigt sein. Ändern sich die Geschäfts-regeln (z. B. bei einer Kreditvergabe), mussdies sowohl im Prozessmodell als auch inder technischen Ausführung angepasst wer-den. Zeitliche Verzögerungen in der Syn-chronisation zwischen fachlichem Modellund technischer Ausführung führen schnellzu Inkonsistenzen und damit zu wirtschaft-lichen Problemen. Es bietet sich daher an,alle Elemente einer SOA in einemRepository zu konzentrieren (siehe Abb. 7).

Durch die Zusammenführung der fach-lichen und technischen SOA-Ebenen in ARISwerden wechselseitige Abhängigkeiten trans-parent und steuerbar. Per Mausklick kannherausgefunden werden, welcher Service inwelchem Prozess verwendet wird. BeimAusfall eines Service kann schnell geprüft wer-den, welcher Geschäftsprozess beeinträchtigtist und wer im Fachbereich und in der IT-Abteilung benachrichtigt werden muss. InARIS wird so ein umfassendes semantischesService-Repository aufgebaut. Durch die weit-gehend automatisierte Überführung vonARIS-Prozessmodellen in ausführbare BPEL-Modelle wird gleichzeitig die Synchronisationzwischen fachlichem Modell und technischerAusführung stark vereinfacht.

ZusammenfassungEine SOA beginnt und endet mit denGeschäftsprozessen eines Unternehmens.Durch die Ableitung technischer Abläufe

Abb. 7: ARIS – Ein Repository für Business- und IT-Logik

aus betriebswirtschaftlichen Prozessstruk-turen und die Verwendung eines einheit-lichen Repositorys für Business- und IT-Logik wird die Kluft zwischen Fachbereichund IT-Abteilung geschlossen. Die Modelleauf der technischen Ebene entsprechen derprogrammierten Realität und führendadurch zu einer hohen Nutzerakzeptanz.Gleichzeitig werden Unternehmen in dieLage versetzt, innovative Geschäftsstrate-gien und die zu Grunde liegenden Prozesseschnell und flexibel zu realisieren.

Ein weiterer Meilenstein für eine durch-gängige Prozessmanagement-Lösung fürBetriebswirtschaft und Informations-technik auf Basis einer SOA steht jetzt an.Die Modellierungsumgebung von ARISwird in den künftigen Versionen von SAPNetWeaver ein direkter Bestandteil des„SAP Enterprise Services Repository”,einer Weiterentwicklung des jetzigen „SAPNetWeaver XI Integration Repository”.Dies erlaubt eine elegante Integration vonbetriebswirtschaftlicher Prozesssicht undsystemseitiger Ablauflogik ohne Schnitt-

stellen- oder Medienbrüche in einem zen-tralen Repository. Die Integration vonbetriebswirtschaftlichem Prozesswissen mitder technischen „Orchestrierung” vonEnterprise-Services ermöglicht die evolutio-näre Umsetzung einer flexiblen, service-orientierten Umgebung auf Basis dermodellierten Geschäftsanforderungen. ■

Literatur[Sch04] A.-W. Scheer, F. Abolhassan, W.

Jost, M. Kirchmer (Hrsg.), Business Process

Automation - Combining Best and Next

Practices, Springer, 2004

[Sch05] A.-W. Scheer, W. Jost, K. Wagner

(Hrsg.), Von Prozessmodellen zu lauffähigen

Anwendungen, Springer, 2005

[Sch06] A.-W. Scheer, H. Kruppke, W. Jost,

H. Kindermann (Hrsg.), Agilität durch ARIS

Geschäftsprozessmanagement, Springer,

2006

[Woo06] D. Woods, T. Mattern, Enterprise

SOA – Designing IT for Business Innovation,

O'Reilly, 2006