Für einen effizienten und serviceorientierten Rechenzentrumsbetrieb stehen viele Provider heute vor der Herausforderung, die Vielzahl vorhandener Managementsysteme zu integrieren oder sich auf die Leistungsfähigkeit des Portfolios eines Herstellers zu verlassen. Es treffen die Anforderungen eines datengetriebenen „Data Repositories“ auf die mehrerer Expertensysteme, und die Lücke zwischen businessorientiertem Service (die „Business-Strategie“) und technikgetriebener IT-Strategie soll nach Möglichkeit geschlossen werden. So das Wunschdenken.
Ein „Data Repository” steht im Zentrum eines effizienten und serviceorientierten Rechenzentrumsbetriebs und integriert alle anfallenden oder vorhandenen Rohdaten, beziehungsweise versorgt alle „Abnehmer“ (Infrastruktursysteme, Prozesse, Services) mit aufbereiteten Informationen. Die Schwierigkeiten beginnen jedoch bereits mit dem Datenmodell. So setzen viele Hersteller entweder auf generische Modelle, und überlassen dem Kunden schlichtweg die Detailmodellierung, oder historisch gewachsene Standardmodelle werden auf die Kundensituation hin „customisiert“, mit dem Risiko einer eingeschränkten Erweiterbarkeit oder nur mit hohem Aufwand verbundenen Updatefähigkeit. Außerdem ist darauf zu achten, ob der Kunde selbst entwickeln darf oder dies dem Hersteller vorbehalten ist.
Neben der Datenhaltung muss ein „Data Repository“ eine weitere wesentliche Eigenschaft mitbringen: Schnittstellenvarianz. Seit den frühen Zeiten von EAI („Enterprise-Application-Integration“) existiert der Wunsch nach Orchestrierung und geregeltem Datenaustausch. Derzeit kann der vielzitierte „Web-Service“ lange nicht alle Anforderungen erfüllen (Mengenverarbeitung, Geschwindigkeit), und die Verfügbarkeit leistungsfähiger „ETL“-Werkzeuge (extract, transform, load) lässt zu wünschen übrig.
Im Rechenzentrum treffen eine ganze Reihe vielschichtiger und mächtiger Expertensysteme aufeinander: von Konfigurationssystemen, Netzwerk- und Kabelverwaltungssoftware („Configuration“) beziehungsweise Gebäude- und Gebäudeanlagenverwaltung („Facility“) für die Infrastrukturabbildung, über Messwertverarbeitung, Monitoring, bis hin zu integrierten Service und Prozesskonsolen ist alles zu finden. Viele Systeme und deren Pflegeprozesse sind historisch gewachsen, und erfüllen ihre Aufgabe sachdienlich. Es mangelt jedoch entweder an einer ausreichenden Integration der Systeme, Prozesse oder Querschnittsfunktionen, oder einzelne dieser „Silos“ erfüllen funktional nicht die Erwartungen.
Motivation für Umbrella-System
Eine der häufigsten Motivationen für die Einführung eines „Umbrella“-Systems stellt immer noch die Erfüllung technischer Detailfunktionen dar („Customer Technology Processes“). Sei es die Umstellung des Netzbetriebs auf eine duale IPv4/IPv6-Strategie, die Beerdigung der letzten vorhandenen analogen Telefonanlagen, der Betrieb der heterogenen Netzwerke (LAN/WAN) von der Verkabelung bis in die höheren Layer, oder mangelnde Funktionstiefe in der Rechenzentrumssoftware („Datacenter Infrastructure Management“). Sie haben alle eines gemeinsam: Die funktionalen (technischen) Daten dienen nicht nur dem Betrieb, sondern werden auch an anderer Stelle benötigt: Verrechnung und Abrechnung, Serviceerbringung, Monitoring, übergeordnete ITSM-Prozesse.
Ohne Prozesse geht es nicht. Von einer „sich selbst pflegenden Infrastrukturverwaltung“ ist die RZ-Industrie weit entfernt. So trifft man in der Praxis auf einen gesunden beziehungsweise ungesunden Mix aus automatisierter Pflege, geregelten Pflegeprozessen, und den unbeliebten und aufwändigen Adhoc-Änderungen (Nachdokumentation). Prozesse und Betriebsoptimierung liefern „Hand-in-Hand“ eine zweite Motivationsgruppe für den Bedarf übergeordneter Systeme. Das Anforderungsspektrum öffnet sich von ITIL, „Compliance-Frameworks“ bis hin zu BSI-Grundschutzzertifizierungen.
In technischen Diskussionen werden zudem zur Verwaltung benötigte Enterprise-Resource-Planning-Daten ausgeklammert oder massiv unterschätzt. Lokationen und Standortkürzel, Gebäudedaten, Personen, Verträge etc. werden typischerweise nicht in den IT-Abteilungen gepflegt oder unterliegen speziellen Zugriffsrestriktionen, Geheimhaltungen oder Datenschutzklauseln. Leider sind sie in der IT-Infrastrukturverwaltung unumgänglich, und können als dritte Motivationsgruppe genannt werden.