Gegenstand und Motivation

Verteilte heterogene Informationssysteme sind momentan im Umfeld mittlerer und großer Unternehmen -- und somit auch im Gesundheitswesen -- nicht mehr wegzudenken. 50 Jahre nach dem Aufkommen der ersten Systeme und Verfahren zur elektronischen Datenverarbeitung bilden sie in allen modernen Industrie- und Dienstleistungsländern das Rückgrat von Firmen, Behörden und Organisationen.

Während also die elektronische Datenverarbeitung für ein Unternehmen ein Werkzeug darstellt, so bindet sie selbst ein großes Potential an materiellem und personellem Aufwand für verschiedene Tätigkeiten, die für die Dienstleistung elektronische Datenverarbeitung erbracht werden müssen. Diese Tätigkeiten im Rahmen von Projekten innerhalb der Informationstechnologie (IT) umfassen in der Regel:

Im Rahmen der Planung wird zunächst festzulegt, welche Merkmale ein (künftiges) Informationssystem umfassen soll und welchen Leistungsumfang es besitzen soll. Ziel der Systemanalyse ist es, eine vorhandene Infrastruktur auszuwerten, deren Struktur zu verstehen und Schwachpunkte zu erkennen. Die darauf folgende Entwurfsphase beschäftigt sich mit der detaillierten Ausarbeitung der Funktionsweise des neuen Systems und der Festlegung von Randparametern wie Schnittstellen zu anderen Systemen und den einzusetzenden Werkzeugen und Plattformen. Hierauf folgt dann die eigentliche Implementierung des Systems, bestehend aus Tätigkeiten wie der Anpassung von hinzugekauften Anwendungen und der Programmierung eigener Teile.

Den bisherigen Tätigkeiten dieses -- hier stark generalisiert dargestellten -- Prozesses eines IT-Projekts ist eines gemeinsam: Sie sind abstrakt und noch nicht mit Leben erfüllt, da sie noch keinen Zweck erfüllen. Dies geschieht erst zu dem nach der Implementierung folgenden Zeitpunkt der Inbetriebnahme, bei der das neue System -- im Rahmen einer Neueinführung oder der Ablösung eines bestehenden Systems -- zum Einsatz kommt. Für viele Personen, die in die Einführung eines neuen Systems involviert sind, ist das Projekt zu diesem Zeitpunkt abgeschlossen. Doch mit der Aufnahme des Betriebs fangen viele wichtige Tätigkeiten für ein Informationssystem erst an:

All dieses Aufgaben erfordern einen hohen finanziellen und personellen Aufwand, und dies nicht nur einmalig, sondern über einen größeren Zeitraum hinaus, nämlich über den gesamten Betriebszeitraum des Systems. Verschiedenen Studien über die Total Cost of Ownership (TCO)[*] von IT-Systemen liefern zwar sehr variierende Ergebnisse, ihnen gemeinsam ist jedoch, dass der Anteil für die Betriebskosten bei einem Einsatzzeitraum von 5 Jahren zwischen 50 und 75% der Gesamtkosten liegt. Besonders erschreckend hierbei ist die Tatsache, dass laut einer Studie der International Date Group[*] (IDC) 29% der Betriebskosten nicht budgetiert sind, insbesondere werden Probleme wie Systemausfälle nicht in Kalkulationen aufgenommen.

Fest steht somit: Der Betrieb eines Informationssystems, und nicht nur sein Entwurf, sollte nicht außer Acht gelassen werden, um nicht hohe und unerwartete Kosten für die IT-Infrastruktur eines Unternehmens zu verursachen. Andererseits bietet sich hier ein oft übersehener Ansatzpunkt, um möglicherweise entstehende Kosten zu senken: Durch den Einsatz effizienterer Werkzeuge für den Betrieb und die Verwaltung von Informationssystemen können Kosten in dem Bereich eingespart werden, der die höchsten hiervon verursacht. Dabei handelt es sich um Werkzeuge und Systeme des Systems Management.

Doch nicht genug der Probleme durch aufwändige Tätigkeiten wie Überwachung, Fehlerbeseitigung, Erweiterung oder Pflege des Systems -- in heutigen Unternehmensstrukturen und Einsatzgebieten von Informationstechnologien ist es eine Seltenheit, dass ein einzelnes System für alle anfallenden Aufgaben zum Einsatz kommt. Vielmehr werden für verschiedene Aufgaben viele verschiedene Anwendungssysteme eingesetzt, die sich nicht nur durch die eingesetzte Applikation, sondern auch durch unterschiedliche zugrunde liegende Datenbanken, Betriebssysteme, Rechnerarchitekturen oder Netzwerksysteme unterscheiden.

Hiermit sind wir bei den zwei wichtigsten Attributen einer heutigen IT-Landschaft angelangt. Sie sind:

Eine Ursache der Verteilung wurde bereits angesprochen -- ein einzelnes System ist nie mächtig genug, um sämtliche in einem Unternehmen anfallenden Aufgaben lösen zu können, so dass mehrere Systeme zum Einsatz kommen, die jeweils eine spezialisierte Aufgabe erfüllen. Doch genauso, wie Mitarbeiter verschiedener Abteilungen einer Firma in ständigem Kontakt zueinander stehen, ist dies auch in einzelnen IT-Systemen nötig. Es findet also eine Kommunikation untereinander statt, wobei der Austausch durch eine Vielzahl von Schnittstellen klar definiert ist. Ein weiterer Aspekt der Verteilung entsteht durch räumliche Distanz: Ein Unternehmen besitzt oft eine Vielzahl an Niederlassungen, was einen permanenten Austausch von Informationen nötig macht.

Doch auch der Fortschritt der letzten Jahrzehnte auf dem Gebiet der Informationstechnik führte zu einer weiteren Verteilung von Informationssystemen, denn die Datenverarbeitung ist heute nicht mehr auf ein einzelnes zentrales System beschränkt, dessen Nutzung längere Fußmärsche erfordert[*], sondern vernetzte Personal Computer gestatten ein Arbeiten vom Arbeitsplatz aus -- oder zwischenzeitlich durch das Internet inzwischen von fast jedem beliebigem Punkt auf der Erde.

Die Verteilung ist ein Grund, der den Aufwand für die Verwaltung von IT-Systemen sicherlich erhöht, der andere, der dies mindestens gleichermaßen tut, ist die Heterogenität: Darüber hinausgehend, dass für verschiedene Anwendungssysteme spätestens in Unternehmen mittlerer Größe auch verschiedene darunter liegende Plattformen wie Betriebssysteme, Datenbanken, Rechnerarchitekturen oder Netzwerksysteme zum Einsatz kommen, steigt der Managementaufwand in einem noch höheren Maße, als dies sonst der Fall wäre.

Die Ursachen der Heterogenität können vielfältig sein:

Somit können wir die aktuellen Anforderungen an den Betrieb von IT-Systemen folgendermaßen formulieren:

Anforderungen an ein Werkzeug zum Systems Management
  1. Werkzeuge zum Systems Management sollen in dem Bereich der Informationsverarbeitung die Effizienz erhöhen, der die meisten Kosten verursacht, nämlich der Betrieb des IT-Systems.
  2. Die Komplexität dieser Werkzeuge muss gering sein, um nicht selbst hohe Kosten zu verursachen.
  3. Diese Werkzeuge müssen in der Lage sein, verteilte heterogene Informationssysteme zu verwalten.

Auch wenn es bereits verschiedene Ansätze gibt, die versuchen, diesen Anforderungen gerecht zu werden, so hat sich bisher aus verschiedenen Gründen keiner von ihnen durchsetzen können:

Sicherlich besteht nach wie vor der Bedarf an Werkzeugen, welche die oben genannten Anforderungen erfüllen. Dieser kann aber nicht von einem einzelnen Produkt erfüllt werden. Sinnvoller wäre die Definition eines Frameworks für das Systems Management, also ein offener Standard, der das Zusammenspiel einzelner Komponenten standardisiert, so dass verschiedene Implementierungen jeweils spezialisierte Aufgaben erfüllen könnten. Das Framework würde dann nur die Kommunikation der einzelnen Komponenten definieren.

Die Firma Thinking Objects Software GmbH[*], durch deren Initiative diese Arbeit entstand, beschäftigt sich seit längerer Zeit mit dieser Thematik und unternahm im Jahr 2000 mit BlueConf den Versuch, einen solchen offenen Standard zum Systems Management zu definieren und speziell für das Management vieler Linux-Systemdienste auf Mainframesystemen zu implementieren. Dabei sollten Programme und Dienste ihre Konfiguration über eine einheitliche API laden.

Im Rahmen dieser Initiative zeigte sich, dass der Aufwand für den Entwurf eines Framework recht hoch ist, da nicht nur ein Kommunikationsprotokoll definiert werden muss, sondern zusätzlich für die Darstellung sämtlicher Entitäten von IT-Systemen ein umfangreiches Datenmodell nötig ist.

Es zeigte sich aber auch, dass gerade zu diesem Zeitpunkt ein Industriestandard entstand, der genau den oben aufgeführten Ansprüchen Rechnung tragen sollte. Dabei handelt es sich um das Common Information Model (CIM) der Distributed Management Task Force[*](DMTF). Es definiert ein Datenmodell für das Systems Management, das folgende Merkmale aufweist:

Diese Merkmale lassen CIM als das ideale Framework für das Systems Management erscheinen, was den Anlass dazu gab, dies im Rahmen dieser Arbeit genauer zu untersuchen. Es erschien jedoch sehr bald offensichtlich, dass eine solche Untersuchung auf theoretischem Wege nicht weit genug geht, und dass die Implementierung eines Piloten hier einen sehr viel weitreichenderen Nutzen haben würde.

Ein wichtiger Gesichtspunkt dieser Implementierung war die Fragestellung, ob es mit CIM möglich ist, Applikationen generisch zu verwalten, ob sich also CIM-Schemata formulieren lassen, mit deren Hilfe die Beschreibung von Applikationen und Systemdiensten unabhängig von ihrer Implementierung bzw. unabhängig vom eigentlich eingesetzten Softwareprodukt möglich ist.

Daher erschien es naheliegend, in CIM ein Datenmodell für das Management einer solchen Applikation oder eines Dienstes zu entwerfen und anschließend -- basierend auf genau diesem Schema -- die Implementierung der CIM-Anbindung für zwei verschiedene solcher Systeme vorzunehmen. Um möglichst kritisch beurteilen zu können, ob das gewünschte Ziel erreicht werden konnte, sollten sich die Zielsysteme möglichst stark unterscheiden.

Die Entscheidung, welche Art von System als Ziel für Schemaentwurf und Pilotimplementierung überhaupt zum Einsatz kommen soll, ergab sich recht schnell zugunsten eines Mailserver-Systems. Verschiedene Gründe sprachen dafür:

Somit ergab sich für diese Arbeit eine Struktur, die von den theoretischen und praktischen Grundlagen des Systems Management (beginnend mit seiner geschichtlichen Entwicklung) über ältere Ansätze im Bereich des verteilten heterogenen Systems Management zu einer detaillierten Vorstellung von CIM -- sowohl der Theorie, als auch vorhandener Implementierungen -- führt. Daran schließt sich der praktische Teil der Arbeit mit Entwurf des generischen Schemas für Mailserver-Systeme und nachfolgender Implementierung eines Piloten an, schlussendlich folgt die Bewertung der Eignung von CIM und der geleisteten Arbeit.

Im Detail behandeln die nachfolgenden Kapitel also folgende Themen:

Geschichte des Systems Management:
In diesem ersten Teil soll auf die geschichtliche Entwicklung des Systems Management eingegangen werden, insbesondere unter Berücksichtigung der Entwicklung der Rechner- und Netzwerkparadigmen der letzten Jahrzehnte: vom Zentralrechnersystem über Client-Server-Architekturen bis hin zum Network Computing.
Technische Grundlagen:
Hier sollen zunächst Grundlagen des Systems Management erläutert werden, außerdem wird eine Unterteilung vorgenommen. Außerdem werden Standards und Protokolle erläutert, auf die CIM und andere Ansätze aufbauen.
historische Ansätze:
sind ältere Protokolle und Frameworks für das Application Management, für die CIM eine Alternative darstellt oder die sogar in CIM integrierbar sind.
Eas Common Information Model:
Im zentralen Kapitel über CIM wird selbiges ausführlich dargestellt: von Organisationen, die für CIM von Bedeutung sind, über Grundprinzipien, Schema-Ebenen bis hin zu WBEM. Außerdem sollen vorhandene Implementierungen im Rahmen einer kurzen Marktübersicht vorgestellt werden.
Mailserver-Systeme:
Da der Schemaentwurf und die Pilotimplementierung für Mailserver-Systeme vorgenommen wurde, sollen die Eigenschaften der Mailserver CMU Cyrus IMAPd und Samsung Contact vorgestellt werden.
Ein generisches CIM-Schema für Mailserver:
Dieses Kapitel behandelt das entworfene Modell für Mailserver-System im Detail: seinen Umfang, zugrunde liegende Designprinzipien und Annahmen
Pilotimplementierung:
Hier werden Auswahl der verwendeten Werkzeuge sowie Umfang und Funktion der Implementierung erläutert.
Abschließende Betrachtung:
Ob der praktische Teil der Arbeit den theoretischen Erwartungen gerecht werden konnte und welche Schlussfolgerungen dies zulässt, wird in diesem Abschnitt geklärt.



Fußnoten

... (TCO)[*]
Dies bezeichnet die Gesamtkosten für den Einsatz eines Informationssystems, berücksichtigt also sowohl Entwicklungs- als auch Betriebskosten.
... Group[*]
http://www.idc.com/
... erfordert[*]
Für eine Anfrage, die auf Lochkarten formuliert war, war der erste Gang nötig, das Resultat konnte bei den frühen Großrechnersystemen dann später in einem zweiten Fußmarsch abgeholt werden...
... GmbH[*]
http://www.to.com/
... Force[*]
http://www.dmtf.org/