Der Markt für Client-Server-orientierte Netz- und System-Management-Lösungen wächst. Bei einzelnen Management-Disziplinen wie zum Beispiel Security oder Network Device Management werden Steigerungen um 30 bis 50 Prozent jährlich bis zum Jahr 2000 und darüber hinaus prognostiziert (vgl. die Einschätzung des Marktpotentials einzelner Management-Disziplinen durch die Gartner Group in CW Nr. 39 vom 27. September 1996, Seite 73).

Die Begründung hierfür ist einfach: Bei weiterhin stark steigender Anwenderzahl und Heterogenität der DV-Umgebung sollen durch ein zahlenmäßig reduziertes IT-Personal unter erhöhtem Kostendruck immer komplexere Anwendungen betrieben werden. Hinzu kommt der Bedarf, ständig neue Technologien wie Internet und Intranet zu integrieren und die damit verbundenen Betriebsanforderungen zu bewältigen. Den Ausweg aus dieser Situation, der anmutet wie der Versuch einer Quadratur des Kreises, sehen viele IT-Manager in dem verstärkten Einsatz von Automatisierungs-Instrumenten aus dem Bereich des Netzwerk- und System-Managements.

Das derzeitige Angebot an Management-Applikationen entspricht allerdings den Erwartungen der IT-Manager noch nicht. Ein durchgängiges Management wie im Host-Umfeld ist noch lange nicht erreicht. Insbesondere gibt es kaum Management-Applikationen, die in der Lage sind, typischen Anforderungen wie etwa dem plattformübergreifenden System-Management vom PC bis zum Host oder dem Netz-Management über alle Infrastrukturen hinweg gerecht zu werden. Nur für Teilaufgaben existieren leistungsfähige Applikationen, eine durchgängige Konzeption fehlt hingegen häufig.

Selbst die Integration von System- mit Netz-Management, also die Verwaltung von Kommunikations-Infrastrukturen und deren typische Komponenten wie Hubs, Stacks, Switches und Router, steckt noch in den Kinderschuhen. Aufkommende Ansätze wie zum Beispiel Hewlett- Packards Operation-Management-Produkt "IT/Operation" (ehemals "Operation Center") zielen zwar deutlich auf Integration, allerdings zur Zeit nur in horizontaler Form. Eine vertikale Integration mit anderen Management-Instrumenten auch anderer Hersteller ist dagegen eher schwierig und nur mit hohem Implemetierungsaufwand zu realisieren.

Die Integrationsbemühungen einzelner Hersteller von Management-Applikationen verlaufen bisher auf unterschiedlichen Realisierungsebenen. Eine betrieblich relevante Integration müßte neben der Funktionskopplung (eine Funktion kann mit einer anderen Funktion einer anderen Management-Applikation kommunizieren, das heißt, sie initiieren, sie beenden etc.) insbesondere eine Datenkopplung (eine Applikation kann einer anderen Applikation Parameter und Statusinformationen übergeben, Ergebnisse austauschen, Anfragen stellen etc.) bewerkstelligen. Viele Integrationen von Spezialapplikationen in sogenannte Plattformen wie HPs "Openview" oder IBMs "Systemview for AIX" sind auf Basis einer gemeinsamen grafischen Benutzeroberfläche (GUI), der Einbindung in ein gemeinsames Menüsystem (Menu Bar Integration) sowie einer gemeinsamen Nutzung von Event-Mechanismen (Event Integration) ausgeführt.

Proprietäre Management-Ansätze

Eine funktionale Kopplung ist - wenn überhaupt - nur in singulären Unterfunktionen realisiert. Massive Funktionsüberschneidung zwischen solchen Snap-in-Applikationen und dem Plattformsystem sind die Regel. Typischerweise sind Snap-in-Applikationen Management-Anwendungen eines Herstellers, die auch als eigenständige Produkte ohne Plattformintegration vermarktet werden. Plattformsysteme werden mittlerweile von jedem marktrelevanten Hersteller angeboten, allerdings verfolgt jeder Wettbewerber einen eigenen proprietären Management-Ansatz (vgl. CW Nr. 39 vom 27. September 1996, Seite 78).

Eine andere Integrationsform sind bidirektionale Kopplungen unterschiedlicher Management-Applikationen über produktspezifische Application Programming Interfaces (APIs). Hier werden zwei unabhängige Management-Applikationen über Programmier-Schnittstellen so miteinander verbunden, daß eine automatische Interaktion möglich wird. Typisches Beispiel ist die Integration von einem Operation-Management-Tool wie HPs IT/Opera- tion mit einem Problem-Management-Tool wie Action Request Systems "Remedy" über das Zusatzprodukt "Trio". Durch die Kopplung führt ein in IT/Operation erkannter Event automatisch zur Generierung eines Trouble-Tickets in Remedy.

Einen Mittelweg zwischen Plattform- und Kopplungsansatz gehen Anbieter sogenannter Frameworks. Hier versucht ein Anbieter, den gesamten Applikationsbedarf durch eine eigene Produktlinie - die häufig durch zugekaufte Fremdprodukte ergänzt ist - abzudecken. Er sorgt für die Integration der einzelnen Applikationen, allerdings allein nach seinem Gutdünken und nicht unbedingt nach betrieblicher Notwendigkeit der Integration.

All diese Integrationsansätze haben ihre immanenten Probleme. Das Plattformkonzept geht davon aus, daß mittelfristig für jede Management-Disziplin eine "integrierbare" Applikation verfügbar sein wird. Der Hersteller der Plattform bietet nur in begrenzten Bereichen auch Spezialapplikationen an, in der Regel sorgen Drittfirmen für die Abdeckung des Management-Bedarfs. Die Integrationstiefe zwischen Spezialapplikation und Plattform ist eher gering. Der Kopplungsansatz bringt das aus vom Gateway-Einsatz bekannte Multiplikatorproblem mit sich: Zur Kopplung von zwei Applikationen benötigt man nur eine Schnittstelle, für die Kopplung von vier Applikationen untereinander dagegen schon sechs.

Eher Wunsch denn Realität

Zusätzlich ist in jeder Applikation ein API mit der geeigneten Funktionalität erforderlich - auch dies ist eher Wunschtraum denn Realität. Der Framework-Ansatz verbietet sich in einer so dynamischen, technologieorientierten Umgebung wie der Client-Server-Welt von selbst, die Applikationen werden fast zwangsläufig hinter der ständig veränderlichen DV-Umgebung hinterherhinken.

Einen Ausweg aus diesen Schwierigkeiten könnte der Corba-2.0-Standard der Object Management Group (OMG), einer herstellerunabhängigen Vereinigung von Unternehmen aus dem Bereich der Objekttechnologien, bieten. Ziel der OMG war die Definition einer Architektur für Distribution und Kooperation objektorientierter Software in heterogenen und vernetzten Strukturen. Es sollte eine netzwerktransparente Nutzung eigenständiger, objektorientierter Softwarebausteine - realisiert in unterschiedlichen Programmiersprachen auf verschiedenen Systemplattformen - durch diverse Applikationen möglich werden.

Kernstück der Object Management Architecture (OMA) ist der Object Request Broker (ORB), der für die Übermittlung von Requests und Replies zwischen Client und Zielobjekt sorgt. Da dieser OMA-Baustein prägend für die gesamte Architektur ist, wurde diese unter dem Namen Common Object Request Broker Architecture (Corba) veröffentlicht. Neben der angestrebten Nutzungstransparenz über ORBs wurden außerdem mächtige allgemeingültige Dienstleistungs-Schnittstellen (Object Services) und Dienste (Common Facilities) wie Naming, Lifecycle (add, modify, copy, move, delete), Events, Relationship etc. normiert, die Corba zu einer Standardarchitektur machen. Mit Corba 2.0 wurde auch die in Corba 1.x fehlende Interoperabilität zwischen ORBs unterschiedlicher Hersteller durch die Einführung von sogenannten Networked ORBs behoben, die über Bridges mit anderen ORBs kommunizieren können.

Die Fähigkeiten der Corba-Architektur könnten bei einer breiten Marktunterstützung die heutigen Netz- und System-Management-Lösungen revolutionieren, da sowohl die Funktions- als auch die Datenintegration über die Grenzen von Herstellern hinaus zu realisieren wäre. Hiermit sind integrierte Management-Systeme vorstellbar, die Verwaltungsaufgaben plattformübergreifend ohne Kenntnis von Lokation und Struktur des Zielobjekts ausführen können. Die Interaktionen zwischen einzelnen Management-Instanzen sowie der gesamte erforderliche Informationsfluß können über den ORB abgewickelt werden, das Zusammenspiel unterschiedlicher Management-Applikationen von verschiedenen Herstellern würde Realität. Entsprechende Ansätze liegen im Markt bereits vor: So setzt das von Tivoli Systems formulierte "TME" auf Corba auf, ebenso wie die zuvor von IBM definierte Management-Architektur "Karat" (infolge der Tivoli-Übernahme durch IBM ist hier allerdings eine Redefinition zu erwarten).

Die Chancen der Corba-Architektur sind gerade für ein unternehmensweites, plattformübergreifendes Netzwerk- und System-Management sehr groß und müssen jedem IT-Manager als Segen erscheinen. Bedroht wird diese heile Welt durch nicht zu unterschätzende Risiken:

- Corba ist eine herstellerunabhängige, hochkomplexe Norm, konkrete Produkte sind derzeit Mangelware. Ein ähnliches Schicksal, wie es zum Beispiel OSI mit seinem Ansatz Common Management Information Protocol (CMIP) erfahren hat - das primitivere, aber verfügbare Simple Network Management Protocol (SNMP) hat sich am Markt durchgesetzt - steht zu befürchten.

- Microsoft als Hersteller objektorientierter Applikationen und Besitzer der OLE-Technologie (OLE = Object Linking and Embedding) ist zwar Mitglied der OMG, forciert allerdings mit der Einführung von Distributed Component Object Model (DCOM) in Windows NT 4.0 eine proprietäre Lösung. Obwohl völlige Unklarheit über die Spezifikation dieser Microsoft-Architektur herrscht und man Corba einen mehrjährigen Entwicklungsvorsprung beimißt, kann eine solche Ankündigung den Markt blockieren und Investitionen hemmen (siehe CW Nr. 39 vom 27. September 1996, Seite 30).

- Für die IT-Manager wächst der Druck allerdings täglich, ein Warten ist für viele nicht mehr möglich.

Es kommt auf die Migrationsstrategie an

In dieser Situation bietet sich eine geeignete Migrationsstrategie als Ausweg an: Marktverfügbare Management-Applikationen werden funktional über APIs gekoppelt und die Daten über ein gemeinsames Repository integriert, in das alle Management-Applikationen relevante Teilinformationen einstellen beziehungsweise von dort auslesen. Dieses auch als System Management Infobase bezeichnete Repository kann in Form einer technischen Bestandsführung auf der Basis einer relationalen Datenbank plattformübergreifend Konfigurationen, (logische) Verbindungen und Verschaltungen sowie Statusinformationen speichern und den Management-Applikationen bei Bedarf zur Verfügung stellen. Kommen dann vermehrt Corba-fähige Applikationen auf den Markt, kann das Repository mit einem Corba-Interface nachgerüstet werden..

Angeklickt

Große Hoffnung setzen viele IT-Manager in die Common Object Request Broker Architecture (Corba). Deren Merkmale könnten bei einer breiten Unterstützung im Markt die heutigen Netz- und System-Management-Lösungen revolutionieren, da sowohl die Funktions- als auch die Datenintegration über die Grenzen der Hersteller hinaus zu realisieren wäre. Dadurch sind integrierte Management-Systeme vorstellbar, die Aufgaben plattformübergreifend ohne Kenntnis der Lokation und Struktur des Zielobjekts, ausführen können. Die Interaktionen zwischen einzelnen Management-Instanzen sowie der gesamte erforderliche Informationsfluß könnten über den Object Request Broker (ORB) abgewickelt werden, das Zusammenspiel unterschiedlicher Management-Applikationen von verschiedenen Herstellern würde Realität.

*Diplomkaufmann Martin Woyke ist Gesellschafter, Ralf Schlimm Entwicklungsleiter der Comconsult Kommunikationstechnik GmbH in Aachen.