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.

Ist die Integration bestehender Anwendungen unverzichtbar?

Der Kunde sollte seine offene Architektur selbst definieren

15.01.1993

Viele Grossunternehmen schwoeren immer noch auf ihren Mainframe, haben aber haeufig Probleme, die in den letzten Jahren entstandene heterogene DV-Landschaft zu vereinheitlichen. Andererseits wollen und koennen sie nicht auf einen Schlag mit Down- oder Rightsizing die gesamte bestehende Infrastruktur abloesen. Viele Systeme sind steuerlich noch gar nicht abgeschrieben.

Eine andere Anwendergruppe umfasst mehr mittelstaendisch orientierte Unternehmen, die allerdings mit einer aehnlichen Problematik kaempfen. Abteilungen arbeiten mit verschiedenen Hard- und Softwaresystemen. Daten sind oft redundant vorhanden, da die einzelnen Anwendungen nicht kommunizieren koennen. Ein neues Konzept ("Bottum-Up") koennte die vorhandenen Inseln verbinden und die redundante Datenhaltung ueberfluessig machen. Dadurch freiwerdende Arbeitskapazitaeten wuerden die Produktivitaet des Betriebes erheblich verbessern.

Die Probleme der DV-Leiter

Beide Anwendergruppen bewegen sich auf eine Loesung hin, die unter dem Stichwort Client-Server-Architektur angeboten wird.

Es hat sich gezeigt, dass DV-Fachleute darunter haeufig folgendes verstehen:

- grafische Benutzerschnittstellen als Ersatz fuer Bildschirmmasken,

- in LANs verteilte Ressourcen,

- SQL-Aufrufe zu Remote-Datenbanken,

- PC-Zugriffe auf Grossrechner oder

- Remote Procedure Calls.

All diese Loesungen haben dabei eines gemeinsam: Ein Prozess oder ein System verlangt bestimmte Dienste und ist somit ein Client, waehrend der Server diese Anforderungen befriedigt, indem er die geforderten Dienste zur Verfuegung stellt.

Aus dieser Definition geht hervor, welche Probleme DV-Leiter heute am haeufigsten beschaeftigen. Beispielsweise muessen sie Anwender in der Bedienung vieler Applikationen mit je verschiedenen Benutzeroberflaechen schulen: ein zeitaufwendiges Unterfangen. Des weiteren sollen sie einen transparenten Zugriff auf alle Datenbestaende im Unternehmen ermoeglichen, dabei aber auch die Datenintegritaet und den Datenschutz sicherstellen.

Zugleich wollen die Anwender neue Programme haben. Diese zu entwickeln, ist besonders zeitkritisch, da mehr als die Haelfte der Mitarbeiter mit der Wartung der vorhandenen Anwendungen beschaeftigt ist. Auch das Management uebt Druck auf die DV- Verantwortlichen aus: Alles soll weniger kosten, man will Mitarbeiter abbauen, und die Entwicklungskosten sollen sich die Entwicklungskosten schneller amortisieren.

Sind Client-Server-Modelle also der rettende Strohhalm, die sichere Basis? Ja und nein. Sie koennen einen Grossteil der genannten Anforderungen erfuellen. Allerdings sind sie nicht einfach nur eine neue Schicht innerhalb der DV-Pyramide.

Sehr hohe Kosten bei proprietaeren Systemen

Mit proprietaeren Client-Server-Systemen wachsen die Kosten weiterhin ins Uferlose. Viele Anwendungen muessen selbst gestrickt werden, was den Wartungsaufwand nicht gerade verringert. Es werden eher mehr Programmierer gebraucht als vorher, und es kann nicht garantiert werden, dass wirklich alle Anwender auf die Unternehmensdaten zugreifen koennen.

Inseln sind kaum abbaubar, es sei denn durch Neuinvestitionen in Hard- und Software und eigene Manpower. Letztendlich hat man das bislang drueckende Korsett nicht abgelegt, sondern nur noch fester geschnuert. Die Abhaengigkeit von wenigen Anbietern steigt und wird mit teurem Geld bezahlt werden muessen.

Dennoch koennen Client-Server-Modelle durchaus die Anforderungen der DV-Chefs erfuellen. Das Stichwort heisst offene Systeme. Heute verwenden viele Hersteller den Begriff "offen" als eine Art Synonym fuer das Betriebssystem Unix. Sicherlich, und das hat die Vergangenheit gezeigt, ist Unix ein Schritt in die richtige Richtung. Doch Unix ist noch lange nicht gleich Unix.

Eine haeufige Vision von dem, was ein offenes System sein sollte, sei hier wie folgt beschrieben: "Eine Anzahl heterogener, miteinander vernetzter Computer, die so zusammenarbeiten, als waeren sie ein System, ganz egal wo die Rechner stehen, in welcher Form sie Informationen verarbeiten, welcher Anbieter sie produziert hat und welches Betriebssystem sie benutzen."

Darunter kann dann auch die Ausrichtung nach Standards verstanden werden, und zwar im Sinne des US- Beratungsunternehmens Gartner Group: "Offene Systeme sind solche, deren Spezifikationen von unabhaengigen Standardisierungsgremien wie ISO, Posix, X/Open etc. veroeffentlicht und weiterentwickelt werden."

Waehrend sich Posix und X/Open hauptsaechlich um die Betriebssystem-Ebene kuemmern, unterstuetzen ISO-Normen die Kommunikation unterschiedlicher Rechner oder auch Applikationen.

Netzwerke sind heute in den Unternehmen zu einem der wichtigsten Faktoren avanciert. DV-Leiter erhoffen sich von ihnen vor allem Interoperabilitaet. Es soll moeglich sein, alle Systeme, egal von welchem Hersteller sie einmal gekauft wurden, unter einen Hut zu bringen. Ein Beispiel: User wollen mit PCs auf Unix-Server zugreifen und ebenfalls Daten vom Mainframe herunterladen. Dabei will der Anwender nicht wissen muessen, wo die Daten im Unternehmen zu finden sind, welches Betriebssystem auf dem Zielrechner laeuft und wie die Daten dort abgespeichert sind. Er will einfach auf eine Anfrage hin seine gewuenschten Daten erhalten und das, ohne auf ein Ergebnis mehrere Sekunden oder gar Minuten warten zu muessen.

Standard-Betriebssysteme und Interoperabilitaet gehoeren zwar als Basis zu den offenen Systemen, doch darf man die reinen Anwenderprogramme nicht vernachlaessigen. Sie sind es doch, die heute so viel Manpower in der DV-Zentrale verschlingen. Natuerlich muss man den DV-Chefs zugestehen, dass sie wissen, was heute zu den Standard-Softwareprodukten gehoert. Dennoch sind sie, wenn sie sich erstmalig mit Donwsizing beschaeftigen, nicht gewohnt, mit einem Softwarehaus direkt zu verhandeln (Ausnahmen bestaetigen die Regel). Laeuft das Programm auf der neuen Hardware auch wirklich, muessen noch Anpassungen vorgenommen werden - ungewohnte Fragen fuer einen Mainframer, der sich jetzt mit anderen Terminologien herumschlagen muss.

Ein anderer Punkt bereitet weitere Probleme. Es duerfte heute allgemein bekannt sein, dass die Hauptschwierigkeit beim Entwurf offener Systeme in der Zusammenstellung und Integration der Software liegt. Dabei ist in den meisten Faellen zu beruecksichtigen, dass bereits eine Anzahl Hard- und Softwaresysteme vorhanden und in die neue Architektur einzubinden sind.

Fuer eine solche Aufgabe gibt es keine "Kochbuch-Loesung", auch wenn manche Hersteller solche vermarkten. Andere Anbieter gehen hier einen anderen Weg: Der Kunde selbst muss seine offene Systemarchitektur definieren. Ist- und Soll-Konzepte koennen dabei helfen, eine wirklich offene Umgebung zu realisieren. Nur dann besteht Gewaehr, dass der Anwender seine DV-Traeume auch wirklich in die Realitaet umsetzen kann.

*Thomas Dreller ist im Marketing fuer Computersysteme und Netzwerke der Hewlett-Packard GmbH in Boeblingen verantwortlich fuer Informationstechnologie.