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.

17.01.1992

Das zentrale Repository - ein Anachronismus?

Wolf-Rüdiger Hansen Geschäftsführer GMO Mitte GmbH, Frankfurt/M.

Unter den Informatikern, die Verantwortung für die kaufmännischen Anwendungssysteme tragen, ist Zittern zu einer Berufskrankheit geworden. Entweder zittern sie um ihre Jobs, weil neue Trends wie Outsourcing, Downsizing und die Umstellung auf Standardsoftware ihr tradiertes Berufsbild verändern. Oder sie zittern, weil sie noch nicht wissen, wie sie die als vordringlich erkannten Aufgaben bewältigen sollen.

Diese Aufgaben betreffen vor allem drei Bereiche: Zum einen müssen die - in über 25 Jahren - pragmatisch und nach abteilungsspezifischen Kriterien gewachsenen Informationssystem-Landschaften in tragfähige Architekturen verwandelt werden, zum anderen soll sich die Anwendungsentwicklung an den Unternehmenszielen ausrichten, und zum dritten ist die Softwareproduktion auf ingenieurgerechte Verfahrensweisen und Methoden umzustellen.

Die Hersteller bemühen sich, die Informatiker bei der Wahrnehmung dieser Aufgaben zu unterstützen, indem sie Rahmenwerke definieren. Der Wert dieser Architekturen liegt vor allem darin, daß die Hersteller sie zum Bestandteil langfristiger Masterpläne gemacht haben, wodurch sie auch für den Anwender als richtungsweisend gelten könnten.

Die Tatsache, daß die kurzfristigen Ziele der Anwender und der Hersteller divergieren, führt jedoch zu Störungen der Masterpläne, die den langfristiger Zielen eher im Wege stehen: Viele der klassischen Hersteller haben derzeit Verluste zu beklagen; zumindest erreichen die Ergebnisse bei keinem die erwünschte (oder notwendige) Höhe. Die kurzfristigen Herstellerziele richten sich folglich darauf, den Verkauf ihrer Produkte zu beschleunigen, um ihre Ertragsprobleme zu belieben. Das ist keineswegs verwerflich, aber es kollidiert mit der Aufgabe der Anwender, eine eigene Software-Architektur zu entwerfen und zu implementieren.

Die momentane Situation läßt sich so beschreiben: Die Hersteller stehen schon mit dem Betonmischer (mit ihren Produkten) vor dem Grundstück, während die Architekten (Informatiker) noch erste Handskizzen mit ihren Bauherren (der Unternehmensleitung und den Anwendern) diskutieren. Aus gegebenem Anlaß fehlt den Herstellern die Geduld zu warten, bis zumindest der Plan gezeichnet und die Schalung für den Beton angebracht ist. Unnötig zu betonen, daß es dem Anwenderunternehmen nichts einbringt, wenn es den Beton einfach vor die Baustelle gekippt bekommt.

Die Masterpläne der Hersteller geben zwar Auskunft darüber, was die Informatiker tun müssen, um die Informationssysteme ihrer Unternehmen so zu gestalten, wie es für die Aufgaben der kommenden Jahre notwendig ist - insbesondere für die Entwicklung von abteilungsübergreifenden Funktions- und Datenmodellen. Doch die Informatiker können diese Aufgaben nicht in eigener Vollkommenheit leisten, sondern sie brauchen dazu die aktive Mitarbeit der Unternehmensleitung und der Fachabteilungen.

Solange es Aufgabe der Informatiker war, vorhandene Abläufe durch Informationstechnik zu unterstützen und damit effizienter zu machen, funktionierte die Arbeitsteilung mit dem Anwender. Heute jedoch geht es um den strategischen Einsatz der Informatiktechnik; und den kann man nicht mehr aus der Analyse bestehender Abläufe heraus gestalten. Bevor hardware- und softwaretechnische Entscheidungen getroffen, also Beschaffungsmaßnahmen für Produkte eingeleitet werden können, müssen Informatiker und Unternehmensleitung in Teamarbeit festlegen, welche Ziele zu verfolgen und wie diese umzusetzen sind.

Über die Notwendigkeit, ein Unternehmens-Datenmodell zu erstellen besteht bei den Beteiligten weitgehend Einigkeit. Wenn es an die praktische Umsetzung geht, tauchen jedoch Probleme auf.

Ist überhaupt zu erwarten, daß diese Aufgaben unternehmensweit mit einem vernünftigen Aufwand zu lösen sind? Ist nicht vielmehr zu befürchten, daß die Erstellung unternehmensweiter Informationsmodelle an zu hoher Komplexität scheitert? Analog dazu muß gefragt werden, ob nicht auch das zentrale Repository (die Datenbank für das Informationsmodell) bereits zum Scheitern verurteilt ist, bevor es überhaupt in Angriff genommen wurde.

Ein immenser Zeitaufwand ist notwendig, um die Zusammenarbeit der beteiligten Parteien zu klären sowie die Geschäftsregeln und -abläufe mit den dafür notwendigen Daten festzulegen und zu beschreiben. Folglich besteht die Gefahr, daß etwaige Ergebnisse immer wieder vom Wandel der Märkte überholt werden. Produkte und Dienstleistungen, die heute noch profitabel sind, geraten morgen in die Verlustzone; Geschäftsregeln, die zehn Jahre lang richtig waren, verändern sich mehrfach binnen Jahresfrist. Die Folge sind OrientierungsprobIeme seitens der Unternehmensleitung und der Fachabteilungen; und die Informatiker wissen es auch nicht besser.

Auch und besonders der Branchenführer IBM wird von diesem Wandel hart getroffen. Er verliert in allen Märkten an Einfluß und Profit; hier funktionieren die etablierten Geschäftsregeln offenbar ebenfalls nicht mehr. Zusammen mit der IBM wird die gesamte Informatikbranche einschließlich der Berater heftig durchgeschüttelt.

Führende Marktbeobachter haben mehrfach konstatiert, daß Überkomplexität das wesentliche Übel heutiger Wirtschaftsunternehmen ist. Auch bei dem zentralistischen Ansatz der IBM für das Informationsmodell und das Repository handelt es sich um einen sehr komplexen, möglicherweise um einen überkomplexen Ansatz. Es sieht so aus, als müßten sich die AD/Cycle-Architekten demnächst wieder in Klausur begeben, um Leitlinien für eine Informationsarchitektur zu entwickeln, die sich stärker an dem betriebswirtschaftlichen Leitsatz "Keep it simple"(McKinsey) und am Wandel der Märkte orientiert.

Vieles spricht dafür, das Repository auf eine Grundstruktur umzustellen, die heute in aller Munde ist: die Client-Server-Architektur. Für die Zukunft zeichnet sich demzufolge ein Schema mit vielen Repositories ab, die durch geeignete Management- und Kontrollstrukturen hinsichtlich ihrer unternehmensweiten Konsistenz und Aktualität gesichert werden müssen.

Sollten diese Gedanken in der IBM-Vertriebsmannschaft auf Unverständnis stoßen, so wird die Unternehmensspitze in den USA den Zweiflern möglicherweise schon in Kürze auf die Sprünge helfen. Es sieht ganz so aus, als würde sich die IBM demnächst in viele kleine Geschäftseinheiten gliedern, die notwendigerweise miteinander in Wettbewerb treten. Ob diese Einheiten unter den gegebenen Umständen noch ein zentralistisches Repository verkaufen werden, ist zumindest zweifelhaft. Möglicherweise folgen sie lieber gemeinsam mit den Anwendern dem Trend zum Client-Server-Schema - wenn auch mit Zittern!