* Dieter Hieke ist als Berater bei Plenum Management Consulting in Hamburg tätig; Volker Oesinghaus reitet diese Geschäftsstelle, während Hartmut Skubch die Geschäfte von Plenum Managern in Wiesbaden führt.

Auf das DV-Management kommt ein erheblicher Umdenkprozeß zu: Künftig wird die Systementwicklung immer stärker geprägt sein vom Zusammenwirken der Faktoren Objektorientierung, unternehmensweites Datenmodel und biokybernetisches Systemverständnis. Dieter Hieke, Volker Oesinghaus und Hartmut Skubch* beschreiben eine Methode, die auf diesen Voraussetzungen basiert.

Trotz technologischer Konzepte wie SAA, trotz Einsatz von IDV-Mitteln zum einen und CASE-Euphorie zum anderen hat sich die Leistungsfähigkeit unserer DV-Bereiche nicht durchschlagend verbessert. Wir steuern im Gegenteil immer stärker auf eine beinahe katastrophale Situation zu.

Das Rationalisierungspotential durch DV-Systeme ist weitestgehend erschöpft. Die ständig steigenden DV-Budgets lassen sich durch ihre "Rendite" kaum noch rechtfertigen. Die künftigen Anforderungen an das Informations-Management liegen bald nur noch im Bereich der flexiblen Anpassung; dies gilt sowohl, für die Informationsbeschaffung, -aufbereitung und -bereitstellung als auch für die Anpassung an organisatorische, technologische und geschäftspolitische Änderungen.

Ursache für die Leistungseinbuße

In der Zukunft wird die Leistungsfähigkeit der DV-Abteilung primär an ihrer Reaktions-Fähigkeit auf diese Veränderungen und an dem damit verbundenen Aufwand gemessen werden. Darauf sind wir in keiner Weise vorbereitet.

Primär sind es drei Problemkreise, die noch immer die Leistungsfähigkeit der heutigen DV/Organisations-Bereiche in den Unternehmen beeinträchtigen.

Datenchaos und Informationsdefizite: Trotz relationaler Datenbanken, trotz verstärkter Datenanalyse in den Projekten und trotz des endlich vorhandenen Datenadministrators ist der Datenbestand häufig eher ein Datenfriedhof. Das Informationspotential der Datenbestände wird nur in ganz geringem Maße genutzt. Das Thema Datenmodell entpuppt sich zwar langsam auch in Vorstandsetagen als salonfähig, aber die konkrete Nutzung ist von den DV-Verantwortlichen noch nicht genau genug durchdacht. Die Frage der Umsetzung in die konkrete Anwendungsentwicklung bleibt häufig unbeantwortet.

Geringe Flexibilität und Wiederverwendbarkeit: Trotz Modularisierung und ausgefeilter Unterprogrammtechnik ist auch die Wiederverwendbarkeit von Softwarebausteinen großenteils noch Wunschdenken. Es ist keine Seltenheit, daß große Teile komplexen Anwendungssysteme mehrfach entwickelt werden, weil man ihre strukturelle Ähnlichkeit nicht erkannte. Außerdem sind unsere Anwendungssysteme überfrachtet mit organisatorischen Verfahrensweisen und Abläufen. Jede Änderung der Organisation führt demnach zur Hochkonjunktur bei den Wartungsprogrammierern.

Auch äußere Einflüsse man denke nur an die Einführung und Abschaffung der Quellensteuer - beschäftigen ganze Heerscharen von Programmierern.

Lange Projektlaufzeiten und deterministische Systementwicklung: Trotz intensiver Einbeziehung der Fachbereiche bei der Erstellung der Fachkonzepte ist die Überraschung immer groß, wenn die Entwickler aus der Realisierungsphase wieder auftauchen und die Fachbereiche das Ergebnis nicht mit Jubel aufnehmen.

Zu lang sind noch die Projektlaufzeiten, zu sehr ändern sich währenddessen die "Umweltbedingungen, und zu sehr ist noch der Glaube an das Phasenkonzept als Wasserfallmodell verbreitet, der Glaube, man könne komplexe Systeme beliebig genau spezifizieren und sie dann genau so realisieren.

Was müssen wir anders machen? Zuerst sollten wir das Kurieren an den Symptomen einstellen. Hören wir auf damit, einen Prozeß (klassisches Vorgehensmodell) automatisieren zu wollen (klassischer CASE-Ansatz), der von seinem Grundverständnis her der falsche Weg ist und nicht zum Erfolg führen kann!

Nur die grundsätzliche Änderung unserer Denkhaltung kann den Weg frei machen zu einer entscheidenden Verbesserung in der Informationsversorgung unserer Unternehmen zu akzeptablen Kosten.

Der Weg dahin ist evolutionär, denn wir können auf dem bisherigen Wissen aufbauen. Radikal ist nur die neue Denkhaltung; hier darf es keine Kompromisse geben. Das neue Denken in der Systementwicklung setzt sich aus vier Komponenten zusammen.

1. Biokybernetisches Systemverständnis:

Ein Informationssystem ist komplex und nicht deterministisch. Es läßt sich in der Entwicklung nicht bis ins letzte Detail vorherbestimmen. Dies gilt schon deswegen, weil der Mensch integraler und kreativer Bestandteil und nicht lästiger Störfaktor dieser Systeme ist. Die Systeme der Zukunft werden sich evolutionär entwickeln; die Kunst der Systementwickler wird darin bestehen, zunächst "lebensfähige Einzeller" zu schaffen, die sich dann durch permanente Kommunikation mit ihrer Umwelt schrittweise weiterentwickeln oder aber "aussterben", wenn sie nicht mehr lebensfähig sind.

2. Funktionaler Aufbau:

Ein Informationssystem unterliegt vielfältigen Einflüssen wie Markt, Technologie, Aufbau- und Ablauforganisation. Diese Einflüsse dürfen nicht ungefiltert auf das Informationssystem als Ganzes durchschlagen. Das System muß so konstruiert sein, daß die Einflüsse in einzelnen funktionalen Schichten (Schichtenmodell) aufgefangen und behandelt werden.

3. Objektorientierung:

Wir müssen Daten und Prozesse wieder mehr als Einheit als Objekt - betrachten, so wie es der Realität entspricht. Diese Objekte bilden stabile Elemente (Einzeller), aus denen sich komplexe Gebilde zusammensetzen lassen die wiederum leicht verändert, also angepaßt werden können.

4. Datenmodellorientierung:

Wir müssen die Architekturen der Informationssysteme grundsätzlich an den Strukturen der Daten orientieren, da sich diese Strukturen als sehr stabil gegen über Umweltveränderungen erwiesen haben. Äußere Veränderungen verfälschen ein gut entwickeltes Datenmodell nicht; es wird nur konkreter beziehungsweise detaillierter. Dies gilt beispielsweise für einen Funktionenbaum im allgemeinen nicht.

Auf der Basis dieser Denkansätze wurde die Datenmodell-Objekt-Methode (DMO) entwickelt. Die Einzelteile dieser Methode waren schon bekannt, aber die Kombination von Datenmodell, Objektorientierung, Schichtenmodell und evolutionärer Systementwicklung - basierend auf einem biokybernetischem Systemverständnis - zu einem praxisgerechten Vorgehen ist sicherlich neu. Die DMO eröffnet uns ein Verfahren, mit dem wir schrittweise Bausteine entwickeln können, die in der Praxis reifen und sich gegenüber künftigen Anforderungen und Veränderungen als flexibel erweisen.

Grundlage aller Software-Engineering(SE)-Methoden ist die Analyse von informationsverarbeitenden Prozessen, um Funktionen und Daten zu identifizieren und ihre wechselseitigen Abhängigkeiten wie Kommunikation und Ablauf darzustellen. Die Mehrzahl der Methoden legt das Schwergewicht auf die "Funktionen", die "Daten verarbeiten und wieder ausgeben.

Eine unternehmensweite Betrachtung zeigt aber, daß bei Änderung geschäftlicher Abläufe und organisatorischer Zuständigkeiten das Datenmodell wesentlich stabiler als das Funktionenmodell und das Einbeziehen zusätzlicher Geschäftsfelder im Datenmodell meist einfacher ist. Daher geht der DMO-Ansatz vom Datenmodell aus. Die Funktionen werden den Daten zugeordnet und nicht umgekehrt.

Einfache Terminologie

Diese Idee floß auch in die Konstruktion von objektorientierten (00)-Sprachen ein. So sind im DMO-Ansatz Begriffe und Denkweise zu finden, die in den 00-Sprachen benutzt werden.

Die Qualitätsmerkmale "Wiederverwendbarkeit", "Änderbarkeit" und "Testbarkeit" finden sich bei Softwaresystemen, die mit Hilfe der 00-Sprachen entwickelt wurden; diese Eigenschaften charakterisieren auch die mit der DMO-Methode entwickelten Anwendungen. Die aus der 00-Welt entlehnte Terminologie ist hingegen bewußt einfach gehalten. Auf Begriffe wie "Klasse", "Klasse von Klassen" oder "Instanz" wird verzichtet, da - unserer Erfahrung nach - die Probleme bei der Vermittlung dieser Begriffe größer sind als der Nutzen ihrer Einführung.

Die objektorientierte Systementwicklung geht von der Erfahrung und der Art und Weise aus, wie Objekte der realen Welt miteinander agieren. Dabei spielen vor allem drei Begriff-Komplexe eine Rolle:

- Objekt:

Ein Objekt hat einen Namen, bestimmte Eigenschaften und bestimmte Verhaltensweisen. Eigenschaften und Verhaltensweisen werden ausgedruckt durch Daten (Objekt-Attribute) und Prozeduren (Objekt-Funktionen).

- Signal Nachricht:

Objekte kommunizieren miteinander, indem sie Signale oder Nachrichten austauschen. Wenn ein Objekt eine Nachricht erhält, wird geprüft, ob eine zur Nachricht passende Objekt-Funktion existiert. Diese Objekt-Funktion wird anschließend ausgeführt.

- Hierarchie und Vererbung:

Objekte können hierarchisch geordnet werden. Je nach Sichtweise gibt es Super- (die "darüber") und Subobjekte (die "darunter"). Subojekte erben die Eigenschaften und Verhaltensweisen ihrer Superobjekte.

Bei Anwendung der DMO-Methode in der Systementwicklung entsteht eine Software-Architektur, die von den Entitäten des Datenmodells ausgeht. Sie basiert auf den im System benutzten Objekten und nicht auf den durchzuführenden Funktionen.

Es wird eine strukturierte Sammlung von Objekten gebildet, die miteinander agieren. Die Objekte sind dabei weitgehend "selbständig" und unabhängig von dem sie umgebenden System. Solche Objekte lassen sich in anderen Systemen wiederverwenden. Die Systemkonstruktion kann dann als Bottom-up-Kombination von vorher definierten Objekten erfolgen.