Die konventionelle unternehmensweite Datenmodellierung und die gaengigen CASE-Werkzeuge konnten die mit ihnen verbundenen Erwartungen bisher nicht einloesen. Peter Gerard* erlaeutert im ersten Teil seiner Ausfuehrungen, warum Vision und Realitaet soweit auseinanderklaffen und welche Konsequenzen daraus zu ziehen sind.Der schweizerische Kultur- historiker Jakob Burkhard (1818- 1897) bezeichnete das heranziehende 20. Jahrhundert als "das Zeitalter der uebergrossen Vereinfachungen". Es war ihm dabei wohl klar, dass die gezielte und bewusste Vereinfachung komplexer Sachverhalte das Grundprinzip allen Verstehens und Lernens ist. Was er jedoch kritisieren wollte, war die zunehmend zu beobachtende Praxis, das Nachdenken ueber hochgradig komplexe und miteinander vernetzte Probleme durch eine oberflaechliche und grobe, aber sehr eingaengige Plakatierung mit einem Schlagwort zu ersetzen.Hierdurch wird nicht nur die eigentliche Substanz des Problems und damit auch die seiner Loesung innewohnenden Chancen und Moeglichkeiten nahezu auf Null reduziert, durch die Allgegenwart des Schlagwortes entsteht auch der falsche Eindruck des Vertrautseins mit dem Problem - bis hin zum Ueberdruss.Eine derart plakative Argumentation hat leider auch Einzug in unser Themengebiet, die Informationstechnologie, gefunden. DV- Hersteller, Softwareanbieter und Technologieberater nehmen in ihren Verkaufsargumenten Schlagwoerter auf, die tunlichst zu hinterfragen sind. Zwei derart vertraute Schlagwoerter sind seit einiger Zeit Unternehmensdaten-Modellierung und CASE. Enthusiastisch als Aufbruch in ein neues IT-Zeitalter gefeiert, stellt sich nach Vorliegen der ersten Erfahrungen in grossen Unternehmen ernuechternd die Frage nach dem praktischen Nutzen, ja sogar nach der Umsetzbarkeit ueberhaupt.Im folgenden werden Anspruch und Wirklichkeit der Unternehmensdaten-Modellierung aus Sicht eines grossen Informationsverarbeiters dargestellt.Die Ausfuehrungen werden in der Erkenntnis muenden, dass eine herkoemmliche Unternehmensdaten-Modellierung im praktischen Umfeld zum Scheitern verurteilt ist. Die daraus folgende Notwendigkeit, auf die Spezifika des jeweiligen Unternehmensgeschaefts einzugehen, wird in dem abschliessend vorgestellten Konzept beruecksichtigt, mit dem die Entwicklung eines unternehmensweiten Informationssystems unter Beachtung der spezifischen Belange einer Bank dargestellt werden (Teil 2). Bankgeschaeft und Informationsverarbeitung sind heute untrennbar miteinander verbunden. Es gibt keinen Geschaeftsvorfall mehr, der nicht sofort in einen entsprechenden informationsverarbeitenden Prozess umzusetzen ist. Insofern kann das geschaeftliche Umfeld einer Bank als ein gutes Beispiel fuer die Rahmenbedingungen herangezogen werden, in denen unternehmensweite Informationssysteme zu konzipieren und umzusetzen sind.Das Umfeld ist heute gekennzeichnet durch:- Globalisierung der Maerkte,- Neue Anforderungen und Wettbewerber im EG-Binnenmarkt,- Auftreten branchenfremder Wettbewerber,- Deregulierung der Finanzmaerkte mit einer Fuelle neuer Finanzprodukte,- Neue Produktfelder wie Versicherungen und Bausparen.Schon von diesen Entwicklungen im Umfeld des Bankgeschaefts sind die informationsverarbeitenden Systeme direkt betroffen: Sie muessen permanent an neue Geschaeftsanforderungen angepasst werden. Parallel dazu fuehren eine Reihe von geschaeftsimmanenten Entwicklungen zu einem erheblichen Zuwachs an Komplexitaet in der Informationsverarbeitung einer Bank: Die steigende Vernetzung der verschiedenen Geschaeftsfelder (siehe Abbildung 1) fuehrt beispielsweise dazu, dass es nicht mehr ausreicht, Produkte isoliert zu betrachten und mit DV-Systemen zu unterstuetzen.Unabhaengig von Produkt- und Marktabgrenzungen stehen die verschiedenen Bankprodukte zueinander in Beziehung und beeinflussen sich gegenseitig. Eine isolierte Betrachtung einzelner Produkte kann es deswegen nicht mehr geben. Insbesondere fuer das Risiko-Management ist eine ganzheitliche Betrachtung und die entsprechende Gestaltung der Systeme unumgaenglich. Parallel dazu erfordert die rasante Entwicklung immer neuer Instrumente mit zunehmender Komplexitaet eine hohe Flexibilitaet der Systementwicklung. Auch hat sich die Erwartungshaltung der Kunden geaendert: Sie wollen heute mit einem umfassenden und qualitativ hochwertigen Rundum-Service bedient werden. Dazu sind Informationssysteme noetig, die produkt-, geschaeftsfeld- und laenderuebergreifend alle relevanten Informationen zusammenfassen und die sofortige Geschaeftsabwicklung integrieren. Gleichzeitig ist das Problem der Integration bestehender und neuer Teilloesungen immer dringlicher geworden. Integrationskosten machen schon heute den groessten Teil der Kosten einer Neuimplementierung aus.Die aufgezeigten Umfeldbedingungen und die geschaeftsimmanenten Kraefte fuehren zu einer steigenden Bedeutung der Informationsverarbeitung fuer das Bankgeschaeft. Dies aeussert sich nicht zuletzt im permanenten Druck,Systeme schneller zu entwickeln.Die Komplexitaet der Informationsverarbeitung einer Bank ist also ueberdurchschnittlich hoch. Neben die typischerweise genannten Komplexitaetsdimensionen der Daten, Funktionen und der Zeit (vgl. E. Jourdon) treten im geschaeftlichen Umfeld gleichbedeutend die Dimensionen des geschaeftlichen Wandels und der Kommunikation (siehe Abbildung 2). Im Zusammenhang mit der Zeit muss darueber hinaus beachtet werden, dass nicht nur die Daten in der Zeit konsistent zu halten sind, sondern dass auch eine globale, in allen Zeitzonen praesente Informationsverarbeitung zu gewaehrleisten ist.Aus Sicht einer Bank - und dies gilt aehnlich fuer die meisten Unternehmen mit einer bedeutenden Informationsverarbeitung - ergibt sich somit die Notwendigkeit, ein unternehmensweit integriertes Informationssystem aufzubauen und zu pflegen, das folgenden Anforderungen genuegt:- Es muss eine unternehmensweit gueltige Struktur zur Abbildung der geschaeftsrelevanten Informationen bieten, da nur so die Integration ueber Unternehmens- funktionen und Produkte hinweg erreicht werden kann.- Das Informationssystem muss eine Struktur haben, die laengerfristig unveraendert bleibt.- Zukuenftige, heute noch nicht bekannte Geschaeftsanforderungen sind zu unterstuetzen.- Es soll einen standardisierenden Effekt auf die Systement- wicklung haben, indem sie den Entwicklern einen verbindlichen konzeptuellen Rahmen vorgibt.Grosse Hoffnungen in Unternehmensdaten-Modelle Vor dem geschilderten Hintergrund versprach der Einsatz von Unternehmensdaten-Modellierung im Verbund mit CASE, die Produktivitaet der Anwendungs- entwicklung drastisch zu erhoehen. Gleichzeitig glaubte man, das schon klassische Problem der Softwarepflege und Wiederverwendbarkeit von Teilsystemen loesen zu koennen.Mit der Unternehmensdaten-Modellierung war eine Liste von Erwartungen verknuepft:- Mit Unternehmensdaten-Modellen sollte die Komplexitaet des unternehmensweiten Daten-Managements bewaeltigt werden.- Sie versprachen, Datenredundanzen und damit Konsistenzverletzungen zu verhindern.- CASE, so die allgemeine Erwartung, wuerde neben die Datenmodellierung noch eine Prozess- und Funktionsmodellierung stellen.- Durch den Einsatz von Methoden sollte der Schwerpunkt der Anwendungsentwicklung von der Programmierung auf Analyse und Design verschoben werden.- Datenmodelle und CASE-Tools schienen gleichzeitig eine effektive Kommunikation mit den Fachexperten zu ermoeglichen, um diese damit staerker in die Anwendungsentwicklung zu integrieren. Fehler sollten so schon in der Anfangsphase der Systementwicklung erkannt und eliminiert werden.Wer jedoch heute nach Erfolgsnachrichten in bezug auf CASE und Unternehmensdaten-Modellierung sucht, wird enttaeuscht werden. Eher herrscht die Erfahrung vor, dass der Aufbau eines Unternehmensdaten-Modells kein geeigneter Weg ist, Komplexitaet handhabbar zu machen. Meist werden teure Entwicklungen nach mehreren Jahren unvollendet abgebrochen. In bezug auf die Werkzeuge kann man feststellen, dass CASE gewoehnlich nur in der Analysephase eingesetzt wird.Die im weiteren angefuehrten Gruende fuer diese Situation spiegeln die Erfahrungen eines Anwenders. Modelle werden im allgemeinen mit dem Ziel aufgebaut, die Komplexitaet des abgebildeten Sachverhaltes handhabbar zu machen. Dieses Kriterium erfuellt nach dem heutigen State of the art ein Unternehmensdaten-Modell im komplexen Umfeld eines grossen Unternehmens nicht. Komplexitaet wird auf- und nicht abgebaut Vielmehr schafft hier der Aufbau eines unternehmensweiten Datenmodells (UDM) zusaetzliche Komplexitaet, die die An- wendungsentwicklung mehr behindert als foerdert. Ein wesentlicher Grund dafuer ist die fehlende Moeglichkeit, Bottom-up-Schritte im Zuge der Unternehmensdaten-Modellierung durchzufuehren, da beim Uebergang von Teilmodellen zu einem Gesamtmodell Normalisierungsregeln verletzt werden koennen. Aus einer 1-zu-1- Relation im Teilmodell, kann eine 1-zu-n-Relation im Gesamtmodell werden, woraufhin Anwendungen, die auf Basis des Teilmodells entwickelt wurden, entsprechend zu modifizieren sind. Das folgende Beispiel (aus einem Datenmodell eines bekannten Herstellers) illustriert diesen Sachverhalt. Man stelle sich vor, in einer Bank existierten zwei lokale Datenmodelle, die jeweils die Adresse eines Kunden abbildeten. Im ersten Modell, das fuer eine Privatkonto-Anwendung entwickelt wurde, gibt es eine 1-zu-1- Relation zwischen Kontonummer und Adresse des Inhabers. Auf Basis dieses Modells greift die entsprechende Anwendung ueber den Schluessel Kontonummer auf die Adresse zu.Das zweite Modell wurde fuer eine Marketing-Anwendung entwickelt und bildet deswegen ebenfalls in einer 1-zu-1-Relation die Adresse eines Kontoinhabers ab. Hier ist jedoch die Adresse gemeint, unter welcher der Kunde regelmaessig zu erreichen ist. Bei der Integration beider Teilmodelle faellt auf, dass es sich um zwei verschiedene Adressen handeln kann und deswegen im Gesamtmodell zwischen Konto-, respektive Kundennummer und Adresse eine 1-zu-n-Beziehung besteht. Da aber schon eine Anwendung existiert, die nur ueber einen Schluessel auf die Adresse zugreift, muss diese entweder umgeschrieben werden, oder eine andere mehr oder weniger komplexe Loesung mit Zwischenebenen oder aehnlichen Konstrukten gesucht werden.Nicht vorgesehen, aber da: Denormalisierungen Eine direkte Konsequenz der fehlenden Moeglichkeit, Bottom-up-Schritte in die Datenmodellierung zu integrieren, ist die geringe Tauglichkeit von Unternehmensdaten-Modellen zur Loesung des dringenden Integrationsproblems bestehender Systeme: Eine Systemintegration ohne Bottom-up-Schritte ist nicht moeglich.Auf dem Weg vom normalisierten, abstrakten Datenmodell zum real implementierten System muessen regelmaessig Denormalisierungen vorgenommen werden. Der Grund liegt in der mangelnden Performanz normalisierter Systeme. Ein Entwicklungsteam steht immer wieder vor der Wahl, entweder einen zeitintensiven Join zwischen normalisierten Tabellen zur Laufzeit des Systems ausfuehren zu lassen oder diesen Join in einer denormalisierten Tabelle abzubilden, um schnelle Antwortzeiten des Systems zu erreichen. In der Praxis ist nur die Denormalisierung akzeptabel.Problematisch wird dieser notwendige Schritt in die Denormalisierung erst, weil es keine Moeglichkeit zur Bottom-Up-Integration von denormalisierten Tabellen in das Datenmodell gibt. Koordinierungsprobleme sind nicht loesbar Als Konsequenz entfernt sich die Welt des Datenmodells von der Welt der implementierten Systeme und die Relevanz des Datenmodells fuer die praktische Arbeit schwindet. Als Folge wachsen denormalisierte Datenbestaende im Umfeld der einzelnen Anwendungen, was letztlich zu Integritaetsverletzungen zwischen den verschiedenen Datenbestaenden fuehren muss.Geht man die Unternehmensdaten- Modellierung konsequent an, so entsteht in einem groesseren Unternehmen mit mehreren Geschaeftsfeldern und einer Vielzahl von Produkten ein enormer Koordinierungsbedarf. Ueber bestehende Organisationsgrenzen hinweg muss ueber Datenobjekte und ihre Bedeutungen bis auf die Attributebene hinab Einigkeit erzielt werden. Diese Aufgabe kann von technischen Systemen, das heisst CASE-Tools, nur begrenzt unterstuetzt werden. Auch bei der Verfuegbarkeit von Datenenzyklopaedien bedarf es zusaetzlich einer eigenen Aufbauorganisation, die den Abstimmungsprozess im Gesamtunternehmen koordiniert.UDM verfehlt "Time to market", zementiert Fehler Es wurde schon verdeutlicht, dass der Aufbau eines UDM in einem komplexen Geschaeftsumfeld ein langwieriger Prozess ist. Natuerlich bleibt das Umfeld eines groesseren Unternehmens waehrend dieses Prozesses nicht unveraendert. Das heisst, dass schon waehrend des Aufbaus des UDMs Anpassungen notwendig werden.Die angefuehrten praktischen Probleme machen diese Anpassungen zumindest sehr aufwendig. Letztlich verzoegert sich die Auslieferung des Unternehmensdaten-Modells, die Anwendungen koennen jedoch nicht warten. Es werden pragmatische Teildatenmodelle eingesetzt, die wiederum kaum zu integrieren sein werden etc.Sobald ein Unternehmensdaten-Modell genutzt wird, das heisst als Basis fuer eine Anwen- dungsentwicklung dient, werden die Modellierungsentscheidungen, die zum UDM fuehrten, - ob richtig oder falsch - festgeschrieben. Nachdem die erste Anwendung entwickelt worden ist, fuehrt eine Aenderung des zugrundeliegenden Unternehmensdaten-Modells zu einem ernsthaften Reengineering- Problem in den betroffenen Anwendungen.Nun liegt es aber im Wesen eines Modells, dass man kaum von "richtigen" oder "falschen" Modellen sprechen kann. Da Modelle zielorientierte Vereinfachungen der Realitaet darstellen, ist ihre Richtigkeit zielabhaengig. Aendert sich das Ziel, verliert das urspruengliche Modell seinen Wert. Im Rahmen der Unternehmensdaten-Modellierung fuehrt deswegen das Versaeumnis, zuerst nach den langfristig stabilen Modellierungszielen zu suchen, zu vorprogrammiert "falschen" Modellierungen.Je groesser die Anzahl der Anwendungen ist, die auf einem fehlerhaften UDM aufbaut, desto geringer wird die Chance, Korrekturen vornehmen zu koennen. Als Konsequenz muss auf Ad-hoc- Loesungen zurueckgegriffen werden, die es im weiteren immer schwieriger machen, den einmal festgestellten Fehler zu beheben.Der beschriebene Zusammenhang fuehrt darueber hinaus dazu, dass das konzeptuell-logische Verstaendnis des Geschaefts, kurz als Geschaeftslogik bezeichnet, zum Zeitpunkt der Unternehmensdaten- Modellierung festgeschrieben wird. Das bedeutet letztlich, dass ein Unternehmensdaten-Modell die Flexibilitaet eines Unternehmens, auf Markt- und Umfeldentwicklungen zu reagieren, einschraenkt.CASE benoetigt ein sehr seltenes Mitarbeiterprofil CASE wird gerne als die logische Fortschreibung der Entwicklung von der maschinennahen Programmierung zur Fach-nahen Anwendungsdefinition dargestellt. So sehr dies unter dem Gesichtspunkt einer zu beschleunigenden Systementwicklung zu begruessen waere, so wenig ist heute das dafuer notwendige Mitarbeiterprofil vorhanden. Es gibt offenbar nicht genuegend Fachexperten, die ihr fachliches Know-how mit der zur Systement- wicklung benoetigten analytischen Denk- und Arbeitsweise vereinen koennen.Es hat sich auch gezeigt, dass die urspruenglich mit CASE verknuepfte Hoffnung, eine Basis fuer die Kommunikation mit Fachexperten aufbauen zu koennen, nicht erfuellt wurde. Ein Entity-Relationship-Modell beispielsweise ist fuer die Mehrzahl der Fachexperten keine verstaendliche und damit akzektable Sprachebene.Neben dieser prinzipiellen Schwaeche von CASE behindern eine Reihe von Unzulaenglichkeiten den Einsatz entsprechender Werkzeuge. Tools sind noch immer nicht ausgereift In bezug auf zwei zentrale Schwaechen aktueller CASE-Tools wird der Anwender gerne auf das "naechste Release" vertroestet: Erstens wird die dringend benoetigte Prozessmodellierung nicht hinreichend unterstuetzt und zweitens fehlt ein effektiver, integrierter Uebergang von der Analyse zu Design und Implementierung.Die fehlende Integration auf dem Weg von der fachlichen Analyse zur Implementierung fuehrt zu einer doppelten Dokumentation - einmal auf der Ebene der Analyse und einmal auf der Ebene des Designs und der Implementierung. Da im Rahmen des Designs und der sich anschliessenden Implementierung selbstverstaendlich Veraenderungen notwendig werden, die dann keinen Bezug mehr zur Dokumentation der Analysephase haben, kommt es zwangslaeufig zur Entwicklung von Systemen, fuer die keine nachvollziehbare Dokumentation vorliegt. Daher ist die Wartbarkeit von CASE-gestuetzten Systemen nicht besser als die von traditionell entwickelten Systemen.Vision und Realitaet von CASE und Unternehmensdaten-Modellierung klaffen offensichtlich auseinander. Zusammengefasst laesst sich feststellen:- Die Komplexitaet eines unternehmensweiten Informationssystems wird durch Unternehmensdaten-Modellierung nicht handhabbar - im Gegenteil, die Komplexitaet der Aufgabe wird eher vergroessert. - Datenredundanzen werden nur im Modell, nicht aber in den implementierten Systemen verhindert. Gleichzeitig wird das Problem denormalisierter Datenbestaende aber ignoriert.- CASE-Tools unterstuetzen die Prozessmodellierung noch immer nicht hinreichend.- Analyse und Design bleiben weiterhin nur mangelhaft integrierte Entwicklungsschritte.- Anwender koennen mit dem Instrumentarium der Unternehmensdaten-Modellierung kaum in die Entwicklung einbezogen werden.Neben technischen Unzulaenglichkeiten bei den heute angebotenen CASE-Tools liegt der Grund fuer das Auseinanderklaffen von Anspruch und Wirklichkeit primaer in der elementaren Unterschaetzung der Aufgabe, ein unternehmensweites Informationssystem aufzubauen. Sie kann in ihrem Komplexitaetsgrad nicht mit einer Aufgabenstellung verglichen werden, wie sie sich im Rahmen der Datenmodellierung einer lokalen Anwendung stellt. Der qualitative Sprung an Komplexitaet beim Uebergang von lokalen zu flaechendeckenden Anwendungen wird von den Verfechtern der Unternehmensdaten-Modellierung nicht genuegend beachtet. Deswegen koennen auch Beispiele von erfolgreichen lokalen Datenmodellierungen in geschlossenen Systemen, wie es sie zum Beispiel bei der Modellierung von Fertigungsstrassen gibt, nicht mit der Aufgabe verglichen werden, ein unternehmensweites Informationssystem aufzubauen. Im Rahmen der Unternehmensdaten- Modellierung wurden trotz der Komplexitaet der Aufgabe notorisch die wohlerprobten Prinzipien missachtet, die in der Softwareentwicklung zur Beherrschung von Komplexitaet entwickelt wurden: Weder gibt es eine Modularisierung, die auch Information Hiding und Incapsulation innerhalb von Modulen vorsieht, noch ist ein systematischer Wechsel von Top-down- und Bottom-up-Schritten vorgesehen.Am staerksten wird die Komplexitaet der anzugehenden Aufgabe von denjenigen missachtet, die meinen, ein weitgehend ferti- ges Unternehmensdaten-Modell "von der Stange" verkaufen zu koennen. Eine derartige Unterschaetzung der realen Gegebenheiten eines Unternehmens wirft ein Schlaglicht auf den Glauben, man koenne unternehmensweite Informationssysteme im Zuge von allgemeingueltigen Loesungen konzipieren. Dies geht - zumindest bis heute - nicht.Konsequenz: UDM ist als Methode ungeeignet Die Konsequenz aus diesen Ueberlegungen lautet: Die Unternehmensdaten- Modellierung ist keine Methode, auf deren Basis ein unternehmensweites Informationssystem aufgebaut werden kann. Bei dieser Aufgabe muessen vielmehr die folgenden Leitlinien beachtet werden:- Ausgangspunkt der System- entwicklung muss die Suche nach den langfristig stabilen Grundstrukturen, den Invarianten, des zu unterstuetzenden Geschaefts sein.- Die Fixierung auf die Daten ist zu ueberwinden und von einer durchgaengigen Orientierung an den wesentlichen Geschaeftsprozessen zu ersetzen.- Das organische Wachstum des gesamten Informationssystems muss als Normalfall der System- entwicklung akzeptiert werden.

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