Artikel von Frank Zeidler, freier Berater bei PROJECT CONSULT in Hamburg
Die Anforderungen an die Organisationsentwicklung (Business-Engineering) und somit auch an die Softwareentwicklung (Software-Engineering) für betriebliche Anwendungen steigen. In immer kürzeren Abständen muß auf die veränderten Marktverhältnisse reagiert werden. Als Achillesferse hat sich hier die Entwicklungszeit von geeigneten Anwendungen herausgestellt. Bestehende Soft-wareentwicklungsprozesse sind für moderne Unter-nehmungen nicht mehr tragbar. Eine radikale Re-strukturierung des Software-Engineerings mit einer wesentlich stärkeren Integration in das Business-Engineering ist notwendig. Eine komponentenbasierte Entwicklung soll dabei behilflich sein. In einem speziellen Ansatz dieses Trends stehen Business-Objects als Komponenten. Die Komponenten haben in diesem Ansatz den Charakter unabhängiger verteilter Objekte.
Der Begriff Business-Object wird in der Literatur bisher uneinheitlich verwendet. Mehr und mehr setzt sich jedoch die Definition der Business Domain Task Force (BODTF) der OMG (Object Management Group) durch. Sie versteht unter einem Business-Object die Repräsentation eines Gegenstandes aus dem realen Geschäftsleben. Die Repräsentation umfaßt neben der Artbezeichnung und der Beschreibung Angaben über Attribute, Verhalten, Beziehungen und Regeln. Modelliert werden Business-Objects im Rahmen einer objektorientierten Analyse. Während bei einer objektorientierten Anwendungsentwicklung die in der Analyse erkannten Objekte in eine konkrete Applikation einfließen, werden im Rahmen der Business Objekt-Entwicklung zu den Analyse-Objekten eigenständige Softwarekomponenten realisiert. Man spricht von einer „Objektorientierung (OO) im Großen“, weil das OO-Prinzip der Kapselung von Daten und Funktionen nicht nur innerhalb eines Anwendungssystems wie bei der OO im Kleinen angewendet wird, sondern systemübergreifend auf der Ebene der Unternehmensarchitektur. Dadurch entsteht eine eigene unternehmensweite Anwendungsarchitektur, die durch die Struktur der Domäne (Unternehmensorganisation) geprägt ist.
Abbildung 1: Objektorientierte Softwareentwicklung
Bestehende Entwicklungen gingen bereits in diese Richtung. Durch den Einzug der Methode des Business-Process-Reengineerings in das Business-Engineering wurde nicht nur die prozeßorientierte Sicht auf eine Unternehmensorganisation eingeführt. Wichtiger war die Tatsache, daß zum erstenmal Methoden aus dem Software-Engineering im Business-Engineering angewendet wurden. Zentraler Bestandteil der Methoden ist ein Modell. Im Business-Engineering resultierten daraus ausdrucksstärkere Modelle wie die Geschäftsprozeßmodelle und auch neuerdings die Produktmodelle beispielsweise im Versicherungsbereich. Es bestand die Möglichkeit auf Grundlage eines gemeinsamen Modells die beiden Methoden zu vereinen. Prozeßmodelle wurden als Workflows zur Ausführung gebracht. Der aktuelle Trend im Software-Engineering hin zu Komponenten-orientierter betrieblicher Anwendungsentwicklung vernachlässigt aber wieder die Diskussion um den Einsatz von Modellen und entfernt sich somit wieder von einer Vereinheitlichung mit dem Business-Engineering. Die einzelne Softwarekomponenten sind so überschaubar, daß sie auch ohne Modell entwickelt werden können.
Wo bleibt also das Modell in einer Welt aus Komponenten?
Ein umfassendes homogenes Modell ist weiterhin ein elementarer Bestandteil einer Methode zur kontrollierten Konstruktion komplexer Systeme, betrieblicher Anwendungssysteme oder Unternehmensorganisationen. Mit umfassend ist gemein, daß alle relevanten Geschäftsobjekte in einem Modell modellierbar sein sollten. Homogen bedeutet, das alle Geschäftsobjekte nach einem einheitlichen Paradigma entworfen werden. Das bedeutet nicht sofort ein allumfassendes objektorientiertes Unternehmensmodell. Dieses Modell kann sukzessive und dezentral erstellt werden, je nachdem wie weit der Betrachtungsbereich im Unternehmen ausgeweitet wird. Ziel ist letztendlich aber ein unternehmensweites objektorientiertes Modell aus Business-Objects, welches als einheitliche Basis oder auch als Kern eines betrieblichen Nutzungskonzeptes zur Ableitung oder Generierung von Softwarekomponenten dienen kann. Die Konzepte der Business-Objects müssen dafür erweitert werden.
Business-Objects sind „Gegenstände aus dem realen Geschäftsleben“. Diese Betrachtung läßt wesentliche Aspekte aus dem Business-Engineering außer acht. Im Business-Engineering spielen nicht nur Gegenstände (Ressourcen) wie Akten, Dokumente, Geräte oder auch Personen eine Rolle, sondern wesentlich mehr sogar abstraktere Gebilde wie z.B. Geschäftsprozesse und OrganisationsAbbildung 2: Einfaches Beispiel eines Rahmenmodells und eines Analysemodells
strukturen. Auch diese „Gebilde“ sollten Business-Objects sein und somit durch eine eigene Softwarekomponente realisiert werden. Geschäftsprozeßmodelle und Organisationsstrukturmodelle müssen Bestandteil eines Unternehmensmodells sein. Wichtig in diesem Zusammenhang ist auch der Einsatz von höheren Modellierungskonzepten, wie z. B. der Einsatz von Rahmenstrukturen (Frameworks), um betriebliche Standards im Modell festzulegen und somit die Freiheiten bei der dezentralen Modellierung sinnvoll einzugrenzen. Die obere Abbildung zeigt ein vereinfachtes Beispiel eines Modells einer kleinen Versicherung. Zum einen wurde eine Klassenhierarchie, der Framework, mit Standards für zukünftige Modelle im Unternehmen festgelegt. Ein erwähnenswerter Nebeneffekt dieser Klassenhierarchie ist eine unternehmensweite Definition aller wichtigen Begriffe. Ein im Rahmen eines Reorganisationsprojektes entwickeltes Analysemodell (z.B. von der Fachabteilung) muß in den Framework „passen“. Entweder werden ganze Klassen aus dem Framework wiederverwendet (in der Abbildung grüne Klassen) oder durch Vererbung werden bestehende Eigenschaften auf neue Klassen vererbt (Superklasse in grün annotiert). Das Standardverhalten der Klassen aus dem Framework bleibt dabei erhalten oder kann an bestimmten Punkten, den sogenannten „Hot Spots“ kontrolliert verändert werden. Das Modell des Frameworks ist in diesem Beispiel nur rudimentär. Die Verfeinerung dieser Unternehmensstandards könnte einer Betriebsorganistion unterliegen. Erweiterungen beträfen z. B. ein standardisiertes unternehmensweites Berechtigungskonzept, die Festlegung von Zielen, ein standardisiertes Dokumenten-Managment-Verfahren und vieles mehr. Ein Workflow-Management-Systeme wäre bereits realisiert. Denn jedes Business-Object „trägt“ sein Verhalten nach den OO-Konzepten in sich. Eine solche „Workflow-Engine“ wäre in der Klasse Business-Object im Framework realisiert und würde sich auf alle zukünftigen Klassen vererben. Jede Komponente enthält somit einen eigenen Workflow. Wenn die Standards eines Frameworks angereichert würden um technische Aspekte könnten aus einem solchen zentralen Unternehmensmodell (Framework + integriertem Analysemodell) die einzelnen Softwarekomponeten automatisch abgeleitet werden. In der obigen Abbildung sind die Klassen grau hinterlegt, die durch eine Softwarekomponete realisiert werden. Das Unternehmensmodell liefert nun auch eine Grundlage zur Strukturierung und Bildung von Komponenten. Somit ist ein Nutzungsskonzept zum kontrollierten Einsatz von Komponenten im Unternehmen gegeben. Allerdings liegt nicht mehr die Zuständigkeit für ein Frameworkmodell allein bei der Betriebsorganisation, sondern auch bei der 
Abbildung 3: Integration des Analysemodells in das Rahmenmodell und Bildung von Komponenten
DV-Abteilung, bzw. Betriebsorganisatoren mit grundlegenden Kenntnissen der DV. Die Realisierung und Wartung eines geeigneten Laufzeitsystems, welches ein Unternehmensmodell verwaltet und Komponenten daraus ableitet und implementiert ist zwar nicht so umfangreich aber sehr komplex, da abstrakt programmiert und gedacht werden muß. Hier sind gute Informatiker unabdingbar. Die Komplexität wird aber durch neuere Entwicklungen wie z. B. JavaBeansä und Enterprise JavaBeansä, die den Entwickler Im Client- als auch im „middle-tier“-Bereich einer dreischichtigen Client/Server-Architektur unterstützen bei der Transaktionsverwaltung, Verwaltung von Instanzen einer Komponenten, der Verbindung zu Datenbank Management Systemen (DBMS) und der Sicherheit für unternehmensweit verteilte Komponenten. Der zentrale Nutzen der konsequent weitergedachten Business-Object-Technologie liegt in der Strukturierung der Anwendungsarchitektur. Damit wird der DV-Bereich, speziell der Software-Entwicklungsprozeß, kontrollierbarer und ein Unternehmen wesentlich flexibler aus folgenden Gründen. Die Anwendungsarchitektur wird bedingt durch die Unternehmensorganisation. Änderungen in der Unternehmensorganisation betreffen genau die korrespondierenden Geschäftsobjekte der operativen Anwendung. Es kommt zu keinen Wechselwirkungen zu anderen Teilen der Anwendung, da nach den OO-Konzepten eine feste Schnittstelle der Komponenten besteht und die Komponenten über Ereignisse nur lose gekoppelt sind. Ein solches System ist konzeptionell auf ständige Änderungen und Anpassungen vorbereitet. Durch die Objektorientierung „im Großen“ und die Realisierung der Business-Objects durch verteilte Komponenten werden kleine standardisierte und beherrschbare Softwarebausteine mit definierten Schnittstellen produziert (evtl. sogar automatisch). Die Aufträge an die DV-Abteilung zur Erstellung oder Änderung einer solchen Komponente sind somit ebenfalls fest abgegrenzt. Es entstehen kleine wenige Tage umfassende DV-Projekte zur Anpassung des Systems. Diskussionen um Aufwände zur DV-Realisierung werden transparenter und kontrollierbarer.
In dieser Technologie liegt noch erhebliches Potential um flexible Anwendungssysteme zu konstruieren. Dabei geht es primär nicht um eine völlige Ablösung der beste-henden DV-Systeme auf einen Schlag – das wäre betriebswirtschaftlich unsinnig und wegen der damit verbundenen Risiken auch technisch nicht zu rechtfertigen. Vielmehr soll ein all-mählicher Übergang ermöglicht werden, der es erlaubt, daß das neue System in die bestehende DV-Landschaft komponentenweise „hineinwächst“ und das Alt-system sukzessive verdrängt. Bestehende Systeme könnten über spezielle Interface-Objekte eingebunden werden. Bestes Beispiel sind die angebotenen Business Objects von SAP (www.sap.de), hier liegen die Schnittstellen zum SAP-System schon als Business Objects vor. Weiterer Nutzen eines geeigneten Unternehmensmodells ist eine einheitliche Sprache über Abteilungsgrenzen hinweg. Es existiert ein Modell an dem jeder kontrolliert weiterbaut. Dies ist die Grundlage für weiterführende Veränderungen im Unternehmen, z. B. die Einführung neuer Technologien und Innovationen. Das Modell stellt den Bauplan des Unternehmens dar, erst jetzt ist eine ingenieursmäßige Unternehmensorganisation und Management möglich. (FZ) 
Metadata
