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
|
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:
![[*]](footnote.png)
![[*]](footnote.png)
![[*]](footnote.png)
![[*]](footnote.png)
![[*]](footnote.png)