Kostensteigerungen, Qualitaetsanforderungen und immer kuerzere Softwareproduktzyklen fuehrten zu Ueberlegungen, wie sich Programme produktiver entwickeln liessen. Ergebnis war der Gedanke an ein bausteinorientiertes Modell mit einem hohen Mass an Wiederverwendbarkeit der einzelnen Bausteine. Hans-Joerg Bullinger, Klaus-Peter Faehnrich und Dietmar Kopperger* erklaeren, was Entwickler und Anwender von Componentware haben koennen.

Grosse Hoffnungen, Wiederverwendbarkeit in die Praxis umsetzen zu koennen, galten der Objektorientierung. Das Ziel dieser Technologie ist es, einfache wiederverwendbare Softwarekomponenten zu erarbeiten und diese dann in Form von Klassenbibliotheken zur Verfuegung zu stellen. Problematisch ist dabei jedoch, dass man in der Regel das einzelne Objekt nur mit grossen Anwendungssystemen bearbeiten kann. Um von dieser applikationszentrierten Wiederverwendbarkeit der einzelnen Objekte loszukommen, erfolgte ein Wechsel zu einer dokumentenorientierten Anwendungsarchitektur.

Dokumentenorientierter Ansatz als Grundlage

Neben dieser Sicht der Componentware entstand eine zweite, die die Anwendungsfunktionalitaeten auf einem hoeheren Abstraktionsgrad betrachtet. Dabei bewegen sich die Objekte auf dem Funktionalitaetsniveau von beispielsweise Termin-Management und Mail. Das Zusammenspiel und die Schnittstellen der einzelnen Komponenten steht im Mittelpunkt.

Mit Componentware sollen freie, kombinierbare und austauschbare Operatoren sprachuebergreifend und skriptorientiert programmieren sowie Nutzung und Distribution vereinfachen koennen. Diese Ziele lassen sich nur mit einem dokumentenorientierten Ansatz erreichen.

Ausgangspunkt dessen ist die Ueberlegung, Objekte unterschiedlichster Herkunft in ein Dokument zu integrieren. Die Werkzeuge, die fuer eine Bearbeitung notwendig sind, stellt das System zur Verfuegung. Der Anwender arbeitet nur noch mit dem Dokument und muss sich keine Gedanken ueber die zur Bearbeitung benoetigten Applikationen machen.

Fuer die Entwicklung der Anwendungsapplikationen bedeutet dies, dass sie sich nur noch um die spezifische Funktionalitaet der Programme kuemmern muss. Standardfunktionalitaeten lassen sich aus den vorhandenen Komponenten entnehmen. Damit waechst die Produktivitaet bei hoher Qualitaet, und das Bedienungsmuster wird dank der Standardfunktionen einheitlicher.

Es existieren zwei verschiedene Dokumentenmodelle, OLE 2.0 von Microsoft und Opendoc von den Component Integration Laboratories (CIL), einem Firmenkonsortium.

OLE 2.0 ist ein Standard fuer Compound Documents (zusammengesetzte Dokumente). Hinter diesem Begriff verbirgt sich ein sogenannter Container, der die verschiedensten Dokumente beinhalten kann, zum Beispiel Tabellen, Texte oder Grafiken. Bei der Integration der einzelnen Objekte zu einem zusammengesetzten Dokument ergeben sich zwei Moeglichkeiten: die Einbettung eines Objekts oder die Referenzierung auf ein solches.

Eine Einbettung bedeutet, dass das Objekt im Zusammenhang mit dem einzelnen Dokument gespeichert wird und auch nur in diesem bearbeitet werden kann.

Bei der Referenzierung erfolgt eine vom Verbunddokument unabhaengige Speicherung. Damit lassen sich verschiedenste Dokumente separat bearbeiten sowie auf das Objekt referenzieren.

Eine Alternative zu OLE stellt Opendoc dar, das die Firmen Apple, Borland, IBM, Novell, Sunsoft, Oracle, Taligent und Xerox propagieren und das auf dem Objektmodell DSOM (Distributed System Object Model) der IBM aufsetzt. Angestrebt wird die Festlegung eines Konzeptes fuer den Aufbau von verteilten Anwendungen. Das Modell ist fuer plattformuebergreifendes Arbeiten gedacht und soll zu einem spaeteren Zeitpunkt in der Lage sein, mit anderen Dokumentenmodellen Objekte auszutauschen.

Unterschiede zwischen OLE und Opendoc

Die Dokumente sind bei diesem Modell in einzelne Elemente, sogenannte Parts, unterteilt. Fuer diese stehen Editoren (zur Bearbeitung) und Viewer (zur Ansicht und zum Ausdruck) zur Verfuegung. Jedes Element besitzt ein Modell mit Objekten und Operatoren, das es hinsichtlich der Darstellung gegenueber dem Anwender spezifiziert.

OLE und Opendoc weisen Gemeinsamkeiten, aber auch deutliche Unterschiede auf. Bei beiden Modellen vereinfacht Drag and drop den Datenaustausch. Dabei betrachtet OLE noch den Objekttyp und macht von ihm Einbettung oder Referenzierung abhaengig. Was die Sprachen betrifft, ist der OLE-Nutzer auf Visual Basic for Applications festgelegt, waehrend Opendoc sich an der verwendeten Plattform orientiert, so dass der Einsatz von unterschiedlichen Sprachen moeglich ist. Versionsverwaltung von Objekten in einem Dokument ist nur in Opendoc moeglich.

Das Zusammenspiel der einzelnen Software-Objekte regeln bei beiden Modellen objektorientierte Mechanismen, die die Kommunikation zwischen den Objekten sowie ueber die Grenze einer Rechnerwelt hinweg bestimmen. Zur Erstellung von Bausteinsoftware gibt es verschiedene Objektmodelle. Bekannt sind beispielsweise Appware von Novell, Common Object Model (COM) von Microsoft, Distributed Objects Everywhere (DOE) von Sun, Distributed Object Management Facility (DOMF) von HP, Object Exchange (OBEX) von Borland, Portable Distributed Objects

(PDO) von Next und System Object Model (SOM) beziehungsweise DSOM von IBM.

Viele Unternehmen stellen momentan ihre DV-Infrastruktur auf Client-Server-Umgebungen um. Dabei sind vorhandene, teils selbst entwickelte Systeme in die neue Umgebung zu integrieren. Am Fraunhofer-Institut IAO wurde zur Unterstuetzung von Anwendern in dieser Situation ein methodisches Vorgehen entwickelt, das im folgenden erlaeutert werden soll.

Eine Basishypothese ist, dass IuK-technische Plattformen der naechsten Generation nur unter verstaerktem Einsatz von marktgaengigen Standardbaugruppen (Componentware) entwickelt werden sollten. Diese decken die Bereiche Buerokommunikation, Computer Supported Cooperative Work und Mail, Geschaeftsprozess-Management mit Vorgangsbearbeitung und -steuerung, Dokumenten-Management einschliesslich Imaging, Archivierung und Retrieval sowie vertikale Standardsoftware (PPS, MIS, CAD etc.) ab.

Unter Abstimmung des DV- und des Organisationsbereiches und unter Integration der Anwenderbereiche wird ein umfassender Anforderungskatalog erarbeitet, der - nach bisherigen Erfahrungswerten - zwischen 500 und 800 Kriterien umfassen kann. Mit Hilfe der Prozessmodellierung erfolgt die Beschreibung eines Geschaeftsprozesses. Dabei handelt es sich um ein Aneinanderreihen von gewuenschten Funktionalitaeten, die das Unternehmen benoetigt, die aber unter Umstaenden auf verschiedene Realprozesse verteilt sind. Es bietet sich an, einen Realprozess um die gewuenschte Funktionalitaet zu ergaenzen.

Ist der Prozess modelliert, so wird er, genauso wie der Kriterienkatalog, den Anwendern vorgelegt. Diese bewerten die Wichtigkeit der einzelnen Funktionen fuer bestimmte Abteilungen. Damit entstehen Praeferenzreihenfolgen.

In aller Regel kann kein Anbieter saemtliche gewuenschten Funktionen abdecken. Daher gilt es, ein Konsortium mehrerer Unternehmer ins Leben zu rufen. Dazu werden fuer die einzelnen Hauptkriteriengruppen des Kataloges die marktfuehrenden Anbieter ermittelt. (Am Fraunhofer-Institut IAO existieren hierzu umfangreiche Marktanalysen, auf die Anwender zurueckgreifen koennen.)

Im Vordergrund steht die Entwicklung einer Architektur fuer Buerokommunikation und Daten-Management als Teil einer Client- Server-Architektur mit Steuerungsebene, Anwendungs-Clients, Bearbeitungs-Clients, Kommunikationsschicht und Systemdiensten. In diese Architektur werden Standardpakete als Componentware eingebettet. Ein Middleware-Spezialist uebernimmt die Rolle des Systemintegrators. Dazu muss er Staerken im Bereich der Kommunikation und/oder des Daten-Managements haben. Er integriert die benoetigte Client- und Spezialsoftware (zum Beispiel fuer das Dokumenten-Management).

Zumeist bietet er Unterstuetzung bei Konfiguration und Betrieb (Netzwerk- und System-Management) der spaeteren Loesung an.

Dabei wird der Versuch unternommen, ausgehend von einer Buerokommunikations- oder Groupware-Standardloesung mit hohem Marktanteil wie Microsoft Office oder Lotus Notes fehlende Komponenten zu integrieren. Dabei gibt es derzeit allerdings oft Schwierigkeiten mit den Workflow-Elementen. Auch waere erst nachzuweisen, wie weit diese bisher eher lokal mit grossem Erfolg verwendeten Loesungen auch die Basis fuer eine unternehmensweite Plattform bilden koennen. Bei Microsoft zeichnet sich mit dem Exchange Server eine interessante Entwicklung ab, die man zumindest fuer mittelgrosse Anwendungen oder als eine weitere Zwischenschicht fuer groessere Unternehmensbereiche und Aussenstellen im Auge behalten sollte.

Sehr reizvoll erscheint auch eine Loesung, bei der Workflow-Systeme einer Systemintegration dienen. Dabei soll die explizite Vorgangssteuerung eine prozessorientierte Systemintegration von Buerokommunikations-, Groupware- und Daten-Management-Komponenten leisten. Das Workflow-System aktiviert Anwendungsmodule beziehungsweise Systeme und initiiert und ueberwacht den Austausch von Datenobjekten.

Die Entwicklung eines Prototypen zwingt die Beteiligten, sich noch eingehender mit der Thematik zu beschaeftigen. Bei Tests unter Echtbedingungen gewinnt das Unternehmen weitere Informationen fuer die Einfuehrung der entsprechenden Systeme.

Parallel dazu gilt es, die Migration der bestehenden Dokumente und Services in die Wege zu leiten. Ein auf die geplante Systemeinfuehrung abgestimmter Migrationsplan muss aufgestellt werden. Eine Migration ist sehr unternehmensspezifisch und kann je nach Anzahl und Komplexitaet der betroffenen Objekte mehrere Jahre dauern.

Die beiden Schlagworte Integration und Wiederverwendbarkeit zeigen, worin die Bedeutung von Componentware in der heutigen DV- Welt liegt. Wiederverwendbare und integrierbare Softwareprodukte bedeuten hoehere Produktivitaet und sinkende Kosten bei hohem Qualitaetsniveau. Componentware wird demnaechst noch wichtiger werden.

Literatur:

Bullinger, H.-J.; Faehnrich, K.-P.; Kopperger, D.: Componentware. In: "Office Management" 1-2/1995, Seite 14-20

Bullinger, H.-J.; Faehnrich, K.-P.; Kopperger, D.: Component Ware: Integration von Dokumentenmanagement, Boerokommunikation und Anwendungssystemen in Client-Server-Umgebungen. In: Bullinger, H- J.

(Hrsg.): Dokumenten- und Workflow-Management. IAO-Forum 18.05.1995.

Stuttgart; Institut fuer Arbeitswirtschaft und Organisation, Seite 13-68

Bullinger, H.-J.; Weisbecker, A.: Innovative Software-Technologien fuer die Unternehmen der Zukunft. In: Bullinger, H-J. (Hrsg.): Neue Software-Technologien im Einsatz. IAO-Forum 29.11.1994. Stuttgart; Institut fuer Arbeitswirtschaft und Organisation, Seite 9-29

Kroeger, S.: Baukasten-Software. In: "Business Computing" 4/1995, Seite 60-64

Malischewski, C.: Component Ware. In: "Wirtschaftsinformatik" 1/1995, Seite 65-67

Udell, J.: Component Ware. In: "Byte" 5/1994, Seite 46-56

*Professor Dr.-Ing.habil. Hans-Joerg Bullinger, Universitaet Stuttgart, ist Leiter des Fraunhofer-Instituts fuer Arbeitswirtschaft und Organisation (IAO) in Stuttgart.

Dr.-Ing. Diplommathematiker Klaus-Peter Faehnrich leitet am IAO stellvertretend den Fachbereich Informations-Management.

Diplomkaufmann Dietmar Kopperger ist im Dokumenten-Management- Zentrum des IAO taetig.