Im ersten Teil seiner Ausfuehrungen hatte Peter Gerard* aufgezeigt, warum die unternehmensweite Datenmodellierung und der herkoemmliche CASE-Ansatz nicht die erwarteten Erfolge gebracht haben. Hier erklaert der Autor nun am Beispiel des Bankgeschaefts, wie ein unternehmensweites Informationssystem ausgehend von Geschaeftsereignissen und nicht von Daten aufgebaut werden kann.

Zentrale Aufgabe eines unternehmensweiten Informationssystems ist die Unterstuetzung des Geschaefts und der mit ihm verbundenen Geschaeftsereignisse. Die Abbildung von Daten ist dabei nur Mittel zum Zweck. Die Geschaeftsereignisse sind deswegen der adaequate Ausgangspunkt zur Entwicklung eines Informationssystems und nicht etwa die Daten.

In einer Bank wird ein Geschaeftsereignis dadurch ausgeloest, dass ein Kunde oder Geschaeftspartner einen Auftrag erteilt. Ein solches Ereignis initiiert einen Prozess, in dessen Ablauf der Geschaeftsauftrag ausgefuehrt wird. Ausfuehren heisst dabei, dass der Prozess ueber eine Anzahl von Teilprozessen, zum Beispiel Pruefungs-, Dispositions- und Komplettierungsschritte, bis zum Abschluss gebracht wird. Typisch fuer das Bankgeschaeft ist dabei, dass der Geschaeftsauftrag aus beabsichtigten Wertebewegungen besteht.

Vom Geschaeftsereignis zur Transaktion

Das entscheidende Merkmal dieser Wertebewegungen ist, dass sie in bezug auf den Geschaeftsprozess die Eigenschaft haben, sich waehrend des Prozesses von ihrem Inhalt her nicht zu veraendern. Zum Beispiel sind Betrag, Waehrung und Ziel einer Ueberweisung offensichtlich unabhaengig vom Fortschritt ihrer Bearbeitung.

Wir bezeichnen im folgenden die ueber den Lebenszyklus eines Geschaeftsprozesses betrachtete Wertebewegung als "Transaktion". Fuer die Transaktion gilt zweierlei:

1. Mit Transaktionen koennen alle Vorgaenge des operativen Bankgeschaefts abgebildet werden.

2. Die beschreibenden Attribute einer Transaktion, also die Abbildung des zugrundeliegenden Geschaeftsauftrags, bleiben bis zum Abschluss der Transaktion unveraendert.

Die bisher recht allgemeine Ueberlegung zur Beziehung von Geschaeftsereignis und Transaktion muss nun in bezug auf die Struktur der Transaktion verfeinert werden. Im Prozess der Abarbeitung eines Geschaeftsauftrags wird eine Anzahl von Wertebewegungen ausgefuehrt. Dies koennen je nach Auftrag zum Beispiel Geld-, Wertpapier- oder Bewegungen von Edelmetallen sein. Strukturell sind diese verschiedenen Typen von Wertebewegungen nicht verschieden, da sie unabhaengig von der Art des bewegten Wertes mit gleichartigen Informationen beschrieben werden koennen.

Ein Geschaeftsauftrag ist durch seine spezifische Kombination von Wertebewegungen charakterisiert. Beispielsweise setzt sich eine Ueberweisung aus einer Menge von Geldbewegungen zusammen, die die Belastung des Auftraggebers und die Gutschriften fuer die Empfaenger darstellen. Bei einem Wertpapierkauf sind sowohl Geldbewegungen zum Begleichen des Rechnungsbetrags notwendig als auch die entsprechenden Wertpapierbewegungen zwischen Bank und Geschaeftspartnern.

So ist jeder Geschaeftsauftrag grundsaetzlich in eine Vielzahl verschiedener Wertebewegungen aufloesbar.

Schon zum Zeitpunkt der Initiierung eines Auftrags ist dabei bekannt, welche Bewegungen mit dem jeweiligen Auftrag verbunden sind. Nur wenn Marktinformationen zur Bewertung einer Wertebewegung einbezogen werden, zum Beispiel im Fall einer Wertpapier-Order, muessen einzelne Attribute der Wertebewegung zu einem spaeteren Zeitpunkt beschrieben werden.

Zur Abbildung der Dynamik eines Geschaeftsprozesses wird der Wertebewegung zusaetzlich ein Status zugeordnet, der den aktuellen Stand der Auftragsbearbeitung darstellt. Die um den Status erweiterte Wertebewegung ergibt eine Transaktion mit einer Struktur, wie sie in Abbildung 1 zu sehen ist.

Im "statischen Teil" der Transaktion werden alle Informationen, die bei der Initiierung vorliegen, abgelegt. Diese Informationen werden im weiteren Lebenszyklus der Transaktion nicht mehr veraendert. Im Einzelfall sind Informationen zu ergaenzen, die zum Zeitpunkt der Auftragsinitiierung nicht vorlagen. Alle Informationen im statischen Teil der Transaktion werden jedoch nur einmal festgelegt und liegen dann fuer den gesamten weiteren Lebenszyklus der Transaktion fest.

Zu den Angaben im statischen Teil der Transaktion gehoeren:

1. Informationen zur Klassifizierung und Typisierung der Transaktion: Hier sind neben einer eindeutigen Transaktionsnummer alle Verweise auf transaktionsexterne Beschreibungskategorien abzulegen. Dies reicht vom Verweis auf den betroffenen Geschaeftspartner ueber den Typ der Transaktion bis hin zur Art der Geschaeftsvereinbarung, in deren Zusammenhang die Transaktion aufgelegt wurde.

2. Geschaeftsdaten: Hier werden alle geschaeftlichen Informationen abgelegt, also in erster Linie der nominale Betrag, die Einheit und die Richtung der betroffenen Wertebewegung (siehe Kasten).

Der Status schliesslich ist der Teil der Transaktion, mit dem die Dynamik eines Geschaeftsprozesses beschrieben wird. Der Geschaeftsauftrag, der einen Geschaeftsprozess initiiert hat, durchwandert im Zuge seiner Bearbeitung eine Reihe von Zustaenden, die von der Annahme beispielsweise ueber eine Pruefung bis hin zur Buchung und zum Abschluss des Auftrags fuehren. Jeder einzelne Zustand kann erst erreicht werden, wenn - abhaengig von der Gestaltung des Geschaeftsprozesses - ein oder mehrere vorgelagerte Zustaende erreicht worden sind.

Mit dem Status einer Transaktion wird diese dynamische Veraenderung des Zustands der Auftragsbearbeitung abgebildet. Die Kontrolle der Statusuebergaenge obliegt den jeweiligen Anwendungen. Dies hat zur Konsequenz, dass die Logik eines Geschaeftsprozesses unabhaengig von der Struktur der jeweiligen Transaktionen ist. Damit koennen also zukuenftige Veraenderungen eines Geschaeftsprozesses isoliert in der jeweiligen Anwendung realisiert werden, ohne dass die Basis des Informationssystems, die Transaktionen oder andere Anwendungen betroffen sind. Den Zusammenhang zwischen Geschaeftsprozess, Geschaeftsauftrag und Transaktionen verdeutlicht die Grafik in Abbildung 2.

Prozessnormalisierung und -standardisierung

Transaktionen werden in einem ersten Schritt alleine aus den Erfordernissen des in Frage stehenden Geschaeftsereignisses entwickelt. Dazu ist der zur Abarbeitung des Geschaeftsereignisses notwendige Prozess in seine grundlegenden Bestandteile, die Transaktionen, zu zerlegen. Vorher aber muessen die einzelnen mit dem Geschaeftsereignis verbundenen Wertebewegungen identifiziert werden. Fuer jede Wertebewegung ist dann jeder moegliche Status zu ermitteln.

Auf diese Weise wird eine Prozessnormalisierung vollzogen, da der komplexe und in der Regel mit Redundanzen versehene Prozess in seine Einzelbestandteile, die Transaktionen, zerlegt wird. Diese sind aus Prozesssicht redundanzfrei. Die Normalisierung wird spaeter bei der Implementierung der Transaktionen bedeutend, da normalisierte Transaktionen die Basis fuer die Normalisierung der Daten liefern.

Transaktionen, die im Zusammenhang anderer Geschaeftsereignisse eingesetzt werden, finden zunaechst jedoch keine Beachtung. Dadurch wird gewaehrleistet, dass die Struktur existierender Systeme nicht die Entwicklung neuer Systeme behindert.

Erst nachdem die Prozesse in Transaktionen zerlegt worden sind, setzt ein Prozess des Abgleichs mit schon existierenden Transaktionen ein. Es werden gemeinsame Attribute verschiedener Transaktionen identifiziert und bei Bedarf abgeglichen. So taucht beispielsweise der Verweis auf einen Bankkunden oder eine Geschaeftsvereinbarung in einer Vielzahl von Transaktionen auf. Im Zuge der Standardisierung werden diese Gemeinsamkeiten identifiziert und analysiert, so dass schliesslich unternehmensweit konsistente Transaktionsattribute zum Verweisen auf Kunden oder Geschaeftsvereinbarungen verwendet werden.

Die Standardisierung ist damit die konsequente Weiterfuehrung der Prozessnormalisierung. Waehrend die Normalisierung die konsistente Darstellung eines Prozesses ermoeglicht, wird im Zuge der Standardisierung die konsistente Darstellung der Transaktionen fuer das gesamte Informationssystem erreicht.

Gleichzeitig stellt die Standardisierung von Transaktionen eine praktisch realisierte Software-Wiederverwendung dar. Schon vorhandene Transaktionen koennen fuer neue Systeme wiederverwendet werden und die Suche nach existierenden Transaktionen, die fuer neue Systeme eingesetzt werden koennen, ist im methodischen Vorgehen institutionalisiert.

Die standardisierten Transaktionen repraesentieren gleichzeitig die Prozesse und die zu ihrer Abwicklung benoetigten Daten fuer das gesamte unternehmensweite Informationssystem. Da in einer Transaktion alle Informationen, die zu ihrer Ausfuehrung notwendig sind, abgebildet sind, umfasst die Gesamtheit aller Transaktionen auch die Gesamtheit der Informationen, die zur Abwicklung des gesamten Geschaefts des Unternehmens noetig sind. Mathematisch ausgedrueckt, bildet die Vereinigungsmenge aller Transaktionen genau den Informationsbedarf des Unternehmens ab.

Die konsistente und redundanzfreie Strukturierung des gesamten Informationsbestandes liefert dann ein bottom-up erstelltes Datenmodell, das den tatsaechlichen Informationsbedarf des Unternehmens umfasst. Somit ist dieses Datenmodell das Ergebnis und nicht der Ausgangspunkt der Systementwicklung (siehe als Beispiel Abbildung 3, das Top-Datenmodell der Deutschen Bank).

Man koennte nun versucht sein, kritisch anzumerken, dass zur Entwicklung eines solchen Datenmodells keine aufwendige Prozessmodellierung notwendig sei. Wer so argumentiert, uebersieht jedoch voellig, dass dieses Ergebnis der Systementwicklung schon eine Abstraktion der zur Geschaeftsabwicklung benoetigten Daten auf der Attributebene darstellt. Hinter diesem Top-Modell steht ja eine auf der Attributebene konsistente Darstellung genau der benoetigten Daten des Unternehmens.

Das Informationssystem kann organisch wachsen

Darueber hinaus ist dieses Datenmodell eigentlich nur ein Nebenprodukt der Systementwicklung. Auf Basis der standardisierten Transaktionen wurden in der Praxis bereits Teilsysteme implementiert, die spaeter sowohl mit anderen Teilsystemen als auch mit dem Datenmodell konsistent waren.

Eine wesentliche Konsequenz dieses Vorgehens ist, dass das Informationssystem als Ganzes organisch wachsen kann und dennoch integriert ist. Dies laesst sich verdeutlichen, wenn die Vorgehensweise beim Hinzufuegen eines neuen Teilsystems betrachtet wird.

Wieder ist der Ausgangspunkt das neu zu betrachtende Geschaeftsereignis. Dessen lokale Analyse - zuerst ohne Beachtung des schon existierenden Gesamtsystems - wird zu einer Menge von Transaktionen fuehren. In der resultierenden Menge noch nicht standardisierter lokaler Transaktionen wird eine Anzahl von schon existierenden Transaktionen des bisherigen Systems vertreten sein. Zum Beispiel duerfte haeufig eine Transaktion auftreten, die eine Geldbewegung darstellt. Diese kann nun auch fuer das neue Teilsystem genutzt werden.

Der Abgleich mit den schon existierenden Transaktionen, also die Transaktionsstandardisierung, fuehrt zu einer minimierten Erweiterung der gesamten Transaktionsbasis. Mit der Standardisierung werden also lokal abgeleitete Transaktionen in die Transaktionsbasis des Gesamtsystems ueberfuehrt. Auf dieser Grundlage kann dann die Implementation des neuen Teilsystems vorgenommen werden. Durch das Hinzufuegen des neuen Systems wird dabei kein existierendes Teilsystem in seiner Integritaet beeintraechtigt, da keine existierende Transaktion veraendert wird und neu hinzugekommene die Altsysteme nicht beeintraechtigen.

Gleichzeitig waechst ein integriertes System, da das Gesamtsystem auf einer uniformen Datenbasis operiert: der Datenbasis der Transaktionen. Diese steht auch sofort fuer uebergreifende Auswertungen zur Verfuegung. Dieser Datenbasis entspricht ein ebenso organisch gewachsenes Datenmodell, das sich bottom-up auch in Zukunft ausweiten laesst.

Abbildung 4 verdeutlicht das formale Vorgehen der System- (weiter- )entwicklung im Rahmen des Transaktionskonzepts. Dabei wird ausschliesslich das formale Vorgehen bei der Erweiterung des Informationssystems dargestellt. Es laesst sich gut in die Praxis umsetzen, weil es durch ein inhaltliches und geschaeftsspezifisches Konzept hinterlegt ist, das Transaktionskonzept. Dadurch wird eine inhaltliche Leitlinie fuer die einzelnen Schritte, zum Beispiel vom Geschaeftsereignis zur lokalen Transaktion, vorgegeben.

Pointiert lassen sich die folgenden Unterschiede zwischen dem Transaktionskonzept und der Unternehmensdaten-Modellierung identifizieren:

- gezielter Wechsel von Top-down- und Bottom-up-Schritten im Rahmen des Transaktionskonzepts statt einseitiger und der Komplexitaet unangemessener Top-down-Orientierung in der Unternehmensdaten-Modellierung.

- Identifikation des fuer eine Bank geschaeftstypischen Konstrukts der Transaktion, statt Anwendung eines allgemeinen Ansatzes.

- Basis des Informationssystems im Transaktionskonzept bildet ein einfaches und damit robustes Konzept anstelle eines komplexen und damit instabilen Modells im Rahmen der Unternehmensdaten- Modellierung.

- Ueberwindung der dogmatischen Orientierung an der Datennormalisierung durch das Transaktionskonzept ermoeglicht ein organisches Wachstum des Informationssystems.

Letztlich ergibt sich aus dem Transaktionskonzept ein Datenmodell des unternehmensweiten Informationssystems. Allerdings hat dieses den entscheidenden Vorteil, dass es mit zukuenftigen Anforderungen wachsen kann, ohne die Systementwicklung einzuengen. Der Grund fuer diesen entscheidenden Unterschied liegt in der Methodik, die im Rahmen des Transaktionskonzepts angewandt wird. Anstatt, wie es bei der Unternehmensdaten-Modellierung propagiert wird, von den Daten auszugehen, wird von den Geschaeftsereignissen ausgegangen, und erst am Ende der konzeptionellen Entwicklung ergibt sich ein beschreibendes Datenmodell.

Wie stellt sich das Transaktionskonzept hinsichtlich der im ersten Teil des Beitrags gestellten Anforderungen an ein unternehmensweites Informationssystem dar?

- Langfristige Stabilitaet: Indem als Basis fuer das Informationssystem Transaktionen definiert wurden, die eine um einen dynamischen Status erweiterte, sehr allgemeine Wertebewegung darstellen, wurde ein Konzept gefunden, das unabhaengig von Produkt- und Organisationsstrukturen der Bank ist.

Die grosse Aehnlichkeit der Transaktion zum Buchungssatz der klassischen kaufmaennischen Buchfuehrung, der seit den ersten Anfaengen der Buchfuehrung im 15. Jahrhundert strukturell unveraendert blieb, ist ein weiteres Indiz fuer die langfristige Stabilitaet des Konzepts.

- Unterstuetzung neuer Geschaeftsanforderungen: Zur Umsetzung einer neuen Geschaeftsanforderung in ein entsprechendes System muessen im wesentlichen die zur Prozessabwicklung benoetigten Transaktionen abgeleitet werden. Sofern keine neuen Klassen von Transaktionen notwendig sind - was zwar nicht auszuschliessen, aber nicht sehr wahrscheinlich ist - koennen im Zuge der neuen Geschaeftsanforderungen bestehende Berichtssysteme unveraendert bleiben.

Die Chance: Standardisierte Prozesse

Dies wirkt sich zum Beispiel im Bereich des Risiko-Managements positiv aus. Bei der Einfuehrung neuer Produkte, beispielsweise im Bereich der derivativen Finanzinstrumente, muessen keine neuen Berichtssysteme entwickelt werden, da sich das Risiko eines derivativen Produkts aus den Risiken der Produktkomponenten aggregiert.

- Foerderung der Integration: Das oben vorgestellte Transaktionskonzept ist ein von vornherein auf die Integration bestehender Systeme hin ausgerichtetes Konzept. Dadurch, dass die System- entwicklung zuerst lokal fuer eine neue Geschaeftsanforderung und die damit verbundenen Prozesse beginnt und danach erst bottom-up ein Abgleich mit dem schon existierenden Gesamtsystem stattfindet, wurde zweierlei ermoeglicht: Neue Teilsysteme koennen in ueberschaubaren Projekten entwickelt werden, ohne dass dies zur Neustrukturierung der bestehenden Infrastruktur fuehren muss. Ausserdem waechst das Gesamtsystem immer nur um die tatsaechlich neue Funktionalitaet und die neuen Informationsbestaende, die durch eine veraenderte Geschaeftsanforderung erforderlich werden.

Mit dem Transaktionskonzept wird die Integration also nicht nur gefoerdert, sie wird zum Normalfall der Systementwicklung. Dass damit der Realitaet der Systementwicklung entsprochen wird, in der es keine "gruene Wiesen" mehr gibt, muss kaum noch erwaehnt werden.

- Standardisierung in der Entwicklung: Das Transaktionskonzept stellt einen wesentlichen Schritt auf dem Weg zur Standardisierung von Geschaeftsprozessen dar. Diese hat zwei wesentliche Effekte: Sie fuegt die heute noch ungezuegelte Kreativitaet der Systementwickler in einen stabilen konzeptuellen Rahmen ein, der ihnen Halt gibt und dadurch ihre Produktivitaet foerdert. Aufgrund der Stabilitaet des Konzepts werden darueber hinaus Lernkurveneffekte erzielt, die die Produktivitaet der Entwickler weiter erhoehen.

Als zweiter Effekt ermoeglicht die Standardisierung der Prozesse, dass neue Systeme aus einem Fundus existierender Prozesskomponenten relativ einfach massgeschneidert werden koennen. Aehnlich wie fernoestliche Autoproduzenten mit der Einbindung existierender Komponenten in die Modellentwicklung zu kuerzeren Entwicklungszeiten kamen und sich damit entscheidende Wettbewerbsvorteile erarbeiteten, fuehrt die Verwendung standardisierter Transaktionen zu einer schnelleren Systementwicklungszeit.

Bis heute blieb das Jahrhundertdilemma des Software-Engineerings ungeloest: Waehrend die Hardwaretechnologie ein erstaunlich hohes technologisches Niveau erreicht hat, hinkt die Softwaretechnologie vergleichsweise um Jahrzehnte hinterher. Dem Software-Engineering fehlt ein tragfaehiges Konzept zur Entwicklung von flaechendeckenden Systemen. Die Hardware-Industrie hat ihre Hausaufgaben erledigt, die Software-Industrie - noch - nicht.

Nicht Daten, sondern Prozesse standardisieren

Ein wesentlicher Grund fuer den traurigen Entwicklungsstand liegt in der irrigen Fokussierung auf die Daten. Nicht die Daten, sondern die Prozesse muessen standardisiert werden, so wie es im Rahmen des Transaktionskonzepts geschieht. Wie gezeigt wurde, fuehrt die Konzentration auf die Abbildung der Prozesse schliesslich sogar zu einem besseren, da fundiertem Daten-Management und Datenmodell.

Nun gilt es auch fuer Forschung und Industrie, die Wende hin zu den Prozessen mitzuvollziehen. Dazu muss folgendes geleistet werden:

- Die Forschung muss die Vorgehensweise bei der Standardisierung von Prozessen methodisch durchdringen und weiter aufbereiten.

- Zusammen mit der Software-Industrie muessen die Ergebnisse der Forschung in Entwicklungswerkzeuge umgesetzt werden.

- Die Software-Industrie muss schliesslich zusammen mit den Anwendern die Disziplin aufbringen, das beschriebene Konzept durchzuhalten und standardisierte Prozesse zu entwickeln.

Mit einer derart konzertierten Anstrengung koennen wir einen entscheidenden Beitrag zur Ueberwindung der Softwarekrise leisten: Wir koennen so verhindern, dass in Zukunft weitere Milliarden von Programmcode-Zeilen produziert werden, die weder zu pflegen noch vernuenftig wiederzuverwenden sind.

Heute verursachen die von der Software-Industrie gelieferten Produkte bei den Anwendern Kosten, die die Hardwarekosten um ein Vielfaches uebersteigen. Die gesamte Software-Industrie steht deswegen in der Pflicht, an der beschriebenen Entwicklung umfassender und integrationsfaehiger Systeme mitzuarbeiten. Nur so ist der heute real existierende volkswirtschaftliche Schaden, der durch die Software-bedingte Fehlallokation unternehmerischer Ressourcen entsteht, zu vermeiden.

Wir koennten dann auch endlich die benoetigten Ressourcen freisetzen, um tatsaechliche Fortschritte in der Software- Entwicklung erzielen - und nicht nur von ihnen zu reden. Prozessorientierung und Transaktionskonzept zeigen einen Weg, wie wir von der Anwendungsprogrammierung zu einer Anwendungskomposition standardisierter Prozesskomponenten kommen koennen.

Bisher bestand in der Software-Industrie noch die zu grosse Neigung, weit in der Zukunft liegende Probleme anzugehen statt Loesungen fuer die Gegenwart zu liefern. Mit dem gezeigten Transaktionskonzept besteht dagegen die Chance, die nur plakative Ankuendigung einer "schoenen, neuen Technologiewelt" zu ueberwinden und heute Probleme standardisiert zu loesen.

*Peter Gerard ist als Generalbevollmaechtigter der Deutschen Bank AG, Frankfurt, unter anderem fuer die konzernweite Koordination, die Entwicklung und den Betrieb der Informationsverarbeitung verantwortlich.