Management abstract

Das Thema Integration ist durch die Ausbreitung von SOA aktueller denn je geworden. Sowohl die Ära der isolierten betrieblichen Informationssysteme auch als die der Silos, auch Stovepipe genannt, ist endgültig vorbei (vgl. Liebhart et al. 2008, S.1). Die Anwendung, die zu einem bestimmten Zweck erstellt worden ist, ohne dass sie sich mit anderen Systemen austauschen muss, ist unwahrscheinlich. Dies ist auch für die webbasierte Projektmanagement-Software „Blue Ant“ des jungen Berliner Beratungs- und Softwarehaus proventis GmbH der Fall.

Durch den Erfolg des Produkts im Enterpriseumfeld mit aktuellen Kunden, wie z.B. Porsche oder Berliner Bank, stellt sich für das Unternehmen in immer größerem Umfang die Notwendigkeit, sich mit Integrationsproblematiken bzw. deren Lösungen im Enterpriseumfeld zu beschäftigen, wobei aktuell kein Wissen vorhanden ist.

Als Standardarchitektur für die Integration setzt sich SOA mehr und mehr durch. Wobei SOA als Ganzes betrachtet, eine unterstützende Funktion für betriebliche Abläufe einer IT-Systemlandschaft darstellt. SOA ermöglicht es Prozesse einfacher und schneller zu gestalten und umzugestalten. Dadurch wird eine deutlich höhere Flexibilität erreicht. Darüber hinaus stehen Dienste bzw. Services zur Verfügung, die in einer anderen Anwendung wieder verwendet werden können. Außerdem können neue Dienste und Produkte schneller am Markt eingeführt und bestehende Dienste schneller an neue Anforderungen angepasst werden. Dies führt dazu, dass die Kosten für Entwicklung und Wartung gesenkt werden können. Der Blueprint für die Systemintegration hilft bei der richtigen Umsetzung auf Basis von SOA, ohne das Gesamtbild einer flexiblen, skalierbaren, performanten und bezahlbaren Unternehmensarchitektur aus den Augen zu verlieren.

Seite I

INHALTSVERZEICHNIS

Inhaltsverzeichnis   

MANAGEMENT  ABSTRACT.  I

ABBILDUNGSVERZEICHNIS   VI

TABELLENVERZEICHNIS   VIII

ABK  ÜRZUNGSVERZEICHNIS.  IX

DANKSAGUNG   XIV

1  EINLEITUNG  1

1.1  PROBLEMSTELLUNG UND ZIELSETZUNG  1

1.2  ABGRENZUNG  2

1.3  AUFBAU DER ARBEIT  2

2  GRUNDLAGEN.  4

2.1  GESCHÄFTSPROZESS UND WORKFLOW  4

2.1.1  Begriff des Prozesses  4

2.1.2  Begriff des Geschäftsprozesses.  5

2.1.3  Komponenten von Geschäftsprozessen.  6

2.1.4  Begriff des Workflows  7

2.1.5  Gegenüberstellung von Geschäftsprozess und Workflow  9

2.1.6  Fazit.  10

2.2  GESCHÄFTSPROZESSMODELLIERUNG (BUSINESS PROCESS MODELING)  10

2.2.1  ARIS-Architektur integrierter Informationssysteme.  11

2.2.1.1  Modellierungskonzept  11

2.2.1.2  EPK Ereignisgesteuerte Prozesskette.  12

2.2.1.3  Erweiterte Ereignisgesteuerte Prozesskette (eEPK)  14

2.2.1.4  Modellierungsregeln.  15

2.2.2  BPEL oder BPEL4WS.  15

2.2.2.1  Kontrollfluss eines BPEL-Prozesses  16

2.2.2.2  BPEL-Basiselemente  17

2.2.2.3  BPEL Activities.  17

2.2.2.4  Beispiel von BPEL und WSDL.  18

2.2.3  Fazit.  18

2.3  SERVICE-ORIENTIERTE ARCHITEKTUREN (SOA)  19

2.3.1  Grundlegende Merkmale einer SOA  20

Seite II

INHALTSVERZEICHNIS

2.3.1.1  Lose Kopplung  20

2.3.1.2  Dynamisches Binden  21

2.3.1.3  Verzeichnisdienst  22

2.3.1.4  Verwendung von Standards  22

2.3.1.5  Einfachheit  22

2.3.1.6  Sicherheit  22

2.3.2  Merkmale einer SOA bzgl. komplexer Aspekte  23

2.3.3  Was ist eine Service-orientierte Architektur?  23

2.3.3.1  Die Sichtweise der Analysten  23

2.3.3.2  Die Definitionen der großen Hersteller  24

2.3.4  Service (Dienste) als Grundkomponente.  26

2.4  DIE WICHTIGSTEN STANDARDS.  26

2.4.1  Web Services.  27

2.4.1.1  Definition Web Services  27

2.4.1.2  Web Service-Basistechnologie.  28

2.4.1.3  Bestandteile einer Web Service-Architektur  28

2.4.1.3.1  Dienstanbieter (Service Provider)  28

2.4.1.3.2  Dienstnachfrager (Service Requestor)  28

2.4.1.3.3  Dienstmakler (Service Broker)  29

2.4.1.4  Aktionen.  29

2.4.2  Grundlegende Standards SOAP, WSDL und UUDI.  30

2.4.2.1  SOAP.  30

2.4.2.1.1  Aufbau einer SOAP-Nachricht.  31

2.4.2.1.2  SOAP-Verwandte.  33

2.4.2.2  WSDL  33

2.4.2.3  UDDI (Verzeichnisdienste für Web Services)  36

2.5  WEB SERVICES SCHICHTENMODELL (WEB SERVICE ARCHITEKTUR)  39

2.6  SOA-ARCHITEKTURMODELL.  41

2.6.1  Präsentation.  41

2.6.2  Geschäftslogik  41

2.6.3  Datenbank und Applikationssysteme  42

2.6.4  Prozesslogik  42

2.6.5  Servicelogik  42

2.6.6  Sonstige Geschäftslogik.  42

2.7  FAZIT.  43

2.8  PROJEKTMANAGEMENT (PM) UND WEBBASIERTES P-MTOOL  44

2.8.1  Was ist ein Projekt?  44

Seite III

INHALTSVERZEICHNIS

2.8.2  Was ist Projektmanagement (PM)?  45

2.8.3  Webbasiertes P-MTool.  45

2.8.4  Funktionen von P-MTool  46

2.8.5  Klassifikation von P-MTool  48

2.8.6  Fazit.  48

3  PROVENTIS GMBH.  50

3.1  DAS PRODUKT-BLUE ANT (BA)  50

3.2  FAZIT.  50

4  LÖSUNGSANSÄTZE FÜR EINE INTEGRATIONSPROBLEMATIK.  52

4.1  INTEGRATIONSANSÄTZE  52

4.1.1  Point-to-Point-Architektur  52

4.1.2  Hub-and-Spoke-Architektur.  53

4.1.3  Bus-/Pipeline-Architektur.  54

4.1.4  Service-orientierte Architektur  54

4.2  INTEGRATION ARCHITEKTURE.  55

4.2.1  Logische Integration.  55

4.2.2  Enterprise Service Bus.  56

4.2.2.1  Grundlegende Eigenschaften.  57

4.2.2.2  Nachrichtenorientierte Middleware (MOM)  58

4.2.2.3  Integration basierend auf Standards.  59

4.2.2.4  Die Entwicklung von ESB in den letzten Jahren  63

4.2.3  Data Integration  64

4.2.4  Prozess Integration  64

4.3  BESONDERHEIT EINER SOA-LÖSUNG  64

4.4  VORGEHENSWEISE  65

4.4.1  Top-Down  65

4.4.2  Bottom-Up.  65

4.4.3  Meet-in-the-Middle  66

4.4.4  Schrittweise Einführung  66

4.5  ARCHITEKTUR SZENARIEN BLUE ANT-INTEGRATION.  68

4.5.1  Blue Ant-Integration über AS/Broker-Web Services  69

4.5.2  Integration über ESB mit JBI  70

4.6  OPEN SOURCE SOA-STACK-BEWERTUNG  71

4.7  FAZIT.  73

5  UMSETZUNG DER ARCHITEKTUR „ARBEITSZEITERFASSUNG“  75

Seite IV

INHALTSVERZEICHNIS

5.1  WERKZEUGAUSWAHL.  75

5.1.1  Integrationsarchitektur mittels ESB  75

5.1.2  Orchestrierungsebene.  75

5.1.3  Service - Ebene.  76

5.1.4  Modellierung  76

5.1.5  IDE (integrated development environment)  76

5.2  ENTWICKLUNGSUMGEBUNG  76

5.3  VORGEHENSWEISE BEI DER UMSETZUNG  77

5.3.1  Beschreibung der fachlichen Geschäftsprozesse.  78

5.3.1.1  Arbeitszeiten im Backend-System erfassen  78

5.3.1.2  Arbeitszeiten im Blue Ant (BA)-System erfassen.  83

5.3.2  Beschreibung der technischen Geschäftsprozesse.  88

5.3.2.1  XML-Schema  88

5.3.2.2  WSDL  90

5.3.2.3  BPEL-Prozess.  91

5.3.3  BPEL-Prozess compilieren und deployen  94

5.3.4  BPEL-Prozess testen  94

5.4  FAZIT.  98

6  ZUSAMMENFASSUNG UND AUSBLICK  99

LITERATURVERZEICHNIS.   102

Seite V

ABBILDUNGSVERZEICHNIS   

Abbildungsverzeichnis   

Abbildung  2.1: Definition von Prozess (vgl. Schmelzer 2006, S. 60)  

Abbildung  2.2: Definition von Geschäftsprozess (vgl. Schmelzer 2006, S. 60)  

Abbildung  2.3: Komponenten von Geschäftsprozessen (vgl. Schmelzer 2006, S. 61)  

Abbildung  2.4: Verfeinerung der Geschäftsprozesse im Workflow (vgl. Freund, 2004)  

Abbildung  2.5: Geschäftsprozess vs. Workflow (vgl. Gadatsch 2005, S. 47)  

Abbildung  2.6: Das ARIS-Haus (vgl. Gadatsch 2005, S. 114)  

Abbildung  2.7: Standard Building Blocks von BPEL (vgl. Liebhart 2007, S. 19)  

Abbildung  2.8: BPEL und ein Web Service (vgl. Liebhart 2007, S. 21)  

Abbildung  2.9: SOA Tempel (vgl. Melzer et al. 2007, S. 11)  

Abbildung  2.10: Web Service-Dreieck (vgl. Melzer et al. 2007, S. 52)  

Abbildung  2.11: Protokoll Stack von Web Services (vgl. Liebhart et al. 2007, S. 295)  

Abbildung  2.12: SOAP-Nachrichtenstruktur: (vgl. Liebhart 2007, S. 15)  

Abbildung  2.13: WSDL-Dokument (Version 1.1) (vgl. Liebhart 2007, S. 16-17)  

Abbildung  2.14: WSDL-Nachrichtentypen (WSDL 1.1) (vgl. Liebhart 2007, S. 17)  

Abbildung  2.15: Die UDDI Business Registry (UBR) (vgl. Melzer et al. 2007, S. 149)  

Abbildung  2.16: UDDI (vgl. Melzer et al. 2007, S. 52)  

Abbildung  2.17: Web Services Stack (vgl. Melzer et al. 2007, S. 54)  

Abbildung  2.18: Service-orientierte Softwarearchitektur (vgl. Mathas2008, S. 28)  

Abbildung  4.1: Point-to-Point-Architketur (vgl. Liebhart et al. 2008, S. 24)  

Abbildung  4.2: Hub-and-Spoke-Architektur (vgl. Liebhart et al. 2008, S. 26)  

Abbildung  4.3: Bus-/Pipeline-Architektur (vgl. Liebhart et al. 2008, S. 27)  

Abbildung  4.4: Service-orientierte Architektur (vgl. Liebhart et al. 2008, S. 28)  

Abbildung  4.5: ESB-Aufbau nach dem JBI-Standard (vgl. Adelhardt, D., S. 18)  

Abbildung  4.6 JBI Architektur (vgl. White, Spec JSR 208)  

Abbildung  4.7: Blue Ant-Integration Passiv/Pull (eigene Darstellung)  

Abbildung  4.8: Blue Ant-Integration über AS/Broker-Web Services (eigene Darstellung)  

Abbildung  4.9: Ein Open Source SOA-Modell (vgl. Liebhart 2007, S. 56)  

Abbildung  5.1: Oracle BPEL Process Manager (vgl. o.V., Copyright 2004 Oracle)  

Abbildung  5.2: Entwicklungsumgebung mit integrierter Oracle BPEL Designer.  

Abbildung  5.3: Top-Down-Ansatz (eigene Darstellung)  

Abbildung  5.4: Arbeitszeiten im Backend-System erfassen (eigene Darstellung)  

Abbildung  5.5: Arbeitszeiten im BA-System erfassen (eigene Darstellung)  

Abbildung  5.6: XML-Schema der Arbeitszeiterfassung.  

Abbildung  5.7: XML-Schema des Fehlerfalls der Arbeitszeiterfassung.  

Seite VI

ABBILDUNGSVERZEICHNIS   

Abbildung  5.8: Auszug der WSDL-Datei für Arbeitszeiterfassung.  

Abbildung  5.9:BPEL-Prozess von Arbeitszeiterfassung  

Abbildung  5.10 Veröffentlichung der WSDL-Datei.  

Abbildung  5.11:Anmeldemaske von BPEL Console  

Abbildung  5.12: Oracle BPEL Console.  

Abbildung  5.13: Generiertes HTML-Formular.  

Abbildung  5.14: Ergebnis der asynchronen Kommunikation.  

Abbildung  5.15: Visueller Flow „Arbeitszeiterfassung“-Teil 1  

Abbildung  5.16: Visueller Flow „Arbeitszeiterfassung“-Teil 2  

Abbildung  5.17: Audit-Instanz für die Liste der „Arbeitszeiterfassung“  

Seite VII

Tabellenverzeichnis

Tabelle 2.1: Notation der Grundelemente der EPK (vgl. Gadatsch 2005, S. 158) .................13 Tabelle 2.2: Erweiterung der Notation der EPK (vgl. Gadatsch 2005, S. 160) ......................14 Tabelle 2.3: Aspekte der losen Systemkopplung (vgl. Mathas 2008, S. 21)..........................21 Tabelle 2.4: SOAP Fault Block (vgl. Melzer et al. 2007, S. 77) .............................................33 Tabelle 4.1: Vorgehensweise bei der schrittweisen Einführung (vgl. Liebhart 2007, S. 174f)67 Tabelle 4.2: Eine Auswahl von Open Source Tools für SOA (vgl. Liebhart 2007, S. 55).......72

Seite VIII

Abkürzungsverzeichnis

AJAX Asynchronous JAvaScript and XML Aufl. Auflage ARIS Architektur integrierter Informationssysteme BC Binding Components BCWP Budgeted Cost of Work Performed auch Earned Value BCWS Budgeted Cost For Work Scheduled auch Planed Value BPEL Business Process Execution Language BPEL4WS Business Process Execution Language for Web Service BPML Business Process Modeling Language bspw. beispielsweise bzw. beziehungsweise CDDL Community Development and Distribution License COM Component Object Model CORBA Common Object Request Broker Architecture CPM Critical Path Method DC Delivery Channel DCOM Distributed Component Object Model d.h. das heißt DIN Deutsches Institut für Normung e.V. DNS Directory Name Service EAI Enterprise Application Integration

Seite IX

EDV Elektronische Datenverarbeitung EII Enterprise Information Integration EIS Enterprise-Integrationsschicht EJB Enterprise JavaBeans eEPK Erweiterte Ereignisgesteuerte Prozesskette EPK Ereignisgesteuerte Prozesskette ERM Entity Relationship Model ERP Enterprise Ressource Planning ESB Enterprise Service Bus etc. et cetera FTP File Transfer Protocol GmbH Gesellschaft mit beschränkter Haftung GUI Graphical User Interface, HLA High Level Architecture Hrsg. Herausgeber HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IDE integrated development environment IDL Interface Definition Language i.d.R in der Regel IP Internet Protocol ISA Information System Architecture IT Informationstechnologie

Seite X

JBI Java Business Integration JCA Java Connector Architecture JMS Java Message Service JSP JavaServer Pages J2EE Java 2 Plattform Enterprise Edition MOM Message-oriented Middleware MPL Mozilla Public License MPM Metra-Potential-Method NMR Normalized Message Router o.J. ohne Jahr OMG Object Management Group o.g. oben genannt o. V. ohne Verfasser PC/PCT Percent Complete PERT Program Evaluation and Review Technique PM Projektmanagement REST Ressource orientierter Schnittstellenaufruf ROI Return of Invest RPC Remote Procedure Call- R/3 ERP der Firma SAP s. siehe S. Seite SE Service Engine

Seite XI

SMTP Simple Mail Transfer Protocol SOA Service-orientierte Architektur SOAP Simple Object Access Protocol sog. sogenannte SQL Structured Query Language s.u. siehe unten TCP Transmission Control Protocol TFH Technische Fachhochschule u. und u. a. und andere(s); unter anderem/anderen UDDI Universal Description Discovery and Integration URI Uniform Ressource Identifier URL Uniform Ressource Locator usw. und so weiter Verl. Verlage vgl. vergleiche WfMC Workflow-Management Coalition WS Web Services WSBI WebSphere Business Integration Server Foundation WSBPEL Web Service Business Process Execution Language WSDL Web Services Description Language WWW World Wide Web auch 3W, W3, Web genannt XLANG eXtensible Language

Seite XII

XML eXtensible Markup Language XSLT eXtensible Stylesheet Language Transformation z.B. zum Beispiel zw. zwischen z.Z. zur Zeit

Seite XIII

Danksagung

Ich widme diese Arbeit meiner geliebten kleinen Schwester und Freundin Aminata Diabaté, die am 15.12.2008 im Alter von nur 36 Jahren in meiner Heimat Mali von uns ging. Möge ihre Seele in Frieden ruhen.

An dieser Stelle möchte ich folgenden Personen für ihre Unterstützung bei der Erstellung dieser Masterarbeit danken.

Mein recht herzlicher Dank gilt meinem Betreuer Herrn Prof. Dr. Langenbacher für seine Unterstützung und die zahlreichen wissenschaftlichen Ratschläge, die ich während dieser Masterarbeit von ihm erhalten habe.

Ein großer Dank gilt der Firma proventis GmbH, im Besonderen Herrn Frischmuth und Herrn Eckert für die Bereitstellung der nötigen Basisdokumentation und Infrastruktur.

Ein ganz herzlicher Dank gelten meinem Chef Herrn Friedrich, der trotz des stressigen Beraterjobs, mir den Rücken in dieser Zeit freigehalten konnte, sowie meinem Arbeitskollegen Lars Bunge für die zahlreichen guten Ideen und Ratschläge, die Kritik und das Korrekturlesen.

Besonderer Dank gebührt meiner Ehefrau Ina Hellmuth-Diabaté (Mäuschen), die mich während des Studiums immer wieder motivierte und auf dem richtigen Weg hielt. Von Anfang an unterstützte sie mich beim Schreiben meiner Masterarbeit durch Zuhören, konstruktive Diskussionen und Korrekturlesen, so dass das Familienleben in dieser Zeit fast zum Erliegen kam. Vielen Dank für die persönlichen Entbehrungen.

Bedanken möchte ich mich auch bei meinen Eltern, die in Afrika leben und meinen neuen liebgewonnen Großeltern Omi und Opi in Warnsted, die mich immer wieder moralisch unterstützten.

Ohne die genannten Personen wäre diese Arbeit nicht möglich gewesen.

Seite XIV

KAPITEL 1 EINLEITUNG

1 Einleitung

Das Kernprodukt des 2001 gegründeten Berliner Beratungs- und Softwarehauses proventis GmbH ist die webbasierte Projektmanagement (PM)-Software Blue Ant, die derzeit in Deutschland, Österreich und in der Schweiz vertrieben wird. Blue Ant unterstützt den gesamten Projektlebenszyklus in einem durchgängigen Prozess von der Auftragserteilung über Termin- und Ressourcenplanung bis hin zum Nachweis der erbrachten Leistungen. Dabei folgt proventis dem Prinzip der Ganzheitlichkeit, in dem alle Beteiligten über die Software in die Projektarbeit einbezogen werden. Das steigert die Transparenz, verbessert die Kommunikation und macht die Projektarbeit für alle Beteiligten erfolgreicher. Somit können Kosten und Zeit eingespart werden (vgl. o.V. 2009, Produktinformation). Aufgrund der zunehmenden Komplexitäten der Projekte und des immer kürzer werdenden Produktenlebenszyklus und deren Geschäftsprozesse ist für die erfolgreiche Durchführung eines Projekts ohne Unterstützung von PM-Software in den heutigen Zeiten nicht vorstellbar. Die Integration solcher Software oder Anwendungen in eine bestehende IT-Systemlandschaft mit ERP-Systemen, Data Warehouses oder Portal-Lösungen und den dort abgebildeten Geschäftsprozessen bringt zusätzliche Anforderungen an die Integrationsfähigkeit der eingesetzten Software, sowie die Verwendung von Standard Enterprise Integrations-Architekturen (z.B. SOA), mit sich. Dies kann nur mit zusätzlichem fachlichen und technischen Aufwand bewältigt werden.

Zu den oben genannten Herausforderungen kommt noch hinzu, dass die Unternehmen in der Lage sein sollten, auf Änderungen der Unternehmensstruktur flexibel reagieren zu können. Der Ansatz der serviceorientierten Architektur (SOA) mit Web Services verspricht, diese Aufgabe bewältigen zu können und dabei gleichzeitig die IT-Kosten zu senken.

1.1 Problemstellung und Zielsetzung

Durch den Erfolg des Produkts im Enterpriseumfeld mit aktuellen Kunden, wie z.B. Porsche, Berliner Bank, stellt sich in immer größerem Umfang für das Unternehmen die Notwendigkeit, sich mit Integrationsproblematiken bzw. deren Lösungen im Enterpriseumfeld zu beschäftigen, wobei aktuell kein Wissen vorhanden ist.

Ziel der Masterarbeit soll es sein, einen grundlegenden Ansatz (konzeptionell sowie technologisch) für diese Problemstellung zu liefern, d.h. für diese Arbeit ergibt sich daraus für den praktischen Teil die Konzeption und Realisierung der Blue Ant-Web Sevices sowie die theoretische Betrachtung eines möglichen Integrationsszenarios (trivial). Die Lösung wird nicht auf einen speziellen Kunden ausgerichtet, sondern soll als Basis für den Wissensaufbau in der Firma, sowie Blueprint (Blaupause) für Integrationsanforderungen von Kunden dienen.

Seite 1

KAPITEL 1 EINLEITUNG

Das Konzept soll für die Realisierung einer breiteren und flexibleren Integration von Blue Ant (BA) (Prototype bzw. Blaupause) mit Fremdsystemen bzw. Backendsysteme wie z.B. SAP, Zeiterfassungssystem-Datenbank oder Queue abgedeckt werden und die möglichen Lösungsansätze mit deren Vor- und Nachteilen darlegen zu können. Diese Integration basierend auf Standards wie ESB (Enterprise Service Bus), die gleichen Integrationskonzepte wie Enterprise Application Integration (EAI) nutzt oder BPEL Business Process Execution Language) für Web Service auch BPEL4WS (Business Process Execution Language for Web Service). Diese Integrationslösung soll dabei die Anforderungen eines Kunden erfüllen und mit einem vernünftigen Aufwand realisiert werden.

Um das erreichen zu können, wird der Geschäftsprozess „Arbeitszeiterfassung“ für die Integration sowohl fachlich als auch technisch beschrieben. Danach wird ein Konzept erstellt, wie dieser Geschäftsprozess zu integrieren ist, dabei sind die möglichen Integrationsszenarien zu erläutern und darzulegen, anschließend folgt die Realisierung des Geschäftsprozesses „Arbeitzeiterfassung“. Abschließend ist die adäquate Werkzeugauswahl für die Realisierung auch Bestandteil der Zielsetzung.

1.2 Abgrenzung

Die Auswahl der standardisierten und bewährten Grundkomponenten mit Hilfe von Tools und Produkten für ein funktionierendes Ganzes basiert auf Open Source Produkten bzw. Software. Es wird in der Masterarbeit keine Prozess- bzw. Geschäftprozessanalyse eines realen Kunden durchgeführt, sondern als Grundlage wird ein „Metaprozess“ dienen. Unter Metaprozess wird hier eine kleinstmögliche, allgemeingültige Prozesskette verstanden, die in Absprache mit der Firma proventis GmbH entwickelt wird. Eine Integration unter Zuhilfenahme eines kommerziellen Brokers (z.B. IBM-WSBI, WebSphere Business Integration Server Foundation) ist grundsätzlich möglich und in den Unternehmen klar der favorisierte Weg, aber die Realisierung solcher Lösung ist aufwendig und kann nicht berücksichtig werden, weil diese den Rahmen dieser Arbeit sprengt.

1.3 Aufbau der Arbeit

In diesem Kapitel wird die Vorgehensweise dieser Arbeit beschrieben. Nach dem Abstract und der Einleitung werden in Kapitel 2 die wesentlichen Begriffe der Themenbereiche von Geschäftsprozessen, Workflow, Modellierungsmöglichkeiten sowie von SOA erläutert. Zu den Modellierungsmöglichkeiten wird auf zwei der bekanntesten Ansätze, den ereignisgesteuerten Prozessketten (EPK) von ARIS auf der fachlichen Ebene und BEL4WS (Business Process Execution Language for Web Services) kurz BPEL und BPML (Business Process Modeling Language) auf der technischen Ebene eingegangen. Außerdem werden standardi-

Seite 2

KAPITEL 1 EINLEITUNG

sierte Services als Grundkomponente und der konsequente Einsatz der Standards SOAP, WSDL und BPEL als ausführbarer Geschäftsprozess den wesentlichen Bestandteil dieser Grundlage dargestellt. Danach wird auf das SOA Architekturmodell, das als ein Architekturkonzept für verteilte und lose gekoppelte Systeme zu verstehen ist und deren technische Bandbreite und Vielfalt ernorm sind, näher eingegangen. Abschließend werden Projektmanagement (PM), webbasierte PM-Tools und deren Nutzen für die Abwicklung eines Projektes erläutert.

Anschließend werden in Kapitel 3 das 2001 in Berlin gegründete Software- und Beratungshaus „proventis GmbH“ und deren 100%ig webbasierte Multi-Projektmanagementsoftware „Blue Ant“ dargestellt.

Darauffolgend werden in Kapitel 4 die Lösungsansätze für eine Integrationsproblematik wie Point-to-Point, Hub and Spoke, Pipeline und SOA skizziert. Außerdem wird die Umsetzung der Integration Architektur-Ebene mit ESB definiert. Für die Integration werden der Top-Down-, Bottom-Up-, Meet-in-the-Middle- Ansatz und die schrittweise Einführung beschrieben. Anschließend werden Architektur Szenarien Blue Ant-Integration und ein Open Source SOA-Stack als Basisinfrastruktur für die Realisierung von Anwendungen mit Open Source Tools und Frameworks für ein SOA-Modell dargestellt.

Anschließend wird in Kapitel 5 die Umsetzung der Architektur am Beispiel „Arbeitszeiterfassung“ zusammengefasst. Dabei werden die möglichen Werkzeuge für die Realisierung und die Entwicklungsumgebung aufgezeigt.

Die Arbeit wird in Kapitel 6 mit einer Zusammenfassung und einem Ausblick abgeschlossen.

Seite 3

KAPITEL 2 GRUNDLAGEN

2 Grundlagen

Dieses Kapitel fasst die Grundlage von Geschäftsprozessen, Workflow, Modellierungsmöglichkeiten sowie von SOA zusammen. Dabei stellt der standardisierte Service Grundkomponente und der konsequente Einsatz der Standards SOAP, WSDL und BPEL den wesentlichen Bestandteil dieser Grundlage dar.

2.1 Geschäftsprozess und Workflow

Hier werden die Geschäftsprozesse und Workflows definiert und der Unterschied zw. den beiden gegenübergestellt.

2.1.1 Begriff des Prozesses

Unternehmen erzeugen Leistungen, um die Bedürfnisse der Kunden befriedigen zu können. Die Vermarktung dieser Leistungen führen dazu, dass der wirtschaftliche Erfolg des Unternehmens gesichert werden kann.

Die Leistungen können Sach- oder Dienstleistungen sein und werden in Prozessen erstellt. Somit wird allgemein unter einem Prozess „eine Reihe von Aktivitäten verstanden, die aus einem definierten Input ein definiertes Ergebnis (Output) erzeugen“ (Schmelzer 2006, S. 58). Unter Input sind Einsatzfaktoren, wie z.B. Arbeitsleistung, Betriebsmittel (Maschinen, Gebäude), Energie, Werkstoffe (Roh-, Hilfs- und Betriebsstoffe) und Informationen zu verstehen und Output sind Produkte oder Dienstleistungen.

Im Zusammenhang mit Prozessen wird häufig auch von Lieferanten-Kunden- oder Input-Output-Beziehung gesprochen, aufgrund dessen, dass der Input von Lieferanten bereitgestellt und der Output für Kunden bestimmt wird.

Nach DIN 66201 ist ein Prozess als „Umformung und/oder den Transport von Materie, Energie und Informationen von einem Anfangszustand in einen Endzustand nach genau festgelegten Regeln“. Dabei wird der Prozess in den technischen Prozess für die Verarbeitung von Materie/Energie und in den Rechenprozess/Informatikprozess, für die Verarbeitung von In-formation, aufgeteilt (vgl. Schlingloff 2005, Folie 8).

Der Prozessbegriff reicht nicht aus um über die Begrenzung, Reichweite, Inhalte und Struktur des Prozesses sowie die Empfänger der Prozessergebnisse zu sprechen, sondern es wird erst über Prozess gesprochen, wenn wenige Aktivitäten oder Arbeitsschritte miteinander verknüpft sind, um ein Arbeitsergebnis erstellen zu können. In diesem Sinne laufen hunderte oder tausende von Prozessen innerhalb eines Unternehmens ab.

Seite 4

KAPITEL 2 GRUNDLAGEN

Abbildung 2.1: Definition von Prozess (vgl. Schmelzer 2006, S. 60)

2.1.2 Begriff des Geschäftsprozesses

In der Literatur findet sich eine Vielzahl verschiedener Definition für den Geschäftsprozess, die jeweils verschiedene Komponenten des Geschäftsprozesses hervorheben. Hammer und Champy definieren den Geschäftsprozess im Rahmen des Business Reengineering als „Menge von Aktivitäten, für die ein oder mehrere unterschiedliche Inputs benötigt werden und die für die Kunden ein Ergebnis von Wert erzeugen“ (Gadatsch 2005, S. 34). Die Entwicklung eines neuen Produkts wird als Beispiel von den beiden genannt.

Scheer und Jost verstehen unter Geschäftsprozess „die modellhafte Beschreibung der in einem Unternehmen durchzuführenden Funktionen in ihrer inhaltlichen und zeitlichen Abhängigkeit.“ (Gadatsch 2005, S. 34). Dabei ist unter Funktion die einzelne Aufgabe und Tätigkeit zu verstehen. Diese sind über Ereignisse, die von Ihnen ausgelöst wurden, miteinander verknüpft.

Der Begriff des Geschäftsprozesses wird von Scheer mit der Prozesskette und der Vorgangskette gleichgestellt und somit wird der Akzent auf die funktionsübergreifende Eigenschaft des Geschäftsprozesses gesetzt, der sich auf mehrere Funktionsschritte ausdehnt (vgl. Gadatsch 2005, S. 35).

Nach Österle ist der Geschäftsprozess „eine Abfolge von Aufgaben, die über mehrere orga-nisatorische Einheiten verteilt sein können und deren Ausführung von informationstechnologischen Anwendungen unterstützt wird. (vgl. Gadatsch 2005, S. 35). Österle betrachtet dem Geschäftsprozess als Bindeglied zwischen der Unternehmensstrategie und der Systementwicklung bzw. den unterstützenden Informationssystem.

Nach Berkau werden Prozesse in betriebliche Geschäftsprozesse und technische Prozesse aufgeteilt. Unter den betrieblichen Geschäftsprozessen sind kaufmännische Tätigkeiten, wie z.B. die Bearbeitung von Kundenaufträgen oder Einstellung eines Mitarbeiters, zu verstehen. Die technischen Prozesse dienen zur primären Leistungserstellung, wie z.B. Montage eines Motors. (vgl. Gadatsch 2005, S. 35)

Seite 5

KAPITEL 2 GRUNDLAGEN

Schlüter/Schneider aus dem Bereich der Produktionsplanung und -steuerung verfolgen gleichartige Ansätze. Sie definieren Geschäftsprozess als „Folgen sachlogisch zusammenhängender Aktivitäten, die eine in sich geschlossene Aufgabe realisieren, deren Ziel darin besteht, Materialien und Informationen in eine vom Kunden gewünschte Form zu bringen.“ (Gadatsch 2005, S. 35)

Laut Gadatsch ist ein Geschäftsprozess „eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen unter Nutzung von Informations-und Kommunikationstechnologien ausgeführt werden können. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen.“ Die Beschreibung eines Geschäftsprozesses kann formal auf unterschiedlichen Detaillierungsgradsebenen und aus mehreren Sichten erfolgen. Der maximale Detaillierungsgrad ist z.B. dann erreicht, wenn die ausgewiesene Arbeit von einem Mitarbeiter in einem Zug ohne Wechsel des Arbeitsplatzes durchgeführt werden kann. (vgl. Gadatsch, S. 36).

Im weiteren Verlauf wird folgende Definition des Geschäftsprozesses verwendet: Unter einem Geschäftsprozess wird die inhaltlich abgeschlossene, zeitlich-logische Abfolge der Funktionen verstanden, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig sind.

Mit anderen Wörtern ist ein Geschäftsprozess (eng. business process) ein Prozess, der dazu beiträgt, die definierten Unternehmensziele zu erreichen und eine Wertschöpfung zu erbringen, z.B. Reisekostenabrechnung, Bestellungen.

In einiger Literatur wird der Begriff Geschäftsprozess mit Unternehmens-, Wertschöpfungs-oder Kerngeschäftsprozess gleichgesetzt. Innerhalb eines Unternehmens werden häufig alle Prozesse als Geschäftsprozess bezeichnet.

Abbildung 2.2: Definition von Geschäftsprozess (vgl. Schmelzer 2006, S. 60)

2.1.3 Komponenten von Geschäftsprozessen

Die Komponenten von Geschäftsprozessen sind Abbildung 2.3 zu entnehmen.

Seite 6

KAPITEL 2 GRUNDLAGEN

Wobei die Anforderungen der Kunden am Anfang des Prozesses und die Bereitstellung der zu erwartenden Leistungen bzw. Ergebnisse am Ende des Prozesses stehen. Dabei ist zu bemerken, dass es bei den Geschäftsprozessen nicht um die Input-Output-Beziehung geht, sondern um die Anforderungs-Ergebnis-Beziehung. Für die Unternehmen sind die Prozessergebnisse, die aus einzelnen Produkten oder Dienstleistungen oder aber auch aus einer Kombination der beiden bestehen, wichtig für die Zukunftssicherung des Unternehmens. Unter Kunden sind hier nicht nur der einzelne Kunde zu verstehen, sondern die Interessengruppen (Stakeholder), von denen der Erfolg des Unternehmens abhängt. Dies können z.B. Kunden, Lieferanten, Kapitalgeber, Partnerunternehmen, Mitarbeiter usw. sein. Alle Aktivitäten, die für die Erzeugung der Ergebnisse in einem Geschäftsprozess erforderlich sind, werden organisatorisch gebündelt. Diese Bündelung kann sich über aufbauorgani-satorische Grenzen wie z.B. Funktionen und Abteilungen genauso auch über Unternehmensgrenzen hinweg erstrecken (vgl. Schmelzer 2006, S. 61-62).

Abbildung 2.3: Komponenten von Geschäftsprozessen (vgl. Schmelzer 2006, S. 61)

2.1.4 Begriff des Workflows

Es sind zahlreiche manchmal auch teilweise widersprüchliche Definitionen in der Literatur bzw. in der Praxis über den Begriff Workflow zu finden. Aus diesem Grund hat die in 1993 gegründete „Non-Profit“ Organisation Workflow-Management Coalition (WfMC) ¹ , deren Dokumente weitgehend von der Industrie akzeptiert werden, als Ziel einen Standard zu etablieren, an welchen sich fast alle Publikationen und auch Produkte orientieren sollen. Der Duden definiert Workflow als „Ablauf arbeitsteiliger Vorgänge bzw. Geschäftsprozesse in Unternehmen u. Behörden mit dem Ziel größtmöglicher Effizienz“ oder in der EDV als „Arbeitsablauf bei Computerprogrammen“

¹ WfMC wurde 1993 gegründet und ist ein Verbund von Forschungsinstituten, Hochschulen, Anwen-

dern und Softwareherstellern, die sich mit Standards im Bereich des Workflow-Managements befas-

sen.

Seite 7

KAPITEL 2 GRUNDLAGEN

Unter Workflow versteht die WfMC „the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules” (o.V., WfMC 1999, S. 8). Auf Deutsch ist ein Workflow ein ganz oder teilweise automatisierter Geschäftsprozess, in welchem Dokumente, Informationen oder Aufgaben unter Berücksichtigung von Prozedurregeln von einem Teilnehmer an einen anderen zur Ausführung übergeben werden. Galler und Scheer sehen den Workflow als nichts anderes als eine technische Verfeinerung des betriebswirtschaftlichen Geschäftsprozesses. Wobei die Automatisierbarkeit als Kriterium für den Verfeinerungsgrad festgelegt wird (vgl. Gadatsch 2005, S. 41).

Österle beschreibt den Workflow ähnlich wie Galler und Scheer. Auch er definiert den Workflow als einen verfeinerten Geschäftsprozess. Dabei wird der Prozessentwurf in Teilprozesse zerlegt bis der gewünschte Detaillierungsgrad erreicht ist. Die Aufgaben sind so zu zerlegen, dass sie von dem Prozessmitarbeiter zugeordnet und als Arbeitsanweisung umgesetzt werden können. Anstelle einer Führungskraft übernimmt der Computer die Ablaufsteuerung (vgl. Gadatsch 2005, S. 41).

Becker, Rosemann und Kugler bezeichnen „einen Prozess, dessen Funktionsübergänge in der Kontrollsphäre eines Anwendungssystems liegen als Workflow“ (Gadatsch 2005, S. 41).

Zusammenfassend wird Workflow folgendermaßen definiert:

Ein Workflow wird als formal ganz oder teilweise automatisierter Geschäftsprozess beschrieben. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufs auf der operativen Ebene erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter oder durch Anwendungsprogramme vorgesehen.“(Gadatsch 2005, S. 41) Die Geschäftsprozesse werden im Workflow verfeinert (s. Abbildung 2.4).

Seite 8

KAPITEL 2 GRUNDLAGEN

Abbildung 2.4: Verfeinerung der Geschäftsprozesse im Workflow (vgl. Freund, 2004)

2.1.5 Gegenüberstellung von Geschäftsprozess und Workflow

Oftmals werden Workflows und Geschäftsprozesse gleichgesetzt, weil beide Arbeitsabläufe beschreiben, eine klare Abgrenzung ist aufgrund des gemeinsamen Untersuchungs-gegenstandes nicht immer möglich. Trotz des engen Zusammenhangs zwischen Workflows und Geschäftsprozessen verfolgen die beiden unterschiedliche Ziele (s. Abbildung 2.5). Der wesentliche Unterschied ist, dass der Geschäftsprozess beschreibt, „WAS“ zu tun ist, um die vorgegebene Geschäftsstrategie umsetzen zu können. Der Workflow beschreibt „WIE“ dies umgesetzt werden soll. Der Geschäftsprozess ist in der fachlichen Ebene zu finden, der Workflow in der operativen Ebene.

In der Praxis gibt es keine feste Regel bzw. „objektive“ Kriterien für einen angemessen Detaillierungsgrad.