Was ist ein Configuration Item (CI)?

Ein Configuration Item (CI), auf Deutsch auch Konfigurationselement, ist jede Komponente, die verwaltet werden muss, damit ein IT-Service erbracht werden kann - ein Server, eine Anwendung, ein Netzwerk-Switch, sogar ein Dokument -, erfasst in einer Configuration Management Database (CMDB). Der Begriff stammt aus ITIL, dem am weitesten verbreiteten Rahmenwerk für IT-Service-Management. Was ein CI von einem gewöhnlichen Asset-Datensatz unterscheidet, sind die Beziehungsdaten: Eine CMDB listet Komponenten nicht nur auf, sie bildet ab, wie sie voneinander abhängen, sodass bei einem Ausfall sichtbar wird, wie weit die Auswirkungen reichen.

Was Sie hier erfahren

• Configuration Item: die kurze Definition
• Wofür CI steht - und wofür nicht
• CI-Typen mit Unterklassen
• Was ein CI-Datensatz enthält
• Arten von CI-Beziehungen
• Der Lebenszyklus eines CI
• Wie Sie entscheiden, was ein CI wird
• Woher die CI-Daten kommen
• CI-Datensätze vertrauenswürdig halten
• CI, Asset und Inventarposition im Vergleich
• Brauchen Sie überhaupt eine CMDB?
• FAQ

Configuration Item: die kurze Definition

CI = Configuration Item. ITIL definiert es als jede Komponente, die verwaltet werden muss, damit ein IT-Service erbracht werden kann. ISO/IEC 20000 fasst denselben Gedanken als jedes Element, das gesteuert werden muss, um einen Service zu liefern. Der praktische Test lautet: Wenn eine Änderung daran die Servicebereitstellung, die Verfügbarkeit, die Sicherheit oder die Compliance beeinflussen kann, ist es ein Configuration Item.

Dieser Test ist bewusst grob, denn die Alternativen, zu denen Teams gerne greifen - „Ist es teuer?”, „Haben wir es aktiviert?”, „Ist es körperlich vorhanden?” -, liefern alle die falsche Liste. Eine Domain-Verlängerung für vier Euro ist ein CI. Ein Reserve-Monitor für 900 Euro im Schrank ist keines.

Wofür CI steht - und wofür nicht

Im IT-Service-Management bedeutet CI Configuration Item - genau in diesem Sinn wird der Begriff auf dieser Seite verwendet.

In der Softwareentwicklung bedeutet CI Continuous Integration - die automatisierte Build- und Teststufe einer CI/CD-Pipeline. Damit hat eine CMDB nichts zu tun. Deshalb ist die bloße Abkürzung in jedem Gespräch mehrdeutig, an dem Entwicklung und Betrieb gleichzeitig beteiligt sind, und deshalb sagen Plattform-Teams im Zweifel lieber „Konfigurationselement” oder „Config Item” dazu.

In der System- und Wehrtechnik ist ein Configuration Item etwas Älteres und Strengeres: eine Zusammenfassung von Hardware und/oder Software, die für ein eigenständiges Konfigurationsmanagement bestimmt und formal gegen eine Baseline kontrolliert wird. Dort begegnen Ihnen Hardware Configuration Items (HWCI), Computer Software Configuration Items (CSCI), Schnittstellen-CIs und COTS-CIs, geführt über funktionale, zugeordnete und Produkt-Baselines, wobei ein Änderungsgremium jede Revision freigibt. Gleiche Formulierung, andere Disziplin - und eine häufige Verwechslungsquelle, wenn Engineering und IT dasselbe Vokabular, aber nicht dieselbe Definition benutzen.

CI-Typen mit Unterklassen

Die meisten CMDBs ordnen CIs in eine Klassenhierarchie ein, damit gemeinsame Attribute und Regeln vererbt statt jedes Mal neu erfasst werden. Die üblichen obersten Klassen:

• Hardware- und Infrastruktur-CIs - physische und virtuelle Server, Storage-Arrays, Load Balancer, Hypervisoren, Drucker sowie die Laptops und anderen Endgeräte, von denen ein Service tatsächlich abhängt.
• Software- und Anwendungs-CIs - Betriebssysteme, Fachanwendungen, Middleware, Datenbanken, Container-Images und SaaS-Mandanten, jeweils mit Version.
• Netzwerk-CIs - Router, Switches, Firewalls, VLANs und Subnetze, DNS-Einträge, VPN-Tunnel, WLAN-Access-Points und der Rest Ihrer Netzwerktechnik.
• Cloud- und Plattform-CIs - verwaltete Datenbankinstanzen, Kubernetes-Cluster, Storage-Buckets, IAM-Rollen, Message Queues sowie die Accounts oder Subscriptions, in denen sie liegen.
• Service-CIs - der Service selbst, wie ihn die Nutzer sehen („Lohnabrechnung”, „E-Mail”), dazu APIs und Schnittstellen zwischen Services.
• Dokumentations-CIs - Runbooks, Netzwerkdiagramme, SLAs und OLAs, Installationsanleitungen und die Golden-Image-Definitionen, aus denen Builds erzeugt werden.
• Gebäude- und Infrastruktur-CIs - Serverräume, USV-Anlagen, Stromverteilungen, Klimatechnik und Zutrittskontrolle, sofern deren Ausfall die IT mitreißt.
• Lieferanten- und Vertrags-CIs - der Anbieter, der Supportvertrag oder das Software-Nutzungsrecht, auf das ein Service rechtlich oder praktisch angewiesen ist.

Manche Modelle führen zusätzlich Personen und Rollen als CIs, damit „Wer ist dafür verantwortlich?” in der Abhängigkeitskarte steht und nicht nur in jemandes Kopf. Der entscheidende Test bleibt überall die Auswirkung auf den Service, nicht der Preis. Ein günstiges SSL-Zertifikat ist ein Musterbeispiel für ein CI, weil sein Ablauf einen Service lahmlegt. Ein teurer Gegenstand ohne Rolle für einen Service - Reserve-Festplatten im Schrank oder Konferenzraum-Ausstattung, von der niemandes Verfügbarkeit abhängt - ist ein Asset, das sich zu erfassen lohnt, aber selten eines, das sich als CI zu modellieren lohnt.

Was ein CI-Datensatz enthält

Ein brauchbarer CI-Datensatz ist kurz und vollständig, nicht lang und halb ausgefüllt. Die Felder, die praktisch jede CMDB erwartet:

• Eindeutige CI-Kennung - eine stabile Inventarnummer, die Umbenennungen und neue IP-Adressen übersteht.
• Name - eine lesbare Bezeichnung nach einer dokumentierten Namenskonvention.
• Typ oder Klasse - der Platz in der Klassenhierarchie.
• Status - aktiv, in Wartung, inaktiv, ausgemustert.
• Umgebung - Produktion, Staging, Test, Entwicklung.
• Verantwortlicher - eine benannte Person oder ein benanntes Team.
• Version, Modell oder Build - für alles, was gepatcht oder aktualisiert wird.
• Standort - Rechenzentrum, Liegenschaft, Cloud-Region oder Account.
• Seriennummer oder Instanz-ID - die Referenz des Herstellers oder der Plattform.
• Lieferant und Supportvertrag - wen Sie anrufen und bis wann.
• Zugehöriger Service - der Geschäftsservice, den diese Komponente letztlich stützt.
• Beziehungen - die Verknüpfungen zu anderen CIs, dazu gleich mehr.
• Änderungshistorie - ein Audit-Trail darüber, was sich wann und durch wen geändert hat.

Widerstehen Sie der Versuchung, mehr aufzunehmen. Jedes Attribut ist ein Feld, das jemand pflegen muss, und der schnellste Weg, eine CMDB unglaubwürdig zu machen, besteht darin, sie mit Spalten zu füllen, die niemand liest.

Arten von CI-Beziehungen

Die Beziehungen sind das Attribut, das die eigentliche Arbeit leistet. Nimmt man sie weg, schrumpft eine CMDB zu einem gewöhnlichen IT-Inventar mit ein paar Extra-Feldern. Die meisten Modelle gruppieren sie in vier Familien:

• Abhängigkeit - „läuft auf”, „hängt ab von”, „nutzt”. Die Anwendung hängt von der Datenbank ab.
• Zugehörigkeit - „gehostet von”, „Teil von”, „Mitglied von”. Die VM wird vom Hypervisor gehostet, die Platte ist Teil des Arrays.
• Verantwortung - „im Besitz von”, „betreut von”, „verwaltet von”. Verknüpft ein CI mit einem Team oder einer Person.
• Auswirkung - die abgeleitete Sicht: Was fällt nachgelagert aus, wenn dieses CI ausfällt?

Eine durchgespielte Kette macht es deutlich. Access-Switch → Hypervisor-Host → virtuelle Maschine → Datenbankinstanz → Zahlungsservice. Fällt der Switch aus, kann der Service Desk dank dieser einen Verknüpfung den Zahlungsservice in Sekunden benennen, statt zu warten, bis Kunden ihn melden. Liest man dieselbe Kette in der Gegenrichtung, wird daraus eine Bewertung der Änderungsauswirkung: Wer den Hypervisor patcht, muss um die Zahlungen herum planen. Liest man sie ein drittes Mal, wird daraus der Geltungsbereich für Risiko und Compliance - alles in dieser Kette fällt unter die Kontrollen, die Zahlungsdaten schützen.

Das sind drei verschiedene Aufgaben, bedient von einem einzigen Satz Verknüpfungen. Genau deshalb lohnt sich der Pflegeaufwand für Beziehungsdaten dort, wo sie wirklich gepflegt werden, und ist wertlos, wo das nicht geschieht. Dasselbe Prinzip steht auf der Verzeichnisseite hinter der Anlagenstruktur, nur zu deutlich geringeren Kosten.

Der Lebenszyklus eines CI

Ein CI-Datensatz hat ein eigenes Leben, das ungefähr parallel zum IT-Asset-Lebenszyklus verläuft:

1. Planung und Entwurf - die Komponente wird spezifiziert, eine CI-Klasse und eine Namenskonvention werden festgelegt.
2. Beschaffung oder Bau - gekauft, bereitgestellt oder gebaut.
3. Identifizieren und erfassen - eine eindeutige CI-Kennung wird vergeben und der Datensatz angelegt. Das ist der Schritt, den Teams überspringen, und alles Nachgelagerte erbt die Lücke.
4. Test - Prüfung gegen die vorgesehene Konfiguration oder Baseline.
5. Inbetriebnahme - Überführung in die Produktion, wobei Beziehungen erfasst werden, sobald sie entstehen.
6. Frühe Betreuung - enge Beobachtung; der Datensatz wird korrigiert, solange die Details noch frisch sind.
7. Betrieb - im Einsatz, wobei jede Änderung im Datensatz nachgezogen wird.
8. Ausmusterung und Entsorgung - Status auf „ausgemustert” gesetzt, Beziehungen aufgelöst, und das physische oder vertragliche Ende über Stilllegung und ITAD abgewickelt.

Jede Phase entspricht einem Statuswert, den der Datensatz tatsächlich trägt: aktiv, in Wartung, inaktiv, ausgemustert. Ein Statusfeld, das niemand aktualisiert, ist der erste Teil einer CMDB, der verrottet, und ausgemusterte, aber noch verknüpfte CIs sind die häufigste Ursache dafür, dass eine Abhängigkeitskarte still und leise aufhört, der Realität zu entsprechen.

Wie Sie entscheiden, was ein CI wird

Vier Fragen, in dieser Reihenfolge:

1. Muss eine Änderung daran geprüft oder auditiert werden? Wenn eine Änderung durch ein Änderungsgremium läuft oder in einem Compliance-Bericht landet, modellieren Sie sie.
2. Betrifft ein Ausfall einen Service, den Nutzer bemerken würden? Wenn ja, lohnt es sich, die Abhängigkeiten abzubilden.
3. Ist wirklich jemand dafür verantwortlich? Ein CI ohne benannten Verantwortlichen ist ein Datensatz ohne Pfleger.
4. Wird der Datensatz aktuell gehalten? Lautet die ehrliche Antwort nein, legen Sie ihn nicht an.

Danach legen Sie die Detailtiefe fest: Verwenden Sie die gröbste Klassifizierung, die Ihre Fragen noch beantwortet. Jede zusätzliche Detailebene vervielfacht den Pflegeaufwand, ohne die Entscheidungen zwangsläufig zu verbessern. „Datenbankserver” als ein CI reicht oft aus; ihn in Gehäuse, RAID-Controller und einzelne Platten zu zerlegen, reicht selten weiter - es sei denn, Sie tauschen diese Teile unabhängig voneinander.

Bei Cloud- und kurzlebigen Ressourcen modellieren Sie die stabile Vorlage statt jeder einzelnen Instanz: die Autoscaling-Gruppe, nicht die vierzig Container, die sie heute Nachmittag gestartet hat; die Funktionsdefinition, nicht jede Ausführungsumgebung. Eine saubere Tagging-Disziplin im Cloud-Account bringt hier mehr als jede noch so genaue Modellierung auf Instanzebene. Und die Regel, die über allem steht: Modellieren Sie nicht, was Sie nicht pflegen werden.

Woher die CI-Daten kommen

CI-Datensätze entstehen und bleiben auf drei Wegen aktuell, meist in Kombination.

Manuelle Erfassung geschieht beim Kauf oder bei der Inbetriebnahme. Das ist der genaueste Weg für alles ohne API - Gebäude-CIs, Dokumentation, Lieferantenverträge - und zugleich der fragilste, weil er vollständig davon abhängt, dass jemand daran denkt.

Massenimport holt herein, was bereits in Tabellen, Beschaffungsunterlagen oder einem anderen System liegt. So starten die meisten Verzeichnisse, und das ist als Ausgangspunkt in Ordnung, sofern die Daten bereinigt werden, bevor sie landen, und nicht danach.

Automatische Erkennung fragt die Umgebung direkt ab. Agentenlose Verfahren lesen aus den APIs von Cloud-Anbietern, Virtualisierung und Netzwerk; agentenbasierte Verfahren installieren Software auf den Hosts und liefern mehr Tiefe, etwa installierte Pakete und laufende Prozesse. Eine kontinuierliche Synchronisation schlägt einen Wochenlauf, denn eine CMDB, die eine Woche hinterherhinkt, führt in genau der Störung, in der es darauf ankommt, ebenso in die Irre wie eine, die ein Jahr alt ist. IT-Discovery beschreibt die Marktlandschaft dazu im Detail.

Der wichtige Vorbehalt: Automatisierung löst die Erhebung, nicht die Struktur. Die Erkennung sagt Ihnen, dass eine Maschine existiert; sie kann Ihnen nicht sagen, welchen Geschäftsservice sie stützt, wer sie verantwortet oder ob das Duplikat, das sie gerade angelegt hat, wirklich ein eigener Host ist. Klassifizierung, Verantwortlichkeiten und Prüfregeln bleiben Handarbeit - deshalb verfallen auch vollständig automatisch erkannte CMDBs, und deshalb bleiben unerkannte Ecken wie Schatten-IT so oder so unsichtbar.

CI-Datensätze vertrauenswürdig halten

Eine teilweise korrekte CMDB ist gefährlicher als gar keine, weil man ihr mitten in einer Störung vertraut. Die Pflegedisziplin, die das verhindert:

• Namen und Schlüsselfelder standardisieren. Eine Namenskonvention, dokumentiert, ab Anlage angewendet. Namen nachträglich zu korrigieren ist eine elende Arbeit.
• Pro CI oder pro Klasse einen benannten Verantwortlichen festlegen, bevor eine Störung die Lücke offenlegt, nicht währenddessen.
• Duplikate und Waisen nach Plan bereinigen. Erkennung erzeugt Duplikate, Außerbetriebnahmen hinterlassen Waisen. Die Abstimmung des Bestands ist die Routine, die beides einfängt, und so werden auch Karteileichen - Datensätze für Dinge, die es nicht mehr gibt - ausgeräumt.
• Attribute auf Felder begrenzen, die jemand liest. Ungenutzte Felder bleiben nicht leer, sie füllen sich mit plausiblem Unsinn.
• Änderungen erfassen, während sie geschehen, nicht in einer jährlichen Aufräumaktion. Die jährliche Aufräumaktion ist der Ort, an dem CMDB-Projekte sterben.

Auch auf Prozessebene sind Verantwortlichkeiten entscheidend: Ein Configuration Manager verantwortet Standards und Audits, Service-Verantwortliche stehen für die CIs hinter ihren Services ein, und der Betrieb spiegelt reale Veränderungen in die Datensätze zurück. Ohne diese drei Rollen ist Datenqualität niemandes Aufgabe.

CI, Asset und Inventarposition im Vergleich

Alle drei beschreiben dieselbe physische Welt aus verschiedenen Blickwinkeln.

Die Mengen überschneiden sich, ohne deckungsgleich zu sein. Ein Produktionsserver ist Asset und CI. Ein Reserve-Monitor ist ein Asset, aber kein CI. Eine kostenlose Open-Source-Bibliothek oder ein Runbook ist ein CI, taucht aber in keiner Bilanz auf - so wie ein Software-Nutzungsrecht lizenzrechtlich ein Asset ist, ganz gleich, ob es jemand in einer CMDB modelliert oder nicht.

Am klarsten zeigt es sich an einer einzelnen VM. Im IT-Asset-Management ist sie eine Kostenstelle, eine Lizenzverbraucherin und eine Zeile im Abschreibungsplan, mit einer Position im Hardware-Austauschzyklus dahinter. In der CMDB ist dieselbe VM ein Knoten mit vier Verknüpfungen zu anderen Knoten. Keine der beiden Sichten ist das ganze Bild, und keine ersetzt die andere.

Brauchen Sie überhaupt eine CMDB?

CMDBs haben sich ihren Ruf des Verfalls verdient. Beziehungsdaten aktuell zu halten ist teuer - jede Architekturänderung, jede Migration und jede Ausmusterung muss nachgezogen werden -, und eine CMDB, die zu 80 Prozent stimmt, ist gerade deshalb gefährlich, weil man ihr mitten in einer Störung vertraut.

Anzeichen, dass Sie eine brauchen: ineinandergreifende Services, bei denen eine Komponente mehrere andere stützt; ein formales Änderungsmanagement mit Freigabegremium; regulierte Verfügbarkeits- oder Prüfpflichten; und ein Betriebsteam, das groß genug ist, dass niemand mehr die ganze Karte im Kopf hat.

Anzeichen, dass ein gut geführtes Inventarverzeichnis reicht: ein paar Dutzend Endgeräte; eine Handvoll SaaS-Mandanten; ein oder zwei Personen, die die IT machen; und Abhängigkeiten, die sich in zehn Minuten auf ein Whiteboard zeichnen lassen.

Der Mittelweg, der zu den meisten Organisationen passt: Beginnen Sie mit einem korrekten Verzeichnis - Verantwortlicher, Status, Standort, Seriennummer, Historie - und ergänzen Sie die Beziehungsmodellierung nur für die kleine Menge an Komponenten, deren Ausfall wirklich teuer wird. Damit holen Sie den größten Teil des Nutzens für die Störungsbearbeitung, ohne sich auf Pflegeaufwand in Konzerngröße einzulassen. Mit einem einfachen Inventarverzeichnis anfangen zeigt, wie das geht, und der Eintrag zur CMDB beschreibt, was die vollständige Variante bedeutet, falls Sie sie doch brauchen.

FAQ

Was heißt CI in der IT?

Das hängt davon ab, in welchem Raum Sie gerade stehen. Im IT-Service-Management steht CI für Configuration Item - eine Komponente, die in einer CMDB geführt wird, weil ein Service von ihr abhängt. In der Softwareentwicklung steht CI für Continuous Integration, den automatisierten Build- und Testschritt einer CI/CD-Pipeline. Beides hat nichts miteinander zu tun. In gemischten Runden aus Entwicklung und Betrieb lohnt es sich deshalb, kurz dazuzusagen, welches CI gemeint ist.

Was ist ein Configuration Item nach ITIL?

ITIL definiert ein Configuration Item als jede Komponente, die verwaltet werden muss, damit ein IT-Service erbracht werden kann. In ITIL 4 gehört das zur Praktik Service Configuration Management, deren Aufgabe es ist, korrekte Informationen über CIs und ihre Beziehungen untereinander vorzuhalten. Die Datensätze liegen in einer oder mehreren CMDBs, und der praktische Test bleibt derselbe: Wenn eine Änderung an der Komponente einen Service beeinflussen kann, ist sie ein CI.

Was ist der Unterschied zwischen Configuration Item und Asset?

Ein Asset-Datensatz beantwortet Eigentums- und Geldfragen: was es gekostet hat, wer es hat, wann die Garantie endet. Ein CI beantwortet Servicefragen: was diese Komponente unterstützt und was ausfällt, wenn sie versagt. Genau deshalb tragen CIs Beziehungen zu anderen CIs. Derselbe Server kann beides sein. Viele Assets werden nie zu CIs (Reserve-Monitore, Möbel), und manche CIs sind gar keine finanziellen Assets (Dokumentation, eine kostenlose Software-Bibliothek).

Was ist der Unterschied zwischen CMDB und Inventarverzeichnis?

Eine CMDB speichert Configuration Items und vor allem die Beziehungen zwischen ihnen, sodass sich nachvollziehen lässt, was ausfällt, wenn eine Komponente ausfällt. Ein Inventarverzeichnis speichert Eigentum, Kosten, Standort, Status und Lebenszyklus der Gegenstände, die Ihnen gehören. Dieselbe VM kann in beidem auftauchen: als abzuschreibende Kostenposition im Verzeichnis und als verknüpfter Knoten in der CMDB. Für die meisten kleinen und mittleren IT-Teams liefert ein gepflegtes Verzeichnis den größeren Teil des Nutzens bei einem Bruchteil des Aufwands.

Was sind Beispiele für Configuration Items?

Hardware: Server, Netzwerk-Switches, Firewalls, die Laptops, von denen ein Service abhängt. Software: Betriebssysteme, Anwendungen, Datenbanken, Middleware. Darüber hinaus alles, was verwaltet wird, um einen Service zu erbringen: SSL-Zertifikate, Cloud-Instanzen, Runbooks und SLA-Dokumente sowie die Services selbst. Jedes CI trägt eine eindeutige Kennung, einen Verantwortlichen, einen Status, wo relevant eine Version und seine Beziehungen zu den CIs, von denen es abhängt.

Muss jedes Asset ein CI sein?

Nein. CIs lohnen sich nur dort, wo die Beziehungsdaten aktiv gepflegt werden. Eine CMDB voller veralteter Verknüpfungen ist schlimmer als gar keine CMDB, weil man ihr mitten in einer Störung vertraut. Üblich ist es, nur die Komponenten als CIs zu modellieren, deren Ausfall Services betrifft (Server, Netzwerktechnik, Kernanwendungen), und alles andere als einfachen Asset-Datensatz mit Verantwortlichem, Status und Lebenszyklus zu führen.

Werkzeuge, die das erleichtern

Wenn Sie beim Mittelweg landen, besteht die Aufgabe in einem korrekten Verzeichnis und nicht in einem Abhängigkeitsgraphen. AMPthilly gibt jedem Gegenstand einen Datensatz mit Kategorie und Unterkategorie, einem Status (im Einsatz, eingelagert, in Reparatur, ausgemustert), aktuellem Besitzer und Standort, Seriennummer, Lieferant, Kaufdatum und Garantieende, dazu eigene Felder je Assettyp für alles, was in Ihrer Umgebung speziell ist. Physische Ausstattung, Softwarelizenzen und Verbrauchsmaterial liegen im selben Verzeichnis, vorhandene Daten lassen sich per CSV importieren und wieder exportieren, druckbare QR-Etiketten öffnen den passenden Datensatz mit der normalen Handykamera im Browser - ohne App-Installation -, und eine dauerhafte Audit-Historie protokolliert jede Ausgabe, Rückgabe, Übertragung, Statusänderung und Feldbearbeitung. Der kostenlose Tarif umfasst 3 Nutzer und 25 Assets, ohne Kreditkarte.

Das Wichtigste in Kürze

Ein Configuration Item ist jede Komponente, die Sie verwalten müssen, um einen IT-Service zu erbringen. Es wird über die Auswirkung auf den Service bestimmt, nicht über den Preis, und es wird erst durch die daneben erfassten Beziehungen nützlich. Bekommen Sie die vier Grundlagen richtig hin - eine eindeutige Kennung, einen benannten Verantwortlichen, einen Status, den jemand pflegt, und Verknüpfungen, die der Realität entsprechen -, dann zahlt sich die CMDB durch schnellere Triage und sicherere Änderungen aus. Bekommen Sie sie falsch hin, wird daraus eine selbstbewusste, veraltete Karte, der Menschen in den falschen Ausfall folgen. Wenn Ihre Umgebung klein genug ist, dass die Abhängigkeiten noch in einen Kopf passen, beginnen Sie mit einem gut geführten Inventarverzeichnis und ergänzen Sie die CI-Modellierung nur dort, wo ein Ausfall wirklich teuer wird.

Verwandte Begriffe

• CMDB - die Datenbank, in der Configuration Items und ihre Beziehungen liegen
• Inventarverzeichnis - die Eigentums- und Kostensicht, die die meisten Teams zuerst brauchen
• IT-Asset-Lebenszyklus - die Phasen vom Kauf bis zur Entsorgung, die die Asset-Sicht abbildet
• Hardware-Austauschzyklus - der geplante Ersatzrhythmus für Hardware-CIs und Assets
• Software-Nutzungsrecht - die Lizenzrechte hinter Software-CIs
• Kauflizenz vs. Abo - die zwei Bezahlmodelle für Software-CIs
• Per-User-Lizenzierung - platzbasierte Lizenzierung, an Nutzer statt an Komponenten gebunden