Letztlich dienen alle Bemühungen einem Gesamtziel: dem effizienten Betrieb und der serviceorientierten Ausrichtung – also einer „IT Management Landscape“. Die beteiligten und vorhandenen Systemgruppen (Silos) haben durchaus ihre Daseinsberechtigung zur Erfüllung ihrer Aufgaben. Schwerpunkte und Grenzen einzelner Silosysteme lassen sich jedoch wie in der Grafik ersichtlich wie folgt grob charakterisieren.
ITSM: ITSM-Systeme dienen der prozessualen Steuerung von Arbeitsprozessen. Es sollte weder versucht werden aus einem ITSM-System ein technisches Konfigurationssystem noch ein Infrastrukturverwaltungswerkzeug zu machen. Es fehlen schlichtweg Modelle und grafische Repräsentanz.
Business-Service-Management (BSM): Keine Serviceerbringung ohne Servicekonsole. Werkzeuge mit vordefinierten Service-Schablonen und freier Zuordnung von Konfigurations- und Monitoringdaten helfen massiv. Ausklammern bestimmter Komponententypen behindern massiv.
Konfigurationsdatenbanken: Configuration-Management und CMDB sind zum „buzzword“ verkommen, da sich weder zentralistische noch föderalistische Ansätze eindeutig durchgesetzt haben und das Thema aufgrund der Vielschichtigkeit und Komplexität in vielen Unternehmen kritisch betrachtet wird. Was beim Configuration-Management im kleineren Fokus ersichtlich ist, gilt für die „IT Management Landscape“ im Gesamtkontext: Ohne Gesamtstrategie, Priorisierung, Fokussierung und Rückhalt durch das Management ist diese oftmals zum Scheitern verurteilt.
DCIM: Messwertverarbeitung wird als Teildisziplin von DCIM verstanden. Ohne ausreichend Informationen zur beteiligten Infrastruktur und Konfiguration sind sinnvolle Ableitungen und Maßnahmen kaum zu treffen. Verschärft wird die Problematik durch unzureichende Abbildung der
Strominfrastruktur und fehlenden Zugriff auf Konfigurationsdaten.
Facility: Ursprünglich aus der Gebäude- und Anlagenverwaltung entstandene Systeme sind mit zu vielen technischen Details überfordert. Grafische Darstellungen sollten dem Einsatzzweck dienen, Funktionalität geht hier vor. Architekturpläne werden häufig nicht in der IT gepflegt.
Monitoring: System- und Netzwerkmonitoring arbeiten im Regelfall sehr gut, allerdings oftmals auf der Basis mehrerer Systeme mit unterschiedlichen Identitäten und Nomenklaturen der Überwachungsknoten. „Root Cause“ oder „Impact Analysen“ werden durch Zusatzwerkzeuge oder Integrationen abgedeckt, sind jedoch im Fehlerfall sehr dienlich. Größter Mehrwert und geringste Wiederherstellungszeiten werden durch systemische Notfallpläne und qualifizierte Logbücher erreicht.
Für eine Gesamtstrategie ist ein Beratungsansatz notwendig, der in einem ersten Analyseschritt vorhandene Systeme (Silos), Prozesse und Daten aufgreift und in eine Zieldefinition überführt. Nur so können historische Investitionen gesichert und „Mammutprojekte“ vermieden werden. Auch wenn einzelne Silos ersetzt werden, oder Integrationen in ein „Umbrella“-System notwendig sind, ist dies weit entfernt von einem „All-in-one“-Ansatz.
Zur Erfüllung, also das Erreichen des maximalen Mehrwerts, sollte fokussiert überprüft werden, welches Silo wie und in welcher Qualität besetzt ist, und welchen Zweck das Silosystem künftig bedienen soll. Erst wenn die Zielstellung definiert ist, sollte die Datenintegration in ein „Data Repository“ beginnen. Kann das „Data Repository“ einzelne Silos ersetzen, ergeben sich größtmögliche, nachhaltige Synergien.
Die Aufgabe des Datenbrokers sollte letztlich mit den gesetzten übergreifenden Zielen in Einklang gebracht werden:
Ob der Vorteil eines „Umbrella“-Systems (das auch funktionale Teilaufgaben aus den Silos übernimmt) oder einer Integrationsstrategie (vorwiegend Datenhaltung im „Data Repository“) überwiegt, kann jedoch lediglich an der Einzelsituation entschieden werden und hat zu viele Einflussfaktoren.
Es sei jedoch darauf hingewiesen, dass aufgrund geringerer Komplexität der „Umbrella“-Ansatz gar zu optimistischen Integrationsbestrebungen vorzuziehen ist.