Skip to main content

6.2 Configuration Items und Beziehungen

Kurz erklärt

Ein Configuration Item (CI) ist ein Bestandteil, der für einen IT-Service wichtig ist und deshalb verwaltet werden soll.

Beziehungen zwischen CIs zeigen, wie Services, Anwendungen, Systeme, Netzwerke, Datenbanken, Zertifikate, Lieferanten und andere Bestandteile zusammenhängen.

Der eigentliche Wert entsteht nicht nur durch die Liste einzelner CIs, sondern durch das Verständnis ihrer Abhängigkeiten.

Warum Configuration Items wichtig sind

IT-Services bestehen meistens aus mehreren technischen und organisatorischen Bestandteilen.

Beispiel:

Ein Mitarbeiterportal kann abhängig sein von:

  • Webserver,
  • Anwendung,
  • Datenbank,
  • Identity Provider,
  • MFA,
  • DNS,
  • Zertifikat,
  • Load Balancer,
  • Firewall,
  • Storage,
  • Backup,
  • Monitoring,
  • Schnittstellen,
  • Lieferant,
  • Dokumentation,
  • und Supportgruppe.

Wenn diese Bestandteile nicht bekannt sind, werden Incidents, Problems und Changes schwieriger.

Configuration Items helfen dabei, diese Bestandteile strukturiert zu erfassen.

Was ist ein Configuration Item?

Ein Configuration Item ist ein Element, das für die Bereitstellung, den Betrieb, die Steuerung oder die Unterstützung eines Service relevant ist.

Ein CI kann technisch oder nicht-technisch sein.

Beispiele:

  • Server,
  • Anwendung,
  • Datenbank,
  • Netzwerkgerät,
  • Firewall-Regel,
  • Zertifikat,
  • Cloud-Ressource,
  • Benutzergruppe,
  • Service,
  • Schnittstelle,
  • Dokumentation,
  • Lieferantenvertrag,
  • Lizenz,
  • Monitoringregel,
  • Backupjob,
  • Arbeitsplatzgerät,
  • Drucker.

Nicht jedes vorhandene Objekt muss automatisch ein CI sein.

Entscheidend ist, ob das Objekt für Servicebetrieb, Risiko, Support, Change oder Steuerung relevant ist.

CI ist nicht gleich Asset

Ein Asset ist häufig ein wirtschaftlich oder vertraglich relevantes Objekt.

Ein CI ist ein für den Servicebetrieb relevantes Objekt.

Asset Configuration Item
Fokus auf Besitz, Kosten, Vertrag oder Lebenszyklus Fokus auf Servicebeziehung, Abhängigkeit und Betrieb
wichtig für Einkauf und Lizenzierung wichtig für Incident, Problem, Change und Release
Beispiel: Notebook mit Kaufdatum Beispiel: Notebook als Teil eines verwalteten Arbeitsplatzservices
Beispiel: Server als Anlagegut Beispiel: Server als Bestandteil einer produktiven Anwendung

Ein Objekt kann gleichzeitig Asset und CI sein.

Beispiel:

Ein produktiver Datenbankserver ist ein Asset und gleichzeitig ein CI.

Welche Objekte sollten als CI erfasst werden?

Ein Objekt sollte eher als CI erfasst werden, wenn:

  • ein Service davon abhängig ist,
  • ein Ausfall Benutzer betrifft,
  • Changes daran risikoreich sind,
  • es für Sicherheitsbewertung wichtig ist,
  • es für Incident-Diagnose benötigt wird,
  • es eine relevante Version oder Konfiguration besitzt,
  • es durch einen Lieferanten unterstützt wird,
  • es eine wichtige Beziehung zu anderen Komponenten hat,
  • es für Compliance, Audit oder Nachvollziehbarkeit wichtig ist,
  • oder es in Problem- und Change-Analysen regelmäßig benötigt wird.

Ein Objekt muss nicht erfasst werden, nur weil es technisch existiert.

Die Pflege muss einen praktischen Nutzen haben.

Beispiele für CI-Typen

CI-Typ Beispiel
Business Service Mitarbeiterportal
Technical Service Datenbankplattform
Anwendung Warenwirtschaft
Server PRD-APP-PORTAL-01
Datenbank SQL-Cluster Produktion
Netzwerkgerät Standort-Firewall
Cloud-Ressource App Service, Storage Account
Sicherheit TLS-Zertifikat, MFA-Richtlinie
Identität Entra-ID-Gruppe
Schnittstelle REST-API zum ERP-System
Monitoring Alarmregel für Zertifikatsablauf
Backup Backupjob für Datenbank
Dokumentation Betriebsrunbook
Lieferant Supportvertrag Provider

Die CI-Typen sollten zur Organisation passen.

Zu viele CI-Typen können die Pflege unnötig erschweren.

Zu wenige CI-Typen können wichtige Unterschiede verdecken.

Service-CI und technische CIs unterscheiden

Ein Service selbst kann als CI betrachtet werden.

Beispiel:

  • Service: Mitarbeiterportal
  • Anwendung: Portal-App
  • Server: Webserver
  • Datenbank: Portal-DB
  • Zertifikat: portal.example.tld
  • Identity Provider: zentrale Anmeldung
  • Supportgruppe: Application Support

Der Service ist das, was Benutzer wahrnehmen.

Die technischen CIs sind Bestandteile, die den Service ermöglichen.

Diese Unterscheidung hilft, technische Informationen mit Benutzer- und Geschäftsbezug zu verbinden.

Attribute eines Configuration Items

Ein CI sollte nur so viele Attribute besitzen, wie sinnvoll gepflegt und genutzt werden können.

Mögliche Attribute:

  • CI-Name,
  • CI-Typ,
  • Beschreibung,
  • Status,
  • Umgebung,
  • Version,
  • Standort,
  • Servicezuordnung,
  • Owner,
  • Supportgruppe,
  • Lieferant,
  • Kritikalität,
  • Sicherheitsklassifizierung,
  • Dokumentationslink,
  • letzte Änderung,
  • letzte Prüfung,
  • Beziehungen,
  • verknüpfte Incidents,
  • verknüpfte Problems,
  • verknüpfte Changes.

Wichtig ist nicht maximale Datenmenge.

Wichtig ist nutzbare Datenqualität.

CI-Name

Der CI-Name sollte eindeutig und verständlich sein.

Ungeeignet:

  • Server1,
  • AppNeu,
  • TestAlt,
  • FirewallFinal,
  • Datenbank2.

Besser:

  • PRD-APP-PORTAL-01,
  • TST-DB-ERP-02,
  • BER-FW-STANDORT-01,
  • PRD-CERT-PORTAL-2026,
  • PRD-API-ERP-PARTNER.

Eine Namenskonvention kann enthalten:

  • Umgebung,
  • Standort,
  • Funktion,
  • Servicebezug,
  • laufende Nummer.

Die konkrete Namenskonvention muss zur Organisation passen.

CI-Status

Der Status zeigt, in welchem Zustand sich ein CI befindet.

Mögliche Status:

  • geplant,
  • bestellt,
  • im Aufbau,
  • aktiv,
  • in Wartung,
  • gesperrt,
  • außer Betrieb,
  • ersetzt,
  • archiviert.

Der Status ist wichtig für:

  • Incident-Diagnose,
  • Change-Planung,
  • Sicherheitsbewertung,
  • Lizenz- und Asset-Abgleich,
  • Außerbetriebnahme,
  • und Dokumentationspflege.

Ein CI, das außer Betrieb ist, sollte nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen.

Umgebung

Die Umgebung zeigt, wo ein CI genutzt wird.

Beispiele:

  • Entwicklung,
  • Test,
  • Integration,
  • Abnahme,
  • Staging,
  • Produktion,
  • Disaster Recovery,
  • Labor,
  • Schulung.

Ein Change an einem Testsystem ist anders zu bewerten als ein Change an einem produktiven System.

Fehlende Umgebungskennzeichnung kann gefährlich sein.

Beispiel:

Ein Administrator führt eine Änderung auf einem System aus, das für Test gehalten wird, tatsächlich aber produktiv ist.

Version und Konfiguration

Für viele CIs ist die Version wichtig.

Beispiele:

  • Betriebssystemversion,
  • Anwendungsversion,
  • Datenbankversion,
  • Firmwareversion,
  • Clientversion,
  • Konfigurationsstand,
  • Zertifikatslaufzeit,
  • API-Version,
  • Treiberversion.

Versionen helfen bei:

  • Incident-Diagnose,
  • Known Errors,
  • Sicherheitsbewertung,
  • Patchmanagement,
  • Release Management,
  • Problem Management,
  • und Change-Bewertung.

Beispiel:

Wenn nur VPN-Client-Version 5.8 betroffen ist, muss diese Information auffindbar sein.

Owner und Supportgruppe

Für wichtige CIs sollte klar sein:

  • Wer ist fachlich verantwortlich?
  • Wer ist technisch verantwortlich?
  • Wer betreibt das CI?
  • Wer unterstützt bei Incidents?
  • Wer darf Changes genehmigen?
  • Wer pflegt Dokumentation?
  • Welcher Lieferant ist beteiligt?

Unklare Verantwortlichkeiten führen zu Verzögerungen.

Ungeeignet:

Niemand weiß, wem dieser Server gehört.

Besser:

Service Owner, technischer Owner, Supportgruppe und Lieferant sind dokumentiert.

Kritikalität

Die Kritikalität beschreibt, wie wichtig ein CI oder der zugehörige Service ist.

Mögliche Stufen:

  • geschäftskritisch,
  • hoch,
  • mittel,
  • niedrig,
  • nicht produktiv.

Die Kritikalität beeinflusst:

  • Incident-Priorisierung,
  • Change-Risikobewertung,
  • Monitoring,
  • Backup-Anforderungen,
  • Patchplanung,
  • Notfallplanung,
  • Lieferantensteuerung,
  • und Service Reviews.

Wichtig:

Die Kritikalität sollte nicht nur technisch bewertet werden.

Ein unscheinbarer Server kann geschäftskritisch sein, wenn ein zentraler Prozess davon abhängt.

Sicherheitsklassifizierung

Manche CIs benötigen zusätzliche Sicherheitsinformationen.

Beispiele:

  • enthält personenbezogene Daten,
  • verarbeitet vertrauliche Daten,
  • besitzt Internetzugang,
  • ist extern erreichbar,
  • besitzt Administratorzugänge,
  • ist Teil kritischer Infrastruktur,
  • ist auditrelevant,
  • verarbeitet Zahlungsdaten,
  • besitzt erhöhte Verfügbarkeitspflichten.

Solche Informationen helfen bei:

  • Risikobewertung,
  • Change Enablement,
  • Sicherheitsvorfällen,
  • Patchpriorisierung,
  • Zugriffskontrolle,
  • und Compliance.

Was sind CI-Beziehungen?

CI-Beziehungen beschreiben, wie Configuration Items miteinander verbunden sind.

Beispiele:

  • Service nutzt Anwendung,
  • Anwendung läuft auf Server,
  • Server nutzt Storage,
  • Anwendung nutzt Datenbank,
  • Anwendung authentifiziert gegen Identity Provider,
  • Webservice nutzt Zertifikat,
  • Standort nutzt Firewall,
  • Anwendung kommuniziert mit API,
  • Monitoring überwacht Service,
  • Backupjob sichert Datenbank,
  • Lieferant unterstützt System.

Beziehungen machen sichtbar, welche Auswirkungen ein Ausfall oder Change haben kann.

Warum Beziehungen wichtiger sind als Einzelinformationen

Eine Liste einzelner CIs beantwortet nur:

Was gibt es?

Beziehungen beantworten:

Was hängt wovon ab?

Beispiel:

CI-Liste:

  • APP-01,
  • DB-01,
  • FW-01,
  • CERT-01.

Beziehungen:

  • Mitarbeiterportal läuft auf APP-01.
  • APP-01 nutzt DB-01.
  • APP-01 ist über FW-01 erreichbar.
  • Mitarbeiterportal nutzt CERT-01.
  • DB-01 nutzt Storage-Cluster PRD-STO-01.

Erst durch Beziehungen wird klar, welche Komponenten gemeinsam einen Service ermöglichen.

Typische Beziehungstypen

Beziehung Bedeutung
nutzt Ein CI verwendet ein anderes CI
läuft auf Anwendung läuft auf Server oder Plattform
ist abhängig von Service funktioniert nur mit anderem CI
verbindet zu Netzwerk- oder Schnittstellenbeziehung
wird überwacht von Monitoringbeziehung
wird gesichert durch Backupbeziehung
wird unterstützt von Lieferanten- oder Supportbeziehung
ist Teil von Komponente gehört zu größerem Service
ersetzt neues CI ersetzt altes CI
kommuniziert mit technische Schnittstelle zwischen Systemen

Die Beziehungsarten sollten verständlich und einheitlich genutzt werden.

Beispiel: Mitarbeiterportal

Mitarbeiterportal
    ↓ nutzt
Portal-Anwendung
    ↓ läuft auf
Webserver PRD-APP-PORTAL-01
    ↓ nutzt
Datenbank PRD-DB-PORTAL-01
    ↓ nutzt
Storage PRD-STO-01

Weitere Beziehungen:

  • Mitarbeiterportal nutzt DNS-Eintrag portal.example.tld.
  • Mitarbeiterportal nutzt TLS-Zertifikat PRD-CERT-PORTAL.
  • Mitarbeiterportal nutzt Identity Provider.
  • Webserver wird durch Monitoring überwacht.
  • Datenbank wird durch Backupjob gesichert.
  • Anwendung wird durch Application Support betreut.

Beispiel: VPN-Service

VPN-Service
    ↓ nutzt
VPN-Gateway
    ↓ nutzt
Firewall
    ↓ nutzt
Internetanbindung

Zusätzliche Abhängigkeiten:

  • VPN-Client,
  • Zertifikat,
  • MFA,
  • Identity Provider,
  • Benutzergruppen,
  • DNS,
  • Monitoring,
  • Netzwerkteam,
  • Lieferant.

Wenn MFA ausfällt, kann der VPN-Service betroffen sein, obwohl das VPN-Gateway technisch läuft.

Beispiel: Druckservice

Druckservice
    ↓ nutzt
Druckserver
    ↓ verwaltet
Netzwerkdrucker
    ↓ nutzt
Netzwerksegment

Weitere Abhängigkeiten:

  • Druckertreiber,
  • Benutzerberechtigungen,
  • Spooler-Dienst,
  • Papier- und Verbrauchsmaterial,
  • Standortnetz,
  • Fachanwendung,
  • Etikettenvorlagen.

Ein Druckproblem kann also viele Ursachen haben.

Ohne Beziehungen wird oft nur der Drucker selbst betrachtet.

Beispiel: Schnittstelle zwischen Anwendungen

Anwendung A
    ↓ sendet Daten an
API-Gateway
    ↓ leitet weiter an
Anwendung B
    ↓ schreibt in
Datenbank B

Zusätzliche Abhängigkeiten:

  • Zertifikat,
  • Firewall-Regel,
  • DNS,
  • API-Token,
  • Berechtigungen,
  • Monitoring,
  • Lieferant,
  • Datenformat.

Eine kleine Änderung am API-Token kann den gesamten Datenaustausch stoppen.

Beziehungen und Incident Management

Bei Incidents helfen Beziehungen, die Auswirkung zu verstehen.

Beispiele:

  • Welcher Service ist betroffen?
  • Welche CIs sind beteiligt?
  • Gibt es eine gemeinsame Abhängigkeit?
  • Welche anderen Services könnten betroffen sein?
  • Wer ist zuständig?
  • Welche Changes wurden zuletzt an beteiligten CIs durchgeführt?
  • Gibt es Known Errors für diese Version oder Komponente?

Beispiel:

Mehrere Anwendungen melden Fehler.

CI-Beziehungen zeigen, dass alle denselben Datenbankcluster nutzen.

Die Diagnose wird schneller eingegrenzt.

Beziehungen und Problem Management

Problem Management nutzt CI-Beziehungen, um Muster zu erkennen.

Beispiele:

  • wiederkehrende Incidents betreffen dieselbe Hardwaremodellserie,
  • mehrere Services nutzen dasselbe Zertifikat,
  • mehrere Anwendungen sind von derselben Schnittstelle abhängig,
  • ein Standort hat Probleme mit derselben Firewall,
  • eine bestimmte Clientversion erzeugt viele Tickets.

Ohne Beziehungen bleiben solche Muster oft unsichtbar.

Beziehungen und Change Enablement

Bei Changes sind Beziehungen besonders wichtig.

Zu prüfen ist:

  • Welche CIs werden geändert?
  • Welche Services hängen davon ab?
  • Welche Benutzergruppen sind betroffen?
  • Welche Schnittstellen werden beeinflusst?
  • Welche anderen Teams müssen beteiligt werden?
  • Welche Dokumentation muss aktualisiert werden?
  • Welche Tests sind notwendig?
  • Welche Rollback-Auswirkungen gibt es?

Ein Change an einem kleinen CI kann große Auswirkungen haben, wenn viele Services davon abhängen.

Beispiel: Change-Auswirkung durch Beziehung

Change

Ein Zertifikat soll erneuert werden.

Ohne Beziehung

Es wird nur der Webserver betrachtet.

Mit Beziehung

Es wird sichtbar:

  • Zertifikat wird vom Mitarbeiterportal genutzt,
  • Anmeldung läuft über Identity Provider,
  • externe Schnittstelle prüft Zertifikatskette,
  • Monitoring muss nach Erneuerung geprüft werden,
  • Service Desk muss mögliche Anmeldefehler kennen.

Dadurch wird der Change besser geplant.

Beziehungen und Release Management

Release Management benötigt Beziehungen, um zu verstehen:

  • welche Komponenten Bestandteil des Releases sind,
  • welche Zielumgebungen betroffen sind,
  • welche Abhängigkeiten bestehen,
  • welche Versionen zusammenpassen,
  • welche Benutzergruppen betroffen sind,
  • welche Knowledge-Artikel aktualisiert werden müssen.

Ein Release kann fehlschlagen, wenn eine abhängige Komponente vergessen wird.

Beziehungen und Information Security Management

Sicherheitsarbeit benötigt CI-Beziehungen.

Beispiele:

  • Welche Services sind extern erreichbar?
  • Welche Systeme verarbeiten vertrauliche Daten?
  • Welche Anwendungen nutzen ein gefährdetes Zertifikat?
  • Welche Server verwenden eine verwundbare Softwareversion?
  • Welche Benutzergruppen haben Zugriff?
  • Welche Schnittstellen übertragen sensible Daten?
  • Welche Systeme sind von einem kompromittierten Konto betroffen?

Ohne Beziehungen ist Sicherheitsbewertung unvollständig.

Beziehungen und Notfallplanung

Für Notfallplanung sind Abhängigkeiten entscheidend.

Zu klären ist:

  • Welche Services sind geschäftskritisch?
  • Welche CIs werden für Wiederherstellung benötigt?
  • Welche Reihenfolge ist beim Wiederanlauf notwendig?
  • Welche Datenbanken müssen zuerst verfügbar sein?
  • Welche Netzwerkverbindungen sind erforderlich?
  • Welche Lieferanten müssen erreichbar sein?
  • Welche Backupjobs gehören zu welchem Service?
  • Welche Dokumentation wird im Notfall benötigt?

Ein Wiederanlaufplan ohne Abhängigkeiten ist häufig unvollständig.

Tiefe der Beziehungspflege

Nicht jede Beziehung muss bis ins kleinste Detail gepflegt werden.

Zu klären ist:

  • Welche Beziehungen werden wirklich genutzt?
  • Welche Beziehungen helfen bei Incident, Problem und Change?
  • Welche Services sind kritisch?
  • Welche CIs ändern sich häufig?
  • Welche Daten können automatisiert gepflegt werden?
  • Welche Daten müssen manuell gepflegt werden?

Zu wenig Beziehungspflege macht die CMDB nutzlos.

Zu viel Detailtiefe macht sie schwer wartbar.

Beispiel für sinnvolle Detailtiefe

Für einen geschäftskritischen Service sinnvoll:

  • Service,
  • Anwendung,
  • Datenbank,
  • Server,
  • Netzwerk,
  • Zertifikat,
  • Identity Provider,
  • Backup,
  • Monitoring,
  • Owner,
  • Lieferant,
  • wichtigste Schnittstellen.

Für einen einfachen Testservice kann weniger Detail genügen.

Die Pflege muss zum Risiko passen.

Horizontale und vertikale Beziehungen

Vertikale Beziehungen

zeigen den Aufbau eines Service von oben nach unten.

Beispiel:

Service
    ↓
Anwendung
    ↓
Server
    ↓
Plattform
    ↓
Storage

Horizontale Beziehungen

zeigen Verbindungen zwischen gleichartigen oder verbundenen Komponenten.

Beispiel:

Anwendung A  ↔  API  ↔  Anwendung B

Beide Beziehungstypen sind wichtig.

Vertikale Beziehungen helfen bei Auswirkungsanalyse.

Horizontale Beziehungen helfen bei Schnittstellen- und Kommunikationsproblemen.

Upstream und Downstream

Bei Schnittstellen wird oft zwischen Upstream und Downstream unterschieden.

Begriff Bedeutung
Upstream vorgelagertes System, von dem Daten oder Dienste kommen
Downstream nachgelagertes System, das Daten oder Dienste erhält

Beispiel:

CRM-System
    ↓ sendet Kundendaten an
ERP-System
    ↓ sendet Rechnungsdaten an
Buchhaltungssystem

Wenn das CRM-System fehlerhafte Daten liefert, können downstream weitere Probleme entstehen.

Single Point of Failure erkennen

CI-Beziehungen können Single Points of Failure sichtbar machen.

Beispiel:

Mehrere Services nutzen denselben Datenbankserver.

Wenn dieser Server ausfällt, sind alle Services betroffen.

Mögliche Maßnahmen:

  • Hochverfügbarkeit prüfen,
  • Backup und Restore testen,
  • Monitoring verbessern,
  • Kapazität planen,
  • Change-Risiko erhöhen,
  • Notfallverfahren dokumentieren.

Beziehungen helfen also nicht nur bei Dokumentation, sondern auch bei Risikobewertung.

Dubletten und Namensprobleme

CI-Beziehungen werden unbrauchbar, wenn CIs mehrfach oder uneinheitlich erfasst sind.

Beispiele:

  • APP-01,
  • app01,
  • AppServer Portal,
  • PRD-APP-PORTAL-01

beschreiben möglicherweise dasselbe System.

Folgen:

  • Incidents werden falsch verknüpft,
  • Changes wirken unvollständig,
  • Beziehungen fehlen,
  • Reports werden ungenau,
  • Owner erscheinen widersprüchlich.

Namenskonventionen und Dublettenprüfung sind deshalb wichtig.

Veraltete Beziehungen

Beziehungen können veralten durch:

  • Migrationen,
  • Releases,
  • Servertausch,
  • Cloud-Umzug,
  • neue Schnittstellen,
  • Außerbetriebnahme,
  • Notfalländerungen,
  • Lieferantenwechsel,
  • Prozessänderungen.

Veraltete Beziehungen sind riskant.

Beispiel:

Ein Change wird als unkritisch bewertet, weil eine alte Beziehung fehlt.

Nach Umsetzung fällt ein abhängiger Service aus.

Beziehungen durch Changes aktualisieren

Jeder relevante Change sollte prüfen:

  • Wurde ein CI geändert?
  • Wurde ein CI neu erstellt?
  • Wurde ein CI entfernt?
  • Hat sich eine Version geändert?
  • Hat sich eine Beziehung geändert?
  • Hat sich ein Owner geändert?
  • Hat sich eine Schnittstelle geändert?
  • Hat sich ein Zertifikat geändert?
  • Muss die CMDB aktualisiert werden?

Configuration Management darf nicht getrennt von Change Enablement betrachtet werden.

Beziehungen durch Discovery erkennen

Technische Beziehungen können teilweise automatisch erkannt werden.

Beispiele:

  • Server kommuniziert mit Datenbank,
  • Anwendung öffnet Verbindung zu API,
  • Zertifikat ist auf Webserver installiert,
  • Softwareversion ist vorhanden,
  • Netzwerkgerät ist erreichbar,
  • Cloud-Ressource existiert.

Aber:

Discovery erkennt nicht immer fachliche Bedeutung.

Ein Tool kann eine Verbindung sehen.

Es weiß nicht automatisch, ob diese Verbindung geschäftskritisch ist.

Manuell gepflegte Beziehungen

Manuell gepflegt werden oft:

  • Service Owner,
  • fachliche Kritikalität,
  • Geschäftsprozessbezug,
  • Supportmodell,
  • Lieferantenverantwortung,
  • Risikoakzeptanz,
  • geplante Ablösung,
  • Dokumentationslinks,
  • fachliche Schnittstellenbedeutung.

Diese Informationen brauchen Verantwortliche und regelmäßige Prüfung.

Beziehungen visualisieren

CI-Beziehungen können als Diagramm, Tabelle oder Abhängigkeitsansicht dargestellt werden.

Mögliche Formen:

  • Service Map,
  • Abhängigkeitsdiagramm,
  • Schnittstellenübersicht,
  • Tabellenansicht,
  • Netzwerkplan,
  • CMDB-Beziehungsansicht,
  • Architekturdiagramm.

Wichtig ist, dass die Darstellung für den Zweck geeignet ist.

Ein Management-Review benötigt andere Details als eine technische Fehleranalyse.

Service Map

Eine Service Map zeigt die wichtigsten Bestandteile eines Services.

Beispiel:

Service: Mitarbeiterportal

Benutzer
    ↓
DNS
    ↓
Load Balancer
    ↓
Webserver
    ↓
Anwendung
    ↓
Datenbank
    ↓
Storage

Zusätzlich:
Identity Provider, Zertifikat, Monitoring, Backup, Supportgruppe

Eine Service Map muss nicht jedes Detail enthalten.

Sie soll die wichtigsten Abhängigkeiten verständlich machen.

Tabellarische Beziehungspflege

Eine einfache Tabelle kann für kleinere Umgebungen ausreichend sein.

Service CI Beziehung Abhängig von Owner
Mitarbeiterportal Portal-App läuft auf PRD-APP-PORTAL-01 App-Team
Mitarbeiterportal Portal-App nutzt PRD-DB-PORTAL-01 DB-Team
Mitarbeiterportal Portal-App nutzt Identity Provider IAM-Team
Mitarbeiterportal Webservice nutzt TLS-Zertifikat Plattform-Team

Wichtig ist, dass die Tabelle gepflegt und genutzt wird.

CI-Beziehungen in Tickets nutzen

Tickets sollten relevante CIs enthalten.

Das hilft bei:

  • Auswirkungsanalyse,
  • Priorisierung,
  • Eskalation,
  • Trendanalyse,
  • Problem Management,
  • Change-Verknüpfung,
  • Reporting.

Beispiel:

Ein Incident wird nicht nur als „Anwendung gestört“ erfasst.

Er wird mit Service, Anwendungsversion, Datenbank und betroffener Schnittstelle verknüpft.

Dadurch können spätere Muster erkannt werden.

CI-Beziehungen in Changes nutzen

Ein Change Request sollte betroffene CIs enthalten.

Beispiele:

  • Zielserver,
  • Anwendung,
  • Datenbank,
  • Zertifikat,
  • Firewall-Regel,
  • Schnittstelle,
  • Monitoringregel,
  • Dokumentation.

Zusätzlich sollten abhängige Services geprüft werden.

Ein Change an einer zentralen Komponente muss anders bewertet werden als ein Change an einem isolierten Testsystem.

CI-Beziehungen in Problems nutzen

Ein Problem Record sollte relevante CIs und Beziehungen enthalten.

Beispiel:

Mehrere Incidents betreffen verschiedene Anwendungen.

Problem Management erkennt:

  • alle Anwendungen nutzen dieselbe API,
  • API nutzt ein ablaufendes Zertifikat,
  • Zertifikatsmonitoring fehlt.

Die CI-Beziehung hilft, eine gemeinsame Ursache zu finden.

Praxisbeispiel: Datenbank als gemeinsame Abhängigkeit

Situation

Drei Anwendungen melden Performance-Probleme.

Einzelbetrachtung

Jedes Team sucht zunächst in seiner Anwendung.

CI-Beziehungen zeigen

  • alle drei Anwendungen nutzen denselben Datenbankcluster,
  • Datenbankcluster nutzt denselben Storage,
  • Storage zeigt hohe Latenz.

Nutzen

Die Analyse wird schneller auf die gemeinsame Abhängigkeit gelenkt.

Praxisbeispiel: Zertifikat als CI

Situation

Anmeldung am Service schlägt fehl.

CI-Beziehungen zeigen

  • Service nutzt Webzertifikat,
  • Zertifikat läuft heute ab,
  • Identity Provider prüft Zertifikatskette,
  • Monitoring überwacht nur HTTP-Status, nicht Zertifikatslaufzeit.

Verbesserung

Zertifikate werden künftig als eigene CIs mit Ablaufdatum, Owner und Monitoringbeziehung gepflegt.

Praxisbeispiel: Standort-Firewall

Situation

Ein Standort meldet Zugriffsstörungen.

CI-Beziehungen zeigen

  • Standort nutzt bestimmte Firewall,
  • mehrere Services laufen über dieselbe VPN-Verbindung,
  • letzte Änderung war eine Firewall-Regel,
  • betroffene Benutzergruppe sitzt nur an diesem Standort.

Nutzen

Die Fehlersuche wird auf Standortnetz, Firewall und VPN eingegrenzt.

Praxisbeispiel: Veraltete Beziehung

Situation

Eine alte Datenbank wird abgeschaltet.

Problem

In der CMDB ist nicht dokumentiert, dass ein Reporting-Service noch darauf zugreift.

Folge

Nach Abschaltung fällt das Reporting aus.

Lerneffekt

Vor Außerbetriebnahme müssen Abhängigkeiten geprüft und alte Beziehungen bereinigt werden.

Typische Fehler

Fehler 1

Nur technische Geräte werden als CIs betrachtet.

Fehler 2

Services selbst werden nicht als CIs erfasst.

Fehler 3

Beziehungen zwischen CIs fehlen.

Fehler 4

Beziehungen werden einmal erstellt und danach nicht gepflegt.

Fehler 5

Zu viele unwichtige Details werden gepflegt, aber wichtige Abhängigkeiten fehlen.

Fehler 6

CIs haben keinen Owner.

Fehler 7

CI-Namen sind uneinheitlich oder doppelt.

Fehler 8

Discovery-Daten werden ohne fachliche Prüfung übernommen.

Fehler 9

Changes aktualisieren CI-Beziehungen nicht.

Fehler 10

Tickets werden nicht mit betroffenen CIs verknüpft.

Fehler 11

Kritikalität wird ohne Servicebezug bewertet.

Fehler 12

Schnittstellen, Zertifikate und Cloud-Ressourcen werden vergessen.

Checkliste: Ist ein Objekt ein sinnvolles CI?

  • unterstützt es einen Service?
  • kann ein Ausfall Benutzer betreffen?
  • ist es für Incidents relevant?
  • ist es für Problems relevant?
  • ist es für Changes relevant?
  • besitzt es wichtige Beziehungen?
  • besitzt es relevante Versionen oder Konfigurationen?
  • hat es Sicherheits- oder Compliance-Bedeutung?
  • braucht es einen Owner?
  • muss es regelmäßig geprüft werden?
  • lohnt sich der Pflegeaufwand?

Checkliste CI-Attribute

  • eindeutiger Name
  • CI-Typ
  • Beschreibung
  • Status
  • Umgebung
  • Version oder Konfigurationsstand
  • betroffener Service
  • Owner
  • Supportgruppe
  • Lieferant, falls relevant
  • Kritikalität
  • Sicherheitsklassifizierung, falls relevant
  • Dokumentationslink
  • letzte Prüfung
  • relevante Beziehungen

Checkliste CI-Beziehungen

  • Service zu Anwendung verknüpft
  • Anwendung zu Server oder Plattform verknüpft
  • Anwendung zu Datenbank verknüpft
  • Anwendung zu Schnittstellen verknüpft
  • DNS-Abhängigkeit geprüft
  • Zertifikate verknüpft
  • Identity Provider oder MFA verknüpft
  • Netzwerk und Firewall berücksichtigt
  • Storage berücksichtigt
  • Backup berücksichtigt
  • Monitoring berücksichtigt
  • Lieferant berücksichtigt
  • Supportgruppe verknüpft
  • Dokumentation verknüpft

Checkliste Beziehungspflege nach Changes

  • neue CIs angelegt
  • entfernte CIs archiviert
  • geänderte Versionen aktualisiert
  • geänderte Schnittstellen dokumentiert
  • neue Abhängigkeiten ergänzt
  • entfernte Abhängigkeiten gelöscht
  • Owner aktualisiert
  • Lieferantenbezug aktualisiert
  • Dokumentationslinks geprüft
  • Monitoring- und Backupbeziehungen geprüft
  • Service Map aktualisiert
  • Ticket oder Change Record verknüpft

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten praktisch mit vielen Configuration Items.

Beispiele:

  • Server,
  • Clients,
  • Firewalls,
  • Switches,
  • VPN,
  • Drucker,
  • Benutzergruppen,
  • Zertifikate,
  • Backupjobs,
  • Monitoringregeln,
  • Cloud-Ressourcen,
  • Anwendungen,
  • Schnittstellen.

Wichtig ist nicht nur, diese Komponenten technisch zu kennen.

Wichtig ist auch zu verstehen:

  • welcher Service davon abhängt,
  • welche Benutzer betroffen wären,
  • welche Changes riskant sind,
  • welche Beziehungen bei Fehleranalyse helfen,
  • wer zuständig ist,
  • und welche Informationen aktuell gehalten werden müssen.

Gute CI-Beziehungen machen technische Arbeit schneller, sicherer und nachvollziehbarer.

Zusammenfassung

wichtige Services identifizieren
↓
relevante Configuration Items bestimmen
↓
sinnvolle Attribute erfassen
↓
Owner und Kritikalität festlegen
↓
Beziehungen zwischen CIs dokumentieren
↓
Serviceabhängigkeiten sichtbar machen
↓
CIs in Incidents, Problems und Changes nutzen
↓
Beziehungen nach Changes aktualisieren
↓
Datenqualität regelmäßig prüfen

Merksätze

Ein CI ist nur dann wertvoll, wenn es für den Servicebetrieb relevant ist.

Beziehungen zeigen, welche Auswirkungen ein Ausfall oder Change haben kann.

Eine CI-Liste ohne Beziehungen ist nur begrenzt hilfreich.

Technisch kleine Komponenten können geschäftlich sehr wichtig sein.

Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung.

CI-Beziehungen müssen nach Changes gepflegt werden.

Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management.

Verwandte Seiten

  • 6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen
  • 6.3 Configuration Management Database
  • 6.4 Discovery, Pflege und Datenqualität
  • 6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management
  • Incident Management
  • Problem Management
  • Change Enablement
  • Release Management
  • Information Security Management

Quellen und Versionsstand

Offizielle Grundlagen

  • PeopleCert – ITIL Practice Guide: Service Configuration Management
  • PeopleCert – ITIL Practice Guide: IT Asset Management
  • PeopleCert – ITIL Practice Guide: Change Enablement
  • PeopleCert – ITIL Practice Guide: Incident Management
  • PeopleCert – ITIL Practice Guide: Problem Management
  • ITIL Foundation – Version 5

Einordnung

Die dargestellten:

  • CI-Beispiele,
  • Beziehungstypen,
  • Service-Maps,
  • Tabellen,
  • Checklisten,
  • und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

  • CI-Typenliste,
  • Beziehungstypenliste,
  • Attributliste,
  • Service-Map-Struktur,
  • Namenskonvention,
  • oder konkrete Modellierungstiefe

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

  • Services,
  • Risiken,
  • Supportmodell,
  • Organisationsgröße,
  • Toollandschaft,
  • Datenqualität,
  • Sicherheitsanforderungen,
  • Change-Modell,
  • und verfügbare Fähigkeiten

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

Back to top