Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.03.1996 - 

Problem 2000/Um nicht vor verwirrend komplexen Zusammenhaengen kapitulieren zu muessen:

Zuerst mit einem Repository die DV-Landschaft erforschen

Nach der erfolgreich durchgefuehrten Postleitzahlenumstellung glauben viele Unternehmen, sich um solche Kleinigkeiten wie zwei Nullen mehr nun wirklich keine Sorgen machen zu muessen. Dabei wird gern uebersehen, dass sich moeglicherweise schon Fehler in die Datenbanken eingeschlichen haben, die sich heute zwar noch nicht auswirken, die aber mit Sicherheit einmal ans Tageslicht kommen werden - nach Murphys Gesetz natuerlich genau dann, wenn es am meisten weh tut. Vielleicht sogar erst nach dem Jahr 2000.

Ein Programm, das in der Datenhaltung eine falsche Jahresangabe hinterlaesst, bleibt vielleicht lange Zeit unbemerkt. Irgendwann jedoch greift eine andere Software auf diese Jahreszahl zu und liefert falsche Ergebnisse. Oder es gibt wieder nur etwas Falsches weiter. Das verkehrte Datum aus dem ersten Programm macht sich so ganz langsam im ganzen System breit - und irgendwann wird es dann verwendet, um beispielsweise Zinsen zu berechnen.

Eventuell wird der Fehler noch bemerkt. Wo die wirkliche Ursache liegt, laesst sich jedoch kaum noch feststellen. Wo dieses falsche Datum ueberall festgehalten wurde, bleibt ebenfalls im dunkeln und kommt erst nach und nach ans Tageslicht. Vielleicht sind es auch die mit viel Aufwand und gutem Willen geaenderten Programme, die, wenn sie die falsche Jahreszahl benutzen, fehlerhaft arbeiten. Das Chaos duerfte perfekt sein - manche sprechen in diesem Zusammenhang von "Datumsviren".

Wer die Datumsumstellung vorbereitet, muss sich also zwangslaeufig mit mehr beschaeftigen als nur mit den einzelnen Feldern und Programmen. Er muss sich damit befassen, wie die ganze Anwendungslandschaft mit ihren zahllosen Applikationen im Unternehmen zusammenhaengt.

Die Idee, die wichtigen strukturellen Informationen des Unternehmens in einem Repository als Metadatenbank abzubilden, ist nicht neu. Schon als in den 70er Jahren die Idee des Data- Dictionary aufkam, wollte man ein Problem in den Griff bekommen:

Es ging damals wie auch heute wieder (oder immer noch?) darum, einen Ueberblick ueber die Daten und Programme zu gewinnen, die ein Unternehmen verwendet, und natuerlich ueber die Zusammenhaenge zwischen diesen, ueber ihre Formate etc. Wie sonst sollte es gelingen, die Auswirkungen auch nur der Aenderung eines einzigen kleinen Datenbankfelds wirklich zu kontrollieren?

In den 80er und 90er Jahren gewann das Repository, das nun auch so genannt wurde, weiter an Bedeutung. Der CASE-Boom setzte ein. IBM kuendigte seinen "Repository Manager MVS" an - und zog ihn ein paar Jahre spaeter wieder zurueck.

Was blieb, war die Erkenntnis, dass nicht nur DV-technische Zusammenhaenge ins Repository gehoeren, sondern auch logische Modelle von Daten- und Funktionen, darueber hinaus Organisations- und Geschaeftsprozessmodelle. Es bietet damit die Moeglichkeit, die Zusammenhaenge sowie die strukturellen Abhaengigkeiten des ganzen Systems "Unternehmen" zu erfassen und zu kontrollieren.

Unternehmen, die ein Repository einsetzen, haben spaetestens bei der Postleitzahlenumstellung gemerkt, wie wertvoll ein solches Instrument ist. Voraussetzung ist, dass es flexible Modellierungs- und Abfragemoeglichkeiten, Auswirkungsanalysen, Suchmoeglichkeiten etc. bietet.

Ein solches Repository darf allerdings keine starren Strukturen besitzen. Es muss anpassbar sein an die Welt eines Unternehmens, an dessen spezifische Strukturen und Organisationszusammenhaenge. Das Repository-Informationsmodell (RIM), das die Grundstruktur des Repositorys abbildet, muss frei definier- und anpassbar sein. Natuerlich liefern die Hersteller auch Referenzmodelle und Modelle zum Beispiel fuer die Unterstuetzung von bestimmten Datenbanksystemen. Aber auch sie muessen sich leicht in ein Gesamtmodell integrieren lassen.

Ein Repository ist das ideale Instrument, um die Umstellung auf die neuen Jahreszahlen in den Griff zu bekommen, weil es nicht nur die komplexen und von Unternehmen zu Unternehmen unterschiedlichen Zusammenhaenge erfassen und auswertbar machen, sondern auch Aenderungen simulieren und generieren kann. Es ist also nicht nur die Analyse des Problems moeglich, sondern auch dessen Loesung.

Die Interaktion der Programme analysieren

Der erste Schritt ist das Fuellen des Repositorys mit relevanten Daten. Dazu sind leistungsstarke Scanner noetig, die sich auch an bestimmte Unternehmensspezifika anpassen lassen. Sie muessen Dateien, Datenbanken, Programme in verschiedenen Sprachen, Masken, Jobs etc. beruecksichtigen und die Metainformationen ueber diese verschiedenen Objekte im Repository hinterlegen. Wichtig ist es dabei nicht nur, einzelne Objekte zu dokumentieren, sondern vor allem die Zusammenhaenge zwischen Objekten verschiedener Art zu erkennen und festzuhalten.

Doch auch das reicht nicht aus: Sind die Daten einmal im Repository hinterlegt, weiss man natuerlich noch lange nicht, wo sich ueberall Datumsinformationen befinden. Dazu bedarf es einer spezifischen Funktionalitaet, die es erlaubt, datumsrelevante Objekte herauszufinden. Ein durchschnittlicher Scanner kann noch nicht beurteilen, ob ein zweistelliges Feld "YY" ein Feld fuer eine Jahreszahl ist oder ob das Feld "YEARGER" mit acht Stellen wirklich das Datum im deutschen Format enthaelt. Auch Unternehmenskonventionen bieten da keine Sicherheit.

Eine Liste kritischer Objekte erstellen

Ein solches Utility ist lediglich in der Lage, Kandidaten fuer datumsrelevante Objekte zu identifizieren - eine rein semantische Analyse ist maschinell nicht voll unterstuetzbar. Sie lassen sich ueber Namens-, Format- und Kontextanalysen finden. Die Entscheidung ueber die wirkliche Relevanz der gefundenen Objekte liegt dann beim Benutzer.

Nun gilt es, jene herauszufinden, bei denen Aenderungsbedarf besteht, zum Beispiel Programme, in denen mit zweistelligen Jahreszahlen gerechnet wird. Hier kommt die Faehigkeit eines Repositorys, komplexe Zusammenhaenge auswertbar und ueberschaubar zu machen, zum Tragen. Die Frage, wo zweistellige Jahresfelder benutzt und eventuell veraendert werden, laesst sich jetzt mit relativ einfachen Mitteln beantworten. Die Liste der zu aendernden Objekte ist mit geringem Aufwand bald erstellt.

An dieser Stelle sind zudem Auswirkungsanalysen unerlaesslich - fuer das Repository eine Grundfunktionalitaet. Solche Auswirkungsanalysen beantworten beispielsweise die Frage, in welchen Programmen ein Datumsfeld verwendet wird. Sie koennen jedoch auch komplexer sein: So kann die Frage notwendig sein, in welchen Programmen Datenbank-Views verwendet werden, die wiederum in Zusammenhang mit Tabellen stehen, in denen ein zu aenderndes Datumsfeld vorkommt.

Tools zur Simulation von Aenderungen sind ebenfalls eine grosse Hilfe fuer ein Jahr-2000-Projekt. Doch fuer solche Werkzeuge (sowie fuer den ganzen Prozess von Analyse, Wartung, Test und Uebergabe in Produktion) ist es noetig, Konfigurations-Management zu betreiben. Die geaenderten Objekte muessen sich eindeutig von den in Produktion befindlichen unterscheiden lassen.

Eine Status-Facility mit "Durchblickfunktion" erlaubt es, ein einzelnes Objekt in einem Status "Produktion" mit allen seinen Zusammenhaengen zu halten, eine geaenderte Version aber in einem Status "Simulation". Die letztere kennt alle Verknuepfungen des produktiven Objekts - damit ist es nicht noetig, alle Objekte in den Teststatus zu kopieren, lediglich die geaenderten werden dort gehalten.

Aber auch innerhalb eines Status koennen verschiedene Varianten eines Objekts sinnvoll sein, etwa fuer verschiedene Datumsformate.

Ein solches System erlaubt umfangreiche Auswirkungsanalysen. Beispielsweise laesst sich nun die Frage beantworten, wo ein Programm denn seine Informationen ablegt und welches Programm diese Daten wiederverwendet. Es faellt nicht mehr schwer zu erkennen, an welchen Stellen die Gefahr lauert.

Die Kandidaten fuer Datumsviren lassen sich relativ einfach finden, und genaue Analysen der produktiven Datenbank koennen dann auch die Frage beantworten, ob sich schon Fehler eingeschlichen haben. Sind diese einmal gefunden, lassen sie sich leicht korrigieren - und man hat vielleicht eine ganze Menge Geld gespart.

Sind alle Analysen und Tests durchgefuehrt, gilt es die Aenderungen in die Produktion zu ueberfuehren. Auch hier ist ein geplantes, Tool- und Repository-unterstuetztes Vorgehen noetig. Generierungen fuer unterschiedliche Zielsprachen und Datenbanksysteme sind durchzufuehren und die noetigen Kompilierungsvorgaenge anzustossen. Hierbei sind natuerlich auch die unternehmensspezifischen Uebergabeverfahren und Richtlinien fuer Konfigurations-Management etc. zu beruecksichtigen.

Dies alles sollte automatisiert und kontrolliert durch das Repository geschehen, so dass sich Aenderungen bei Bedarf schnell rueckgaengig machen lassen. Wie man dabei vorgeht, haengt von der Art der Anwendungs- und Datenhaltung eines Unternehmens ab - und nicht zuletzt von der Menge und der Komplexitaet der Aenderungen.

Auch nach dem erfolgreich bewaeltigten Jahrtausendwechsel bleibt das Repository eine wertvolle Hilfe. Die DV-Welt des Unternehmens ist erfasst, warum sollte man diese ungemein wertvolle Information nicht auch weiter nutzen? Synonym- und Homonymanalysen, Re- Engineering-Projekte (Umstellung von Legacy- auf Client-Server- Systeme etc.), kontrollierte Daten- und Datenbankadministration und vieles mehr ist moeglich. Und warum sollten die Moeglichkeiten des Repositorys nicht auch fuer Business Process Re-Engineering und die Unterstuetzung der Anwendungsentwicklung Verwendung finden?

Kurz & buendig

Der Wechsel ins Jahr 2000 bringt fuer PC-Anwender ein besonderes Problem. Im BIOS der meisten Rechner dieser Art ist das Systemdatum - trotz vierstelliger Anzeige - nur zweistellig implementiert. Allerdings sind die Reaktionen der PCs beim Datumssprung sehr unterschiedlich, manchmal scheinbar absurd. Problematisch wird die falsche Zeitangabe insbesonders bei Servern. Ein stichprobenartiger Test beim Mannheimer Grossanwender Boehringer hat ergeben, dass der Pharmakonzern zahlreiche PCs ausmustern muss.

*Axel Becker ist Vertriebsleiter Sued bei der MSP GmbH, Geschaeftsstelle Muenchen.