6
GESCHÄFTSPROZESSMANAGEMENT ALS GRUNDLAGE FÜR SOA licher Anforderungen aus Sicht der Unternehmenssteuerung in die IT-Systeme. Die großen Hersteller von Unterneh- menssoftware entsprechen mit ihren Strategien immer stärker diesem Trend. Während sich beispielsweise IBM als Technologielieferant für eine durchgängige SOA positioniert, bietet SAP mit dem Konzept der Enterprise SOA nicht nur die technologischen Voraussetzungen für eine service-orientierte Architektur (z. B. durch die Werkzeuge im „SAP NetWeaver”), son- dern auch die funktionalen Bausteine innerhalb der SAP-Systeme, die hinter der service-orientierten Technologie liegen. SAP liefert somit sowohl die technologische Plattform für eine SOA als auch die betriebswirtschaftlichen Inhalte in Form von fertigen Services. Diese können dann basierend 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ür die fachliche Prozessmodellierung (wie bei- Das Thema SOA hat in den letzten Monaten viel Beachtung gefunden. Es wurde jedoch im überwiegenden Maße auf der technischen Ebene diskutiert. Dabei wur- de die eigentliche Aufgabenstellung der IT häufig aus den Augen verloren: die Unterstützung der Unternehmensprozesse. In diesem Artikel wird dargestellt, wie aufbauend auf Geschäftsprozessen technische Services abgeleitet und im Rahmen einer 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. mehr zum thema: www.aris.de www.ids-scheer.de 1 Eric Brabänder (E-Mail: [email protected]) ist bei der IDS Scheer AG für das internationa- le Produkt-Marketing der „ARIS Platform” verantwortlich. Er betreut konzeptionell das Softwareprodukt „ARIS for SAP Netweaver” und die Entwicklung der in SAP NetWeaver integrierten ARIS-Lösung. Jörg Klückmann (E-Mail: [email protected]) ist bei der IDS Scheer AG für das interna- tionale Produkt-Marketing rund um die „ARIS Implementation Platform” ver- antwortlich. ten in den kommenden fünf Jahren Ein- sparungen von bis zu 53 Mrd. US-Dollar durch SOA, wie die Aberdeen Group in einem aktuellen IT-Benchmark-Report pro- gnostiziert. Ein weit verbreiteter Irrglaube ist jedoch, dass SOA zum einen gleichbedeutend mit Web-Services und zum anderen als Produkt käuflich erwerbbar ist. Das Gegenteil ist der Fall. Denn SOA ist in erster Linie ein Management- und Architekturkonzept, das eine IT-Infrastruktur fordert, die flexibel auf veränderte Anforderungen im Unter- nehmensumfeld reagiert. Das dazugehörige Systemarchitektur-Konzept zerlegt die Unternehmenssoftware in fachliche Funk- tionseinheiten, die durch kleine Soft- warebausteine ausgeführt werden. Diese Funktionsbausteine können durch modell- gestützte Konfiguration ohne größeren Programmieraufwand an die unternehmeri- schen Anforderungen flexibel angepasst werden. 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 technologische Basis für die Realisierung eines agilen Unternehmens ist, wird sehr schnell klar, dass neben der reinen Diskussion um die technologische Umsetzung auch der fachli- che Bezug eine stärkere Rolle spielt. Wo bisher standardisierte Prozesse als inte- grierte Funktionalität einer Standardsoft- ware ausgeliefert wurden, können diese Prozesse nun wesentlich flexibler gestaltet und somit natürlich auch enger an der Unternehmensstrategie ausgerichtet wer- den. Aus diesem Grund ist das Geschäfts- prozessmanagement eine wesentliche Voraussetzung für die Übersetzung fach- BPM + SOA = Agilität Der Erfolg eines Unternehmens wird immer mehr dadurch bestimmt, wie schnell es auf geänderte Marktbedingungen mit adäqua- ten Produkten und Dienstleistungen reagie- ren kann. Viele Unternehmen nutzen zur Steigerung ihrer Handlungsagilität bereits ein aktives Geschäftsprozessmanagement (Business Process Management, BPM). Während die fachliche Beschreibung bzw. Anpassung der Geschäftsprozesse mittels spezieller Prozessdesign- und Analysewerk- zeuge deutlich beschleunigt werden kann, kommt es bei der Umsetzung der Geschäftsprozesse in die unterstützende IT- Landschaft zu teilweise erheblichen Ver- zögerungen. Die in den letzten Jahren propagierte feste Verzahnung von Anwendungen und Prozessabläufen auf einer zentralen mono- lithischen Applikationsstruktur lässt sich nur unter erheblichem Zeit- und Kosten- aufwand modifizieren. Fehlende Dokumen- tationen und intransparente IT-Land- schaften tragen ihr übriges dazu bei, dass sich die IT eher zum Bremser als zum Beschleuniger entwickelt hat. Der Markt für betriebswirtschaftliche Anwendungssoftware steht nicht zuletzt deshalb vor einem technologischen Para- digmenwechsel. Service-orientierte Archi- tekturen (SOAs) sollen den Einsatz und den Nutzen von Software in den Unternehmen revolutionieren. Der Traum von einer Software, die eine agile Unternehmens- steuerung unterstützt, soll so Realität wer- den. Bis zum Jahr 2010 werden laut Prognose der Analysten der Gartner Group mindestens 65% der großen Unternehmen mehr als 35% ihres Anwendungs- Portfolios auf eine SOA umgestellt haben. Die weltweit größten Unternehmen erwar- die autoren advertorial

GESCHÄFTSPROZESSMANAGEMENT ALS GRUNDLAGE FÜR SOA

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

GESCHÄFTSPROZESSMANAGEMENT

ALS GRUNDLAGE FÜR SOA

licher Anforderungen aus Sicht derUnternehmenssteuerung in die IT-Systeme.Die großen Hersteller von Unterneh-menssoftware entsprechen mit ihrenStrategien 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-

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

1

Eric Brabänder (E-Mail:[email protected]) 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:[email protected]) istbei der IDS Scheer AG für das interna-tionale Produkt-Marketing rund um die„ARIS Implementation Platform” ver-antwortlich.

ten in den kommenden fünf Jahren Ein-sparungen von bis zu 53 Mrd. US-Dollardurch 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-

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 eher 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-

d ie au torenadver tor i a l

adver tor i a l

spielsweise ARIS) für die Softwareherstellereine entscheidende Rolle spielt.

Von wachsender Bedeutung ist in diesemZusammenhang auch die XML-basierteSprache 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 technischenServices 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 undVertriebswege, 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:

Abb. 1: BPM-Lebenszyklus

2

3 / 2 0 0 6

adver tor i a l

den 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-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 dem

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 derKreditsumme 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, um

„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-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 abgeglichenwerden. 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.

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

w w w. s i g s - d a t a c o m . d e 3

adver tor i a l

Werkzeug „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 den

Prozessen 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. Das

Prozessmodell 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 diePurchase 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-

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

Abb. 4: Ereignisgesteuerte Prozesskette

4

adver tor i a l

Schritt 6: Export des Service-DesignsDer grafische BPEL-Prozess wird durcheine automatisierte Transformation in eineXML-Datei exportiert. Gleichzeitig wirdeine WSDL-Datei generiert, die den erstell-ten Service beschreibt. Beide Dateien kön-nen zu Ausführungsplattformen übertragenwerden.

Schritte 7-10: Ausführung des ServicesDie gängigen Integrations- und Applika-tionsplattformen haben in den letztenJahren spezifische Erweiterungen desBPEL-Standards eingeführt. Diese Platt-formspezifika müssen in das technischeProzessdesign aufgenommen werden.Nachdem die Prozesse um plattformspezi-sche Informationen erweitert bzw. neuimplementierte Services installiert wurden,müssen die abschließenden Test- undFehlerbehebungsaktivitäten durchgeführtwerden. Der Geschäftsservice ist nun fürdie Ausführung bereit.

netem Service, basierend auf den fachlichen Anforderungen und den technischen Service-Beschreibungen.

Anhand der Ein- und Ausgabedaten des Prozessschrittes Initiate Production Schedulingin Abbildung 4 kann ein geeigneter Service – soweit dieser vorhanden ist – identifiziertwerden. Wird kein entsprechender Service gefunden, kann die Prozessdefinition angepasst,ein existierender Service modifiziert oder ein neuer Service implementiert werden. In letz-terem Fall werden in der Modellierung neue Services definiert. Diese neuen Elemente stel-len dann die Grundlage für die Neuentwicklung des fehlenden Service dar.

Schritt 3: Ergänzung des Prozesses um ServicesIm Geschäftsprozess werden nun die fachlichen Aktivitäten mit den zugehöri-gen Services verbunden. Dabei muss darauf geachtet werden, dass jedeAktivität durch einen Service abgedeckt wird. Gleichzeitig sollten Prozesse, diein einem Service einer höheren Hierarchiestufe abgebildet werden, einen kon-kreten Geschäftsvorgang umsetzen. Dabei darf die Detaillierungsstufe weder zuniedrig (zu hohe Komplexität), noch zu hoch (zu geringe Flexibilität) sein. DasAugenmerk sollte immer auf der Wiederverwendbarkeit des Service liegen.

Das Objekt Scheduling in Abbildung 5 repräsentiert den Service, der denProzessschritt Initiate Production Scheduling automatisieren wird. In hinter-legten UML-Diagrammen ist der Service weiter spezifiziert.

Schritt 4: Umwandlung des Prozesses in technischen AblaufNachdem die EPK durch die technischen Services angereichert wurde, kannnun die Transformation zum BPEL-Prozess gestartet werden. Diese Überfüh-rung ist notwendig, da die Ausführung eines Prozesses in einem IT-Systemzusätzliche technische Informationen erfordert, die dem fachlichen Prozessfehlen. Dabei wird nicht nur der Ablauf des Geschäftsprozesses übertragen,sondern auch die bereits enthaltenden Service-Informationen. Gleichzeitigfallen fachliche Prozessinhalte weg, die für die technische Ausführung irrele-vant sind.

Abbildung 6 zeigt den aus der EPK in Abbildung 4 generierten BPEL-Prozess.Die grafische BPEL-Modellierungsnotation ist Bestandteil des ARIS SOADesigners. Das Invoke-Element Initiate Production Scheduling ist mit einemBPEL-Allocation Diagram hinterlegt, in dem der Aufruf des Services weiter spe-zifiziert ist.

Schritt 5: Vervollständigung des Service-DesignsIst die EPK in einen BPEL-Prozess umgewandelt, kann eine manuelleNachbearbeitung erfolgen. Zusätzliche technische Informationen werden imProzess definiert. Am Ende dieses Schrittes steht eine vollständig ausführba-re technische Beschreibung des Geschäftsprozesses.

Abb. 5: Service im Prozessmodell

3 / 2 0 0 6 w w w. s i g s - d a t a c o m . d e

Abb. 6: Automatisch generierter BPEL-Prozess

5

adver tor i a l

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,

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

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

alle Elemente einer SOA in einemRepository zu konzentrieren (siehe Abb. 7).

Durch die Zusammenführung der fach-lichen und technischen SOA-Ebenen inARIS werden wechselseitige Abhängigkei-ten transparent und steuerbar. Per Maus-klick kann herausgefunden werden, wel-cher Service in welchem Prozess verwendetwird. Beim Ausfall eines Service kannschnell geprüft werden, welcher Geschäfts-prozess beeinträchtigt ist und wer imFachbereich und in der IT-Abteilungbenachrichtigt werden muss. In ARIS wirdso ein umfassendes semantisches Service-Repository aufgebaut. Durch die weitge-hend automatisierte Überführung vonARIS-Prozessmodellen in ausführbareBPEL-Modelle wird gleichzeitig dieSynchronisation zwischen fachlichemModell und technischer Ausführung starkvereinfacht.

ZusammenfassungEine SOA beginnt und endet mit denGeschäftsprozessen eines Unternehmens.Durch die Ableitung technischer Abläufeaus 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. ■

6