1992 GIGAsteps Classics: Insourcing (Teil 7 und Ende)

„Die Sprache besteht in der Sprachgemeinschaft in Gestalt einer Summe von Eindrücken, die in jedem Gehirn niedergelegt sind, ungefähr so wie ein Wörterbuch, von dem alle Exemplare, unter sich völlig gleich, unter den Individuen verteilt wären. Sie ist also etwas, das in jedem Einzelnen von ihnen vorhanden, zugleich aber auch allen gemeinsam ist und unabhängig von dem Willen der Aufbewahrer."

Ferdinand de Saussure, Linguist, 1857 bis 1913[1]

6.0 Primat der Modelle

6.1 Chens Ansatz: Entity Relationship

Trennungsschmerz. Ein Paradigmenwechsel bahnt sich an: „Wir müssen uns von der Vorstellung trennen, dass wir Daten managen, nur um einer Anwendung zu dienen oder einer bestimmten Benutzergruppe", fordert Robert M. Curtice von Arthur D. Little [2]Stattdessen müssen die Daten ‑ losgelöst von den Anwendungen ‑ dem ganzen Unternehmen dienen. „Das Managen von Daten heißt das Managen dessen, was Daten wirklich meinen", befindet der Datenbank‑Experte Daniel S. Appleton, Präsident der Beratungsfirma D. Appleton Inc. in Manhattan Beach (Kalifornien).[3] Subjektive und objektivierte Vorstellungen über das, was Begriffe meinen, müssen übereinstimmen. Die  Datenmodellierung nähert sich damit einem zutiefst philosophischen und schwierigen Thema: der Klärung von Begriffen. Deshalb müssen diese Begriffswelten aus den bestehenden Anwendungen herausgetrennt werden. Ein mitunter schmerzlicher Prozeß, denn damit verbunden ist ein tiefer Blick in die Abgründe so mancher Altanwendung.

Seit mehr als anderthalb Jahrzehnten, seitdem Peter S. Chen von der Louisiana State University 1976 mit seinem Vorschlag eines Entity Relationship Modelling (ERM) die ersten Grundlagen für eine gemeinsame Sicht der Daten geschaffen hatte, wurde die  Datenmodellierung in Fachkreisen immer wieder gefordert.[4] Aber sie wurde lange Zeit aus der Perspektive der Technik und nicht der Begriffe betrachtet.

Wer aber sorgt mit seiner ganzen Expertise für die neue, allgemein‑gültige Sicht? „Die meisten Organisationen haben auch heute noch keine echte Datenadministration", warnt Vaughan Meryl, Chairman der CASE Research Corp.. Die großen Firmen hätten zwar Datenbankverwalter, aber die würden „sich in erster Linie um die technischen Funktionen kümmern. Doch der Datenbank‑Administrator ist der Hüter der Information, der sicherstellen muss, dass die Firma insgesamt eine gemeinsame Sicht der Daten besitzt".[5]

Um das zu erreichen, empfiehlt der Schweizer  Datenmodell‑Experte  Vetter „eine strikte Trennung zwischen Datenbank‑Administrator und Daten‑Administrator", gesteht aber ein, dass aus Kostengründen für viele kleinere Unternehmen nur eine Personalunion in Frage kommt.

Doch dieser Ansatz sollte „nach Möglichkeit vermieden werden", empfiehlt Harald Huber, Datenbankexperte bei der USU Softwarehaus Unternehmensberatung GmbH. Denn man würde „an den Namenkonventionen ziemlich schnell erkennen, ob ein  Datenmodell von einem Datenbanker oder einem Daten‑Administrator gestaltet wird." Der Datenbanker würde „physikalisch orientierte Namen" vergeben. Aber genau das darf nicht der Fall sein, wenn man dem Vorschlag von Chen folgt.

Chens Ansatz war es, die vielen Strömungen der Datenbankmodelle zusammenzufassen ‑ von den hierarchischen bis hin zu den damals gerade erst aufkeimenden relationalen Vertretern. Die Anwender sollten sich über den Inhalt ihrer Daten klar werden, ohne sie gleich wieder aus der funktionalen Sicht der Anwendung zu betrachten. Doch Chen heizte mit seinem Modell nur den internen Wettstreit der Datenbank‑Anbieter an. Sie maßen sich zwar an der vorgeschlagenen „Common View" der Daten. Die Diskussion blieb dabei auf die Fachzirkel beschränkt. Da muss sie nun raus.

Und die Zeichen dafür stehen gut.

Entitäten. Was die Ketten sprengt, macht Mallach deutlich: „Zwischen dem  Datenmodell und dem Datenbank‑Design gibt es einen entscheidenden Unterschied.  Datenmodellierung hat etwas mit dem Geschäftszweck zu tun ‑ und nicht mit Computern. Sie verfährt mit Entities und Attributen, die jene Entities definieren. Datenbanken hingegen kommen in verschiedenen Formen. Das  Datenmodell bleibt immer das Gleiche."[6] Es ist also eine Aufgabe, die sich wegen ihrer Dauerhaftigkeit lohnt, ohne dass die Beteiligten zuerst  Informatiker werden müssen.

Der entscheidende Begriff bei der  Datenmodellierung ist die Entität, sie definiert „etwas Ganzes", erklärt Huber. Gemeint sind damit reale „Wesenseinheiten". Dies kann zum Beispiel ein Angestellter sein oder ein Kunde. Ihnen können Attribute zugeordnet werden wie zum Beispiel „Angestellter arbeitet zu X Prozent an einm Projekt mit".

Aber Entities,  Rhefus nennt sie auch Informationsobjekte, sind nicht für jede Branche gleich. „Entities, die zum Beispiel für eine Bank wichtig sind, interessieren Fertigungsunternehmen überhaupt nicht", meint Mike Galivan, beim kanadischen Stahlgiganten Stelco Inc. in Hamilton (Ontario) für die Systementwicklung verantwortlich.[7] Ergebnis: Letztlich muss sich jedes Unternehmen sein eigenes  Datenmodell schaffen. Es kann allerdings dabei auf branchenspezifischen Konzeptionen zurückgreifen, wie es etwa IBM mit dem COPICS‑Nachfolger CIM APPS für die Fertigungsindustrie vorhält.

Auf der Basis eines  Datenmodells haben die Entwickler die Chance, sich endlich auf das Wesen der Dinge zu konzentrieren: „Die Entwicklung von Datenkonzepten ‑ den sogenannten Entities ‑ ist der wirkliche Schlüsselschritt", formuliert Curtice. „Entities geben eine Terminologie vor, mit der sowohl der Benutzer als auch die Datenbank operieren kann."

Im Idealfall werden damit nicht nur gegenwärtige, sondern auch zukünftige Anwendungen erfaßt. Sicherlich der technische Aspekt ist immer noch da, aber er ist losgelöst von den Anwendungen. Curtice: „Es ist das Design der Datenbank, das  Datenmodell, das uns ein einheitliches Rahmenwerk beschert. Es sorgt dafür, dass alles zusammenpaßt."[8] Der deutsche Datenbankexperte Michael Bauer, Geschäftsführer der Informatik Training GmbH, meint in der Computerwoche: „Der Nutzen eines neuen DBMS ‑ gleichgültig, ob relational oder objektorientiert ‑ erschließt sich erst bei einem sauberen Datenmodell richtig. Und das zu schaffen, kostet Zeit."[9]

Damit setze sich die Erkenntnis durch, dass das  Datenmodell eine ausgezeichnete Schnittstelle zwischen der Fachwelt und der technischen Datenbankwelt bildet, zwischen den Anwendern und der Datenverarbeitung. „Die Entwickler lernen dabei, dass es weitaus wichtiger ist, die Entitäten eines Benutzers zu verstehen als dessen Prozeduren", will Frank Sweet, Präsident der amerikanischen Datenbank‑Beratung Boxes & Arrows in Jacksonville (Florida), der Funktionsorientierung ein Ende setzen.[10] Indes sind in den Prozeduren der Benutzer zumeist die Entitäten begraben. Sie müssen also freigelegt werden. Das ist keine leichte Aufgabe.

6.2 Das Grob‑Grob‑Grob‑Konzept

Kulturrevolution.  Vetter empfiehlt deshalb zuerst die Entwicklung eines „Grob‑Grob‑Grob‑Konzeptes", einer ersten Annäherung an das Unternehmensdatenmodell, in die auch das Top‑Management involviert ist. „Es muss Druck von oben kommen", heißt der kritische Erfolgsfaktor. Nach wenigen Wochen ist ein solcher erster Entwurf zumeist fertiggestellt. In ihm sind die wichtigsten „Objekte" ( Vetter) definiert, die ‑ wie zum Beispiel die Entität „Partner" ‑ auf den ersten Blick „trivial erscheinen", doch hinter denen in Wirklichkeit komplexe Klärungsprozesse stehen. „Ich habe in den zwölf Projekten, die ich mitbegleitet habe, kein Unternehmen gesehen, bei dem die Zahl solcher Objekte höher als acht war."

Bei der DG‑Bank ‑ so bestätigt Brandhofe ‑ waren es zum Beispiel sechs Objekte. Bei der Ausgestaltung zum 1990 fertiggestellten Unternehmensdatenmodell kristallisierten sich dann 160 Entitäten mit insgesamt 2.000 Attributen heraus.

Big Business. Es sind natürlich die großen Anwender, die hier mit gutem Beispiel vorangehen. Die Hoechst AG etwa hat über 15 Fachbereiche hinweg ein hochverdichtetes ERM erarbeitet, das aus rund „70 Entitäten besteht", berichtet Hoechst‑Manager Schmidt. Nach rund neun Monaten war das konzernweit akzeptierte Unternehmensdatenmodell fertig.

Rhefus berichtet, dass innerhalb einer Arbeitsgruppe der Benutzervereinigung GUIDE zum Thema Datenemodelle festgestellt wurde, dass auf Unternehmensebene zwischen 60 und 120 Informationsobjekten definiert würden. Auf Bereichsebene summiert es sich dann bereits zwischen 250 und 400 Informationsobjekte. Zieht man es noch weiter runter, auf die fachliche Detailebene, dann addiert sich das auf bis zu 2.000 Informationsobjekte, die in dem unternehmensweiten  Datenmodell zusammengefaßt werden.

Es steckt also eine Menge Detailarbeit dahinter. Desto wünschenswerter ist es, wenn Hersteller mit  Datenmodellen Hilfestellung geben können. Die DG‑Bank ist zum Beispiel in ein Projekt der IBM Deutschland involviert, bei dem für den Markt der Geldinstitute eine generisches  Datenmodell entwickelt wurde. Es ist das bereits erwähnte Financial Services Industry Data Model (FSI DM), Bestandteil von IBMs Financial Application Architecture (FAA), die wiederum auf der System Anwendungs‑Architektur (SAA) basiert. Und mit dem Entwurf ihres Information Warehouse versucht IBM sogar einen Ansatz, heterogene Welten in dieses Thema miteinzubeziehen.

An solchen Kooperationen und Entwürfen wird deutlich, dass die  Datenmodellierung eine intensive Abstimmung zwischen Herstellern und Anwendern erforderlich macht. „Für IBM ist es ein Feld, bei dem sie ihre Rolle als Systemarchitekt herausstellen kann und muss", erklärt IBM Geschäftsführer Dorn. Dabei sind solche  Datenmodelle aus der Perspektive des Herstellers IBM in mehreren Kontexten zu sehen:

-         in einem internationalen Umfeld. IBM qualifiziert sich hier als transnationaler Hersteller mit SAA.

-         in einem Branchenbezug: IBM erstellt  Datenmodelle gemeinsam mit Kunden und Partnern z.B für Branchen wie Finanzwirtschaft oder Fertigungsindustrie.

-         in einem heterogenen Systemumfeld. Darauf ist letzten Endes der Entwurf des Information Warehouse ausgerichtet.

-         in einer CASE‑Umgebung. Darauf zielt zum Beispiel das ERM im Repository Manager von AD/CYCLE.

Ade, AD/Cycle?

Ende der Superprojekte. Dass dies keineswegs triviale Unterfangen sind, macht die Geschichte rund um den IBMs Repository Manager deutlich. Nach nahezu zehn Jah­ren der Entwicklung musste IBM im Sommer 1992 verkünden, dass es den RM wie geplant nicht mehr geben wird. Das Entstehen von LAN‑gebun­denen Workgroup‑Techno­lo­gien, der Trend zu objektorientierten Pro­grammier‑Systemen und die Auswei­tung der Unix‑Szene torpedieren die heile Welt von AD/Cycle.

Das Realitätsprinzip hatte voll zuge­schla­gen. Große Softwaresysteme wollen der IBM of­fenbar nicht mehr gelingen. Nach­dem bereits OfficeVision auf ei­ne Odyssee nach Nirgendwo & Über­all ge­schickt wurde, drohte AD/Cycle mit dieser Ankündigung ein ähnliches Schicksal. Mit der Ver­heißung, ei­ne schöne, neue Welt für die Software‑Entwicklung zu er­rich­ten, war die auf die SAA‑Welt aus­gerichtete CASE‑Familie im September 1989 angekündigt worden. Ge­stellt unter das Patriat des IBM Repository Ma­nagers (RM) sollte AD/Cy­­cle unternehmensweit den Weg in die seit 30 Jahren ersehnte Wieder­ver­wend­barkeit von Code führen. Doch das Zentralgestirn entwickelte nie jene Leucht­kraft, die sich ih­re Entwickler von ihm erhofft haben. Das harte aber kurze Urteil: zu spät, zu komplex und zu teuer.

Hinzu kam, dass die Zeit der Superprojekte bei den Anwendern schon lange zu Ende war, als IBM noch darauf setzte. Hinter dem Erfolg von SAP, so haben Insider längst ausgemacht, steht nämlich bei vielen Anwendern das Schei­tern eigener Riesenprojekte im Bereich Individualsoftware. Auch IBMs Line of Business Application So­lu­tions rückt seit 1990 immer weiter von der Entwicklung großer monolithischer Softwaresysteme ab und paßt sich dem neuen Trend zu Composite Applications (zusammen­gesetzte Anwendungen) an.

Workgroups. Damit wandelt sich die Anwendungswelt von der zen­tral­gewaltigen Software‑Entwicklung hin zu LAN‑gebunden Work­group‑Umgebungen. In diesem neuen Paradigma arbeiten viele Ent­wicklungsteams, mehr oder weniger losge­löst voneinander, an ver­schiedenen Projekten oder Teilen davon, bei denen der Zu­griff auf ein dediziertes Repositorium genügt. Jenes Zen­tral­system, in dem alle Entwick­lungs­arbeiten global und synchron zusammen­strömen, brau­chen sie nicht mehr oder wenn in einer anderen Form ‑ als Hort von vorgefertigen und wiederverwendbaren Soft­ware­kom­ponenten, die beliebig mit­ein­ander verknüpft wer­den können.

Homogeneität durch Heterogenität. Das bedeutet auch, dass die Systemgrenzen, die AD/Cycle defi­­nierte, gesprengt werden. Ent­wick­lungsumgebungen, die im Unix‑Spektrum ste­hen, können nicht ausgesperrt werden ‑ zumal sie einen nicht unerheblichen und wachsenden Teil der Anwendungswirklichkeit repräsentieren. Merkmal eines Repositorium des neunziger Jahre kann es nur sein, dass ein solcher Manager heterogene Welten zu­sam­menbringt ‑ als composite applications, die der RM in eine homogene Form bringt.

Das wäre dann in der Tat eine überragende Rolle, die einem sol­chen Repositorium zukäme. Versteht man seinen Begriff als einen Ort, in dem etwas abgelegt, genauer: zurückgestellt, wird, dann fungiert es eigentlich als ein Legokasten, dessen Elemente da­zu dienen, die reale Welt als Modell abzubilden. Doch die Software­welt der Superprojekte scheiterte bislang immer wieder bei dem Ver­such, sich der realen Welt informationstechnisch zu bemäch­ti­gen.

Selbst ein  Datenmodell auf der Basis des Entity Relationship Modell (ERM), auch wenn es Daten und Funktionen zusammenbringt, stößt da­bei als Orientierung oder Bauanleitung an seine Grenzen. Denn es ist darauf ausgerichtet, die relationale Welt (DB2) aus­zubeuten, die mehr der Logik der Mathematik als der Spontanei­tät der ereignisgetriebenen realen Welt folgt. Diese mathematisierte Modellwelt, obwohl gerade deshalb von der verwis­sen­schaftlichten  Informatik höchst anerkannt, ist nicht son­der­lich gut ge­eignet Datentypen aus der realen Welt wie etwa Ge­schäftsvorgän­ge und ‑regeln, Grafik, Bewegtbilder, Sprache oder Text zu unter­stüt­zen. Ein Repositorium, das indes diese Ele­men­te nicht in seiner Ablage vorhält, kann nur eine höchst befristete Bedeutung haben. Sie hilft dabei, überhaupt das Denken in Modellen einzugewöhnen.

Die Frage ist nun: Kann es den Transfer eines relationalen Repo­sitoriums zu einer ob­jekt­orien­tier­ten Welt, in der Denken in beliebig konfigurierbaren Mo­del­len möglich und verlangt wird, tatsächlich leisten?

Hier gibt es inzwischen die stärksten Zweifel.

Objektorientierung. Schon technisch gesehen kann dies nur mit ei­nem Höchstmaß an Performance‑Verlusten geleistet werden. Deshalb wird die Forderung immer lauter, dass einem solchen viel­ge­stal­tigen In­for­mationsmodell eine reinrassig objektorientierte Da­ten­bank un­ter­legt sein muss. Sie bringt nach dem heutigen Stand der Technik zu­mindest in Workgroup‑Umgebungen die erforderliche Leistung. Sie reicht indes noch nicht aus, um ein zentrales Re­po­sitorium zu stüt­­­zen, um das AD/Cycle kreisen kann. Deshalb wird sich die SAA‑CASE‑Welt wohl dezentralisieren müssen. Ade heile Welt! Willkommen reale Welt!

Fazit: wenn IBM ihr Allerheiligstes, den Repository Manager ret­ten will, dann muss sie ihn killen. Eine bittere Entscheidung, bei der viele (reale) Manager bei IBM und einige bei ihren Kunden ihr Gesicht verlieren werden. Nur mit ei­nem objektorientierten Ansatz läßt sich die alte und nach wie vor richtige Grundidee über­lie­fern. Fünf Jahre gilt es dabei zu überbrücken, bis ein zentrales Objekt‑RM steht.

In der Zwischenzeit aber bleibt IBM nichts anderes übrig, als die objektorientierten Workgroup‑Angebote Dritter zu akzeptieren und schnell unter Vertrag zu nehmen. Keiner von ihnen wird ernsthaft der Grundidee wi­dersprechen, dass ein solcher zentraler ORM von­nö­ten ist. Jeder von ihnen wird gerne daran mitwirken, dessen Im­ple­mentierung vorzubereiten. Denn er gibt ihren eigenen Produk­ten die richtige Perspektive. IBM aber gewinnt Zeit, ohne Zeit zu ver­lieren.

Alleinstellungsmerkmal. Mit diesen Anstrengungen, die dann in einem Hintergrund‑Repositorium auf ein Metamodell konsolidiert werden, kann es IBM nach Meinung von USU‑Geschäftsführer Udo Strehl gelingen, „ihr Alleinstellungsmerkmal als Systemarchitekt" wieder herauszuarbeiten. „IBMs Philosophie dahinter besteht darin, dass sie nicht länger diktieren will, welche Anwendungssoftware ein Kunde installieren sollte", meint Judith Fischer, Managerin bei The Huntington National Bank in Columbus (Ohio).[11] Indes gibt sie mit der Definition des  Datenmodells eine Menge Kriterien vor, die für die Entwicklung oder Auswahl einer Anwendung wichtig und verpflichtend sind.

6.3 Die zusammengesetzte Welt

IBMs Software‑Vision. Doch das ist ein Anspruch, die einem Architekten, der verantwortlich wirken will, zuerkannt werden muss. Vor allem dann, wenn er praktisch die gesamte Software‑Industrie aufrufen möchte, auf der Basis von  Datenmodellen Produkte zu entwickeln. Das neue Schlagwort dabei heißt composite applications.

In einem vertraulich gehandelten Papier verbreitet IBM die Vision, die hinter diesem Begriff steht. Sie klingt auf den ersten Blick trivial: auf der Basis von IBM‑Architekturen soll sich eine Software‑Gemeinde konstituieren, die Rahmenwerke wie AD/Cycle, Information Warehouse, SystemView etc. mit Anwendungen füllt, die je nach Wunsch des Kunden individuell zusammengesetzt (composite) werden.

Ein kompletter und offener Softwarekorb soll also entstehen, aus dem der Kunde sich nach Herzenslust bedienen kann. Für jedes Problem soll es dabei mehrere Lösungen geben. Manche wurden in IBM‑Labors entwickelt, andere bei Softwarepartnern ‑ und natürlich werden sich auch Kunden daran beteiligen können. Eine Softwaregemeinde auf Gegenseitigkeit soll entstehen, eine community of mutual interests, eine workgroup. Ein prominenter Vorläufer dieses Konzeptes ist bereits aus der AS/400‑Gemeinde bekannt: das MAS 90.

Bei den composite applications werden in den Rahmenwerken der IBM sogenannte boxes definiert, in die nun Dritte ihre Anwendungen hineinentwickeln können. Es wird dabei konkurrierende Angebote für diese boxes geben. Denn Exklusivität ist der Tod des Wettbewerbs und der Kontrapunkt zu jener Offenheit und Reichhaltigkeit des Angebots, die IBM anstrebt. Ihre eigene Aufgabe sieht sie vor allem als Hüter der Architekturen, der Betriebssystemumgebungen, der  Datenmodelle und Schnittstellen, ohne die der Integrationseffekt, auf den diese nach individuellen Gesichtspunkten funktional „zusammengesetzten Anwendungen" zielen, ausbleiben muss.

Systemplattformen wie SAA oder AIX werden von IBM aus einer horizontalen Sicht betrachtet und miteinander vom Betriebsysstem bis hin zum Networking konsistent gehalten. Damit will sie rund 20 Prozent der Ausgaben, die Kunden für Softwaresysteme ausgeben, vornehmlich auf sich lenken. Darüber wölbt sich ein Markt von Querschnittsdiensten, die weitere 20 Prozent des Geschäftes adressieren. Dazu gehören

-         Anwendungstools (z.B. AD/Cycle). Hier, beim application enabling befinden wir uns bereits in einer ersten Sphäre intensiver Kooperationen.

-         die core application services (wie zum Beispiel bei den Datenbanken). Hier wird sich IBM kaum die Butter vom Brot nehmen lassen wollen. Doch sieht man zum Beispiel die Kooperationen, die im Umfeld des Information Warehouse oder SystemView entstehen, dann gewinnt man den Eindruck, dass auch hier die Zeit der monolithischen Gebilde vorbei ist. Und auch bei den

-         die cross systems applications wie Büroanwendungen oder Personalwesen. Hier wird IBM sich kooperativ wie nie zuvor zeigen.

Branchenanwendungen. Doch das Hauptfeld des Marktes und der Zusammenarbeit mit Dritten bilden die branchenspezifischen, vertikalen Anwendungen, die 60 Prozent der Sofwareausgaben von Kunden ansprechen. Das ist der wahre Tummelplatz der Kooperationen, mit denen Nischen und Marktritzen gefüllt werden sollen ‑ von der breitgestreuten Fertigungsindustrie bis hin zu Behörden und Geldinstituten.

Das entscheidende Paradigma, das hinter composite applications steht, liegt in der Neuausrichtung des Geschäftsfocus.

Im Brennpunkt stehten nicht mehr die Produkte, sondern (endlich)  die Probleme der Kunden. Nicht einzelne, monolithisch gestaltete Softwarepakte sollen gepusht werden, sondern die individuellen Wünsche der Anwender sollen aus einem reichgefüllten Korb an (anonymen?) Lösungen bedient werden. Auch das hört sich trivial an, weist aber daraufhin, dass IBM etwas anderes im Sinn hat als die Etablierung von weiteren, ohnehin schon inflationär gehandhabten Markenzeichen.

Deren Bedeutung reduziert sich auf wenige Rahmenwerke wie AD/Cycle oder CIM APPS. Diese Markenzeichen werden aber erst durch die Angebote Dritter, die sich damit identifizieren, zum Leben erweckt. Sie materialisieren sich in der individuellen Situation des Kunden.

Die Reduktion auf wenige Markenbegriffe wird den Softwarehäusern bei ihren eigenen Marketinstrategien wesentlich helfen. Denn die dafür erforderlichen Aufwendungen übersteigen inzwischen die Entwicklungskosten erheblich. Die Softwarekrise wurde für viele Anbieter zu einer Marketingkrise. Viele kleine Anbieter gehen nicht an den Entwicklungsaufwendungen zugrunde, sondern sie brechen unter der Marketinglast zusammen.

Composite applications ist ein Stück Industriepolitik à la IBM. Diese hat allemall bessere Chancen als staatliche Fördermittel oder sonstige Erleichterungen. Was jetzt noch fehlt, ist die Formulierung von Integritätsregeln für die Marketingpraxis. An ihnen muss sich beweisen, wie ernst es der IBM mit der Gründung einer Softwaregemeinde auf Gegenseitigkeit tatsächlich ist. Das wird nicht leicht sein, aber daran wird man den Unterschied zwischen Alter und Neuer IBM messen können. Doch mit der Hinwendung zu objektorientierten Ansätzen, die vielleicht endgültig die Softwarekrise bannen wird, bleibt den Anbietern gar nichts anderes übrig als sich miteinander zu arrangieren.

Die Neue IBM sieht dabei natürlich ihre große Chance. Sie positioniert sich auf diese Weise als ein Dirigent mit Weltgeltung, der das Software‑Orchester durch die Partituren führt. Es sind dabei die  Datenmodelle, die einen entscheidenden Anteil an diesen Partituren haben. Denn sie sind die Grundlage, mit der die Solisten, also die Softwarehäuser, ihre Qualitäten entfalten können. 

Von IBM gemeinsam mit Kunden entwickelte und verfeinerte  Datenmodelle sind aber auch ein Beweis dafür, dass es dem Hersteller tatsächlich um Kundennähe geht. Denn IBM gibt mit ihren Entwürfen den Kunden eine profunde Vergleichsbasis für eigene Schöpfungen. So ist in Großbritannien die National Westminster Bank (NatWest) derzeit dabei, ihr eigenes  Datenmodell mit dem von FAA zu vergleichen.[12] Der Hintergedanke: je größer die Schnittmenge zwischen den beiden, desto sicherer ist die Bank, dass ihr eigener Entwurf stimmig ist mit den Anforderungen ihres Marktes, der zunehmend von unternehmensübergreifenden Aktivitäten geprägt ist.

Umstellung auf DB2 als Anlass. Auch wenn  Datenmodelle unabhängig von der Datenbanktechnologie betrachtet werden können, so hat dennoch die Technik an deren zunehmender Bedeutung einen entscheidenden Anteil. Als sich Mitte der achtziger Jahre die relationalen Datenbanksysteme durchsetzten, war der Ideologie‑Streit der Experten untereinander beigelegt. Zumindest konnten nun die Daten losgelöst von den Anwendungen betrachtet werden, eine riesige Hilfestellung bei der Überwindung der Altlasten.

Bei der DG‑Bank entstand zum Beispiel 1986 auf der Basis von  DB2das unternehmensweite DG Informations‑ und Auskunftssystem, das auf einem  Datenmodell basiert. Dass es indes noch nicht die Integrationsfähigkeit eines zukünftigen Information Warehouse hatte, zeigte sich nach der Not‑Aufnahme der Bayerischen Raiffeisen Zentralbank AG Anfang 1986. Deren gewachsene IMS‑Basis mit ihren eng verwobenen COBOL‑Anwendungen ließ sich nicht ohne weiteres in das neue Auskunftssystem integrieren. Es fehlte das gemeinsame  Datenmodell als Brückenkopf, das auch im Information Warehouse eine Schlüsselbedeutung besitzt.

6.4 Die Kulturrevolution

Höchste Priorität. *] Heute weiß man das alles besser. „Jede wichtige Anwendung muss auf einem  Datenmodell basieren", urteilt Mallach. Aber: „Das Fundament, auf dem das  Datenmodell aufbaut, ist die Datenbank selbst" ‑ und es sind eben nicht die Anwendungen. Diese „können nicht eher stehen, als bis die anderen beiden fest plaziert sind" ‑ die Datenbank und das  Datenmodell.[13]

In dieselbe Richtung denkt wohl auch Harald Huber, Datenmodellexperte bei der USU in Möglingen: „Natürlich ist es Ziel der  Datenmodellierung, ein den Anwendungen gegenüber neutrales Begriffssystem zu schaffen. Nur so kann es die Basis für eine Entwicklung von integrierten Anwendungssystemen darstellen". Doch dann kann ein solches  Datenmodell „automatisch in ein konkretes Datenbankschema transferiert werden. Damit wird es eine entscheidende Grundlage für die Anwendungsprogramme" ‑ und IBM ist nolens, aber noch mehr volens mit ihrem Datenbankangebot im Spiel.

Doch dies ist ein Effekt, es ist nicht Ursache. „Der Einzug von  DB2hat die Diskussion um die Schaffung eines  Datenmodells zwar gefördert, aber dies war nicht der Grund, sondern unser Bemühen, die Software‑Entwicklung zu verbessern", berichtet  Münzenberger über sein Unternehmen. Bei einer Luftlinie sind viele Produkte nicht nur informationsgetrieben, sondern sie sind auch eingebettet in komplexe Vorgänge, die durchaus unternehmensübergreifend wirken. Nehmen wir als Beispiel nur die Reservierung oder die Erstellung der Flugpläne. Das  Datenmodell hilft die Begriffe zu klären und die Abhängigkeiten zu analysieren.

Anstoß für die  Datenmodellierung gab auch bei NatWest die Umstellung auf DB2. Unter dem Namen Customer Relationship Database wurde hier nach Aussage von Ike Richards, Chef der Bankensysteme für die Zweigstellen, „das größte Anwendungs‑Projekt der Welt für IBM  DB2-Datenbank" realisiert, dass vergleichbare Unterfangen an Größe um „den Faktor 4" übertrifft.[14]

Widerstandsbewegung. Na gut. Wichtig ist zu erkennen, dass solche feingeschliffenen  Datenmodelle, die sich dann in Projekten bewähren, nicht über Nacht gedeihen, sondern sie materialisieren sich bei großen Unternehmen über einen Zeitraum von bis zu zehn Jahren. Dabei gilt es mitunter gewaltige mentale Widerstände zu brechen, die vor allen Dingen von den Entwicklern selbst aufgebaut werden. Denn für sie bedeutet es der Umstieg auf das Denken in Modellen.

„Dort, wo es um globalen Modelle geht, können Erfolge erzielt werden", berichtet  Werra. „Aber in der Programmierung sind die Widerstände da. Denn verbunden ist dieser Ansatz mit der Einführung von CASE‑Konzepten. Bei der Gewinnung der Mitarbeiter bedarf es oftmals enormer Anstrengungen".

Damit markiert er die Bruchstelle in der  Datenmodellierung. Bei der Festlegung eines unternehmensweiten  Datenmodells geht es zuerst einmal ja „nur" um ein Grobkonzept, in dem ‑ so Vetter ‑ „typenmäßige aber keine exemplarspezifischen Aussagen über einen zu modellierenden Realitätsausschnitt" getroffen werden. „Es ist neutral gegenüber den Einzelanwendungen und deren lokaler Sicht auf die Daten". Und weiter: „Es stellt das Informationsangebot der Gesamtunternehmung auf begrifflicher (typenmäßiger) Ebene dar und fungiert als Schnittstelle zwischen Anwendungen und Anwender als Informationsnachfrager einerseits sowie Datenorganisation und Datenverwaltung als Informationsanbieter andererseits".[15] Diese Sicht von oben wird indes ergänzt durch die von unten ‑ aus den Projekten. Die hier gewonnenen Erfahrungen müssen in das Grobmodell einfließen. Das heißt: die Datenmodellierung tangiert im hohen Maße die Anwendungs‑Entwicklung. Hier regen sich aber auch die meisten Widerstände.

Richtige Leute. Unbestritten ist, dass  Datenmodelle letztlich zum Nutzen und Frommen aller Benutzer wirken. Es kommt nun vor allem darauf an, dass auch die Entwickler erkennen, dass sie sich nur so aus einer unlösbar scheinenden Pattsituation befreien können. Diese Aufklärung kann durchaus in eine „Kulturrevolution" münden. Es gilt die Widerstände zu brechen. „Mit Saboteuren haben Sie es immer zu tun", warnt  Vetter.

„Systementwicklung auf der Basis eines  Datenmodells ist wie eine Kulturrevolution. Man kann sie nur dann erfolgreich praktizieren, wenn die Projektmitarbeiter diese Kulturrevolution auch wollen", fordert der frühere MBB‑Datenmodellierer  Mistelbauer. Um deshalb so ein Thema wie  Datenmodellierung innerhalb des IS‑Bereichs durchzusetzen, braucht man indes „auch ein bißchen Glück. Es geht darum, die richtigen Leute zu finden." Da gibt es seiner Einschätzung nach Mitarbeiter, die „reden über jene Realität", die sie im funktionalen Blickwinkel haben. Und hier ist die Gefahr groß, dass es „beim Reden bleibt", ergänzt Lufthansa‑Experte Münzenberger.

In Modellen denken. Was stärker gebraucht wird, sind Fachleute, die „in Modellen denken können, die Erkenntnisse aus der praktischen Arbeit als Regeln und Strukturen formulieren können" (Mistelbauer). Solche Streitgefährten zu finden, ist nicht einfach. Deshalb vielleicht seine Beschwörung des Erfolgsfaktors „Glück".

Indes wird immer deutlicher, dass der angeblich so realitätsverhaftete Funktionalismus in eine Pattsituation driftet. Hervorgerufen wird sie durch den existierenden Anwendungsbestand, der allein in der Bundesrepublik einen Wert von mehr als 120 Milliarden Mark darstellt. Wie stark dieses Patt wirkt, macht eine Untersuchung der Beratungsfirma CSC Index Inc. in Cambridge (Massachusetts) deutlich. 142 amerikanischen Top‑Anwender befragte das Institut. Ergebnis: rund 60 Prozent der Anwender gaben zu, dass sie allmählich unter ihrer COBOL‑Altlast zusammenbrechen. Gleichzeitig ist es ihnen unmöglich, überhaupt noch auf neue Anforderungen der Benutzer einzugehen.

Nichts geht mehr.

In der Tat: Wurde bislang angenommen, dass 80 Prozent des Software‑Budgets in die lästige Wartung investiert wird, so erscheint diese Angabe inzwischen als eher konservativ. „Wir waren es bislang gewohnt von einem Verhältnis von 80:20 zwischen Wartung und Neuentwicklung zu sprechen. Doch heute ist diese Relation eher 90:10", befindet Hugh Ryan, Direktor für neue Systeme bei Andersen Consulting in Chicago, dem Informatikzweig der Wirtschaftsprüfungsgesellschaft. Entsprechend ist das Stimmungsbild bei den Anwendern. Ryan: „Es herrscht allgemein der Eindruck, dass es immer schwieriger wird, neue Anwendungen herauszubringen".[16]

Modellklemme. Das bringt nun ausgerechnet die  Datenmodellierer in eine Klemme. Denn bislang gehen sie davon aus, dass der Segen ihrer Arbeit nur bei neuen Projekten so richtig wirken kann. Mehr noch: Die Altanwendungen sollen sich „allmählich ausleben, wenngleich dies über einen längeren Zeitraum geschehen wird", weiß  Werra von der R+V keinen anderen Rat. „Ein altes Projekt läßt sich auf  Datenmodelle nicht umstellen", komplettiert Henkel‑Experte Rhefus das Dilemma. Die Situation scheint fatal. „Das Datenchaos wird erst aufgedeckt, wenn es um die Integration geht", konstatiert Breutmann von der Fachhochschule Würzburg. Dann ist der Punkt erreicht, wo das  Datenmodell helfen soll, aber es läßt sich nicht aktiv an dem Integrationsgegenstand anwenden!

Sind die bestehenden Applikationen also doch als „Altlasten" stigmatisiert? Mistelbauer mag es nicht glauben. „In den alten Anwendungen steckt implizit das  Datenmodell", hält er dagegen. Es muss aus ihnen herausdestilliert und in das globale. konzeptionelle  Datenmodell überführt werden. Aber geht der Weg auch zurück?

Ein Beispiel dafür mag der aus COPICS bei IBM entwickelte Nachfolger CIM‑PPS liefern. Hier wurde aus den alten Anwendungen das  Datenmodell herausgefiltert, um schließlich in das auf DB2 umgestellte CIM‑PPS, das im ersten Anlauf den Funktionsumfang beibehält, einzufließen. Doch auch hier wurde deutlich: es ist und bleibt eine Umstellung, die Zeit und Geld kostet.

Es sind Investitionen, die keiner sieht.

---

[1] Kuno Lorenz: „Die Höhepunkte der sprachlichanalytischen Philosophie ‑ Ludwig Wittgensteins Vermittlung von logischem Empirismus und linguistischem Phänomenalismus" in „Linguistik und Sprachphilosophie, München, 1974, ISBN 3 472 6 1427 3

[2] Datamation, 1/86, Robert M. Curtice: “Getting the database right"

[3] Datamation, 1.5.86, Daniel S. Appleton: „Rule based data resource management"

[4] Datamation, 1.5.86, Daniel S. Appleton: „Rule based data resource management"

[5] Computerworld, 2.7.90, Rosemary Hamilton: „CASE veterans say: lool before you leap">]

[6] Computerworld, 20.8.90, Efrem Mallach: „Without a data model, everything falls down"

[7] Datamation, 1.1.90, Ralph Carlyle: „Is Your data ready for the repository?"

[8] Datamation, 1/86, Robert M. Curtice: „Getting the database right"

[9] Computerwoche, 21.8.92, Michael Bauer: „Kaum eingesetzt und beinahe schon veraltet"

[10] Computerworld, 28.11.88, Frank Sweet: „Database directions"

[11] Computerworld, 27.4.92, Thomas Hoffmann: „IBM shows its flexibility to financial users"

[12] Financial Times, 17.12.91, Dave Madden: „Bankig on a database"

[13] Computerworld, 6.5.91, Rosemary Hamilton: „Indes, Sage pool forces to taken on Case"

[14] Financial Times, 17.12.91, Dave Madden: „Bankig on a database"

[15] Institut '90, IBM Deutschland GmbH, Stuttgart, 12.‑13.9.90, Vortragsunterlagen, Dr. Max Vetter: „Die globale Datenmodellierung zur Lösung des `Jahrhundertproblems der Informatik'"

[16] Computerworld, 26.8.91, Susan Kamp/Joseph Maglita: „Software speeder‑uppers"

TEIL I // TEIL II // TEIL III // TEIL IV // TEIL V // TEIL VI // TEIL VII //

1992 GIGAsteps Classics: Insourcing (Teil 6)

„An dieser Stelle möchte ich hervorheben, dass jede gesellschaftliche Institution, wenn sie bei der Bewältigung von Informationen wirklich funktionieren soll, ein theoretisches Konzept vom Zweck und von der Bedeutung von Information haben muss, dass sie über Mittel verfügen muss, diesem Konzept einen klaren Ausdruck zu geben, und zwar vor allem, indem sie bestimmte Informationen unterdrückt."

Neil Postman, amerikanischer Sozialkritiker in seinem Buch „Das Technopol"

5.0 Gegen den Egoismus

5.1 In Erwartung des Unerwarteten

Ko‑Ordination. Ungeduld ist das, was sich in den neunziger Jahren kein Unternehmen mehr leisten kann. „Das größte Problem, das wir in den neunziger Jahren haben ist nicht technischer Natur, sondern das der Koordination von Menschen", befindet Laszlo Belady, Direktor des Software Research Programms bei dem Forschungs‑Konsortium Microelectronics & Computer Technology Corp. (MCC) in Austin (Texas). „Koordination von Leuten ist das Geschäftsproblem schlechthin, das Manager lösen wollen", bestätigt auch Benn Konsynsky, Professor für Management Informations‑Systeme an der Harvard Business School. Denn von den Menschen geht stets das Unerwartete aus.

Das  Datenmodell kann hier enorm helfen, das Unerwartete zu erwarten, klärt es doch zumindest die gemeinsam verwendeten Begriffe. Sie müssen eindeutig sein, wenn das funktionieren soll, was Thomas Malone, Professor am Massachusetts Institute of Technology (MIT), den „Stoffwechsel der Informationen" nennt, der nicht nur zwischen den Benutzern und dem Computer, sondern zwischen verschiedenen unternehmensweit verteilten Datenbanken ‑ und damit zwischen Menschen aus unterschiedlichen Abteilungen und Bereichen ‑ stattfindet. [1]Engstirniger Abteilungsegoismus läßt sich in den neunziger Jahren nicht mehr durchhalten. Es muss unternehmensweite Klarheit herrschen über die verwendeten Begriffe, wenn sich so etwas wie die vorgangsorientierter Arbeitsweise durchsetzen soll. Und damit sind auch die Topmanager im Boot, die allzu gerne der DV die Schuld zuweisen für organisatorische Mißstände. „Dabei waren sie es, die es versäumten, den Technologen die richtigen Fragen zu stellen", dreht Colin Lesson von der Managementberatung PA Computers and Telecommunications den Spieß um.[2] Das Thema, das damit adressiert wird, ist die Prozeßmodellierung, die gleichsam neben der  Datenmodellierung aufsetzt. Mit ihr kann der Informationsfluß vorgangsorientiert gesteuert werden und somit einen Puffer gegen den größten Störfaktor, das Unerwartete, bilden.

Dieses Unerwartete wird vor allem dann offenbar, wenn Systemwechsel anstehen ‑ und zwei Softwarewelten aufeinander stoßen:

Außer Kontrolle. So wurde im September 1991 das Auswärtige Amt Großbritanniens vom Rechnungshof, dem House of Commons Public Accounts Committee, „stark kritisiert", weil es sein Rechnungswesen softwaretechnisch miserabel unterstützte. Der Übergang von einer alten zu einer neuen Anwendung, der mit einem Jahr Verspätung im November 1989 vollzogen wurde, erwies sich als eine Katastrophe. Die neue Software produzierte einmal ganz andere Ergebnisse als die alte Anwendung, die parallel für eine Übergangszeit noch gefahren wurde. Zum anderen nutzte der Kassierer des Auswärtigen Amtes die mangelhaften Kontrollmechanismen und bereicherte sich um 31.000 Pfund. Kleinmütig musste das Außenministerium zugeben, dass es nicht in der Lage war, solch ein Projekt zu managen. „Wir waren konsterniert darüber, dass es so lange gedauert hat, bis dies erkannt wurde und ein besseres Projekt‑Management installiert wurde", schrieben die britischen Rechnungsprüfer.[3] Das Informationschaos wird zumeist in dem Augenblick offenbar, in dem Daten unternehmensweit erschlossen und integriert werden sollen. Der egoistisch angelegte Funktionalismus begrenzte den Sinn der Informationen zu stark auf Abteilungs‑ oder Fachbereichsebene. Damit zerstörte er nachhaltig den Zugang zum Rohstoff, zu den Daten, die dem Gesamtunternehmen gehören und auch von ihm erschlossen werden sollen. Das Datenchaos ist das Ergebnis. Der den Benutzeranforderungen hinterherhetzende Funktionalismus, der der Softwareentwicklung oktroyiert wurde, erstickt mit der Zeit jeden Versuch, die Daten unternehmensweit zu öffnen. Er produzierte nur spezielle Informationen, die routinemäßig einem genau definierten, eingeengten Insider‑Kreis vorbehalten waren.

5.2 Gegen die Abteilungsgrenzen

Prozeßmodellierung. Den kaum zu befriedigenden Druck in Richtung Funktionalismus erzeugen immer wieder die Abteilungsmanager, die nach höherer Produktivität strebten ‑ nicht des Gesamtunternehmens, sondern des einzelnen Mitarbeiters, für den sie Verantwortung tragen. Terrence R. Ozan, der bei der Wirtschaftsprüfung Ernst & Young in den USA den Fertigungsmarkt betreut, ermittelte aber, dass die „Arbeitskosten bislang zwar einen bedeutenden Faktor bei den Investitionsentscheidungen spielten. Doch in einigen Fällen haben wir inzwischen herausgefunden, dass die Arbeitskosten so unbedeutend sind für das gefertigte Produkt, dass es sich noch nicht einmal lohnt, sie zu messen."[4]

Nicht durch Erbsenzählen wird Produktivität erzielt, sondern durch Straffung und Ordnung der unternehmensweiten Geschäftsprozesse und Berichtswege. So folgt denn auch der  Datenmodellierung die Prozeßmodellierung auf dem Fuß. Und diese Annäherung weist deutlich über die bisherige Anwendungswirklichkeit hinaus, die sich am Egoismus von Abteilungen und Mitarbeiter orientiert. „Die Fachbereiche glaubten in der Vergangenheit, dass sie ihre Daten für sich allein gepachtet hätten. Dieses Besitzstandsdenken läßt sich heute nicht mehr aufrecht erhalten", meint CAP‑debis‑Berater Mistelbauer. „Daten müssen heute im Unternehmen optimal genutzt werden. Sie müssen deshalb entlang der neuen Prozeßketten allen verfügbar sein."

Noch verharren indes zuviele Unternehmen in diesem Abteilungsegoismus. Dies bestätigt eine amerikanische Untersuchung, die von den Wissenschaftlern Thomas Davenport, Robert Eccles  und Lawrence Prussack an der Sloan Management School bei 25 US‑Firmen durchgeführt wurde. Danach grassierte in der Hälfte der Unternehmen das, was die Experten ironisch „Informations‑Feudalismus" nennen, ein Drittel der Firmen schwelgte in einer „Informations‑Utopie" und der Rest litt unter „Informations‑Anarchie". Aussage der Wissenschaftler: „In den meisten informationsorientierten Unternehmen, die wir analysierten, waren die Mitarbeiter am wenigsten dazu bereit, Informationen untereinander zu teilen.[...] Wenn Information die primäre Währungseinheit sind, dann sollten wir nicht erwarten, dass deren Eigentümer auch bereit sind, sie einfach zu verschenken."[5]

Um diese Zustände zu durchbrechen, unter denen die Firmen offensichtlich kräftig litten, empfehlen sie den „Informations‑Föderalismus". Und wenn Information eine Währung ist, dann müßte es auch so etwas wie eine Bundesbank geben, die darüber wacht. Vorsitzender einer solchen Institution wäre dann der Chief Information Officer sein. Er sollte darüber wachen, dass „die mächtigen Barone bereit sind, Informationen mit anderen zu teilen." Firmen, die diese Strategie beherzigen, sind nach Aussage der Wissenschaftler IBM, Xerox, Kodak und Merrill Lynch. Hier stünden an der Spitze der betrieblichen  Informatik Manager, die sich weniger durch technische background auszeichneten, sondern vielmehr durch Führungsqualitäten. „Kein noch so hoher Aufwand an  Datenmodellierung, keine noch so große Zahl an relationalen Datenbanken und keine noch so große Beschwörung der `informationsbasierenden Firma' kann eine neue Informationspolitik herbeizaubern. Was man dazu benötigt, ist das, was einen Politiker auszeichnet: Verhandlungsgeschick, Ausübung von Einfluss, Arbeit im Hintergrund, Bildung von Koalitionen und gelegentlich sogar das Heraufbeschwören eines Krieges." Der Information Manager ist also eminent gefordert. Letztlich muss er mithelfen, die gesamte Unternehmensorganisation zu erneuern, damit die „Währung Information" endlich in Fluß gerät.

Drei Beispiele. Dort, wo die Macht der Barone gebrochen wurde, da wurden auch überraschende Ergebnisse erzielt:

-         Die Trustee Savings Bank (TSB) in Großbritannien hatte seit 1988 das Netzwerk ihrer 1.400 Zweigstellen völlig reorganisiert. 25 Prozent der Arbeit, die bislang vor Ort erledigt wurde, aber nichts mit einem direkten Kundenkontakt zu tun hatten, wurden zentralisiert. Gleichzeitig wurden die Zweigstellenleiter mit mehr Kompetenz ausgestattet. Mit wenigen Tastengriffen stehen den Mitarbeitern alle Informationen zur Verfügung.[6] So können sich die Mitarbeiter mit dem gesamten Unternehmenswissen dem Unerwarteten stellen.

-         Eine Versicherungsgesellschaft ermittelte, dass eine neue Police durchschnittliche 22 Tage brauchte, bis sie von allen Instanzen bestätigt war. Die tatsächliche Bearbeitungszeit aber betrug nur 17 Minuten. Der Rest der Zeit ging dafür drauf, die Police zwischen den Experten hin und her zu bewegen. Nun bearbeitet ein einziger Mitarbeiter den Vorgang, der nach eigenem Gutdünken die Experten einschaltet. Der amerikanische Versicherer Mutual Benefit Life schaltete um auf diese vorgangsorientierte Arbeitsweise und registrierte einen Produktivitätsanstieg von 60 Prozent.

-         Die IBM Credit Corp. (ICC), die für das Leasing‑Geschäft des Computerherstellers in den USA und anderen Ländern verantwortlich ist, reduzierte durch ähnliche Maßnahmen die Bearbeitungszeit von Spezial‑Verträgen von sechs Tagen auf vier Stunden. Gleichzeitig erhöhte sie den Durchsatz an Verträgen um den Faktor 10. Es werden zudem weniger Mitarbeiter gebraucht. 

Der Erfolg liegt nicht so sehr in den Produktivitätsgewinnen, die diese Beispiele dokumentieren, sondern dass sich der Mensch so dem Unerwarteten viel besser stellen kann. Er kontrolliert den „technologischen Impetus" ‑ wie es der Philosoph Hans Jonas nennt. Der Mitarbeiter koordiniert die Vorgänge so, dass deren möglicherweise überraschenden Implikationen ihre zerstörerischen Wirkungen verlieren. Und die Technologie unterstützt ihn dabei.

Sprache als Schlüssel. Das alles verlangt, dass ‑ wie bereits gesagt ‑ unternehmensweit Klarheit und Verbindlichkeit über die verwendeten Begriffe besteht. Die Worthorizonte müssen genau abgestimmt sein. Was ein „Kunde" ist, muss in seiner Bedeutung ebenso eingegrenzt sein wie der Begriff „Auftrag". So bequem es ist, Begriffe aus freiem Gutdünken mit eigenen Bedeutungen einzuführen, im Zusammenspiel eines vorgangsorientiert arbeitenden Unternehmens können sie den Sinnzusammenhalt zerstören. Dann entsteht erneut Informationschaos.

Es ist nunmal höchste Zeit, dass eine einheitliche Sicht der Daten angepackt wird. Denn die Glaubwürdigkeit der Datenverarbeitung wird längst in der Wirtschaftspresse diskutiert. So berichtete die Londoner Financial Times von folgendem Fall.

Die ganze Person... In ein Desaster geriet die Sozialversicherung in Großbritannien, die in den sechziger Jahren noch zu den Pionieren auf dem Gebiet des DV‑Einsatzes gehörte. In den frühen achtziger Jahren war das System indes völlig verrottet. In den Außenstellen der staatliche Rentenversicherung mussten die Zahlungen an 20 Millionen manuell ausgerechnet werden. Versuche, das System dann 1983 zu erneuern, scheiterten zuerst einmal kläglich im Kompetenzstreit der einzelnen Behörden. Das Sozialministerium schaltete schließlich die Beratungsfirma Andersen Consulting ein, um das Projekt neu aufzusetzen. Sieben Jahre später hatten die Berater und Mitarbeiter das 1,5 Milliarden Pfund teure Superprojekt dann gemeistert.

Managebar wurde es, weil Andersen Consulting dahinter eine Vision gesetzt hatte, die von jedem verstanden werden konnte. Es war die Idee von der whole person. Über jeden Empfänger sollte ein genau modelliertes Datenbild angelegt werden, in das all seine Bezüge eingebracht werden konnten.

... der ganze Vorgang. Im Hintergrund dieses  Datenmodells stand aber auch eine ganz andere Arbeitsweise für die rund 34.000 Mitarbeiter. Das heißt: die Prozesse wurden neu modelliert. Obwohl durchaus hervorragend ausgebildet, mussten die Sachbearbeiter bislang stupide Fließbandarbeit im Büro erledigen. Mit der Computerisierung sollte das in vorgangsorientierte Arbeitsweisen umgestaltet werden. Ein richtiger, wengleich auch sehr ehrgeiziger Ansatz, zumal viele Mitarbeiter noch nie in ihrem Leben mit einer Tastatur gearbeitet hatten. 

Die Entwickler, die an dem Projekt beteiligt waren, wußten genau, dass „ihre persönliche Karriere auf dem Spiel stand, falls es schief lief", berichtet Keith Burgess, Managing Partner bei Andersen Consulting. Genau das schreckte so manchen ab. Dennoch ‑ das Projekt wurde gemeistert, denn die meisten erkannten, dass ihnen eine Chance geboten worden war, die man nur einmal in seinem Leben bekommt.

Auf seinem Höhepunkt waren 2.000 Mitarbeiter an der Implementierung des komplexen Software‑Systems beteiligt, das 70 Mainframes an sechs Lokationen umfaßte. „Es ist ohnegleichen in der kommerziellen Welt und vielleicht sogar auch gegenüber dem Verteidigungsbereich" (Burgess), obwohl hier bereits große Erfahrungen auf dem Gebiet langjähriger Superprojekte gesammelt wurden. Doch nach Meinung von Burgess gab es bislang kein Projekt „dieser Größenordnung und Komplexität".[7] Na gut.

Das Beispiel zeigt, dass von einem einzigen Begriff, dem der whole person, Wohl & Wehe eines ganzen Projektes abhängig sein kann. Der Chemiekonzern Hoechst AG in Frankfurt, der kräftig in die  Datenmodellierung investiert, hat aus diesem Grund sogar ein „Genehmigungsgremium für Unternehmensbegriffe" gegründet. Geleitet wird es übrigens von einem Vorstandsmitglied. So wird die Flut von Synonymen, Homonymen etc. eingedämmt. Über die Sprache erschließt sich ein Unternehmen dann seine neuen und seine in den alten Infrastrukturen verborgenen Potentiale.

5.3  Der Methodenstreit

Rückendeckung vom Topmanagement. Es ist in der Tat ein Thema, das unbedingt die Rückendeckung durch das Topmanagement benötigt. Für Henkel‑Manager  Rhefus beginnt sogar alles „beim Topmanagement, das für die zentralen Unternehmensbegriffe verantwortlich sein sollte und gleichzeitig durch Grundsatzentscheidungen die Voraussetzung für ein einheitliches Vorgehen schaffen muss." So geschehen bei Henkel. Und bei der Lufthansa genießt die  Datenmodellierung ebenfalls die „erforderliche Aufmerksamkeit des Topmanagements", berichtet  Münzenberger. Hier wird auch von den Fachbereichen akzeptiert, „dass die  Datenmodellierung ein ausgezeichnetes Kommunikationsmittel zwischen ihnen und der Datenverarbeitung darstellt". Bereits Mitte der achtziger Jahre hat die Luftlinie damit begonnen, das  Vettersche `Jahrhundert‑Problem' anzugehen. Empfiehlt  Münzenberger: „Wichtig ist dabei, dass vor allem die organisatorischen Voraussetzungen geschaffen wurden, um dem Datenchaos zu Leibe zu rücken. Wir gehen nach der Reihenfolge vor: Mensch, Methoden, Tools. Also zuerst die Information, dann die Schulung und schließlich die technischen Hilfsmittel ‑ inklusive eines umfassenden Projektsupports. Das hat sich bewährt."

Die Richtigkeit dieser Vorgehensweise bestätigt auch Howard Fosdick, Präsident der Fosdick Consulting Inc. in Villa Park (Illinois): „Zum ersten Mal seit 30 Jahren entfernen wir uns von dem Codieren" als dem vorherrschende Organisationsprinzip für Anwendungsentwickler. Statt des Funktionalismus rücken Training und Methodologie an die erste Stelle.[8]

Philosophiestreit. Bei der Vorgehensweise zum Thema  Datenmodellierung stoßen natürlich immer wieder zwei Denkansätze aufeinander: top‑down oder bottom‑up. Henkel‑Manager  Rhefus stellt die beiden Methoden so vor:

„Beim top‑down‑Ansatz [...] wird zunächst der Informationsbedarf des Unternehmens in einem groben Unternehmensdatenmodell (UDM) abgebildet. Das UDM dient dann als Basis für die Erstellung detaillierter Projektdatenmodelle."

„Beim bottom‑up‑Ansatz werden die nacheinander entstehenden Projektdatenmodelle zunächst zu einem Basisdatenmodell integriert. Dieser wird dann jeweils zu einer aus mehreren Ebenen bestehenden Unternehmens‑Datenarchitektur verdichtet, deren oberste Ebene dem UDM des top‑down‑Ansatzes vergleichbar ist."

Gleichgültig, für welche Methode man sich entscheidet ‑ Pragmatismus ist bei alldem gefragt und gefordert, weshalb viele das „bottom‑up"‑Verfahren zuerst einmal bevorzugen. Denn dort, wo  Datenmodellierung im „Top‑down"‑Verfahren von einem globalen Ansatz angegangen wird, wird sie schnell „als eine theoretische Sicht" stigmatisiert, wie Alan Bignall, Vice President für Informationssysteme beim Finanzdienstleister IDS, diese Vorgehensweise bezeichnet.[9] Mit ihr können sich vor allem die Benutzer nicht identifizieren, aber auch nicht das Topmanagement, die dieser Form der Grundlagenforschung unwillig gegenüber steht. Es ist ihm suspekt und bestätigt einmal mehr die leidvollen Erfahrungen der Vergangenheit mit der Datenverarbeitung. Deshalb hat das „bottom‑up"‑Verfahren mehr Freunde. So auch bei der Lufthansa. Hier wurde zuerst eine klassische bottom‑up‑Philosophie gefahren. Das heißt aus den einzelnen, bestehenden Anwendungen wurde das  Datenmodell herausdestilliert.  Münzenberger: „Diese wird künftig vermehrt durch Top‑down‑Betrachtungen überlagert. So wurde zuerst für das Vorstandsressort Technik über projektbezogene  Datenmodelle auch ein Ressort‑ Datenmodell erstellt. Dies wiederum dient als Input für das Lufthansa‑ Datenmodell".

Insgesamt besitzt die Lufthansa etwa ein gutes Dutzend Experten auf dem Gebiet der  Datenmodellierung. Mitte der neunziger Jahre wird die Airline soweit sein, dass alle Modelle zu einem einzigen globalen Gebilde zusammenfließen.

Ein rechtzeitiges Umschalten von „Bottom‑Up" auf „Top‑Down" empfiehlt auch Adam Crescenzi, Berater bei der der amerikanische Index Group. Denn nur so kann seiner Meinung nach das mehr experimentelle Vortasten in konsistente Prinzipien umschlagen kann. Seine Sorge ist, dass mit dem reinen Bottom‑Up‑Verfahren nur die bestehende Abteilungs‑Bürokratie abgearbeitet wird, aber nicht der in den neunziger Jahren viel wichtigere Entscheidungsfindungsprozeß abgedeckt wird, der ja unternehmensübergreifende Bedeutung hat.[10]

Die Plus‑Methode. Weil indes beide Verfahren eindeutige Vorteile auf ihrer Seite haben, ist man im Rahmen einer Arbeitsgruppe der Benutzervereinigung GUIDE, die das Thema Enterprise Modelling analysiert und bewertet, zu der Überzeugung gekommen, sie miteinander zu kombinieren. Daraus entstand ein bottom‑up plus‑Verfahren und eine top‑down‑plus‑Methode.

So kann man bei der bottom‑up‑plus‑Methode, wie  Rhefus erläutert, „die Erstellung des Fundaments beschleunigen, indem man neben dem Tagesgeschäft Basissysteme modelliert (Kunde, Produkt, Anlage), deren Daten für viele Anwendungen von Bedeutung sind." Und bei deren Gegenstück, dem top‑down‑plus‑Verfahren wird zuerst ein Unternehmensdatenmodell entwickelt, deren Informationsobjekte dann unentwegt mit Projektdatenmodellen abgeglichen wird. Auf diese Weise entsteht am Ende ein unternehmensweites  Datenmodell.

Datenmodellierung verlangt aber auch, dass die Autorität der Datenverarbeitung gestärkt werden muss. Doch das gelingt nur, wenn sie sich in Übereinstimmung mit der Unternehmens‑Vision befindet. Wie das geht, macht ein Beispiel aus den USA deutlich. Bei der IDS Financial Services in Minneapolis, einer 1984 von American Express übernommenen Versicherungsgesellschaft, wird seit 1987 kein Projekt gestartet, „bevor nicht der Datenadministrator das  Datenmodell für diese Anwendung kreiert hat, das dann Eingang findet in die unternehmensweite Datenarchitektur", berichtet der verantwortliche Manager Alan Bignall. Hintergrund dieser Entscheidung war ein radikaler Strategiewechsel.

Der Finanzdienstleister hatte sich 1984 eine neue Vision gegeben. Das Topmanagement beschloß, dass das Unternehmen nicht mehr versuchen sollte, die beste Versicherung, sondern der beste Finanz‑ und Vermögensplaner am US‑Markt zu sein. Das bedeutete, dass es seine Kunden nur dann optimal bedienen konnte, wenn es über die beste Datenbasis verfügte. Und die war verteilt über funktionale Datenhäfen wie VSAM, DL/1, uralte CICS‑gebundene Assembler‑Dateien und modernes DB2. Eine Gruppe von 14  Datenmodellierern wurde 1984 aufgebaut, die bottom‑up die Datenarchitektur schuf. „Das erste  Datenmodell, das wir schufen, war der `Kunde'. Denn wir sahen ihn als das Herzstück an. Es stellte sich heraus, dass dies die richtige Vermutung war. Dann wechselten wir über zum Marketing‑Modell und diese beiden paßten dann sehr gut zusammen." Nach drei Jahren etwa stand dieser Kern. Doch so richtig komplett wird das globale  Datenmodell erst 1993 sein. Eine lange Zeit, die viel Geduld von den Beteiligten abverlangt. Dennoch ‑ die Anstrengung lohnt sich: „Solange sich unsere Vision nicht ändert, garantieren wir dafür, dass sich die Architektur nicht ändern muss", erklärt IDS‑Manager Bignall.[11]

Redundanz. Schon aus eigenem Antrieb heraus werfen deshalb die höchsten Führungskräfte ein Auge auf das gestalterische Wirken im Bereich der  Informatik. Denn: „Fast jeder Vorstand kann eine Story darüber erzählen, was passiert, wenn er zu einem Thema konsolidierte Zahlen haben möchte", berichtet Peter <$IPersonen; Kirn, Peter>Kirn, Leiter Softwaremarketing bei der IBM Deutschland GmbH in Stuttgart. In manchem Betrieb wurden schon fünf unterschiedliche Berichte erstellt, wenn zum Beispiel ein Executive nach den Kosten pro Mitarbeiter verlangt ‑ nur weil es unterschiedliche Auffassungen darüber gab, was ein Mitarbeiter ist.[12]

Hinzu kommt der Datensalat: Funktional völlig mit den Anwendungen verquickt, werden Kirns Meinung nach in vielen Unternehmen mehr als 50 Prozent der Daten redundant gehalten ‑ mit dem Problem, die Konsistenz dieser Informationen zu bewahren.

Das steigert zwar die Plattenverkäufe der Hersteller, was angesichts sinkender Preise noch zu verschmerzen wäre. Aber weitaus schwerwiegender ist, dass die Entwicklungsarbeit mit einer kaum noch beherrschbaren Komplexität überfrachtet wird, die durch den Wunsch nach Integration heterogener Systeme drastisch verschärft wird.

„Den Preis bezahlen heute die Entwickler, für die immer mehr Anwendungen immer weniger beherrschbar sind. Und die Benutzer bekommen nicht die Anwendungen, die sie sich vorgestellt haben", analysiert IBM Geschäftsführer Dorn. Radikales Umdenken wird verlangt ‑ hin zu Investitionen, die keiner sieht...

---

[1] Fortune, 8.6.87, Louis S. Richman: „Software catches the team spirit“

[2] Financial Times, 30.4.87: „The case for IT as a matter of life and death"

[3] Financial Times, 5.9.91, Robert Mauthner: „Foreign Office is criticised for inadequate controls" >]

[4] Datamation, 1.2.90: „Updating U.S. manufacturers bean counting" >]

[5] Financial Times, 19.10.92, Christpher Lorenz: „From feudalism to federalism"

[6] The Economist, 15.10.91: „Reinventing companies"

[7] Financial Times, 11.12.91, Alan Pike: „Benefits of a seven‑year itch"

[8] Computerworld, 2.7.90, Rosemary Hamilton: „CASE veterans say: lool before you leap"

[9] Computerworld, 18.5.87, Amy Fiore: „It hurt, but IDS built an architecture"

[10] The Economist, 15.10.91: „Reinventing companies"

[11] Computerworld, 18.5.87, Amy Fiore: „It hurt, but IDS built an architecture"

[12] Datamation, 1.1.90, Ralph Carlyle: „Is Your data ready for the repository?"

TEIL I // TEIL II // TEIL III // TEIL IV // TEIL V // TEIL VI // TEIL VII //