„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 Jahren der Entwicklung musste IBM im Sommer 1992 verkünden, dass
es den RM wie geplant nicht mehr geben wird. Das Entstehen von LAN‑gebundenen
Workgroup‑Technologien, der Trend zu objektorientierten Programmier‑Systemen
und die Ausweitung der Unix‑Szene torpedieren die heile Welt von AD/Cycle.
Das Realitätsprinzip hatte voll
zugeschlagen. Große Softwaresysteme wollen der IBM offenbar nicht mehr
gelingen. Nachdem bereits OfficeVision auf eine Odyssee nach Nirgendwo &
Überall geschickt wurde, drohte AD/Cycle mit dieser Ankündigung ein ähnliches
Schicksal. Mit der Verheißung, eine schöne, neue Welt für die Software‑Entwicklung
zu errichten, war die auf die SAA‑Welt ausgerichtete CASE‑Familie im
September 1989 angekündigt worden. Gestellt unter das Patriat des IBM
Repository Managers (RM) sollte AD/Cycle unternehmensweit den Weg in die
seit 30 Jahren ersehnte Wiederverwendbarkeit von Code führen. Doch das
Zentralgestirn entwickelte nie jene Leuchtkraft, die sich ihre 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
Scheitern eigener Riesenprojekte im Bereich Individualsoftware. Auch IBMs Line
of Business Application Solutions rückt seit 1990 immer weiter von der
Entwicklung großer monolithischer Softwaresysteme ab und paßt sich dem neuen
Trend zu Composite Applications (zusammengesetzte Anwendungen) an.
Workgroups. Damit
wandelt sich die Anwendungswelt von der zentralgewaltigen Software‑Entwicklung
hin zu LAN‑gebunden Workgroup‑Umgebungen. In diesem neuen Paradigma arbeiten
viele Entwicklungsteams, mehr oder weniger losgelöst voneinander, an verschiedenen
Projekten oder Teilen davon, bei denen der Zugriff auf ein dediziertes Repositorium
genügt. Jenes Zentralsystem, in dem alle Entwicklungsarbeiten global und
synchron zusammenströmen, brauchen sie nicht mehr oder wenn in einer anderen
Form ‑ als Hort von vorgefertigen und wiederverwendbaren Softwarekomponenten,
die beliebig miteinander verknüpft werden können.
Homogeneität durch Heterogenität. Das bedeutet auch, dass
die Systemgrenzen, die AD/Cycle definierte, gesprengt werden. Entwicklungsumgebungen,
die im Unix‑Spektrum stehen, 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 zusammenbringt ‑ als composite
applications, die der RM in eine homogene Form bringt.
Das wäre dann in der Tat eine überragende Rolle, die einem
solchen 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 dazu dienen, die reale Welt als Modell abzubilden.
Doch die Softwarewelt der Superprojekte scheiterte bislang immer wieder bei
dem Versuch, sich der realen Welt informationstechnisch zu bemächtigen.
Selbst ein Datenmodell
auf der Basis des Entity Relationship Modell (ERM), auch wenn es Daten und
Funktionen zusammenbringt, stößt dabei als Orientierung oder Bauanleitung an
seine Grenzen. Denn es ist darauf ausgerichtet, die relationale Welt (DB2) auszubeuten,
die mehr der Logik der Mathematik als der Spontaneität der ereignisgetriebenen
realen Welt folgt. Diese mathematisierte Modellwelt, obwohl gerade deshalb von
der verwissenschaftlichten Informatik
höchst anerkannt, ist nicht sonderlich gut geeignet Datentypen aus der
realen Welt wie etwa Geschäftsvorgänge und ‑regeln, Grafik, Bewegtbilder,
Sprache oder Text zu unterstützen. Ein Repositorium, das indes diese Elemente
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
Repositoriums zu einer objektorientierten Welt, in der Denken in beliebig
konfigurierbaren Modellen möglich und verlangt wird, tatsächlich leisten?
Hier gibt es inzwischen die stärksten Zweifel.
Objektorientierung. Schon technisch gesehen kann dies nur
mit einem Höchstmaß an Performance‑Verlusten geleistet werden. Deshalb wird
die Forderung immer lauter, dass einem solchen vielgestaltigen Informationsmodell
eine reinrassig objektorientierte Datenbank unterlegt sein muss. Sie bringt
nach dem heutigen Stand der Technik zumindest in Workgroup‑Umgebungen die
erforderliche Leistung. Sie reicht indes noch nicht aus, um ein zentrales Repositorium
zu stützen, 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
retten 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 einem objektorientierten Ansatz läßt sich die alte und nach
wie vor richtige Grundidee überliefern. 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
widersprechen, dass ein solcher zentraler ORM vonnöten ist. Jeder von ihnen
wird gerne daran mitwirken, dessen Implementierung vorzubereiten. Denn er
gibt ihren eigenen Produkten die richtige Perspektive. IBM aber gewinnt Zeit, ohne
Zeit zu verlieren.
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"
[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"
[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'"
Keine Kommentare:
Kommentar veröffentlichen