Servicezentrierter Aufbau einer zentralen CMDB in Xurrent als Single Source of Truth

Es gab keine zentrale, konsistente Sicht auf produktive IT-Systeme und deren Abhängigkeiten zu Services. Konfigurationsdaten waren verteilt, teilweise veraltet und nicht sauber verknüpft, wodurch Impact-Analysen bei Incidents und Changes nur eingeschränkt möglich waren. Dies erschwerte die operative Steuerung und die Einhaltung von SLAs.

Eingeführt wurde eine servicezentrierte CMDB in Xurrent mit verpflichtender Zuordnung aller produktiven Configuration Items zu Service-Instanzen. Ergänzend wurden automatisierte Discovery- und Integrationsflüsse etabliert sowie eine klare Trennung zwischen Application-IT- und Core-IT-Accounts umgesetzt, um Sicherheit und saubere Service-Abhängigkeiten sicherzustellen.

Nach Go-Live steht eine zentrale, aktuelle Single Source of Truth für produktive Systeme und Service-Abhängigkeiten zur Verfügung. Impact-Analysen sind deutlich schneller und verlässlicher, Störungen können gezielter priorisiert werden und SLA-Verletzungen werden reduziert. Operative Entscheidungen basieren erstmals auf konsistenten, automatisiert gepflegten CMDB-Daten.

Fachlich fehlte eine einheitliche und belastbare Sicht auf produktive IT-Systeme und deren Abhängigkeiten zu Services, sodass Auswirkungen von Störungen oder Changes nur mit hohem manuellem Aufwand eingeschätzt werden konnten. Organisatorisch waren Verantwortlichkeiten vorhanden, die zugrunde liegenden Daten jedoch über mehrere Tools und Teams verteilt und nicht konsistent gepflegt. Technisch existierte keine zentrale CMDB als Single Source of Truth, sondern fragmentierte Bestände aus Discovery-Tools, Asset-Listen und Architekturwerkzeugen. Beziehungen zwischen Applikationen, Infrastruktur und Service-Instanzen waren kaum oder nur implizit dokumentiert. Impact-Analysen waren dadurch unzuverlässig, Reaktionszeiten im Incident Management verlängert und SLAs schwer steuerbar. Zusätzlich fehlte eine saubere Trennung sensibler Core-IT-Daten von anderen Service-Domänen.

Die CMDB wurde direkt in Xurrent aufgebaut und eng mit dem Servicekatalog sowie den Service-Instanzen verzahnt. Zentrales Architekturprinzip war, dass Configuration Items ausschließlich im Service-Kontext existieren und dadurch echte End-to-End-Abhängigkeiten sichtbar werden. Ergänzend wurde ein getrenntes Account-Modell für Application-IT und Core-IT eingeführt, um Sicherheits- und Organisationsanforderungen klar abzubilden. Die Befüllung der CMDB erfolgt weitgehend automatisiert über bestehende Discovery-Quellen, die über eine Konsolidierungsplattform harmonisiert werden. Fachlich orientiert sich das Modell an Business Capabilities für Applikationen und an TBM-Standards für Infrastruktur, um Anschlussfähigkeit an LeanIX und Service-Management-Prozesse sicherzustellen.

Zu Beginn wurden Ziele, Scope und Annahmen für die erste CMDB-Phase definiert und die fachlichen Anforderungen aus Service Management und Infrastruktur konsolidiert. Darauf aufbauend entstand ein Ziel-Datenmodell für Services, Service-Instanzen, Produkte und Configuration Items, abgestimmt mit bestehenden Strukturen in Xurrent und LeanIX. Parallel wurden getrennte Xurrent-Accounts für Application-IT und Core-IT inklusive Rollen- und Berechtigungskonzept umgesetzt. Anschließend wurde der Servicekatalog strukturiert aufgebaut, da er die Grundlage für die CMDB bildet. Discovery-Quellen wurden angebunden und über den USU DataHub harmonisiert sowie automatisiert nach Xurrent integriert. Danach folgten die Umsetzung von CI-Typen, Beziehungen und Namenskonventionen sowie umfangreiche Tests. Den Abschluss bildeten Datenvalidierung, fachliche Abnahme sowie die Vorbereitung von Betrieb, Governance und Schulung für den Go-Live.

Fachlich steht nun eine verlässliche, serviceorientierte CMDB zur Verfügung, die klare Abhängigkeiten zwischen Applikationen, Infrastruktur und Services sichtbar macht und fundierte Impact-Analysen ermöglicht. Incident- und Change-Entscheidungen sind schneller, nachvollziehbarer und risikoärmer geworden. Technisch wurde eine zentrale Single Source of Truth etabliert, die automatisiert aus Discovery-Quellen gepflegt wird und manuelle Datenpflege deutlich reduziert. Die Datenqualität ist spürbar höher durch konsolidierte und harmonisierte CI-Informationen. Nutzer profitieren von kürzeren Lösungszeiten, realistischeren Priorisierungen und stabilerer Servicequalität. Provider und IT-Teams erhalten klare Zuständigkeiten, bessere Transparenz und eine belastbare Grundlage für SLA-Steuerung und Reporting. Insgesamt ist die IT besser steuerbar, skalierbarer und näher an den Geschäftsservices ausgerichtet.