Der Anwendungsstau ist Alltag geworden. Um zu verhindern, daß immer komplexere Entwicklungs-Projekte unter der Last von dutzenden von Mannjahren zusammenbrechen, schlägt Reiner Hegenbart* vor, die Anwendungsentwicklung zu automatisieren. In gar nicht so ferner Zukunft sollen qualifizierte DV-Anwender ihre Programme selber erstellen können.
Wer glaubt im Ernst, daß die Anwendungsentwicklung künftigen Herausforderungen mit den herkömmlichen Verfahren begegnen kann, und würden sie noch so schulbuchmäßig angewandt? Zuerst Anforderungsdefinition, dann Grobanalyse, dann Feinanalyse, dann Programmierung, dann Test und schließlich der Wartungsberg, der stetig wächst, wenn man versucht, ihn abzutragen. Es kann nicht angehen, daß wir diesen Wust über die Jahrtausendwende schleppen.
Wenn alles automatisierbar ist, dann auch die Automation. Setzen wir also eine Datenbank ein, um Datenbanken zu erzeugen, verwenden wir einen hilfsbereiten Dialog, um hilfsbereite Dialoge zu schaffen. Was wir brauchen ist eine, wie ich es nenne, automationsorientierte Anwendungsarchitektur.
Ein Vergleich mit dem menschlichen Organismus soll ein mögliches ganzheitliches Unternehmenssystem veranschaulichen (vergleiche Abbildung 1). Das System könnte aus sechs Komponenten bestehen. Das Herz des Ganzen ist die Steuerung. Als Gesicht oder Monitor stelle ich die sichtbaren Unternehmensvorfälle dar. Und während Bearbeitung und Terminierung als tätige Arme fungieren, betrachte ich das Unternehmenslexikon und die Primärdaten als Standbeine des Unternehmens.
Das Gesicht, die Erscheinungsform nach außen, das sind die Leistungen des Systems. Sie können am Bildschirm oder in irgendeiner anderen Form auftreten. Wir wollen sie im folgenden als Online-Vorgang, als Realtime-Rundum-Bearbeitung eines Geschäftvorfalls betrachten.
Die Grundlage eines Unternehmenssystems ist die Datenbasis. Sie besteht aus den Primärdaten und dem aktiven Unternehmenslexikon. Primärdaten sind etwa Kundennamen, die weder aus anderen Daten erzeugt noch einseitig durch das Unternehmen selbst geändert werden können. Sie werden in Form von Datenbanken gespeichert. Die Primärdaten bilden eine Einheit.
Das aktive Unternehmenslexikon enthält alle Festlegungen, die sich das Unternehmen selbst gegeben hat. Dazu gehören natürlich sämtliche Spezifikationen von DV-Systemen bis hin zur Picture-Schablone eines Datenelements. Das Lexikon ist selbst wieder eine Datenbank.
Herzstück im funktionalen Sinn ist die zentrale Anwendungssteuerung. Sie enthält keine Fachlogik und ist daher für alle Anwendungen gleich. Die Steuerung versorgt die Vorgänge mit Primärdaten und wickelt sie gemäß den Festlegungen im aktiven Lexikon ab. Bei der Abwicklung von Vorgängen werden aus Primärdaten weitere Daten erzeugt, zum Beispiel das Alter aus Geburtsdatum und Tagesdatum. Außerdem werden Primärdaten im Rahmen eines Vorgangs eingegeben, verändert oder gelöscht. Es entstehen also temporäre Datenbestände die erst am Ende eines Vorgangs mit den Primärdaten synchronisiert werden und bis dahin unabhängig bleiben.
Terminierte Daten sind Daten in Bearbeitung, die für einen gewissen Zeitraum neben den Primärdaten konserviert und erst nach Abschluß der Terminierung mit diesen synchronisiert werden. Diese Situation tritt auf, wenn ein Kunde einen Antrag unvollständig ausgefüllt hat, und die fragmentarischen Daten schon einmal eingegeben wurden, der Antrag als Ganzes aber noch nicht abschließend bearbeitet werden konnte. Die Regeln für die Terminierung findet die Steuerung im aktiven Lexikon. Sie kann damit auf einem vergangenen Dialogschritt mit den damaligen Daten wiederaufsetzen.
Nun zu den komischen Ärmeln und Hosenbeinen, die in der Abbildung bei der Steuerung zu sehen sind. Es handelt sich dabei um Schnittstellen, durch die die Steuerung unabhängig von den Eigenarten der umgebenden Komponenten wirkt.
Die Schnittstelle zu den Primärdaten, also die Datenbankschnittstelle, gewährt in diesem Modell der Steuerung eine objektorientierte, relationale Datensicht. Sie setzt diese Sicht in die Technik des jeweiligen Datenbank-Management-Systems um. So können zum Beispiel IMS oder UDS anwendungsseitig wie ein relationales DBMS betrieben werden.
Die Schnittstelle zu den Vorgängen, hier also die Dialogschnittstelle, aktiviert die fälligen Masken in der Technik des jeweiligen Betriebs- oder DC-Systems, so wie sie im aktiven Lexikon vereinbart sind.
Damit behält die zentrale Steuerung auch hier ihre logische Datensicht. Wenn wir das Modell der automationsorientierten Anwendungs-Architektur betrachten, wird offensichtlich, welche Teile des Ganzen noch in herkömmlicher Weise programmiert werden müssen: die Steuerung und ihre Schnittstellen. Dabei handelt es sich allerdings durchweg um Standardfunktionen, die beliebige Sachlogik verarbeiten können, also jeweils nur einmal entwickelt werden müssen. Eine anwendungsunabhängige Steuerung steuert alle Applikationen.
Ganz wesentliche Bedeutung kommt nun den Inhalten des aktiven Unternehmenslexikons zu, die unter anderem die gesamte Anwendungslogik repräsentieren. Wie kann also der fachliche Umfang eines Unternehmens oder DV-Systems so strukturiert werden, daß er sich maschinell verwertbar auf einer dafür maßgeschneiderten Datenbank darstellen läßt.
Die Methode dafür ist im Prinzip bekannt und wurde in einigen Häusern auch schon mehr oder weniger weitgehend angewandt. Grundlegend ist die Unterscheidung der statischen und dynamischen Seiten eines Systems sowie die Untersuchung ihrer Beziehungen. Die statische Seite ist im wesentlichen durch die Primärdaten geprägt, die dynamische durch die Funktionalität.
"System" kann hier auch konkret als ein spezieller Vorgang verstanden werden, der eine gewisse Funktionalität und bestimmte Daten umfaßt. Als Ganzes kann er durch die wesentlichen Objekte und ihre Beziehungen überblickmäßig beschrieben werden.
Das entscheidende Prinzip heißt Atomisierung und Kombination. Atomisierung meint hier Zerlegung in die logisch kleinsten Einheiten, aus denen durch Kombination beliebig komplexe Zusammenhänge erzeugt werden können. Jedes Informationsatom ist unternehmensweit unique, das bedeutet, es gibt kein zweites mit gleicher Bedeutung. Atomisierung ist dabei die geistige Knochenarbeit, der gegenüber die Kombination als baukastenartiges Spiel erscheint.
Atomisierung der Daten verlangt das Ermitteln der Datenelemente. Sie sind die kleinsten sachlogischen Informationseinheiten, semantische Singularitäten, wie der Vorname einer natürlichen Person". Jedes Datenelement hat daher einen sprechenden Namen. Wichtig ist die exakte Festlegung der Bedeutung, etwa durch "und zwar der 1. Vorname (Rufname)". Daher wird der Name häufig durch einen Definitionstext präzisiert. Präzision heißt aber auch, so konkret zu definieren wie möglich.
Jedes Datenelement sollte es unternehmensweit genau einmal geben. Dies kann nur durch eine zentrale Stelle Datenadministration sichergestellt werden. Namen, Definitionen und Beziehungen von Datenelementen werden im aktiven Lexikon gespeichert, nachdem sie von der Datenadministration abgesegnet wurden. Kombination der Daten heißt Zusammenstellen von Datenelementen zu sachlogischen Komplexen, die sich an den Objekten und ihren Beziehungen orientieren. Diese Komplexe bilden insbesondere Relationen in einer geeigneten Normalform, höchstwahrscheinlich der dritten. Die Relationen sind miteinander über Schlüssel-/Fremdschlüsselbeziehungen verbunden.
Neu kombinierte Ausschnitte aus den Relationen bilden die Datensichten von Bildschirmmasken sowie Vorgängen überhaupt. Daraus folgt, daß Amtliche Datenbanken und Dialoge nur vorher exakt definierte Datenelemente enthalten dürfen.
Die Gesamtheit der Datenelemente und ihrer Kombinationen bezeichnen wir als Datenmodell des Unternehmens. Es soll als Ganzes redundanzfrei und eindeutig sein, so daß jede Information allein aufgrund der Bedeutung und des Wertinhalts von Datenelementen ermittelt werden kann. Tautologisch, aber doch: Das Unternehmensdatenmodell gilt unternehmensweit. Auch wenn es sukzessive, bottom-up, Anwendung für Anwendung über Jahre hinweg entwickelt wird, gibt es stets definierte Unternehmensbereiche, deren Anwendungen bereits darauf laufen und nur darauf. Dies wird in unserem Modell durch die vollständige Darstellung im aktiven Lexikon und seine Kontrolle durch die Datenadministration erreicht.
Atomisierung der Funktionalität heißt Ermitteln der Elementarfunktionen. Das sind die aus Anwendersicht kleinsten funktionalen Einheiten. Eine Elementarfunktion zur Ermittlung des Alters hätte beispielsweise die Form "Alter = Tagesdatum - Geburtsdatum". Einfache Zuweisungen lassen sich auch als Elementarfunktionen darstellen, wie "Mehrwertsteuersatz = 14 Prozent". Eine Funktion zur Ermittlung der Steuerrückzahlung würde sich dagegen erst aus der Kombination zahlreicher Elementarfunktionen ergeben.
Jede davon erzeugt genau ein Datenelement aus einem oder zwei Eingabedatenelementen beziehungsweise Festwerten. Die so erzeugten Daten bezeichnen wir ins genetische im Unterschied zu den primären Daten. Jede Elementarfunktion ist frei von Entscheidungslogik, und nur einmal im Unternehmen vorhanden.
Kombination von Funktionen bedeutet Verbinden von Elementarfunktionen zu funktionalen Komplexen, wie etwa zur Ermittlung des Betrags der Steuerrückzahlung. Solche Funktionen können über Datenelemente oder Bedingungen verbunden werden.
Die Atomisierung der Funktionalität beinhaltet auch die Ermittlung von Elementarbedingungen, zum Beispiel "Alter > 30". Elementarbedingungen können ebenfalls zu komplexen Bedingungen gruppiert werden. Die Verknüpfung von Bedingungen und Funktionen bezeichnen wir als Regeln, zum Beispiel "Alter > 30" - "Vertrauenswürdigkeit = 0". Regeln können aus beliebig komplexen Bedingungen und Funktionen bestehen. Man kann Regeln daher nicht atomisieren.
Die Basis des magischen Dreiecks, nämlich seine Daten und Funktionen, haben wir nun in ihre kleinsten Bestandteile zerlegt und aus diesen neu zusammengesetzt. Nun liegt es am System, also am Vorgang, zu sagen, was mit den Elementen und Komplexen geschehen soll. Die Beschreibung eines Vorgangs im Unternehmenslexikon ist im wesentlichen eine Aufzählung von Aktivitäten, die jede für sich bereits im Lexikon als eigenes (Meta-)Objekt beschrieben wurde. Dabei kann es sich zum Beispiel um das Ausgeben einer Maske, das Lesen einer Datenbank, das Durchführen einer Funktion oder das Umsetzen einer Regel handeln.
Zur Laufzeit wird diese Vorgangsbeschreibung von der zentralen Steuerung abgearbeitet. Damit wirkt der Inhalt des aktiven Unternehmenslexikons direkt steuernd, damit wirken sich Änderungen an seinem Inhalt direkt aus.
Wie wirkt sich die automationsorientierte Anwendungsarchitektur auf die tägliche Entwicklungsarbeit aus? Die Anwendungsentwicklung wird im Dialogverfahren betrieben, wobei die zugehörige Datenbank als Lexikon dient. Mit diesem Dialog kann der Programmierer Masken beschreiben, Objekte und Relationen festlegen (einige Mitarbeiter dürfen daraus auch echte Datenbanken generieren), Funktionen festlegen und daraus schließlich - immer noch im Dialog - Vorgänge definieren.
Bis hierher werden drei Arten von Fachleuten benötigt:
- der Anwender in der Fachabteilung,
- der Anwendungsentwickler im Sinne der automationsorientierten Anwendungsarchitektur (kann mit dem ersten identisch sein) sowie
- der Fachmann für Datenbanken.
Nun kann der Prototyp, der partiell definierte Vorgang, probeweise laufen. Die zentrale Steuerung teilt dem Entwickler mit, wenn sie auf Merkwürdigkeiten stößt. Wenn etwa die Tabelle Länderkennzeichen keine Einträge enthält, dann muß der Prototyp zurück in den Entwiklungsmodus, um Albanien und Andorra einzugeben: neuer Versuch, interaktives Testen. Erscheinungsbild und sachliche Richtigkeit werden vom Anwender überprüft, die logische Vollständigkeit testet das System selbst.
Die technische Fehlerfreiheit einer Anwendung sollte bei einer produktionsreifen Steuerung gewährleistet sein. Daher ist das Testen fast ausschließlich eine Sache, die Anwender und System unter sich ausmachen.
Und wo bleibt die Grobanalyse? Wo bleibt die Projektdokumentation, die revisionssichere Programmdokumentation, wo das Benutzerhandbuch - diese von wenigen geliebten, von vielen verfluchten Traumata traditioneller Anwendungsentwicklung? Sie alle werden implizit oder explizit entbehrlich.
Die Analyse macht der Anwender so grob er mag, Objekte und Beziehungen erkennt er dann schon. Die Feinheit allerdings treibt er bis zum logischen Atom. Hier sinkt er knietief ins Eingemachte. Doch dann, so nach und nach zusammensetzend, gewinnt er Grund und wird allmählich immer schneller; kann er doch selbst auf recht abstrakter Ebene Änderungen vornehmen.
Der Stand eines Projekts ist stets im Lexikon vorführungsreif enthalten und kann bei Bedarf mal ausgedruckt werden. Damit entfällt die Programmdokumentation, so wie die Programmierung selber.
Das Benutzerhandbuch ist implizit, denn alle Elemente des Systems sind abfragbar beschrieben. Die Definition eines Datenelements, die dem Entwickler hilft, sagt auch dem Sachbearbeiter, was gemeint ist, wenn sein Cursor stockt, und er die Hilfe-Taste drückt (besser sollte man es umdrehen: Die Definition, die dem Azubi weiterhilft, fördert auch die Kommunikation der Entwickler).
Ein Benutzerhandbuch im engeren Sinn erübrigt sich, da alle Informationen über das System, also auch über Vorgänge, Masken und Tabellen im aktiven Lexikon gespeichert werden und somit stets online verfügbar sind. Jede Anwendung gibt über sich selbst Auskunft.
Und was ist mit den Handbüchern im weiteren Sinn, also zum Beispiel Anweisungen für die Bearbeitung schwieriger Fälle, die bisher durch umfangreiche Austauschdienste mühevoll auf dem laufenden gehalten werden? Dabei handelt es sich zweifelsfrei um Regelungen, die Einfluß auf Arbeitsabläufe nehmen. Folglich ist der Ort dieser Informationen nicht unter den Primärdaten, sondern im Lexikon.
Diese Regelungen in Textform steuern allerdings kein DV-System, sondern das Verhalten von Sachbearbeitern. Sie werden daher so gespeichert, daß sie für den Endbenutzer optimal erreichbar sind. Dieser kann sein Problem grob schlagwortartig beschreiben, das System liefert dazu einen knappen, bildschirmgerechten Text, dessen Bedeutung der Schnittmenge aus den Schlagworten entspricht.
Fachwissen ist an Begriffen festgemacht; deshalb gibt es in Fachbüchern Schlagwortregister. Begriffe stehen zu anderen Begriffen in Beziehung. Diese Beziehungen haben Namen, die mit der Leserichtung wechseln, wie bei "enthält" und "ist enthalten in". Beziehungen sind sachlogisch zu verstehen und damit unabhängig von der sprachlichen Formulierung.
In dem Beispiel "Forelle ist ein Fisch" bleibt die Bedeutung der beiden Objekte und ihrer Beziehung gleich, auch wenn ich den Namen Forelle durch den Namen "trout", "Fisch" durch "fish" und "ist ein" durch "is a" ersetze.
Das Auffinden von Objekten über Begriffe hat also nichts mit Buchstabenfolgen zu tun, sondern geschieht allein über Beziehungen. Wer mit dem Schlagwort "Fisch" nach Rezepten sucht, findet implizit auch die "Forelle Müllerin".
Man fühlt sich an die Wissensbasis eines Expertensystems erinnert. Offenbar haben wir es mit der integrierten Wissensbasis des Unternehmens zu tun, die von verschiedenen Systemen, auch Expertensystemen, genutzt werden kann.
Besonders interessant ist diese Technik für die Anwendungsentwicklung. Dort ermöglicht sie erst die Eindeutigkeit von Datenelementen und Funktionen. Nur wenn ich fragen kann: "Welche Elementarfunktion errechnet das Alter", vermeide ich Redundanzen und erreiche die Wiederverwendung bereits definierter Komponenten. Die Technik, bestimmte Objekte über assoziative Schlagworte zu finden, wendet der Anwendungsentwickler ebenso an, wie der Rat suchende Sachbearbeiter in einem schwierigen Fall.
Ist diese Form der Anwendungsentwicklung Utopie? - Nein, denn das Neue entwickelt sich aus dem Alten, das zukünftige System basiert auf den heutigen. So sind die einzelnen Teile, die hier beschrieben wurden, für sich betrachtet bereits Wirklichkeit.
Es gibt bereits unternehmensweit vernetzte Primärdatenbanken, die den Anwendungen durch eine Datenbankschnittstelle relational präsentiert werden. Auch Dialogschnittstellen, die Anwendungen streckenweise unabhängig von den Eigenheiten eines Betriebs- beziehungsweise DC-Systems sein lassen, sind schon im Einsatz. In Verbindung mit einem Maskengenerator obliegen schon einige Teile der Entwicklungsarbeit - auch technisch - direkt den Fachbereichen.
Es gibt partielle Vorstöße in Richtung auf eine fachunabhängige Anwendungssteuerung, etwa in Form von Online-Tabellensystemen. So können die Schwankungen des Dollarkurses laufzeitwirksam nachgefahren oder Versicherungstarife geändert werden, ohne den Programmcode anrühren zu müssen.
Es gibt die unternehmensweite Anwendung der Daten- und Funktionsanalyse bis auf Elementebene. Deren Ergebnisse werden in einem Data-Dictionary dargestellt, aus dem und nur aus dem - dann Datenbankbeschreibungen und DC-Elemente generiert werden. Und unser Unternehmen schließlich bietet ein Unternehmenslexikon an, das für einige Zwecke zur Laufzeit ausgewertet wird. Dies hat sukzessive den Verzicht auf Handbücher in Papierform nach sich gezogen.
Was es meines Wissens bisher nicht gibt, ist die Verschmelzung solcher Ansätze zu einer homogenen, automationsorientierten Anwendungsarchitektur.
Um einige Einwände vorwegzunehmen: Die Umstellung von alt auf neu muß natürlich schrittweise erfolgen. Dann kann die Anwendungsarchitektur der Zukunft auch mit herkömmlichen DV-Landschaften koexistieren. Sie kann in einem beliebigen fachlichen Teilbereich beginnen und dort stufenweise entwickelt werden. Ihren Ausgang nehmen muß sie aber von der Datenbasis aus.
Das Unternehmenslexikon kann zur Laufzeit interpretiert werden. Darin liegt seine Stärke. Aus seinem Inhalt kann aber auch lauffähiger Code generiert werden. Das ist umständlicher aber schneller. Der Code wird allerdings nur auf diesem Weg erzeugt, ohne manuelle Verbesserungen. Deshalb nenne ich das Lexikon aktiv.
Standardfunktionen, wie die zentrale Steuerung oder die Schnittstellen, werden konventionell programmiert.
Die Einbettung der Architektur in die jeweilige Systemumgebung, die Optimierung und Überwachung erfolgen mit den Mitteln der Systemtechnik und unterliegen damit nicht der künftigen Anwendungsarchitektur.
Die Unterscheidung von Primärdaten und Lexikon gilt nur in erster Näherung. Sie kann später aufgehoben werden. Bis dahin sollte entschieden werden, ob zum Beispiel die Organisations- und Stellendatenbank oder eine DV-Gerätedatenbank dem einen oder anderen Teil der Untemehmensdatenbasis zugerechnet wird.
Natürlich werden durch das von mir vorgestellte Konzept Programmierer nicht arbeitslos. Neben dem Systemprogrammierer wird es den Fachmann für Analysetechnik geben. Reine Codierer werden sich, jedoch auf die Pflege von Altsystemen einschränken müssen. Um anzufangen fehlen uns weder das Wissen noch die Technik.
* Rainer Hegenbart ist bei der Mummert und Partner GmbH in München zuständig für den Bereich Informationsmanagement