HAUPTBEITRAG / CONFIGURATION-MANAGEMENT-DATENBANKEN

Integration verteilterund heterogener Configuration-Management-DatenbankenEine Anforderungs- und Marktanalyse

Holger von Jouanne-DiedrichJuliane Blechinger

Christoph P. NeumannStefan Schwarz · Richard Lenz

Kernpunkt des in ITILbeschriebenen IT Service

Managements bildetdie Configuration-

Management-Database(CMDB).

Die Informationen zuden in der CMDB zuverwaltenden Confi-guration Items liegenin heutigen Unterneh-

men oftmals in Form verteilter, heterogener undautonomer Systeme vor. Es besteht aber der Bedarffür einen zentralisierten Zugriff auf die CMDB imRahmen einer Föderationsschicht. Am Beispielder Anforderungen von Siemens IT Solutions andServices werden in diesem Artikel CMDB-Produkteder Hersteller BMC, CA, HP und IBM auf derenAnforderungsüberdeckung untersucht. Dabei wirdfestgestellt, dass eine deutliche Diskrepanz zwischenCMDB-Herstellern und Siemens IT Solutions andServices als einem international tätigen Anbieter fürIT-Dienstleistungen und Outsourcing hinsichtlichdes erwarteten Leistungsspektrums einer föderier-ten CMDB besteht. Die CMDB-Hersteller verfolgenmit ihren Produkten die Visualisierung bestimmterDatensätze, der sogenannten Configuration Items,und deren Beziehungsnetz untereinander im Hin-blick auf Monitoringaspekte. Bei dieser Zielsetzungist ein global schreibender Zugriff nicht vonnöten,weshalb dieser auch nicht von den Produkten geleis-tet wird. Da der schreibende Zugriff allerdings eineessenzielle Anforderung von Siemens IT Solutionsand Services an eine föderierte CMDB darstellt,werden entsprechende Ansätze zur Systemintegra-tion aus wissenschaftlicher Sicht grob klassifiziertund hinsichtlich ihrer wichtigsten Leistungsmerk-male kurz charakterisiert. Da für unterschiedlicheGruppen von Configuration Items durchaus auchverschiedene Anforderungsprofile bestehen, ergibtsich die Schlussfolgerung, dass eine Optimierung

des Systemverhaltens nur durch die Kombinationverschiedener Integrationsansätze erreicht werdenkann.

EinleitungIT-Abteilungen haben sich in den vergangenenJahren verstärkt zu kundenorientierten IT-Dienstleistern entwickelt [15]. Die Maßnahmenund Methoden, die zur effizienten und zuverlässigenBereitstellung solcher Dienstleistungen benötigtwerden, sind Fokus des sogenannten IT ServiceManagements. Eine mögliche Umsetzung des ITService Managements wird in der IT InfrastructureLibrary (ITIL) beschrieben [16], die sich interna-tional als De-Facto-Standard etabliert hat. ITILwurde im Auftrag der britischen Regierung ent-wickelt, um einen vergleichbaren Betrieb in denRechenzentren der Regierung gewährleisten zukönnen. Um einen einheitlichen Sprachgebrauchzu erreichen, wird ein besonderer Wert daraufgelegt, die exakt gleichen Bezeichnungen für dieITIL-Fachbegriffe zu verwenden. Deshalb ist ITIL

DOI 10.1007/s00287-009-0398-6© Springer-Verlag 2009

Holger von Jouanne-DiedrichSiemens AG, Siemens IT Solutions and Services,Lyoner Str. 27, 60528 Frankfurt am MainE-Mail: Holger.Jouanne-Diedrich@siemens.com

Juliane Blechinger · Christoph Neumann · Richard LenzUniversität Erlangen-Nürnberg, Department Informatik,Lehrstuhl für Informatik 6 (Datenmanagement),Martensstraße 3, 91058 ErlangenE-Mail: Juliane.Blechinger, Christoph.Neumann,Richard.Lenz@informatik.uni-erlangen.de

Stefan SchwarzSiemens AG Information Technology Operations, ITO C&P 1,Werner-von-Siemens-Str. 60, 91050 ErlangenE-Mail: S.Schwarz@siemens.com

Informatik_Spektrum_33_4_2010 351

CONFIGURATION-MANAGEMENT-DATENBANKEN

ZusammenfassungKernpunkt des in der IT Infrastructure Library(ITIL) beschriebenen IT Service Managementsbildet die sogenannte Configuration Manage-ment Database (CMDB). Die Informationenzu den in der CMDB zu verwaltenden Configu-ration Items liegen in heutigen Unternehmenoftmals in Form verteilter, heterogener undautonomer Systeme vor. Es besteht aber derBedarf für einen zentralisierten Zugriff aufdie CMDB. Am Beispiel der Anforderun-gen von Siemens IT Solutions and Servicesals einem international tätigen Anbieter fürIT-Dienstleistungen und Outsourcing wur-den CMDB-Produkte der Hersteller BMC,CA, HP und IBM auf deren Überdeckunghin untersucht sowie alternative Lösungsan-sätze in der wissenschaftlichen Fachliteraturrecherchiert. Daraus resultierten folgendeErgebnisse:

– Es herrscht eine deutliche Diskrepanz zwi-schen dem Angebot von CMDB-Herstellernund den Anforderungen von Siemens ITSolutions and Services hinsichtlich des erwar-teten Leistungsspektrums einer föderiertenCMDB.

– Insbesondere der geforderte schreibende Zu-griff über die Föderationsschicht wird von denCMDB-Produkten nicht gewährleistet.

– Auf dem Markt befindliche CMDB-Produktesind am ehesten in die global rein lesendenBereiche der virtuellen Datenintegra-tion und der-Data Warehouse-Systemeeinzuordnen.

– Verfahren aus dem Bereich föderierter Da-tenbanksysteme ermöglichen den globalschreibenden Zugriff über die Födera-tionsschicht. Hierbei müssen allerdingsKonsistenzerhaltungsgrad gegen Aufwand undEinbußen im Antwortzeitverhalten abgewogenwerden.

– Eine funktionelle und leistungsfähige Ar-chitektur kann nur durch die Kombinationverschiedener Integrationsverfahren erzieltwerden, sodass der Zugriff für verschiedeneGruppen von Configuration-Items individuelloptimiert werden kann.

(leider) auch in der deutschen Übersetzung starkdurch englischsprachige Bezeichnungen geprägt.ITIL wird vielfach als „Best-Practice-Leitfaden“für das IT Service Management bezeichnet. In [15,S. 383] konnte jedoch gezeigt werden, dass zumin-dest mit ITIL V2 nicht ein Best-Practice-Modellvorliegt, sondern lediglich ein „Common-Practice-Referenzmodell“. Die neuere Version ITIL V3besteht aus den folgenden fünf Kernpublikationen,die die meisten Bereiche der ITIL V2 beinhaltenund einige erweitern: Service Strategy (Dienst-leistungsstrategie), Service Design (Entwurf vonDienstleistungen), Service Transition (Umsetzungvon Dienstleistungen), Service Operation (Durch-führung und Betrieb von Dienstleistungen) undContinual Service Improvement (kontinuierlicheVerbesserung von Dienstleistungen). Für das ITService Management sind vor allem die BereicheService Design (z. B. mit Service-Level-, Availability-und Capacity-Management), Service Transition(z. B. mit Change-Management und Configuration-Management) und Service Operation (z. B. mitIncident-, Access- und Problem-Management) vonBedeutung. Eine nähere Beschreibung der einzel-nen Bereiche ist in den über ITIL [17] erhältlichenBüchern vorzufinden.

Kernstück des IT Service Managements bildetdie Configuration-Management-Database (CMDB).Diese wird im IT Service Management Forum [18]definiert als „eine Datenbank, die verwendet wird,um Configuration Records während ihres gesam-ten Lebenszyklus zu speichern. [...] Jede CMDBspeichert Attribute von Configuration Items sowieBeziehungen zu anderen Configuration Items“.Dabei sind Configuration Items (CIs) nach ITIL-Definition [18] „alle Komponenten, die verwaltetwerden müssen, um einen IT Service bereitstellenzu können“, während ein Configuration Record (CR)als Datensatz „die Details zu einem ConfigurationItem enthält und den Lebenszyklus eines einzelnenCI dokumentiert“.

In diesem Sinne bildet die CMDB den zentralenInformationspunkt für zahlreiche ITIL-Prozesse,wie Change-, Incident-, Problem-, Availability- undCapacity-Management. Aufgrund dessen zielenviele IT-Dienstleistungsunternehmen darauf ab,eine adäquate CMDB in ihrem Umfeld aufzubauen.Als problematisch erweist sich allerdings, dass die zuintegrierende Altsystemlandschaft meist aus vielenheterogenen und autonomen Systemen besteht.

352 Informatik_Spektrum_33_4_2010

AbstractThe configuration management database(CMDB) is the main issue of the ITIL-related ITservice management. In today’s enterprises theCMDB often exists in a distributed, heteroge-neous and autonomous manner. However, thereis a need for a centralized CMDB access. Usingexisting requirements of Siemens IT Solutionsand Services as an international provider of ITsolutions and services CMDB products fromvendors BMC, CA, HP and IBM were analyzedand alternative proposals and methods residingin the scientific literature were investigated. Theresults were as follows:

– There is a meaningful discrepancy between theoffer of CMDB vendors and the requirements ofSiemens IT Solutions and Services concerningwhat a federated CMDB should offer.

– Especially the required write-access through thefederation layer is not provided by the CMDBproducts.

– Available CMDB products can be categorizedmost likely into the globally read-only areasof virtual data integration and data warehousesystems.

– Techniques from the area of federated databasesystems can affort the write access through thefederation layer. However, consistency has tobe weighed against overhead and performancepenalties.

– A functional and performant architecturecan only be achieved through a combinationof different integration techniques based onconfiguration-item-specific grouping.

Diese beinhalten einerseits notwendige Informa-tionen für die aufzubauende, umfassende CMDB,sollen aber andererseits in ihrer ursprünglichenUmgebung möglichst unverändert erhalten bleiben.

Diese Situation ist auch im konkreten Anwen-dungsfall von Siemens IT Solutions and Servicesgegeben. Hier soll sowohl die abteilungsübergrei-fende Zusammenführung von CI-bezogenen Datenaus gewachsenen, Siemens-internen Altsystemenals auch die Anbindung von Systemen externerKunden auf einer einheitlichen, globalen Ebene

ermöglicht werden. Während bei Siemens-internenSystemen über eine kontrollierte Einschränkungder Autonomie zur Reduzierung der Heterogenitätnachgedacht werden kann, stellen die bei Kundenangesiedelten Systeme diesbezüglich eine besondereHerausforderung dar. Die zu erzielende globaleSchicht soll neben einer angemessenen Mächtigkeitim Sinne von schreibendem und lesendem Zugriffauf die anzuschließenden Altsysteme auch akzep-table Zugriffszeiten und leichte Erweiterbarkeitmiteinander vereinen.

Zielsetzung des Artikels ist es, anhand derbestehenden vielfältigen Anforderungen zunächstdie Marktsituation im Bereich föderierter CMDB-Lösungen darzulegen und auf noch offene Aspektein diesen Produkten hinzuweisen. Darauf aufbauendwerden vom wissenschaftlichen Standpunkt ausLösungsansätze grob klassifiziert. Eine Kombi-nation der verschiedenen Ansätze wird skizziert,sodass eine fallspezifische Optimierung des Zu-griffsverhaltens möglich wird. Die verschiedenenIntegrationsvarianten lassen sich prinzipiell mitexistierenden Produkten großer Datenbanksys-temanbieter realisieren, sind jedoch nicht auf dasAnwendungsfeld der CMDB zugeschnitten. Aus-gangspunkt der vorliegenden Studie waren diekonkreten Systemanforderungen bei Siemens ITSolutions and Services. Im Forrester-Report in [27]werden allerdings die wesentlichen hier genanntenAnforderungen bestätigt, sodass die Studie auchüber den lokalen Kontext hinaus von Interesse seindürfte.

Insgesamt sind die Begrifflichkeiten der CMDB-Hersteller in der Eigenwerbung uneinheitlich und imVergleich zur Fachliteratur teilweise irreführend. Esist notwendig, einheitliche Begriffe und Definitionenvorzugeben und die Produktinformationen diesenunterzuordnen.

Die zentralen Anforderungen an eine CMDBund die wichtigsten Fachbegriffe werden im Ab-schnitt „Anforderungen und Begriffsklärung“erläutert. Im Abschnitt „Bewertung der auf demMarkt befindlichen CMDB-Produkte“ wird alserster Lösungsansatz eine föderierte CMDB, wie sieauf dem Markt angeboten wird, ins Auge gefasst.Die verfügbaren Produkte werden vorgestellt undhinsichtlich der kritischen Leistungsanforderun-gen evaluiert. Im Abschnitt „WissenschaftlicheLösungsansätze“ werden aus wissenschaftlicherSicht mögliche Lösungsansätze und damit ver-

Informatik_Spektrum_33_4_2010 353

CONFIGURATION-MANAGEMENT-DATENBANKEN

bundene Zielkonflikte charakterisiert. Zur grobenKlassifikation wird danach unterschieden, ob einglobaler Schreibzugriff ermöglicht werden soll undob Daten auf globaler Ebene physisch vorgehaltenwerden sollen. Auf dieser Basis werden vier Ansätzeunterschieden: föderierte Datenbanksysteme, Data-Warehouse-Systeme, virtuelle Datenintegration undföderierte Datenbanksysteme in Kombination mitglobaler Materialisierung. Zur Optimierung dergegebenen Anforderungen erscheint eine Kombina-tion der verschiedenen Ansätze mit der Möglichkeitzur individuellen Konfiguration für verschiedeneCI-Gruppen sinnvoll. Abschließend wird im letztenAbschnitt eine Zusammenfassung des Beitrags mitAusblick auf weitere nötige Schritte gegeben.

Anforderungen und BegriffsklärungMithilfe einer CMDB soll bei Siemens IT Solutionsand Services eine Infrastruktur entstehen, die einentransparenten, globalen Zugriff auf CI-Daten er-möglicht. Dabei sollen bei globalen Zugriffeneinerseits kurze Antwortzeiten erreicht werden,andererseits sollen aber auch redundante Daten inden verschiedenen Quellsystemen konsistent ge-halten werden. Darüber hinaus soll der notwendigeWartungsaufwand für Systemerweiterungen undModifikationen minimiert werden. Diese Zielset-zungen verhalten sich teilweise gegenläufig, sodasseine Kompromisslösung gefunden werden muss.

Nachfolgend werden einige kritische Punkte desprojektspezifischen Anforderungskataloges vorge-stellt sowie Grundbegriffe verteilter Datenhaltungeingeführt.

AnforderungskatalogDer Anforderungskatalog von Siemens IT Solutionsand Services an die CMDB-Infrastruktur umfasstinsgesamt 19 Kernpunkte. Von diesen werden indiesem Artikel vier Anforderungen herausgegriffen,die als besonders kritisch bezüglich der Konsequen-zen für die Systemarchitektur angesehen werdenkönnen:

– Schreibender Zugriff über die CMDB auf dieangeschlossenen Komponentensysteme: Überdie CMDB-Schicht sollen sowohl Lese- als auchSchreibzugriffe auf die Daten der angeschlossenenlokalen Systeme ermöglicht werden.

– Zusammenführung vertikaler und horizontalerFragmentierungen, d. h. die Attribute eines CI-

Typs stehen in verschiedenen lokalen Systemenund sollen durch die CMDB zusammengeführt zurVerfügung stehen (vertikale Zusammenführung)oder verschiedene CRs eines CI-Typs stehen inverschiedenen lokalen Systemen und sollen durchdie CMDB zusammengeführt zur Verfügung stehen(horizontale Zusammenführung).

– Duplikaterkennung: Redundante Datensätze einesCI-Typs stehen in verschiedenen lokalen Systemenund sollen durch die CMDB überlappungsfreizusammengeführt zur Verfügung stehen.

– Konsistenzerhaltung: Die Konsistenz der an-geschlossenen Komponentensysteme undder CMDB muss erhalten bleiben. Die ACID-Eigenschaften globaler und lokaler Transaktionen,welche in [13, S. 289f.] erläutert werden, sollengewährleistet werden.

Der schreibende Zugriff wird explizit gefordert,um die automatisierte Abarbeitung von Aufträgenim Rahmen des ITIL-Prozesses Request Fulfillmentzu ermöglichen. Dies beinhaltet insbesondere dasAnlegen, Ändern und Löschen von CI-bezogenenDaten.

Föderierte DatenbanksystemeAls erster offensichtlicher Lösungsansatz kommteine föderierte CMDB im Sinne eines föderier-ten Datenbanksystems infrage. Ein föderiertesDatenbanksystem (FDBS) ist nach [26, S. 235] als„ein System, das Operationen auf Datenbankenermöglicht, die durch autonome und ggf. heterogeneDatenbankmanagementsysteme verwaltet werden“definiert (eigene Übersetzung).

Beim Aufbau eines FDBSs wird eine globale,föderierte Schicht gebildet, die sowohl lesenden alsauch schreibenden Zugriff auf die angeschlossenenDatenbanksysteme bietet. Die lokalen Daten-banksysteme werden aufgrund dessen auch alsKomponentensysteme bezeichnet.

Neben den föderierten Datenbanken sind grund-sätzlich auch andere Formen der verteilten Daten-verwaltung umsetzbar. In Abb. 1 wird eine grobeEinteilung der Alternativen aufgezeigt. Hier wirdunterschieden, ob ein globaler Zugriff auf alle lo-kalen Systeme über eine zusätzliche, globale Ebeneermöglicht werden soll oder ob eine Datenpropa-gierung der lokalen Systeme über Punkt-zu-Punkt-Verbindungen ausreicht. Wird der Aufbau einer zu-sätzlichen, globalen Schicht gewünscht, so kann über

354 Informatik_Spektrum_33_4_2010

Abb. 1 Varianten der verteilten Datenverwaltung

diese ein rein lesender Zugriff auf die Komponen-tensysteme zu Analyse- oder Monitoring-Zweckengenügen oder die Unterstützung sowohl von Lese- alsauch von Schreiboperationen realisiert werden. Inbeiden Fällen können die Daten der lokalen SystemesowohlphysischaufdieglobaleSchichtrepliziertoderweiterhin rein lokal gehalten werden. Bei letzterer Va-riante wird eine logische, globale Ebene konzipiert,die sämtliche Anfragen an die Komponentensystemedurchreicht. Diese Realisierungsmöglichkeiten füreinen globalen Zugriff müssen nicht als Alleinlösungumgesetzt werden, sondern können für Daten mit un-terschiedlichen Anforderungen auch in KombinationAnwendung finden.

Zudem sind neben den hier genanntenKlassifikationsmerkmalen für verteilte Datenhal-tungssysteme noch weitere Merkmale bekannt, diebeispielsweise in der Klassifizierung von Brightet al. [6] aufgeführt werden. Auf eine detaillierteKlassifikation wird hier verzichtet, da hier le-diglich anforderungsgetrieben nach passendenIntegrationsarten gesucht wird.

Föderierte CMDBAuf der Suche nach einer Definition für eineföderierte CMDB, stößt man auf eine Vielzahl un-terschiedlicher Auffassungen. Eine Auswahl vonvier Varianten demonstriert die Diskrepanzen infolgender Gegenüberstellung:

– Die CMDBf-Arbeitsgruppe, nach Clark et al. [11]ein Zusammenschluss aus CA, Microsoft, IBM,BMC-Software, Fujitsu und HP, spezifiziert eineföderierte CMDB in [10, S. 5] als „Sammlungvon Diensten und Datenrepositorien, die Datenzur Konfiguration und andere Datensätze überRessourcen enthalten“ (eigene Übersetzung). AlsRessource werden dabei CIs, Prozessartefakte undBeziehungen gesehen.

– In [2, S. 3] wird der föderierte CMDB-Ansatzwie folgt erläutert: „Daten, die in der CMDBgespeichert werden sollten, werden von solchengetrennt, die das nicht sollten“ beziehungsweise„Die Verknüpfung der CMDB mit externen Datenbeschreibt das Konzept der Föderation und bildetdie Grundlage für eine föderierte CMDB“ (eigeneÜbersetzung).

– Madduri et al. [23, S. 441, 447] stellen im IBMSystems Journal als weitere Option Folgendes fest:„Die CMDB kann entweder eine einheitliche Da-tenbank sein oder eine föderierte Datenbank, eineSammlung von Datenbanken mit einer einzigenBenutzerschnittstelle“. Und ferner: „Durch dieFöderation [...] erscheinen verteilte Daten, alsob sie aus einer Quelle kämen, unabhängig vonSpeicherort, Format und Zugriffssprache“ sowie„Föderation bringt Daten nicht physisch in daszentrale Repositorium“ (eigene Übersetzung).

– Am kompaktesten ist die Definition der Conti-nental Software GmbH: „Unter einer föderierten(federated) CMDB versteht man eine logischeDatenbank, deren Inhalte über verschiedeneDatenquellen verteilt sind“ [12].

Während die von der CMDBf-Arbeitsgruppeerwähnte „Ansammlung“ einige Interpretations-möglichkeiten offen lässt und keine Aussagenhinsichtlich einer physischen oder logischen Um-setzung auf einer globalen Ebene tätigt, geht [2] voneiner größtenteils physischen Speicherung der Da-ten auf der globalen Ebene aus. Lediglich detaillierteoder mit den CIs in Verbindung stehende, zusätzli-che Daten sollen aus externen Quellen logisch an dieglobale CMDB angebunden werden.

Madduri et al. [23] differenzieren im IBMSystems Journal, ob eine CMDB für globale Zu-griffsszenarien physische Replikation einsetzt odereinen logischen globalen Zugriff per Föderationrealisiert. Der Begriff der Föderation ist hier amklarsten definiert, dennoch wird nur die Bezeich-nung „Quelle“ verwendet. Im Kontext der FDBSeunterstreicht normalerweise die Verwendung derBezeichnung „Komponentensystem“ für die lokalenSysteme, dass nicht nur der lesende Zugriff, sondernauch föderative Schreiboperationen erforderlichsind. Da das CMDB-Produkt von IBM die lokalenSysteme letztlich auf Quellen reduziert und nurlesenden Zugriff bietet, wird dies einer Föderationim Sinne von FDBSen nicht gerecht.

Informatik_Spektrum_33_4_2010 355

CONFIGURATION-MANAGEMENT-DATENBANKEN

Jede der aufgeführten Definitionen beinhalteteine partielle Charakterisierung einer föderiertenCMDB. In der Summe verdeutlichen die Beschrei-bungen die Vielfalt der Anforderungen an eineCMDB.

Im Folgenden werden die Produkte derCMDB-Hersteller im Hinblick auf die als kritischidentifizierten Anforderungen evaluiert.

Bewertung der auf dem Markt befindlichenCMDB-Produkte

Zur Bewertung der verschiedenen CMDB-Produkteerfolgten Umfragen bei den großen CMDB-Herstellern BMC, CA, HP und IBM. Die Antwortenwurden zusammen mit öffentlich verfügbaren In-formationen zu den jeweiligen Produkten geprüftund bilden so die Basis nachfolgender Evaluations-ergebnisse. Da die teilweise freitextlichen Antwortender Hersteller noch etwas Interpretationsspielraumoffen lassen, wurde auf eine tabellarische Gegen-überstellung verzichtet, um die Ergebnisse nicht zuverfälschen. Stattdessen werden die entsprechendenAntworten hier im genauen Wortlaut wiedergeben.

BMC Atrium CMDBDas Produktdatenblatt BMC Software [3] konsta-tiert, dass die BMC Atrium CMDB „als zentralesDaten-Repository zum Speichern oder Abrufen vonKonfigurationsdaten“ für verschiedenste IT-Toolsdient.

Der schreibende Zugriff wird als Zielsetzungnicht erwähnt, wozu BMC in der Umfrage wie folgtantwortete: “With BMC Atrium CMDB version 2.x,information related to a configuration item canbe obtained” (Mit der BMC Atrium CMDB kannman Informationen zu Configuration Items ein-holen). Demnach wird das Abfragen der Datenaus lokalen Systemen, nicht aber das Schreiben,unterstützt. Zudem verfolgt die BMC Atrium CMDBeinen weitgehend zentralisierten Ansatz, der diein einer Vielzahl von IT-Datenbeständen vorkom-menden CI-Daten in einen physisch zentralisiertenDatenbestand überführt.

Zwar wird sowohl in [3] als auch titelge-bend in [2] von Föderation und somit vonVerknüpfung der CMDB mit externen Daten ge-sprochen, allerdings wird dies nur für besondersdetaillierte oder verwandte CI-Informationenin sehr einfacher Form angestrebt. Die hiergeforderten Föderationskonzepte, wie beispiels-

weise die Fragmentierungszusammenführung,werden offenbar nicht unterstützt. Dazu ant-wortete BMC in der Umfrage: “Federated datacannot be reconciled or harmonized by thecore BMC Atrium CMDB” (Föderierte Da-ten können durch die BMC Atrium CMDBnicht zusammengeführt oder harmonisiertwerden).

Auch die Duplikaterkennung wird dem Benut-zer überlassen, der sogenannte benutzerdefinierteGeschäftsregeln anlegen muss, die einfache Gleich-heitstests unterstützen. Konsistenzerhaltung bildetkeinen Kernpunkt, was sich aufgrund des fehlendenSchreibzugriffs erklärt. In [3, S. 3] finden sich zwareine kurze Erwähnung von manuell definierbarenIntegritätsprüfungen sowie Regeln für den Daten-austausch zwischen der BMC Atrium CMDB undanderen Anwendungen (was offensichtlich demBenutzer überlassen wird), der Funktionsumfangder definierbaren Integritätsprüfungen bleibt jedochunbekannt.

CA CMDBCA definiert sein CMDB-Produkt in [8] im ein-leitenden Überblick als „eine spezielle Datenbankfür Configuration Items, eine Beschreibung derBeziehungen und eine zentrale Datenquelle, umAuswirkungen von Änderungen zu analysieren“.Genau diese Ansicht wird auch beim Studium deranderen Quellen [7, 24] vermittelt: Die CA CMDBzielt auf die Visualisierung und Navigation der CI-bezogenen Daten und deren Beziehungen für dasChange-Management. Schwerpunkt ist die prospek-tive Analyse der Auswirkungen bei der Planung vonVeränderungen. Ein Schreibzugriff über die CMDB-Schicht auf lokale Systeme ist nicht Gegenstand derCA CMDB.

Die „Integration mehrerer CI-Datenquellendurch Duplizieren und/oder Verknüpfen der Datenvon einer Quelle in die CMDB“ [24, S. 7] wird mitExtract-Transform-Load-Verfahren (ETL) realisiertund unter dem Begriff „Zusammenführung“ alsLeistungsmerkmal der CA CMDB genannt.

Die kritischen Anforderungen der Fragmentie-rungszusammenführung und Duplikaterkennungsind im Leistungsspektrum der CA CMDB amehesten unter dem Stichpunkt „Abstimmung“ zufinden. So kann z. B. die Notwendigkeit vertika-ler Fragmentierungszusammenführung in [24,S. 7] in die Aussagen interpretiert werden: „Die

356 Informatik_Spektrum_33_4_2010

Attributinformationen eines CIs stammen oft ausmehreren Quellen “ und in Folge dessen „arbeitetdie CMDB am effektivsten, wenn sie Informatio-nen aus mehreren Quellen [...] zusammenführenund aufeinander abstimmen kann“. Dass dieseAbstimmung viele Ressourcen in Anspruch neh-men kann, wird erkannt, weshalb der Bedarf fürAutomatisierungsunterstützung in diesem Bereichhervorgehoben wird. Allerdings wird im weiterenVerlauf angemerkt [24, S. 10], dass in der CA CMDBeine automatische Abstimmung nur mit bereinigtenund konsistenten Daten vorgenommen werdenkann und dass diese bei Inkonsistenzen in derNamensgebung fehlschlägt. Dies impliziert, dass derBenutzer vor der Zusammenführung der CIs ausunterschiedlichen Quellen sämtliche Namensgebun-gen manuell auf einen konsistenten Stand bringenmuss, bevor die automatisierte Abstimmung der CACMDB mittels Gleichheitstests starten kann. Dies istschon bei einer geringen Anzahl an anzubindendenlokalen Systemen mit einem enormen Aufwandverbunden und somit praktisch kaum umsetzbar.

Konsistenzerhaltung im Sinne der gefordertenACID-Transaktionen wird aufgrund des fehlendenschreibenden Zugriffs nicht verfolgt. In [9, S. 3]findet sich lediglich eine Beschreibung zweier Mög-lichkeiten zur Synchronisation der CA CMDB mitdem Realsystem unter Verwendung mitgelieferterErkennungstools. Bei der normativen Methodeist die CMDB stets für den gewünschten Konfi-gurationszustand führend. Es gibt jedoch keineautomatische Datensynchronisation zwischen denCI-Daten der CMDB und den de-facto Konfiguratio-nen im Realsystem. Unterschiede werden durch dieErkennungstools aufgespürt, müssen aber manuellausgeglichen werden. Bei der Echtzeitmethode istdas Realsystem stets führend für die gewünschtenKonfigurationen. Ein Korrekturabgleich der CMDBauf Basis der durch die Erkennungstools geliefertenDaten erfolgt kontinuierlich und dient der Übersichtüber das System. Wegen des fehlenden Schreibzu-griffs wird die CA CMDB den hier aufgeführtenAnforderungen dennoch nicht gerecht.

HP Universal CMDBDie frei verfügbare Information zur HP UniversalCMDB ist sehr begrenzt. Als einzige Quelle, nebensehr kurz gehaltenen, marketingorientierten Daten-blättern, ist HP [14] frei zugänglich. Hier wird gleichzu Beginn erwähnt, dass die HP UCMDB gemeinsam

mit der HP Discovery and Dependency MappingSoftware in enger Verbindung steht.

Föderation und Integration finden in [14, S. 10f.]Erwähnung, wobei dies durch das sogenannteHP UCMDB Web-Services-Based Software Devel-opment Kit ermöglicht werden soll. Es wird hierzwar allgemein von CI-Bereinigung mittels der HPUCMDB gesprochen, detaillierte Aussagen fehlenjedoch. In der Umfrage sprach HP zudem von einer„Eliminierung der Möglichkeit von Duplikaten“,auf deren technische Umsetzung allerdings nichteingegangen wird. Ziel der initial formuliertenAnforderungen war es auch nicht, die „Möglichkeitvon Duplikaten“ zu eliminieren, sondern beste-hende und entstehende Duplikate zu erkennen undzusammenzuführen.

In einer Demonstration durch HP-Berater fürSiemens IT Solutions and Services stellte sich zudemheraus, dass der schreibende Zugriff über die CMDBauf die angeschlossenen Komponentensystemenicht durch die HP UCMDB möglich ist und auchzukünftig nicht umgesetzt werden soll.

IBM CCMDBIBM stellt seine Service Management Architekturim Allgemeinen [22] und die hierin enthalteneCCMDB im Speziellen [23] ausführlich im eigenenIBM Systems Journal vor. Für detaillierte Informa-tionen bietet sich die Installationsdokumentationzur CCMDB [19] sowie für Fragen der Umsetzungvon Zusammenführung und Duplikaterkennungin der CCMDB die Dokumentation des hierfürverantwortlichen Tivoli Application DependencyDiscovery Managers (TADDM) in [20] an. DerTADDM ist integraler Bestandteil der CCMDBund für CI-Erkennungs- und Integrationsaufgabenzuständig.

In [22, S. 429f.] wird eine CMDB als Repo-sitorium definiert, welches Konfigurations- undBeziehungsinformationen über Ressourcen verwal-tet. Des Weiteren wird angegeben, dass die CMDBin der IBM Service Management Architektur fol-gende Schlüsselfunktionen anbietet: Erkennung,Anwendungsmapping und Visualisierung sowieFöderation und Bereinigung, autorisierte Quellefür die Konfigurationsattribute und schließlichZugriffskontrolle.

Zu den im vorliegenden Anwendungsfall alsbesonders kritisch identifizierten KernpunktenFöderation, Bereinigung und Zugriffskontrolle sind

Informatik_Spektrum_33_4_2010 357

CONFIGURATION-MANAGEMENT-DATENBANKEN

in [23] weitere Informationen verfügbar. Hier wirdauf S. 447 ausgesagt, dass die CCMDB neben derphysischen Speicherung der Daten auch einen logi-schen, föderierten Zugriff auf Komponentensystemeermöglicht. Die Bereinigung der CI-Daten erfolgtferner mithilfe von durch den Benutzer definierten,priorisierten Namensregeln, wobei anschließenddarauf hingewiesen wird, dass dennoch Dupli-kate existieren können, bis entsprechend genauereInformationen bereitgestellt werden.

Bezüglich des schreibenden Zugriffs kannMadduri et al. [23, S. 443] herangezogen werden.Hier wird ausgesagt, dass „die API nur aus einereinzigen Methode (genannt find) besteht, welchezur Traversierung und Suche von Daten genutztwird“. Diese kann als ein Filter in der SQL-ähnlichenSprache MQL (Model Query Language) aufgefasstwerden, welchen die CCMDB in wirkliche SQL-Ausdrücke übersetzt. Folglich werden auch hier nurAnfragen und keine Updates über die föderierteCMDB-Schicht unterstützt.

Zur weiteren Eruierung der Bereinigungsmög-lichkeiten mittels priorisierter Namensregeln wurdein der TADDM-Dokumentation [20] (IBM TADDM– Verwendung – Information zu Datenabgleichund Priorisierung) recherchiert. Die Funktion zurPriorisierung von Attributen wird hier als Prioritäts-vergabe an Datenquellen erläutert, sodass mithilfebenutzerdefinierter Regeln beschrieben wird, welcheDatenquelle bezüglich des betrachteten Attributsvor anderen Vorrang hat. Es erfolgt allerdings einHinweis, dass eine Priorisierung „nur zwischenzwei Konfigurationselementen angewendet werden[kann], die vom System als dasselbe Element er-kannt werden“. Diese Erkennung findet allerdingsnur statt, „wenn die zur Benennung der Regelattri-bute übergebenen Attributwerte übereinstimmen“.Daraus folgt, dass auch hier nur ein Gleichheitstestzur Duplikaterkennung angeboten wird, der zudemmit vom Benutzer definierten Regeln bedient werdenmuss.

Passenderweise schließt sich in [20] sofort einKapitel an, welches die manuelle Zusammenfüh-rung von Konfigurationselementen erläutert („Diegetrennte Anzeige der CIs beweist, dass sich ihreNamensregeln nicht überschneiden, und dass dieCIs in Bezug auf TADDM unterschiedlich sind.“).Hier wird es dem Benutzer ermöglicht, zwei odermehrere in der TADDM-Produktkonsole als ver-schieden angezeigte Konfigurationselementobjekte

in ein einziges Element zusammenzuführen. Aus derListe der zusammenzufassenden CIs wird dazu einesals permanentes CI ausgewählt, in welches dannnur die Attribute, die im permanenten CI selbstnoch nicht vorhanden sind, aus den restlichen CIsübertragen werden – danach werden die restlichenCIs gelöscht.

Nach intensiver Recherche der von IBM bereit-gestellten Informationen kann darauf geschlossenwerden, dass auch die IBM CCMDB keine Ähn-lichkeitstests zur Duplikaterkennung bereitstellt,sondern in diesem Bereich auf viel Benutzerin-tervention setzt. Der schreibende Zugriff über dieföderierte CMDB-Schicht wird auch hier nichtgeboten.

Zusammenfassung der ProduktevaluationDie auf dem Markt befindlichen CMDB-Lösungenerfüllen die betrachteten Kernanforderungenteilweise gar nicht oder nicht im erwarteten Ausmaß.

Der schreibende Zugriff über die globale Schichtauf die lokalen Systeme wird von keinem der eva-luierten Produkte unterstützt. Möglichkeiten zurBereinigung im Sinne von Fragmentierungszusam-menführungen und Duplikaterkennung werdenteilweise gar nicht verfolgt oder nur über konsistenteNamensgebungen bzw. einfache Gleichheitstestsmit einem hohen Ausmaß an Benutzerinterventionermöglicht. Ähnlichkeitsalgorithmen finden keineAnwendung. Die Konsistenzerhaltung der Produktebeschäftigt sich aufgrund des fehlenden globalenSchreibzugriffes nicht mit den geforderten ACID-Eigenschaften von Transaktionen, sondern vielmehrmit der Synchronisation von CMDB und Erken-nungstools, wie bei der CA CMDB, oder mit manuellvom Benutzer definierten Integritätsprüfungen, wiebei der BMC Atrium CMDB.

Die Diskrepanz zwischen den Anforderun-gen von Siemens IT Solutions and Services unddem Leistungsspektrum der vorgestellten CMDB-Produkte ist darauf zurückzuführen, dass dieCMDB-Hersteller eine andere Sichtweise auf dievon einer CMDB bereitzustellende Funktionalitätvertreten. Aus Sicht der CMDB-Hersteller muss eineCMDB maßgeblich die Visualisierung der CIs undderen Beziehungsnetz untereinander zu Monito-ringzwecken unterstützen. Ein global schreibenderZugriff ist bei dieser Zielsetzung nicht vonnötenund wird deshalb von den Herstellern auch nichtverfolgt.

358 Informatik_Spektrum_33_4_2010

Wegen der marketingspezifischen Orientie-rung vieler im Internet verfügbarer Informationenbleiben noch einige Fragen hinsichtlich der techni-schen Umsetzung und des Genauigkeitsgrades derbeschriebenen Leistungsmerkmale verschiedenerCMDB-Lösungen offen. So ist beispielsweise meistnicht bekannt, wie Fragmentierungszusammenfüh-rungen und Duplikaterkennung genau vonstattengehen oder auf Basis welcher Replikationskon-trollform wann und wie oft die Synchronisationzwischen den Daten in den lokalen Systemen undden global materialisierten Daten vorgenommenwird.

Im Allgemeinen beschreiben die Herstellermit ihren CMDB-Lösungen nur das jeweiligeEndprodukt; wie allerdings der Weg dahinführt, die CMDB-Produkte in einer gegebenenIT-Infrastruktur in den operativen Einsatz zu über-führen und wie beispielsweise die semantischeIntegration erfolgen soll, bleibt offen. Um folglichdie CMDB-Lösungen der Hersteller einsetzen zukönnen, besteht zusätzlich die Notwendigkeit einesVorgehensmodells, das den Integrationsprozess unddie Überführung in ein operatives CMDB-Systembeschreibt.

Wissenschaftliche LösungsansätzeDa die auf dem Markt befindlichen CMDB-Produkteaufgrund abweichender Zielsetzungen den gefor-derten globalen Schreibzugriff nicht bereitstellen,wurde vor dem Hintergrund der wissenschaftli-chen Fachliteratur zur verteilten Datenverwaltunguntersucht, welche Lösungsansätze im vorliegen-den Fall grundsätzlich infrage kommen. Der imAbschnitt „Anforderungskatalog“ vorgestellteAnforderungskatalog beinhaltet typische gegen-läufige Zielsetzungen der verteilten Datenhaltung.So ist die Konsistenzsicherung auf globaler Ebeneim Allgemeinen nicht mit der Autonomie der zuintegrierenden Teilsysteme vereinbar. Lesezu-griffe lassen sich beschleunigen, wenn auf dieSynchronisation im Rahmen verteilter Trans-aktionen verzichtet wird. Es ist also immer eineKompromisslösung zu finden, die für ein gegebenesLastprofil zu optimieren ist. Ausgangspunkt dernachfolgenden Überlegungen ist daher, dass die vierKernanforderungen nicht für alle CIs gleichermaßengelten.

Werden beispielsweise CIs über die globaleEbene ausschließlich gelesen, so ist eine föderierte

CMDB nach Herstellerverständnis grundsätzlicheinsetzbar. Ein Beispiel hierfür ist der globale Abrufvon Daten zu bereits abgeschlossen Kundenverträ-gen. Diese können im Nachhinein ohnehin nichtgeändert werden, sodass in diesem Fall auch der reinlesende Zugriff ausreicht.

Verzichtet man grundsätzlich auf den globalenSchreibzugriff, so müssen sich die föderiertenCMDBen dem Vergleich mit Data-Warehouse-Systemen und den in diesem Kontext verfügbarenETL-Werkzeugen zur Datenintegration stellen. ETLbeschreibt dabei die drei wesentlichen Schritte derDatenbeschaffung aus heterogenen Quellsystemen:Extraktion, Transformation und Laden.

Föderierte Datenbanksysteme (FDBSe) bietendie Möglichkeit, auch auf globaler Ebene Schreib-zugriffe zuzulassen. Wenn nichts über die Semantikder konkurrierend zu ändernden CIs bekannt istund darüber hinaus die Transaktionskonsistenz aufglobaler Ebene gewünscht wird, so ist sind teureVerfahren zur Nebenläufigkeitskontrolle und einatomares Freigabeprotokoll auf globaler Ebene diezwangsläufige Konsequenz. Globale Serialisier-barkeit geht aber mit einer Verschlechterung desAntwortzeitverhaltens einher [5, 25, Kapitel 12.5],darüber hinaus ist bei der Synchronisation repli-zierter Daten besonders für Schreibzugriffe eineverminderte Verfügbarkeit zu erwarten. Der Bedarffür einen globalen Schreibzugriff ist aber zwei-fellos da. Bei Personendaten ist es beispielsweisehäufig der Fall, dass zu einer Person in mehrerenAbteilungssystemen Daten geführt werden undÄnderungen synchronisiert werden müssen. Umin dieser Situation geeignete Kompromisslösungenfinden zu können, ist es sinnvoll, das verfügbareAnwendungswissen über die CIs auszunutzen, umden Aufwand zu reduzieren. Ziel ist es, die CIs nachihren spezifischen Eigenschaften zu gruppieren undfür jede CI-Gruppe eine entsprechend optimierteIntegrationslösung zu konfigurieren.

Bei der Zusammenführung mehrerer au-tonomer, heterogener Datenquellen stellt sichzunächst die Frage, ob eine globale Ebene alsintegrierte, gemeinsame Schnittstelle zu den lo-kalen Systemen überhaupt benötigt wird, oderob gegebenenfalls eine Peer-to-Peer-Architektur(P2P) mit bilateralem Datenaustausch zwischen denKomponentensystemen ausreicht. Im vorliegendenAnwendungsszenario von Siemens IT Solutionsand Services ist eine globale Ebene obligatorisch,

Informatik_Spektrum_33_4_2010 359

CONFIGURATION-MANAGEMENT-DATENBANKEN

weshalb ein P2P-Datenbanksystem, wie es z. B.in [4] vorgeschlagen wird, keine Lösungsalternativedarstellt.

Eine weitere Abgrenzung erfolgt gegenüberLösungen ohne ein globales Schema. Ein globalerZugriff kann entweder über ein einheitliches, globa-les Schema oder auch über einen losen Verbund mitIntegration auf Anwendungsebene erreicht werden.Man spricht im ersten Fall von einem FDBS, im zwei-ten Fall handelt es sich um Multidatenbanksysteme(MDBSe). MDBSe bieten keine Verteilungstrans-parenz, keine semantische Integration und keineAnfragezerlegung. Diese Aspekte müssen vomAnwendungsprogrammierer explizit im Rahmender Datenbankanfragen geleistet werden [4, S. 6].Durch den Verzicht auf das globale Schema wirdbeim MDBS-Ansatz der hohe Aufwand vermieden,den die notwendige ständige Pflege eines globalenSchemas mit sich bringt. Der Verzicht auf ein glo-bales Schema bei MDBSen bedeutet allerdings, dassdie vorhandene Schemaheterogenität auf globalerEbene sichtbar wird. Dies widerspricht dem Zielder globalen Integration von Siemens IT Solutionsand Services. Im vorliegenden Anwendungsfallwird daher eher ein FDBS und kein MDBS ange-strebt, damit die global verfügbare Information zueinem CI stets demselben globalen Schema folgt,unabhängig davon, aus welchem lokalen System dieInformation entstammt. Die globale Schemainte-gration ist ein Ziel, das nur durch kontinuierlicheAnstrengungen aller Beteiligten erreichbar ist. Dassauf lokaler Ebene stets zusätzliche Information zueinem CI existiert, die unabhängig von der globalbereitgestellten Information auf beliebige Art undWeise verwaltet werden kann, bleibt in jedem Fallunangetastet.

Die CI-individuelle Betrachtungsweise erfordertalso für jedes CI ein global einheitlich gültigesSchema, das die jeweils für die globale Ebenerelevanten CRs umfasst. Differenziert wird dahinge-hend, ob der Schreibzugriff „nur lokal“, „nur global“oder konkurrierend „global und lokal“ erfolgen soll.Eine Übersicht des Lösungsspektrums ist in Abb. 2dargestellt.

Das Unterscheidungsmerkmal, ob der Schreib-zugriff „nur global“ oder konkurrierend „globalund lokal“ erfolgen kann, beeinflusst die benötigteQualität des technisch bereitzustellenden globalenSerialisierbarkeitsverfahrens. Daher sind die Inte-grationsvarianten nicht eigenständig benannt. Die

Abb. 2 Architekturvarianten der globalen Ebene

vier grundlegenden Integrationsvarianten werdenkurz beschrieben:

– Nicht global materialisiert und kein globales Schrei-ben (Virtuelle Datenintegration): Diese Variantewird von einigen der vorgestellten CMDB-Produkteangeboten. Die meisten CMDB-Hersteller lassenes offen, ob eine globale Materialisierung erfolgensoll oder nicht.

– Global materialisiert und kein globales Schrei-ben: Typische Vertreter dieser Klasse sindData-Warehouse-Systeme. Ein Data Warehousenach [1, S. 7] ist definiert als „eine physische Daten-bank, die eine integrierte Sicht auf beliebige Datenzu Analysezwecken ermöglicht“. Auch einige dervorgestellten CMDB-Produkte bieten über derenCMDB-Schicht einen reinen Lesezugriff unterZuhilfenahme globaler Replikation. Allerdingssteht hier im Gegensatz zu den Data-Warehouse-Systemen nicht der Aspekt der Analyse, sondernvielmehr das Monitoring im Vordergrund.

– Nicht global materialisiert und globales Schreiben:Eine logische Integration wird in föderierten Da-tenbanksystemen (FDBSen) präferiert. Ein FDBSist ein System, das Operationen auf Datenbankenbereitstellt, welche von autonomen und möglicher-weise heterogenen Datenbanksystemen verwaltetwerden.

– Global materialisiert und globales Schreiben: Alsletzte Variante ist es denkbar, die zu integrie-renden Daten mittels Replikationsmechanismenphysisch auf die globale Ebene zu kopieren, umso in Kombination mit der FDBS-Funktionalitäteinen globalen Schreibzugriff zu erreichen. ZurKonsistenzerhaltung der Replikate muss dann einVerfahren zur Replikationskontrolle angewandtwerden (vgl. [21, S. 76ff.]).

360 Informatik_Spektrum_33_4_2010

Um die CIs entsprechend ihrer spezifischen Anfor-derungen und Eigenschaften zu gruppieren undfür jede CI-Gruppe eine entsprechend optimierteIntegrationsvariante auszuwählen, soll in Zukunftein detaillierter Katalog an Bewertungskriterienerarbeitet werden, der eine gegenüberstellendeWertung erlaubt, welche über die hier dargestellteGrobwertung hinausgeht. So kann beispielsweise fürCIs, die auch auf globaler Ebene geändert werdensollen, der Synchronisationsaufwand reduziertwerden, wenn bekannt ist, dass ein Objekt nur ineinem bestimmten Quellsystem oder nur von einembestimmten Personenkreis modifiziert werden darf.Ebenso kann die Kenntnis der Änderungshäufigkeitoder des Änderungszeitpunkts zur Optimierungausgenutzt werden.

Ist die Gruppierung auf Basis der Kriterienlisteerfolgt, so kann ein föderiertes Datenbanksystementsprechend konfiguriert werden, sodass letztlicheine bedarfsorientierte Kompromisslösung erreichtwerden kann. Am Markt verfügbare relationaleDatenbanksysteme bieten heute bereits ein breitesSpektrum an Konfigurationsmöglichkeiten an,deren Umsetzung allerdings ein tiefes technischesVerständnis und ggf. einen hohen Aufwand er-fordert. Wünschenswert wären dialoggesteuerteWerkzeuge zur Datenbankadministration, die aufder Basis der CI-spezifischen Anforderungen diebedarfsorientierte Anpassung erleichtern.

Zusammenfassung und AusblickIn diesem Beitrag wurden anhand eines realenSzenarios von Siemens IT Solutions and ServicesAnforderungen an eine föderierte CMDB vorgestelltsowie deren Überdeckung in den CMDB-Lösungender Hersteller BMC, CA, IBM und HP analysiert.Hierbei stellte sich heraus, dass neben einem meistals hoch einzustufenden Ausmaß an benötigterBenutzerintervention für Fragmentierungszusam-menführung und Duplikaterkennung vor allembezüglich des schreibenden Zugriffs über die Fö-derationsschicht kein Hersteller die Anforderungenvon Siemens IT Solutions and Services erfüllenkonnte. Dies ist auf eine unterschiedliche Sichtweiseder CMDB-Hersteller auf das Leistungsspektrumeiner föderierten CMDB zurückzuführen. Die Ver-wendung der Bezeichnung „föderierte CMDB“für die hier untersuchten Produkte ist insofernirreführend, als dass das Spektrum der Integrations-mechanismen einer föderierten Datenbank weitaus

umfassender ist und im Allgemeinen auch einenglobalen Schreibzugriff beinhaltet.

Um unabhängig von den untersuchten Produk-ten zu untersuchen, wie der globale Schreibzugriffprinzipiell erreicht werden kann, wurden dieAlternativen der verteilten Datenverwaltunggrob klassifiziert und gegenübergestellt. Dabeiwurden föderierte Datenbanksysteme, Data-Warehouse-Systeme, virtuelle Datenintegrationund Kombinationsmöglichkeiten der FDBS-Funktionalität mit globaler Materialisierungunterschieden. FDBSe bieten im Allgemeinendie gewünschte Funktionalität, sind allerdingsteuer in Aufbau und Pflege sowie limitiert imAntwortzeitverhalten.

Eine Gruppierung der CIs im Rahmen der An-forderungsanalyse ist notwendig, um das Potenzialder Mechanismen zur verteilten Datenverwaltungbesser ausnutzen zu können. Dies beinhaltet ins-besondere die Unterscheidung nach nur lokaler,nur globaler sowie globaler und lokaler Schreib-möglichkeit. Die in diesem Beitrag skizzierteGruppierung bildet die Basis für einen umfas-senderen Kriterienkatalog, mit dessen Hilfe einebedarfsorientierte Konfiguration eines verteiltenDatenhaltungssystems unterstützt werden soll.

Literatur1. Bauer A, Günzel H (2004) Data Warehouse Systeme – Architektur, Anwendung,

Entwicklung. dpunkt.verlag, Heidelberg2. BMC Software (2005) Federation and a CMDB. http://documents.bmc.com/

products/documents/92/49/59249/59249.pdf (Abruf am 17. Oktober 2008)3. BMC Software (2006) BMC Atrium CMDB – Das Herzstück Ihrer IT-Infrastruktur.

http://documents.bmc.com/products/documents/32/11/63211/63211.pdf (Abrufam 17. Oktober 2008)

4. Bonifati A, Chrysanthis PK, Ouksel AM (2008) Distributed databases and peer-to-peer databases: Past and present. SIGMOD Record 37(1):5–11

5. Breitbart Y, Garcia-Molina H, Silberschatz A (1992) Overview of multidatabasetransaction management. Int J Very Large Data Bases (VLDB) 1(2):181–239

6. Bright MW, Hurson AR, Pakzad SH (1992) A taxonomy and current issues in mul-tidatabase systems. Computer 25(3):50–60

7. CA (2007a) Änderungen effizienter und erfolgreicher gestalten – CA CMB undÄnderungs-Management. http://www.ca.com/files/TechnicalDocuments/cmdb_change_tech_brief_de.pdf (Abruf am 17. Oktober 2008)

8. CA (2007b) CA CMDB r11.1. http://www.ca.com/files/ProductBriefs/ca_cmdb_pb_de.pdf (Abruf am 17. Oktober 2008)

9. CA (2007c) Implementierungsstrategien für die CMDB. http://www.ca.com/files/TechnicalDocuments/cmdb_impl_tech_brief_de.pdf (Abruf am 17. Oktober 2008)

10. Carlisle F, Day B, Donohoo S, Dublish P, Eisinger J, Goodman G, Hately A, John-son M, Kowalski V, Labrou Y, Morimoto K, Snelling D, Vambenepe W, WaschkeM, Wiles V, Wurster K (2008) CMDB Federation (CMDBf). http://cmdbf.org/schema/1-0-0/CMDBf_v1.0b.pdf (Abruf am 17. Oktober 2008)

11. Clark D, Dublish P, Johnson M, Kowalski V, Labrou Y, Negritoiu S, Vambenepe W,Waschke M, Wiles V, Wurster K (2007) The Federated CMDB Vision – A Joint WhitePaper from BMC, CA, Fujitsu, HP, IBM, and Microsoft. http://www.cmdbf.org/CMDB-Federation-white-paper-vision-v1.0.pdf (Abruf am 17. Oktober 2008)

12. Continental Software GmbH (2008) Föderierte (Federated) CMDB. http://www.continentalsoftware.com/federated-cmdb/ (Abruf am 17. Oktober 2008)

13. Härder T, Reuter A (1983) Principles of transaction-oriented database recovery.ACM Comput Surveys (CSUR) 15(4):287–317

Informatik_Spektrum_33_4_2010 361

CONFIGURATION-MANAGEMENT-DATENBANKEN

14. HP (2008) An insider’s view tot he HP Universal CMDB – A technical white paper.http://www.rubiksolutions.com/Admin/Public/DWSDownload.aspx?File=%2FFiles%2FFiler%2FPDF+UCMDB%2FUcmdb_whitepaper.pdf (Abruf am 17. Oktober2008)

15. Hochstein A, Zarnekow R, Brenner W (2004) ITIL als Common-Practice-Referenz-modell für das IT Service Management – Formale Beurteilung und Implikationenfür die Praxis. Wirtschaftsinformatik 46(5):382–389

16. ITIL (2008a) What is ITIL? http://www.itil-officialsite.com/AboutITIL/WhatisITIL.asp(Abruf am 12. August 2008)

17. ITIL (2008b) Core OGC Titles. http://www.itil-officialsite.com/Publications/Core.asp(Abruf am 12. August 2008)

18. ITSMF (2007) ITIL V3 Glossar. http://www.best-management-practice.com/officialsite.asp?FO=1230366&action=confirmation&tdi=575004 (Abruf am17. Oktober 2008)

19. IBM (2008) Planning and Installing Change and Configuration ManagementDatabase. http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/topic/com.ibm.ccmdb.doc_7.1.1/reference/ccmdb_plan_install.pdf (Abruf am 17.Oktober 2008)

20. IBM (2007) Dokumentation zu Tivoli Application Dependency DiscoveryManager. http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/index.jsp?

topic=/com.ibm.taddm.doc_7.1/cmdb_welcome.html (Abruf am 17. Oktober2008)

21. Lenz R (1997) Adaptive Datenreplikation in verteilten Systemen. Teubner, Stutt-gart Leipzig

22. Lindquist D, Madduri H, Paul CJ, Rajaraman B (2007) IBM Service Managementarchitecture. IBM Syst J 46(3):423–440

23. Madduri H, Shi SSB, Baker R, Ayachitula N, Shwartz L, Surendra M, Corley C, Be-nantar M, Patel S (2007) A configuration management database architecture insupport of IBM Service Management. IBM Syst J 46(3):441–457

24. Oldfield A, Sterbens R, Waschke M (2007) Einsatz einer CMDB für das Change-und Konfigurationsmanagement – CA und BearingPoint. http://www.ca.com/files/WhitePapers/cmdb_wp_for_ccm_de.pdf (Abruf am 17. Oktober 2008)

25. Rahm E (1994) Mehrrechner-Datenbanksysteme – Grundlagen der verteilten undparallelen Datenbankverarbeitung. Addison Wesley, Leipzig

26. Sheth AP, Larson JA (1990) Federated database systems for managing distribu-ted, heterogeneous, and autonomous databases. ACM Comput Surveys (CSUR)22(3):183–236

27. Yuhanna N, Gilpin M (2008) The Forrester WaveTM – Information-As-A-Service,Q1 2008. http://www.forrester.com/Research/Document/Excerpt/0,7211,43199,00.html (Abruf am 12. Januar 2008)

362 Informatik_Spektrum_33_4_2010