Organisationsmodellierung auf Basis eines Enterprise Application Frameworks Frank Zeidler agens Consulting GmbH, 25479 Ellerau, Buchenweg 11 – 13 [email protected]

1 Motivation Die Anforderungen an die Organisationsentwicklung (Business-Engineering) und somit auch an die Softwareentwicklung (SoftwareEngineering) für betriebliche Informationssysteme steigen. In immer kürzeren Abständen muß auf die veränderten Marktverhältnisse reagiert werden, dies gilt im besonderen für den Versicherungsbereich. Die wichtigsten Innovationen in diesem Bereich sind flexiblere Produkte, spartenübergreifende Angebote sowie verbesserte Kundenbetreuung. Die Geschäftsprozesse einer Versicherung müssen auf solche dynamischen Anforderungen vorbereitet sein. Nachdem Finanzdienstleistungen sich heute zu einem wesentlichen Teil auf die Datenverarbeitung stützen, wurden die existierenden DV-Systeme in vielen Unternehmen zu einem Hemmnis für Veränderungen und zementierten bestehende organisatorische Strukturen und Abläufe. Da Altsysteme nur mit erheblichem Aufwand anzupassen sind und nicht für die neuen Anforderungen ausgelegt sind, ist die Flexibilität der DV innerhalb kurzer Zeit zu einem wichtigen Wettbewerbsfaktor geworden. Zusätzlich zu diesen Anstößen führte die Einführung des Euro und die Jahr2000 Umstellung der Systeme dazu, daß die gesamte Software angepaßt werden muß. Diese dreifache Herausforderung und die daraus resultierenden umfangreichen Änderungen an den bestehenden DV-Systemen birgt eine hohe Ge-

fahr für die Qualität, Wartbarkeit und Robustheit der betrieblichen Informationssysteme. Gerade wenn diese Änderungen unter erheblichem Zeitdruck (Jahr-2000, Euro, Wettbewerb) geschehen, wird die saubere Anpassung und die Dokumentation oft vernachlässigt. Des weiteren stellt sich die Frage, inwieweit die Architekturen der bestehenden betrieblichen Informationssysteme eine Anpassung auf flexible Geschäftsprozesse, die innovative Produkte kundenorientiert anbieten können, überhaupt erlauben. Eine an organisatorischen Bedürfnissen und auf zukünftige Änderungen ausgerichtete ITArchitektur gilt als der zur Zeit vielversprechendste Trend im Versicherungsbereich. Dabei geht es nicht so sehr um eine völlige Ablösung der bestehenden Systeme auf einen Schlag – das wäre betriebswirtschaftlich unsinnig und wegen der damit verbundenen Risiken auch technisch nicht zu rechtfertigen. Vielmehr soll ein allmählicher Übergang ermöglicht werden, der es erlaubt, daß das neue System in die bestehende DV-Landschaft „hineinwächst“ und das Altsystem schrittweise und kontrolliert verdrängt. Eine wichtige Voraussetzung dafür ist eine Facharchitektur, die alle Bereiche des Versicherungsgeschäftes abdeckt und über ausreichende Flexibilität (durch geeignete Abstraktionen) verfügt, um den derzeitigen Trend von

der Versicherung hin zu einem effektiven Finanzdienstleister mit tragen zu können. 1.1

Stand der Technik

Betriebliche Informationssysteme bilden einen integralen Bestandteil der Organisation einer Unternehmung. Insofern muß der Zusammenhang zwischen beiden Begriffen geklärt werden. Eine Organisation ergibt sich aus der Überdeckung von Informationssystemen und stellt letztendlich ein System von Informationssystemen dar. Der Begriff des Informationssystems wird dabei nicht auf die reinen DV-Systeme beschränkt. Die DV-Systeme unterstützen vielmehr die Funktionen von organisatorischen Informationssystemen, indem sie Subsysteme der organisatorischen Informationssysteme bilden. Ein Informationssystem wird hier verstanden als eine Menge von informationsverarbeitenden Funktionen, die Menge der Funktionen selbst und die Menge der Informationssorten, die von den Funktionen als Input oder Output verarbeitet bzw. erzeugt werden, sowie die Relationen zwischen den Mengen. Betriebliche Organisationen und die verwendeten

a)

DV-Systeme können durch eine homogene Systemspezifikation beschrieben und ausgeführt werden. Es wird in der Praxis nur noch ein System entworfen und ausgeführt anstatt wie bisher zwei grundlegend verschiedene Informationssysteme. Der Entwicklungsprozeß der unterschiedlichen Systeme, das Business-Engineering und das Software-Engineering, wandelt sich zu einem homogenen Prozeß des „ConvergentEngineering“ [Tay95]. Durch die Integration der Systeme zu einem homogenen Gesamtsystem ergeben sich erhebliche Synergieeffekte in der Verwaltung und Erstellung von betrieblichen Informationssystemen. Allerdings zieht die Integration auch erhebliche Änderungen in der Entwicklung der Systeme nach sich. Anwendungssysteme werden in diesem Ansatz wesentlich granularer (in Bausteinen/Komponenten) entwickelt, im Gegensatz zu den bisher relativ monolitisch entwickelten Anwendungsystemen. Da die Anwendungssysteme Subsysteme der organisatorischen Systeme sind, bedingt die organisatorische Entwicklung die Anwendungsentwicklung. Die Anwendungsentwicklung orientiert sich einerseits wesentlich stärker an den fachlichen Aktivitäten der Unternehmensorgani-

Workflow modell

Erfolgskontrolle

b)

Erfolgskontrolle Organisations modell

Workflow Ausführung

Modellierung

Geschäftsprozeßmodell

ModellAnalyse

Workflow Ausführung

Modellierung

ModellAnalyse

Abb. 1.1 Einsatz von Modellen im Business-Engineering a) mit Geschäftsprozeßmodell und Workflowmodell b) mit zentralem Organisationsmodell

sation. Auf der anderen Seite muß die Entwicklung organisatorischer Unternehmenssysteme wesentlich formaler und detaillierter durchgeführt werden als bisher. Viele der heute verfügbaren Methoden und Werkzeuge beruhen auf der Unterscheidung der verschiedenen Systeme (repräsentiert durch Modelle). Im Szenario der Abb. 1.1.a), dem heutigen Stand der Technik, besitzen die betrieblichen Anwendungssysteme eine Vorgangssteuerung oder es wird ein Workflow-Managementsystem eingesetzt. Eine Vielzahl von BPR-Tools und Workflow-Managementsystemen unterscheiden zwischen den Modellen. Dabei erfolgt die Modellbildung und Analyse mit einem BPR-Tool und führt zum Geschäftsprozeßmodell. Aus diesem läßt sich durch Transformation ein Workflowmodell generieren, welches die Grundlage für die Ausführung mit einem Workflow-Managementsystem bildet. Im Projekt PHÖNIX [EA99] einer internationalen Versicherung wird z. B. ein Geschäftsprozeßmodell mit dem Geschäftstsprozeßmanagmentsystem ADONIS der Firma BOC [BOC99] erstellt. Dieses Modell wird in einer DesignPhase um technische Informationen, z.B. Aufrufe von Programmblöcken angereichert. Das Modell wird von ADONIS über die Definitionssprache FDL von Flow-Mark [IBM94] exportiert, in das betriebliche Anwendungssystem importiert, von einer Vorgangssteuerung interpretiert und die referenzierten Programmblöcke ausgeführt. In [Gall96] wird eine Umgebung vorgestellt, mit der es möglich wird, Konsistenzbedingungen zwischen Geschäftsprozeßmodellen (modelliert mit ARIS-Toolset [Scheer94]) und WorkflowModellen (modelliert mit der Modellierungssprache des Systems FlowMark [IBM94]) zu prüfen.

Auf Basis dieser Konsistenzbedingungen lassen sich bei Änderungen an den WorkflowModellen die hierzu in Beziehung stehenden Geschäftsprozeßmodellanteile identifizieren. Die für die entsprechenden Modellteile verantwortlichen Modellierer können informiert werden. Bei diesem Vorgehen arbeiten verschiedene Werkzeuge in unterschiedlichen Phasen auf getrennten Modellen. Die Unterscheidung von verschiedenen Modellen in verschiedenen Phasen führt zu einer Entwicklung von Anwendungssystemen, die der Erstellung von Software nach dem Wasserfallmodell gleicht. Typische, aus dem Software-Engineering bekannte Probleme sind hierbei die Weitergabe der Informationen zwischen den Beschreibungen in den verschiedenen Phasen sowie potentielle Konsistenzprobleme zwischen zum Teil redundanten Beschreibungen. Ein anderer Ansatz verwendet ein gemeinsames Modell für alle Phasen eines Lebenszyklus der Geschäftsprozeßmodelle (Szenario 1.1 b). Im FUNSOFT-Ansatz zum Management von Geschäftsprozessen [Emm91] dient ein erweitertes „high-level“-Petri-Netz [Dei95] als einheitliche, formale Grundlage zur Aufnahme der unterschiedlichen Informationen der verschiedenen Phasen des Lebenszykluses. Zur Strukturierung der Informationen dient ein Sichtenkonzept. Auf dem Petrinetz-Kalkül basierende WorkflowAnsätze sind LEU [Gruhn96] und INCOME. Daneben existieren aber auch programmiersprachliche (z.B. MOBILE), objektorientierte Modellierungsansätze (SOM [FerSi95]) und andere graphische Sprachen (PROMET [Öst95], PROZESSWARE [ONE96], u.a.).

Das zentrale Modell aus Abb. 1.1.b) wird in [Dei97] Prozeßmodell genannt. Hier soll es umfassender als Organisationsmodell bezeichnet werden, da in diesem Modell nicht nur ablauforganisatorische Aspekte beschrieben werden sollen, sondern auch die statischen, aufbauorganisatorischen Aspekte der Unternehmensorganisation, welche in den bisherigen Modellen eine untergeordnete Rolle spielen. Die bisher existierenden Modelle werden dann zu verschiedenen Sichten auf das komplexere Organisationsmodell, wie es auch in [Tay95] und in [WeiWo97] gefordert wird. Als neues Paradigma zur Modellbildung komplexer Systeme haben sich in den letzten Jahren die Objektorientierung und darauf aufbauende höhere Konstruktionsprinzipien (Patterns, Components und Frameworks) im Software-Engineering etabliert. Objektorientierte Konzepte und Techniken halten allerdings nur langsam Einzug in das Business-Engineering [JacEr95] oder [Tay95]. Eine Konzeption, wie ein solches objektorientiertes Organisationsmodell aufgebaut und durch einen Enterprise Application Framework unterstützt werden kann, wird nun einführend dargelegt.

2 Frameworks Eine Facharchitektur definiert, aus welchen Komponenten sich die Software-Landschaft zusammensetzt und wie diese miteinander arbeiten. Häufig werden unter Komponenten frei zusammensteckbare Software-Bausteine verstanden, die meist allgemeingültige Dienste anbieten. Wichtig ist dabei vor allem die Middleware, die freie Austauschbarkeit gewährleistet und für die Kommunikation zwischen den Komponenten sorgt. Diese müssen also auf einem gemeinsa-

men Framework, der diese Midleware bildet, beruhen. Komponenten haben dabei den Charakter unabhängiger Objekte. Verschiedene Komponentenmodelle werden in [Szy98] genauer diskutiert. Das Ziel, welches mit Komponenten angestrebt wird, ist einen bisher unerreichten Freiheitsgrad bei der Auswahl und der Komposition von Anwendungsbausteinen (Komponenten) zu erreichen. Dabei spielt es keine Rolle, auf welche Art und Weise - klassisch prozedural oder objektorientiert - entwickelt wird. Die entscheidenden Techniken hierfür sind die aus der Objektorientierung bekannten Techniken der Kapselung, Interfaces und Messages. Die Objektorientierung liefert allerdings ein Konzept zur Strukturierung einer Problemlösung, welches auch im organisatorischen Bereich seine Vorteile bringt und sollte zur Realisierung neuer Komponenten und der Organisationsmodellierung herangezogen werden. Damit eine komponentenbasierte Entwicklung nicht wie eine objektorientierte Entwicklung schnell im Chaos scheitert, etablieren sich zur Zeit implementierte Rahmenwerke (Frameworks). Im Gegensatz zu herkömmlichen Schichtenarchitekturen werden die Schnittstellen zwischen den Komponenten in Application Frameworks nicht durch Normen definiert, sondern in einer Rahmenanwendung implementiert und auf die einzelnen Komponenten vererbt. Der Entwicklungsprozeß auf Grundlage von Frameworks ändert sich dabei radikal im Gegensatz zu dem Entwicklungsprozeß mit Hilfe von Klassenbibliotheken.

2.1

Die Frameworks-Technologie

Wird die Objektorientierung auf naive Weise in großen Projekten eingesetzt, entsteht eine kaum zu beherrschende Komplexität in den Modellen. Daher ist der Einsatz von höheren Abstraktionskonzepten im objektorientierten BusinessEngineering unabdingbar. Die Konzepte von Frameworks, Components und Patterns haben sich bereits im Software-Engineering etabliert. [Pree97] [Gam97] Statt individuelle Komponenten wieder zu verwenden, setzen die meisten erfolgreichen Projekte auf die Entwicklung und Wiederverwendung von Frameworks. Frameworks sind das zentrale, objektorientierte Konzept für eine geregelte Wiederverwendung von Komponenten. Zur Zeit existiert noch keine einheitliche Definition von Frameworks. Eine oft verwendete Definition [Jo97] sagt: „a framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact“. Eine weitere übliche Definition [Jo97] ist: „a framework is a skeleton of an application that can be customized by an application developer“. Zwischen den beiden Definitionen besteht kein Konflikt, da die erste den Aufbau eines Frameworks beschreibt und die zweite den Zweck. Ein Framework entspricht einer Sammlung verschiedener, individueller Komponenten mit definiertem Kooperationsverhalten und soll eine bestimmte Aufgabe erfüllen. Einige der Komponenten sind so entworfen, daß sie austauschbar sind. Zur ausführlicheren Diskussion von Frameworks siehe [Pree97]. In [Fay97] werden drei Klassen von anwendungsspezifischen Frameworks unterschieden. System Infrastructure Frameworks, Middleware

Integration Frameworks und Enterprise Application Frameworks. Die Klasse der Enterprise Application Frameworks wird in diesem Beitrag genauer betrachtet. Diese Art von Frameworks betreffen eine weites Spektrum von Anwendungsgebieten (z. B. Telekommunikation, Produktion, Finanzwirtschaft oder Versicherungen) und bildet die entscheidende Grundlage aller Geschäftsaktivitäten. Relativ zu System Infrastructure und Middleware Integration Frameworks sind Enterprise Application Frameworks teuer in der Entwicklung oder in der Anschaffung. Jedoch können Enterprise Applcation Frameworks einen wesentlichen Return-OnInvestment liefern, wenn sie die Entwicklung von Benutzerschnittstellen und Produkten direkt ermöglichen.[Fay97]

Anwendungsspezifikation Anwendungscode

Klassenbibliothek

Framework

Unterschiede zwischen Klassenbibliotheken und Frameworks

Abb. 2.1 Anwendungen mit Klassenbibliotheken und

Frameworks unterscheiden sich von gewöhnlichen Klassenbibliotheken dadurch, daß Frameworks zusätzlich die Architektur vorgeben. Frameworks beruhen auf dem call-back-Verfahren und invertieren den Kontrollfluß (s. Abb. 2.1). Zentrale Teile der Anwendungsarchitektur, so auch die Interaktion zwischen verschiedenen Komponenten, sind bereits im Framework realisiert. Der Entwickler kümmert sich nicht mehr um die Implementierung der Architektur und den Aufruf von speziellen Diensten aus Klassenbibliotheken, sondern ihm wird eine bereits implementierte und standardisierte Architektur

vorgegeben, die er an entsprechenden Stellen (Hot-Spots) erweitern muß. Er teilt dem Framework mit, was in bestimmten Situationen gemacht werden soll und nicht mehr, wie etwas getan wird. Die Infrastruktur wird durch den Framework bereitgestellt, fachliche Besonderheiten müssen spezifiziert und an den Hot-Spots in den Framework eingehängt werden. Das Charakteristische für White-BoxFrameworks ist, daß sie aus einer Reihe von unvollständig spezifizierten Klassen bestehen. Das sind Klassen, die unvollständig spezifizierte Methoden enthalten, sogenannte abstrakte Methoden. Um nun das Verhalten von White-BoxFrameworks zu verändern, wird Vererbung eingesetzt. Die Architektur der Anwendung verbleibt im Framework. Entwickler passen den Framework an, indem sie die Einschubmethoden überschreiben, die dann von anderen Methoden im Framework aufgerufen werden. Um Methoden zu überschreiben, muß ein Entwickler den Entwurf und die Implementierung des Frameworks zumindest bis zu einem gewissen Detaillierungsgrad verstanden haben. Black-BoxFrameworks sind Frameworks, deren Anpassungskonzept nicht auf unfertigen Klassen, sondern auf einer Anzahl fertiger Komponenten basiert. Änderungen werden durch Komposition dieser Komponenten erreicht, nicht durch die Vervollständigung von Unterklassen, sprich Programmierung. Frameworks sind weder reine White-Box- noch reine Black-Box-Frameworks. Wenn ein Framework oft wiederverwendet wird, dann wird automatisch eine Vielzahl von Spezialisierungen entstehen und sich so eine BlackBox-Struktur ergeben. Entsprechend wird die White-Box-Schnittstelle an Relevanz verlieren (vgl. auch [Pree97]).

Die wesentliche Problematik bei der Entwicklung von Frameworks liegt im Spannungsfeld zwischen der Wiederverwendung und der Flexibilität in der Anpassung. Wie bereits dargestellt, definiert der Framework die Anwendungsarchitektur und hält diese nur noch an bestimmten Punkten, den sogenannten Hot-Spots, flexibel. Das wiederum beschränkt den Freiheitsgrad der Entwickler. Funktionalität kann nur noch dort angefügt werden, wo die Entwickler des Frameworks dies auch vorgesehen haben. Ein weiterer Schwachpunkt von Frameworks ist, daß diese zur Zeit nur auf technische Aspekte der Implementierung ausgerichtet sind. Im Bereich der Entwicklung von GUI-Anwendungen werden Frameworks bereits erfolgreich eingesetzt. „Fortunately, the next generation of OO application frameworks are targeting complex business and application domains“ [Fay97]. Die Architektur und die Schwachstellen bereits bestehender Frameworks sollen am Beispiel des Frameworks „San Francisco“ von IBM einführend dargestellt werden. Weitere bestehende Frameworks sind zum Beispiel Business Framework der SAP AG, Bolero der Software AG, die Business Object Facility der OMG [EeSi98] und der Framework aus dem Werkzeug Material Ansatz [Bäu97]. 2.2

IBM – San Francisco

Mit IBM – San Francisco wird nicht nur die technische Infrastruktur von Client/ServerAnwendungen auf Basis von Java vorimplementiert, sondern darüber hinaus werden vorgefertigte Komponenten für ausgewählte Kernprozesse von Geschäftsanwendungen zur Verfügung gestellt. Der Umfang dieser Komponenten soll bis zu 40% der typischen Anforderung abdecken. Die Hauptanwendungsfelder ergeben

Anwendersoftware

Buchhaltung

Logistik

Fertigung

...

Buchhaltung

Lager

Auftrag

...

andere Anwendungen

Kerngeschäftsprozesse

andere Anwendungen

Allgemeine Geschäftsobjekte

Fundament JAVA virtuelle Maschine

Plattformen

Server: Windows NT, AIX OS/400, Sun/Solaris, HP/Unix ... Client: Browser, Java, Active X, Java Beans ...

Abb. 2.2 Die Architektur des IBM - San Francisco Frameworks

sich aus der Funktionalität der vorgefertigten Anwendungskomponenten. Zur Zeit sind dies die Kernprozesse in den Anwendungsfeldern Buchhaltung, Auftragsabwicklung, Lagerverwaltung sowie Kreditoren- und Debitorenbuchhaltung. Die Entwicklung von Java-Anwendungen kann auf verschiedenen Ebenen der Architektur aufsetzen. Die unterste Schicht der Architektur (Abb. 2.2) ist das Fundament (Foundation Framework), das die plattformunabhängige Basis für alle darüber liegenden Schichten – Allgemeine Geschäftsobjekte und Kerngeschäftsprozesse – bildet, indem es eine transparente Verwendung der unterliegenden Technologien ermöglicht. Anwendungen können aber auch direkt auf der Schicht der allgemeinen Geschäftsobjekte aufsetzen, die zum einen Geschäftsobjekte und zum anderen Anwendungsdienste anbieten. Das Fundament stellt eine Infrastruktur für die Java-basierte Anwendungsentwicklung bereit, auf die entweder über die Foundation Object

Model Classes, Klassen aus der Schicht der allgemeinen Geschäftsobjekte, oder über Utilities zugegriffen wird. Die Object Model Classes definieren die Anwendungsarchitektur. Die Entwicklung einer Anwendung besteht damit aus der Verwendung abgeleiteter Methoden oder der Implementierung abstrakter Methoden im Framework definierter Klassen. Fachliche Logik, die keinem einzelnen Geschäftsobjekt zugeordnet, sondern einem Geschäftsprozeß, werden kann wird über das Hilfskonstrukt „Command“ implementiert. Geschäftsobjekte und die zugehörige Logik werden als transiente oder persistente Entities realisiert. An dieser Stelle liegt mein Hauptkritikpunkt am IBM – San Francisco Framework. Die Verwendung des Begriffes „Prozeß“ oder „Kerngeschäftsprozeß“ hat nichts damit zu tun, wie ein Betriebsorganisator in der Versicherungswirtschaft diese Begriffe versteht. Aus seiner Sicht werden im Framework lediglich einzelne Funk-

tionalitäten von organisatorischen Bereichen, wie die Buchhaltung oder das Lager, bereitgestellt. Die Ausrichtung der Architektur auf diese funktionale Organisation hat weder etwas mit den Begriffen einer prozeßorientierten Organisation noch mit Geschäftsprozessen zu tun. Der Framework ist „nur“ eine neue Form einer Softwareentwicklungsumgebung und rein aus der Softwareentwicklungsperspektive entwickelt worden. Ein Enterprise Application Framework der die Gegebenheiten aus dem Geschäftsprozeßmanagement unterstützt, wie sie im ersten Abschnitt beschrieben wurden, ist nicht zu erkennen. Allerdings ist es möglich, dieses Manko zu beheben. Dazu gehe ich kurz auf den Framework der OMG [EeSi98], die Business Object Facility (BOF) ein.

2.3

OMG – Business Object Facility

Der Framework (Business Object Facility) der OMG basiert auf einer ähnlichen Architektur wie der Framework von IBM. Auch hier existieren ähnliche Schichten im Framework (vgl. Abb. 2.2 und 2.3) . Enterprise Specific Business Objects Financal Manufacturing Other Business Business Business Objects Objects Objects

Common Business Objects Business Object Facility CORBA, CORBAservices, CORBAfacilities

Abb. 2.3 Die Architektur der OMG – Business Object Facility

In diesem Framework werden Geschäftsprozesse allerdings als eigene Geschäftsobjekte angesehen und somit in einer eigenen Komponente realisiert. Die Abbildung 2.4 zeigt eine solche mögliche Komponente aus Sicht des Anwenders. Hier ist auch zu erkennen, daß ein Modell (Geschäftsprozeßmodell) wieder eine zentrale Rolle spielt. Es wird das Activity Diagramm der UML grafisch dargestellt und somit Einfluß auf andere Geschäftsobjekte, hier „Customer“ und „Car“, genommen. Mein Kritikpunkt hier ist, daß zwar der Geschäftsprozeß berücksichtigt wird, aber die Trennung zu den übrigen Komponenten nicht stattfindet. Die Geschäftsobjekte „Customer“, „Car“ und der Prozeß selbst sind zusammen in einer Komponente realisiert. Besser wäre es, wenn jedes Geschäftsobjekt in einer eignen Komponente realisiert würde. Diese würden dann in verschiedenen Fenstern, evtl. auch als Kinderfenster, arrangiert und sauber voneinander getrennt werden. Der Vorteil eine höhere Flexibilität bei Änderungen eines Geschäftsobjektes und eine saubere Ausrichtung an der Systematik würde dann bestehen. Weiterhin würde ich an Stelle der „Activity Diagramms“ eine bestehende Notation der UML für die Modellierung von Geschäftsprozessen wählen. Die Notation der State Charts würde aus meinen Erfahrungen ausreichen, um auch das Verhalten des Gesamtsystems in dem Anwendungsfall der Versicherungswirtschaft zu beschreiben. Von der Systematik her bestünden dann sauber modellierte Bearbeitungszustände von den Geschäftsobjekten „Geschäftsprozeß“. Diese Geschäftsobjekte kontrollierten dann das Gesamtverhalten des Gesamtsystems und würden den Workflow darstellen. Der Prozeß kann über diese Zustandsautomaten kontrolliert wer-

Abb. 2.4 Komponente eines Business Process in der BOF der OMG

den, was ja das Ziel des Geschäftsprozeßmanagements ist. Der zweite, wesentliche Kritikpunkt an bestehenden Frameworks wäre dann: Es werden keine Modelle unterstützt oder sind fest implementiert und es ist nicht geregelt, wie Geschäftsprozeßmodelle und Komponenten zusammenpassen. Das ganze Geschäftsprozeßmanagement mit der Modellierung von Geschäftsprozessen und Workflows [Zei99b] wird nicht oder nur rudimentär berücksichtigt (das gilt ebenfalls für den Business Framework der SAP). Aber gerade diese Modelle spielen eine immer wichtigere Rolle für die Erstellung von betrieblichen Informationssystemen. Die bisherigen Frameworks sind in diese Richtung eher ein Rückschritt.

prozesse würden dann als Geschäftsobjekte im Framework verwaltet und könnten einen Workflow realisieren. Weiterhin müßte eine geeignete Abstraktionsebene erreicht werden, um auf der Ebene von Geschäftsprozeßmodellen diese Geschäftsobjekte zu verändern. Die Geschäftsobjekte „Geschäftsprozesse“ würden alle anderen Geschäftsobjekte kontrollieren und steuern und somit einen Workflow realisieren. In diesem Beitrag soll aber auf eine eigene Architektur eingegangen werden, die diese Punkte realisiert. Das zentrale Modell ist ein Organisationsmodell, bestehend aus Class- und StateCharts. An diesem Modell orientiert sich dann die Erstellung des betrieblichen Informationssystems.

3 Der Business Framework Der IBM Framework San Francisco und die BOF der OMG müßten als neue Kerngeschäftsprozesse nicht nur Entitäten für die Buchhaltung oder anderer Organisationseinheiten bereitstellen, sondern auch für Geschäftsprozesse. Geschäfts-

Die Idee, die hinter dem Business Framework steht ist, die spezifischen fachlichen Gegebenheiten durch ein objektorientiertes Organisationsmodell zu spezifizieren werden. Das Organisationsmodell dient dann als Anwendungs-

Business-Component Legacy Systems

Distributed Client

specific extended Templates

access

access

access

Components

Business Objects

Special Business Objects

access

inheritance

Applications

Business Framework

DBMS

Workflow capability

OrgUnitObjects

ProcessObjects

RessourceObjects

Common Business Objects Templates Architecture Userinterface DB-Access Communication

Workflowstandards

Componentmodel Corba , COM, EJB

Tools GUI-Builder Class -/State-Charts Tools Component -Builder

JAVA virtual machine Plattforms

Server: Windows NT, AIX OS/400, Sun/Solaris, HP/Unix ... Client: Browser,JAVA, Active X, Java Beans ...

Abb. 3.1 Komponentenarchitektur auf Grundlage eines Enterprise Application Frameworks als Middleware

spezifikation im Sinne der Abb. 1.1 und wird durch den Framework „verarbeitet“. Es wird möglich, Komponenten auf Grundlage des Organisationsmodells zu erzeugen, die sich wie im Organisationsmodell spezifiziert verhalten. Dazu muß das Organisationsmodell eine ausführbare Spezifikationsnotation besitzen, die den einzelnen Komponenten als Workflow dient. In diesem Ansatz werden dazu Class- und State-Charts verwendet.

informationsverarbeitenden Funktionen, den Organisationseinheiten (OrgUnits), den Funktionen, den Arbeitsprozessen und letztendlich den einzelnen Aktivitäten (Process) und den Informationssorten, den Ressourcen (Ressource). Bevor das Objektmodell genauer betrachtet werden soll, wird zuvor auf die Organisationsmodellierung mit Class- und State-Charts genauer eingegangen. 3.1

Das Objektmodell des Frameworks spezialisiert die Funktionalität der allgemeinen Geschäftsobjekte nicht nach funktionalen organisatorischen Aspekten wie bei IBM San Francisco, sondern nach der bereits gegebenen Definition von Informationssystemen. Nämlich den Trägern von

Organisationsmodellierung mit Classund State-Charts

Ausführbare Objektmodelle, unabhängig von ihrem Anwendungsbereich, bestehen, wie auch in [HG96] ausgeführt wird, immer aus einer Art Zustandsautomaten und Modellen, die die Klassen mit ihren Beziehungen darstellen. Weitere

Teilmodelle sind nur andere Sichten auf einen Sachverhalt, der bereits in einem dieser beiden Teilmodelle modelliert wurde. Weitere Modelle dienen der Dokumentation des modellierten Systems, was auch die originäre Ausrichtung der UML ist. Die Ausführung des modellierten Systems ist hingegen das Ziel des Organisationsmodells. Class-Charts stellen Klassen von Objekten und im wesentlichen ihre strukturellen Beziehungen sowie ihren strukturellen Aufbau dar. Mit Objekten sind in diesem Anwendungsbereich die Geschäftsobjekte gemeint. Ein Class-Chart ist eine Art ER-Diagramm, entsprechend den Objektdiagrammen aus der UML. In Abbildung 3.2 wurde eine kleine Versicherung, die Simple Insurance Group, modelliert. Hervorzuheben ist, daß auch die Prozesse als eigenständige Klassen (Geschäftsobjekte) modelliert wurden. Der Kundenprozeß der SIG repräsentiert hier aus Vereinfachungsgründen z.B. einen Geschäftsprozeß (Schaden, Leistung, Kfz,...) einer Versicherung. Dieser ist bereits in Teilprozesse strukturiert.

Das Verhalten der spezifizierten Geschäftsobjekte wird durch State-Charts spezifiziert und kontrolliert, die jeweils für eine Klasse angegeben werden. Die Notation entspricht den Grundelementen der Notation der „State-Diagramms“ aus der UML. Ein State-Chart besteht im wesentlichen aus einer geordneten Abfolge von Zuständen mit definierten Übergängen. Ereignisse können als Eingabesymbole für einen Zustandsautomaten interpretiert werden, die im Zeitverlauf auf das Objekt einwirken. Ein StateChart reagiert dann unter bestimmten Bedingungen (E[C]/A Regel) auf diese Ereignisse und führt einen kontrollierten Zustandsübergang durch. Darüber hinaus können Aktionen Anweisungen zum Starten von Aktivitäten oder zur Erzeugung von weiteren Ereignissen enthalten. Aus meiner Erfahrung eignen sich State-Charts zur Modellierung von Berarbeitungszuständen von Geschäftsobjekten wie z. B. Geschäftsprozessen. Die Geschäftsobjekte sind dabei immer in einem fest definiertem Bearbeitungszustand und können somit ständig kontrolliert werden. Den State-Charts der Klasse „Kundenprozeß“ und den Subklassen kommt eine besondere BeKundenprozeß

1

SIG (Simple Insurance Group)

Akte

KundenAnfrage(Beleg) [] /

Eingangsbearbeitung

VerarbeitungStarten(Beleg) [] /

Sachbearbeitung

Ausgangsbearbeitung(Beleg) [] /

Ausgangsbearbeitung

1

Produkt KundenprozeßBeenden() [] /

1 1 Auslöser

Kunde

Eingang

Verarbeitung

1 0..1

Kundenprozeß

ZustM A

0..1

Verarbeitung

[] / gen(“ BelegEingang” , Beleg, Super.Produkt)

Verarbeitung

Ausgang

WeitereBearbeitung() [] /

1

BearbeitungBeendet [] /

Beleg

Autom at

Brief

Internet

M itarbeiter

Telefon

Fax

Form ular

1 SIC Gm bH

Geschäfts1 führer 10 10

Sachbearbeiter

3 3

Bearbeiter

Sach1 bearbeitung 1

Bearbeitung

Abb. 3.2 Class-Chart eines Organisationsmodells

fachliche Bearbeitung

Know How Erfragen(Beleg) [] /

Know how erfragen

VorgangAbgeben [] /

[] / gen(“ VorgangsAbgabe” , Super, Auslöser.ZustM A)

Vorgang abgeben

ErmittlungenNötig[] / Know How Erfragen [] / WeitereBearbeitung [] / gen(“ Ausgangsbearbeitung” , Beleg, Super)

externe Rückfragen

BearbeitungBeendet [] / gen(“ Ausgangsbearbeitung” ,Beleg,Super)

Abb. 3.2 State-Charts der Klassen Kundenprozeß und Verarbeitung

zwischen Produkten und Prozessen im Versicherungsbereich eigentlich ist, ist dringend notwendig.

deutung zu. Hier wird das Verhalten des Gesamtsystems modelliert. In der folgenden Abbildung wird dies beispielhaft durchgeführt. Für eine genauere Beschreibung des Beispiels und zur Abgrenzung des Ansatzes zu den State-ActivityCharts des Workflowsystems MENTOR [WeiWo97] wird auf [Zei99a] verwiesen.

3.2

Die Klasse „Business-Objects“ aus Abbildung 3.3 stellt eine allgemeingültige, einheitliche Schnittstelle für zukünftige Komponenten (Realisierung eines „Business-Objects“) der Unternehmensorganisation bereit. Eine Komponente stellt - wie bereits erwähnt - einen komplexen Baustein der Unternehmensorganisation dar und kann auch aus anderen, einfacheren Komponenten aufgebaut sein. Komponenten beinhalten alle ihre Funktionen sowie die Input- und Output-Ereignisse. Eine Komponente ist somit wiederum aus den Elementen eines Systems aufgebaut und bildet ein vollständiges, eigenständiges Subsystem (Objekt). Realisiert wird die Konstruktion dieser Systeme (Komponenten), bestehend aus Subsystemen (ebenfalls Komponenten), durch das Pattern „Composite“ in Zusammenhang mit dem Pattern „Chain of

Durch die Entkopplung der Objekte über Ereignisse ist auch eine elegante Lösung des Spannungsfeldes zwischen Produkt- und Prozeßmodellierung im Versicherungsbereiches gegeben. In den State-Charts werden Bearbeitungszustände (fachliche Bearbeitung) von Prozessen modelliert. Über Ereignisse dynamisch beim Produkt erfragt, welche Aktivitäten auszuführen sind. Je nach Zustand des Produktes können dies unterschiedliche Aktivitäten sein. Die identifizierte Aktivität wird dann im Bearbeitungszustand des Prozesses ausgeführt. Eine Ausarbeitung zu dieser Problematik ist zur Zeit in Bearbeitung. Versicherungen verkaufen bislang einen Dienstleistungsprozeß als Produkt. Eine Klärung der Frage, was der Unterschied

StateChart

Ein Framework als Infrastruktur für Geschäftsobjekte

output

State

Transition

Chain of Responsibility

record

predecessor

Database

BusinessElem ent

item s

states controlflow

view

Model/View

w orkflow

target View

State

action Action

action

target

Command

BusinessObject

Actors

Composite

event Event

w orklist observers

Observer

Activity

condition

Abb. 3.3 Erster konzeptioneller Entwurf des Business Frameworks

Hot Spot

Responsibility“ [Gam97]. Es wird möglich, eine Baumstruktur von Komponenten und Subkomponenten mit ihren jeweiligen Aktivitäten und Ereignissen aufzubauen. Wenn eine Komponente nicht auf ein erhaltenes Ereignis reagieren kann, ist sie in der Lage dieses an Subkomponeten zu delegieren, bis eine verantwortliche Komponente gefunden wurde. Das komplexe Verhalten einer Komponente ist in ein State-Chart ausgegliedert, realisiert durch die Beziehung „workflow“ und das Pattern „State“ [Gam97]. Das zugeordnete State-Chart definiert das fachliche Verhalten (Arbeitsweise) der Geschäftskomponente. Ein weiteres State-Chart definiert den allgemeinen Zustand der Komponente, z. B. ob sie gerade bereit, gestoppt oder pausiert. Nach [Jab95] wird dieses Verhalten als Kontrollfluß der Komponente bezeichnet und durch die Beziehung „controlflow“ realisiert. Wird eine Komponente gestartet, fängt diese an sich nach der Spezifikation des zugeordneten State-Charts zu verhalten. Zustandsabhängig werden Aktivitäten aufgerufen und Ereignisse verarbeitet oder erzeugt. Das „Bridge“- und „Command“-Pattern realisieren im wesentlichen eine Aktion, die an einer Transition oder innerhalb eines Zustands ausgeführt wird. Eine Aktion kann in dieser Spezifikation aus Ereignissen, Aktivitäten und Komponenten bestehen. Ein späteres Komponentenobjekt kann somit zur Laufzeit sein Verhalten zustandsabhängig verändern. Zur Ausführung eines späteren Objektsystems wird ein ereignisorientierter Beobachtungsmechanismus durch den Framework mit einem veränderten Pattern „Observer“ realisiert. Komponenten beobachten bestimmte Objekte der Klasse Event, indem sie sich bei den Ereignisobjekten

eintragen („observers“), die an den Transitionen („output“) der aktuellen Zustände („states“) annotiert sind. Tritt ein Ereignis ein, werden alle Beobachterkomponenten informiert, ihren Zustand zu aktualisieren. Diese können dann zustandsabhängig auf dieses Ereignis reagieren. Das „Observer“-Pattern ist dahingehend abgeändert worden, daß nicht der Zustand des Observers („Business-Object“) mit dem jeweiligen Subjekt („Event“) abgeglichen wird, sondern der Observer selbst weiß, was zustandsabhängig zu tun ist. Weiterhin werden durch den Framework Zugriffe auf Datenbanken und die standardisierte Erzeugung von Views (Benutzerschnittsellen) vorgegeben, die nachträglich allerdings noch weiter angepaßt werden können. Der Framework soll in einer späteren Verfeinerung die Steuerungs-, Zugriffs-, Oberflächen- und Fachlogikschablonen bereitstellen, die durch Vererbung konkretisiert werden. 3.3

Die Integration des Organisationsmodells in den Business Framework

Die während des Business-Engineerings erstellten Objektmodelle (Organisationsmodell) werden in eine projektübergreifende Facharchitektur, dem objektorientierten Enterprise Application Framework (Business Framework), integriert (s. a. Abb 3.4). Dieser Framework verbindet die Ergebnisse der betrieblichen Modellierung mit den bereits implementierten, technischen Komponenten und ermöglicht somit die Ausführung der spezifizierten Objektmodelle und erlaubt eine umfangreiche Wiederverwendung und einen geregelten Einsatz von Komponenten auf einer höheren Abstraktionsebene.

Das während der Modellierungs- und Analysephasen entstandene Class-Chart des Organisationsmodells kann auf zwei verschiedene Arten zur Ausführung in den Framework integriert werden. Bei beiden Arten muß eine Zuordnung zu bestehenden Klassen des Frameworks im Class-Chart vorgenommen werden. 1. Durch Einfügen der modellierten Objekte als Instanzen bereits existierender BusinessComponents. Diese Integration des ClassCharts kann zur Laufzeit erfolgen, da nur Inhalte von bereits definierten Klassen und deren Links neu erzeugt werden. Diese Erweiterungsart entspricht der BlackboxSchnittstelle. 2. Durch Konstruktion neuer BusinessComponents (Erweiterung des Frameworks). Es wird die spezifizierte Klasse aus dem Class-Chart als Business-Component neu in den Framework eingefügt (Abb. 3.3, nur Spezialisierungshierarchie dargestellt). Dies geschieht durch Spezialisierung bestehender Klassen. Der Framework wird weiter verfeinert. Hier wird die White-Box-Schnittstelle Komponente: Produkt Komponente: Kundenprozeß

OrgUnit

Process

Resource

Business Process

Higher OrgUnit

SIC Gm bH

Business Object

Container

Position

1

Geschäftsführer 1

Sach 1 bearbeitung

10 Sach bearbeiter

1 Bearbeitung

Bearbeiter

3

Kundenprozeß Sim pleProcess

Eingang

Verarbeitung

Produkt

Beleg

Agent

M itarbeiter

Klassen des Frameworks Ausgang

Klassen aus dem Organisationsmodell

Abb. 3.4 Konkretisierung des Frameworks durch Spezialisierung

genutzt. Der rudimentäre Enterprise Application Framework würde zwar einige vorgefertigte BusinessComponents anbieten, könnte dann aber in die Unternehmung „hineinwachsen“, indem neue, firmenspezifische Business-Components konstruiert oder zugekauft werden. Sind die Klassen des Class-Charts in den Framework integriert, kann das Organisationsmodell gestartet werden. Das System aus konkreten Geschäftsobjekten fängt an, sich so zu verhalten, wie es in den State-Charts spezifiziert wurde. Zur genaueren Beschreibung von ausführbaren Objektmodellen wird auf [HG96] verwiesen und zur Beschreibung der Konstruktion von ablauffähigen Komponenten aus dem Organisationsmodell wird auf [EeSi98] (OMG) verwiesen. Als Beispiel sind in Abb. 3.4 zwei ablauffähige Komponenten grau schattiert. Wichtig ist in diesem Zusammenhang, daß diese Komponenten auch alle Klassen des Frameworks aus Abb. 3.1. umfassen.

4 Nutzen und Ausblick Der Enterprise Application Framework (Business Framework) realisiert eine flexibel anpaßbare Middleware. Es werden zur Wiederverwendung Komponenten angeboten, aus denen ein neues System automatisch aufgebaut werden kann. Zukünftig werden keine kompletten Anwendungen mehr entworfen und implementiert, sondern wesentlich kleinere Bausteine, die Komponenten, oder es wird auf bestehende Komponenten aus bereits implementierten Frameworks zurückgegriffen. Im Vergleich zu bestehenden Frameworks (z. B. IBM-San Francisco, Enterprise Java Beans oder über BAPIs des SAP-R/3 Systems) müssen diese wesentlich mehr organisatorische Aspekte berücksichtigen (z. B. Workflowfähigkeit der Komponenten und

die fachliche Ausrichtung der Komponenten an Geschäftsobjekten). Weiterhin ist eine abstraktere Spezifikationssprache (Modelle) an Stelle von Programmiersprachen nötig, damit Betriebsorganisatoren wesentlich stärker an der Konstruktion von Komponenten beteiligt werden können. Komponenten könnten dann automatisch aus Organisationsmodellen abgeleitet werden. Die komponentenorientierte Architektur auf Grundlage eines geeigneten Frameworks ermöglicht eine sehr flexible, schnelle und beherrschbare Anpassung von operativen Anwendungssystemen (sogar zur Laufzeit des Systems, ohne Programmänderungen). Die Konzeption des Business Frameworks beruht auf der Integration in eine bestehende DV-Landschaft und ermöglicht die Einbindung von Altsystemen durch Object-Wrapping. Dadurch ist ein kontinuierlicher und ebenfalls kontrollierbarer Übergang zu der neuen Technologie möglich. Es hat sich gezeigt, daß Techniken zur Verfügung stehen, um saubere Komponenten zu finden, eine flexible Facharchitektur aufzubauen und in einem Rahmenwerk zu implementieren. Der Mut zu unkonventionellen Ansätzen ist dabei eine notwendige Voraussetzung, allerdings auch das größte Hindernis – „People hate changes“ (Tom DeMarco)

Literatur [Bäu97] Bäumer, D., Gryczan, G., Knoll, R., Lilienthal, C., Züllighofen, H.: Framwork Development. C. of the ACM Vol.40, No 10 (1997) 52-59. [BOC99] BOC GmbH: ADONIS Version 3.0. Benutzerhandbuch. Wien 1999. [Dei95] Deiters W., Gruhn V., Striemer R.: Der FUNSOFT-Ansatz zum integrier-

ten Geschäftsprozeßmanagement. Wirtschaftsinformatik, S. 459-466, 1995. [Dei97]. Deiters, W.: Prozeßmodelle als Grundlage für ein systematisches Management von Geschäftsprozessen. Informatik Forschung und Entwicklung, Band 12/2 (1997) 52-60. [EA99] EA Generali Group: Benutzerhandbuch für Business-Object-Framework unter VisualAge, 1999. [EeSi98] Eeles P., Sims O.: Building Business Objects - OMG, John Wiley and Sons, New York, 1998. [Emm91] Emmerich W., Gruhn V.: FUNSOFT nets: A Petrinet based software process modelling language. Proc. of the 6th Int. Workshop on Software Specification and Design, Como 1991. [Fay97]. Fayad, M. E.: Object-Oriented Application Frameworks. C. of the ACM, Vol. 40, No. 10 (1997) October, 3238. [FerSi95] Ferstel O.K., Sinz E.J.: Der Ansatz des semantischen Objektmodells zur Modellierung von Geschäftsprozessen. Wirtschaftsinformatik 3, 1995. [Gall96] Galler J., Hagemeyer J., Scheer A.W.: Asynchroneous cooperation support for distributed collaborative information modeling. In: ISST-Bericht 31/96 Tagungsband zum Workshop der GIFachgruppe „CSCW in Organisationen “, Feb. 1996, Berlin, Frauenhofer ISST 1996. [Gam97]. Gamma. E.; Helm. R.; Johnson. R.; Vlissides, J.: Design-Patterns. 1. Aufl. Reading: Addison-Wesley 1997. [Gruhn96]Gruhn, V.: Geschäftsprozeßmanagement als Grundlage der SoftwareEntwicklung. Informatik Forschung und Entwicklung 2, 94-101, 1996. [HG96]. Harel, D.; Gery, E.: Executable Object

Modelling with Statecharts, Proc. 18th Int. Conf. Soft. Eng., IEEE Press (1996). [IBM94] IBM: FlowMark Modeling workflow. Release 1.1, Publ. Nr. SH19-8175-01 Sept. 1994. [Jab95]. Jablonsky. S.: WorkflowManagement-Systeme. 1. Aufl. Bonn: International Thomson Publishing 1995. [Jo97]. Johnson, R.E.: Frameworks = (Components + Patterns). C. of the ACM Vol.40, No 10 (1997) 39-42. [ONE96] ONEstone: PROZESSWARE Workflow Development & Management Tool auf Basis von Lotus Notes, ONEstone Information Technologies GmbH, Paderborn 1996. [Öst95] Österle H.: Business Engineering: Prozeß- und Systementwicklung, Band 1, Springer, Berlin, 1995. [Pree97]. Pree. W.: Komponentenbasierte Sofwareentwicklung mit Frameworks. 1. Aufl. Heidelberg: dpunkt 1997. [Scheer94]Scheer A.-W.: Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse, Springer Verlag, Berlin 1994. [Szy98] Szyperski. C.: Component Software – Beyond Object-Oriented Programming, 2. Auflage, ACM Press & Addison Wesley, Harlow 1998. [Tay95]. Taylor. D. A.: Business Engineering with Object Technology. 1. Aufl. New York: John Wiley & Sons 1995. [WeiWo97]Wodtke D., Weikum G.: A Fomal Foundation for Distributed Workflow Execution Based on Statecharts. Proc. of the Int. Conf. on Database Theory 1997. [Zei99a] Zeidler, F.: Eine Komponentenarchitektur auf Grundlage eines Enterprise Application Frameworks. Tagungsband der GI-Tagung „Modellierung `99“, Teubner Verlag Stuttgart 1999. [Zei99b] Zeidler, F.: Tagungsband des GI Workshops „Komponenten orientierte

Anwendungsentwicklung“, Universität Magdeburg, (Hrsg. Turowski, K.), 1999