Wat is een configuration item (CI)?

Een configuration item (CI) is elk onderdeel dat beheerd moet worden om een IT-dienst te leveren - een server, een applicatie, een netwerkswitch, zelfs een document - vastgelegd in een configuration management database (CMDB). De term komt uit ITIL, het meest gebruikte framework voor IT service management. Wat een CI onderscheidt van een gewoon assetrecord is de relatiedata: een CMDB somt niet alleen onderdelen op, maar brengt in kaart hoe ze van elkaar afhangen, zodat bij een storing meteen zichtbaar is hoe ver de schade reikt.

Wat u gaat leren

• Configuration item: de korte definitie
• Waar CI voor staat (en waar niet)
• CI-types met subtypes
• Wat een CI-record bevat
• Soorten CI-relaties
• De levenscyclus van een CI
• Hoe bepaalt u wat een CI wordt?
• Waar CI-data vandaan komt
• CI-records betrouwbaar houden
• CI vs asset vs inventarisregel
• Heeft u echt een CMDB nodig?
• FAQ

Configuration item: de korte definitie

CI = configuration item. ITIL omschrijft het als elk onderdeel dat beheerd moet worden om een IT-dienst te leveren. ISO/IEC 20000 formuleert hetzelfde idee als elk element dat beheerst moet worden om een dienst te leveren. De praktische toets: kan een wijziging eraan de dienstverlening, beschikbaarheid, beveiliging of compliance raken, dan is het een configuration item.

Die toets is bewust bot, want de alternatieve toetsen waar mensen naar grijpen - “is het duur?”, “hebben we het geactiveerd?”, “is het tastbaar?” - leveren allemaal de verkeerde lijst op. Een domeinverlenging van 4 euro is een CI. Een reservemonitor van 900 euro in een kast is dat niet.

Waar CI voor staat (en waar niet)

In IT service management betekent CI configuration item - de betekenis die op deze pagina wordt gebruikt.

In softwareontwikkeling betekent CI continuous integration - de geautomatiseerde build-en-teststap van een CI/CD-pipeline. Dat heeft niets met CMDB’s te maken. Precies daarom is de kale afkorting dubbelzinnig in elk gesprek waarin ontwikkelaars en beheerders samenzitten, en zeggen platformteams hardop “config item” om het misverstand voor te zijn.

In systems engineering en de defensie-industrie is een configuration item iets ouders en strengers: een samenstel van hardware en/of software dat is aangewezen voor apart configuratiebeheer en formeel wordt beheerst tegen een baseline. U komt daar hardware configuration items (HWCI), computer software configuration items (CSCI), interface-CI’s en COTS-CI’s tegen, bijgehouden over functionele, toegewezen en product-baselines, met een change board die elke revisie goedkeurt. Dezelfde term, een andere discipline - en een klassieke bron van verwarring wanneer engineering- en IT-teams wel het woord delen, maar niet de definitie.

CI-types met subtypes

De meeste CMDB’s ordenen CI’s in een klassenhiërarchie, zodat gedeelde attributen en regels worden geërfd in plaats van opnieuw ingevoerd. De gebruikelijke hoofdklassen:

• Hardware- en infrastructuur-CI’s - fysieke en virtuele servers, storage-arrays, load balancers, hypervisors, printers, en de laptops en andere endpoints waar een dienst echt van afhangt.
• Software- en applicatie-CI’s - besturingssystemen, bedrijfsapplicaties, middleware, databases, container images en SaaS-tenants, elk met een versie.
• Netwerk-CI’s - routers, switches, firewalls, VLAN’s en subnetten, DNS-records, VPN-tunnels, wifi-accesspoints en de rest van uw netwerkapparatuur.
• Cloud- en platform-CI’s - managed database-instances, Kubernetes-clusters, storage buckets, IAM-rollen, message queues, en de accounts of abonnementen waarin ze draaien.
• Service-CI’s - de klantgerichte dienst zelf (“salarisadministratie”, “e-mail”), plus API’s en koppelvlakken tussen diensten.
• Documentatie-CI’s - runbooks, netwerkdiagrammen, SLA’s en OLA’s, installatiehandleidingen, en de golden image-definities waaruit builds worden gemaakt.
• Facilitaire CI’s - serverruimtes, UPS-units, PDU’s, klimaatinstallaties en fysieke toegangscontrole, waar een storing daarin de IT meesleurt.
• Leveranciers- en contract-CI’s - de leverancier, het supportcontract of de software entitlement waarop een dienst juridisch of praktisch leunt.

Sommige modellen leggen ook personen en rollen vast als CI, zodat “wie is hier verantwoordelijk voor” in de afhankelijkheidskaart staat en niet in iemands hoofd. De bepalende toets blijft overal service-impact, niet prijs. Een goedkoop SSL-certificaat is een schoolvoorbeeld van een CI, omdat het verlopen ervan een dienst platlegt; een duur item zonder servicerol - reserve externe schijven in een kast, of de vergaderruimte-apparatuur waar niemands uptime van afhangt - is een asset die het waard is om te registreren, maar zelden om als CI te modelleren.

Wat een CI-record bevat

Een bruikbaar CI-record is kort en compleet, niet lang en half ingevuld. De velden die vrijwel elke CMDB verwacht:

• Unieke CI-identifier - een stabiel asset ID dat hernoemingen en nieuwe IP-adressen overleeft.
• Naam - een leesbaar label volgens een vastgelegde naamconventie.
• Type of klasse - de plek in de klassenhiërarchie.
• Status - actief, in onderhoud, inactief, afgevoerd.
• Omgeving - productie, staging, test, ontwikkeling.
• Eigenaar - een met naam genoemde persoon of team dat verantwoordelijk is.
• Versie, model of build - voor alles wat gepatcht of geüpgraded wordt.
• Locatie - datacenter, vestiging, cloudregio of account.
• Serienummer of instance-ID - de referentie van fabrikant of platform.
• Leverancier en supportcontract - wie u belt, en tot wanneer.
• Gerelateerde dienst - de bedrijfsdienst die dit onderdeel uiteindelijk ondersteunt.
• Relaties - de koppelingen naar andere CI’s, hierna behandeld.
• Wijzigingshistorie - een audittrail van wat er wanneer en door wie is veranderd.

Weersta de neiging om meer toe te voegen. Elk attribuut is een veld dat iemand moet onderhouden, en de snelste manier om een CMDB onbetrouwbaar te maken is hem vullen met kolommen die niemand leest.

Soorten CI-relaties

Relaties zijn het attribuut dat het echte werk doet. Haal ze weg en een CMDB zakt terug tot een gewone IT-inventaris met extra velden. De meeste modellen groeperen ze in vier families:

• Afhankelijkheid - “draait op”, “hangt af van”, “gebruikt”. De applicatie hangt af van de database.
• Insluiting - “gehost door”, “onderdeel van”, “lid van”. De VM wordt gehost door de hypervisor; de schijf is onderdeel van de array.
• Eigendom - “eigendom van”, “ondersteund door”, “beheerd door”. Koppelt een CI aan een team of persoon.
• Impact - de afgeleide blik: wat er stroomafwaarts uitvalt als dit faalt.

Een uitgewerkte keten maakt het punt. Toegangsswitch → hypervisorhost → virtuele machine → database-instance → betaaldienst. Valt de switch weg, dan laat die ene koppeling de servicedesk binnen seconden de betaaldienst benoemen, in plaats van te wachten tot klanten het melden. Lees dezelfde keten de andere kant op en het is een impactanalyse voor wijzigingen: de hypervisor patchen betekent inplannen rond betalingen. Lees hem een derde keer en het is risico- en compliancescope - alles in die keten valt binnen de maatregelen die betaalgegevens beschermen.

Dat zijn drie verschillende taken die één set koppelingen bedient, en precies daarom is relatiedata het onderhoud waard waar hij echt wordt bijgehouden - en waardeloos waar dat niet gebeurt. Hetzelfde principe stuurt het modelleren van een asset hierarchy aan de registerkant, tegen veel lagere kosten.

De levenscyclus van een CI

Een CI-record heeft een eigen leven, dat ongeveer parallel loopt aan de IT asset lifecycle:

1. Plannen en ontwerpen - het onderdeel wordt gespecificeerd; een CI-klasse en naamconventie worden gekozen.
2. Inkopen of bouwen - gekocht, uitgerold of gecompileerd.
3. Identificeren en registreren - er wordt een uniek CI-ID toegekend en het record wordt aangemaakt. Dit is de stap die teams overslaan, en alles stroomafwaarts erft dat gat.
4. Testen - geverifieerd tegen de bedoelde configuratie of baseline.
5. Uitrollen - in productie genomen, met relaties die worden vastgelegd zodra ze ontstaan.
6. Nazorg - kort na oplevering scherp gevolgd; het record wordt gecorrigeerd terwijl de details nog vers zijn.
7. In bedrijf - in dienst, met elke wijziging verwerkt in het record.
8. Afvoeren en verwerken - status op afgevoerd, relaties losgekoppeld, en het fysieke of contractuele einde afgehandeld via buitengebruikstelling en IT asset disposition.

Elke fase hoort bij een statuswaarde die het record daadwerkelijk draagt: actief, in onderhoud, inactief, afgevoerd. Een statusveld dat niemand bijwerkt is het eerste deel van een CMDB dat gaat rotten, en afgevoerde-maar-nog-gekoppelde CI’s zijn de meest voorkomende reden dat een afhankelijkheidskaart stilletjes niet meer met de werkelijkheid overeenkomt.

Hoe bepaalt u wat een CI wordt?

Vier vragen, in deze volgorde:

1. Moet een wijziging eraan beoordeeld of geaudit worden? Gaat een wijziging langs een change board of belandt hij in een compliancerapport, modelleer hem dan.
2. Raakt uitval ervan een dienst die gebruikers merken? Zo ja, dan is het de moeite waard de afhankelijkheden in kaart te brengen.
3. Heeft iemand er echt eigenaarschap over? Een CI zonder benoemde eigenaar is een record zonder onderhouder.
4. Wordt het record actueel gehouden? Is het eerlijke antwoord nee, maak het dan niet aan.

Bepaal daarna het detailniveau: gebruik de minst gedetailleerde indeling die uw vragen beantwoordt. Elk extra detailniveau vermenigvuldigt het onderhoud zonder de besluitvorming per se te verbeteren. “Databaseserver” als één CI is vaak genoeg; het opsplitsen in chassis, RAID-controller en losse schijven is dat zelden - tenzij u die onderdelen los vervangt.

Voor cloud en kortlevende resources modelleert u het stabiele sjabloon in plaats van elke vluchtige instance: de autoscalinggroep, niet de veertig containers die hij vanmiddag opstartte; de functiedefinitie, niet elke uitvoeringsomgeving. Discipline in tagging binnen het cloudaccount levert hier meer op dan welke modellering op instanceniveau ook. En de regel die alles overkoepelt: modelleer niet wat u niet gaat onderhouden.

Waar CI-data vandaan komt

CI-records ontstaan en blijven actueel via drie routes, meestal in combinatie.

Handmatige registratie gebeurt bij aanschaf of uitrol. Het is de meest accurate route voor alles zonder API - facilitaire CI’s, documentatie, leverancierscontracten - en tegelijk de kwetsbaarste, omdat hij volledig afhangt van iemand die eraan denkt.

Bulkimport haalt binnen wat al bestaat in spreadsheets, inkoopadministratie of een ander systeem. Zo beginnen de meeste registers, en dat is prima als startpunt, mits de data wordt opgeschoond vóór hij landt in plaats van erna.

Geautomatiseerde discovery bevraagt de omgeving rechtstreeks. Agentloze discovery leest uit de API’s van cloudprovider, virtualisatie en netwerk; agent-gebaseerde discovery installeert software op hosts voor meer diepgang, zoals geïnstalleerde pakketten en draaiende processen. Continue synchronisatie verslaat een wekelijkse job, want een CMDB die een week achterloopt is tijdens het incident dat ertoe doet net zo misleidend als een die een jaar achterloopt. Asset discovery behandelt het marktlandschap uitgebreider.

De belangrijke kanttekening: automatisering lost verzameling op, geen structuur. Discovery vertelt u dat een machine bestaat; hij kan niet vertellen welke bedrijfsdienst die ondersteunt, wie de eigenaar is, of dat de zojuist aangemaakte dubbelaar werkelijk een aparte host is. Classificatie, eigenaarschap en beoordelingsregels blijven mensenwerk - en daarom verrotten volledig gediscoverde CMDB’s alsnog, en blijven onontdekte hoeken zoals shadow IT hoe dan ook onzichtbaar.

CI-records betrouwbaar houden

Een deels kloppende CMDB is gevaarlijker dan geen CMDB, omdat mensen er middenin een incident op vertrouwen. De onderhoudsdiscipline die dat voorkomt:

• Standaardiseer naamgeving en sleutelvelden. Eén naamconventie, vastgelegd, toegepast bij aanmaak. Namen achteraf rechttrekken is ellendig werk.
• Wijs een benoemde eigenaar toe per CI of per klasse vóór een incident het gat blootlegt, niet tijdens.
• Ruim dubbelaars en wezen periodiek op. Discovery maakt dubbelaars; buitengebruikstellingen laten wezen achter. Assetreconciliatie is de routine die beide vangt, en zo verdwijnen ook ghost assets - records voor dingen die niet meer bestaan.
• Beperk attributen tot velden die iemand echt leest. Ongebruikte velden blijven niet leeg; ze vullen zich met plausibele onzin.
• Leg wijzigingen vast op het moment zelf, niet in een jaarlijkse schoonmaak. De jaarlijkse schoonmaak is waar CMDB-projecten sterven.

Eigenaarschap telt ook op procesniveau: een configuratiebeheerder bezit de standaarden en de audits, service-eigenaren zijn verantwoordelijk voor de CI’s achter hun diensten, en beheer verwerkt werkelijke veranderingen in de records. Zonder die drie rollen is datakwaliteit niemands taak.

CI vs asset vs inventarisregel

De drie beschrijven dezelfde fysieke wereld vanuit verschillende hoeken.

De verzamelingen overlappen zonder samen te vallen. Een productieserver is zowel asset als CI. Een reservemonitor is een asset maar geen CI. Een gratis open-source bibliotheek of een runbook is een CI maar staat op geen enkele balans - net zoals een software entitlement in licentietermen een asset is, of iemand het nu wel of niet in een CMDB modelleert.

De helderste illustratie is één VM. In ITAM is hij een kostenpost, een licentieverbruiker en een regel op een afschrijvingsstaat, met een plek in de hardware refresh cycle erachter. In de CMDB is diezelfde VM een node met vier koppelingen naar andere nodes. Geen van beide beelden is het hele plaatje, en geen van beide vervangt het andere.

Heeft u echt een CMDB nodig?

CMDB’s hebben een verdiende reputatie van verval. Relatiedata is duur om actueel te houden - elke architectuurwijziging, migratie en buitengebruikstelling moet worden verwerkt - en een CMDB die voor 80 procent klopt is juist gevaarlijk omdat mensen er middenin een incident op vertrouwen.

Signalen dat u er een nodig heeft: in elkaar grijpende diensten waarbij één onderdeel er meerdere draagt; formeel wijzigingsbeheer met een beoordelingsboard; gereguleerde beschikbaarheid of auditverplichtingen; en een beheerteam dat zo groot is dat niemand de hele kaart nog in zijn hoofd heeft.

Signalen dat een goed bijgehouden assetregister volstaat: een paar dozijn endpoints; een handvol SaaS-tenants; één of twee mensen die de IT doen; en afhankelijkheden die eenvoudig genoeg zijn om in tien minuten op een whiteboard te tekenen.

De middenweg, die de meeste organisaties past: begin met een kloppend register - eigenaar, status, locatie, serienummer, historie - en voeg relatiemodellering alleen toe voor het kleine setje onderdelen waarvan uitval echt duur is. Dat levert het grootste deel van de waarde voor incidentafhandeling op zonder dat u zich vastlegt op onderhoud op enterpriseschaal. Begin met een eenvoudig assetregister laat zien hoe u dat doet, en de pagina over CMDB behandelt wat de volledige variant inhoudt als u besluit dat u die nodig heeft.

FAQ

Waar staat CI voor in IT?

Dat hangt af van de kamer waarin u staat. In IT service management staat CI voor configuration item - een onderdeel dat in een CMDB wordt vastgelegd omdat een dienst ervan afhangt. In softwareontwikkeling staat CI voor continuous integration, de geautomatiseerde build-en-teststap in een CI/CD-pipeline. De twee hebben niets met elkaar te maken, dus in gesprekken waarin dev en ops elkaar treffen loont het om te zeggen welke u bedoelt.

Wat is een configuration item in ITIL?

ITIL omschrijft een configuration item als elk onderdeel dat beheerd moet worden om een IT-dienst te leveren. In ITIL 4 valt dit onder de practice service configuration management, die als taak heeft accurate informatie bij te houden over CI’s en de relaties daartussen. De records staan in een of meer CMDB’s, en de praktische toets blijft ongewijzigd: kan een wijziging aan het onderdeel een dienst raken, dan is het een CI.

Wat is het verschil tussen een configuration item en een asset?

Een assetrecord beantwoordt eigendoms- en geldvragen: wat het kostte, wie het heeft, wanneer de garantie afloopt. Een CI beantwoordt servicevragen: wat dit onderdeel ondersteunt en wat uitvalt als het faalt - en daarom dragen CI’s relaties naar andere CI’s. Dezelfde server kan beide zijn. Veel assets worden nooit een CI (reservemonitoren, meubilair), en sommige CI’s zijn helemaal geen financiële assets (documentatie, een gratis softwarebibliotheek).

Wat is het verschil tussen een CMDB en een assetregister?

Een CMDB bevat configuration items en - cruciaal - de relaties daartussen, zodat u kunt herleiden wat er uitvalt als een onderdeel faalt. Een assetregister bevat eigendom, kosten, locatie, status en levenscyclus van wat u bezit. Eén VM kan in beide staan: als afschrijvende kostenregel in het register en als gekoppelde node in de CMDB. Voor de meeste kleine en middelgrote IT-teams levert een kloppend register het grootste deel van de waarde tegen een fractie van het onderhoud.

Wat zijn voorbeelden van configuration items?

Hardware: servers, netwerkswitches, firewalls, de laptops waar een dienst van afhangt. Software: besturingssystemen, applicaties, databases, middleware. Daarbuiten alles wat beheerd wordt om een dienst te leveren: SSL-certificaten, cloud-instances, runbooks en SLA-documenten, en de diensten zelf. Elk CI-record draagt een identifier, een eigenaar, een status, waar relevant een versie, en de relaties naar de CI’s waar het van afhangt.

Moet elke asset een CI zijn?

Nee. CI’s verdienen zich alleen terug waar de relatiedata actief wordt onderhouden - een CMDB vol verouderde koppelingen is erger dan geen CMDB, omdat mensen er tijdens incidenten op vertrouwen. De gebruikelijke aanpak is om alleen de onderdelen te modelleren waarvan uitval diensten raakt (servers, netwerkapparatuur, kernapplicaties), en al het andere als gewone assetrecords te houden met een eigenaar, een status en een levenscyclus.

Tools die dit makkelijker maken

Landt u op de middenweg, dan is de opgave een kloppend register in plaats van een afhankelijkheidsgrafiek. AMPthilly geeft elk item één record met een categorie en subcategorie, een status (in gebruik, in opslag, in reparatie, afgevoerd), een huidige eigenaar en locatie, serienummer, leverancier, aankoopdatum en einddatum van de garantie, plus eigen velden per assettype voor alles wat specifiek is voor uw omgeving. Fysieke apparatuur, softwarelicenties en verbruiksartikelen staan in hetzelfde register, u kunt via CSV importeren wat u al heeft en het weer exporteren, printbare QR-labels openen het juiste record met een gewone telefooncamera in de browser zonder app te installeren, en een permanente audithistorie legt elke uitgifte, retour, overdracht, statuswijziging en veldaanpassing vast. Het gratis plan dekt 3 gebruikers en 25 assets, zonder creditcard.

De kern

Een configuration item is elk onderdeel dat u moet beheren om een IT-dienst te leveren, herkend aan service-impact in plaats van prijs, en pas echt bruikbaar door de relaties die ernaast worden vastgelegd. Krijg de vier basisdingen goed - een uniek ID, een benoemde eigenaar, een status die iemand bijwerkt en koppelingen die de werkelijkheid weergeven - en de CMDB verdient zichzelf terug in snellere triage en veiliger wijzigingen. Krijg ze verkeerd en het wordt een zelfverzekerde, verouderde kaart die mensen de verkeerde storing in stuurt. Past uw omgeving nog in het hoofd van één persoon, begin dan met een goed bijgehouden assetregister en voeg CI-modellering alleen toe waar uitval echt duur is.

Gerelateerde termen

• CMDB - de database waarin configuration items en hun relaties staan
• Assetregister - het eigendoms- en geldperspectief dat de meeste teams eerst nodig hebben
• IT Asset Lifecycle - de aankoop-tot-afvoerfasen die het assetperspectief volgt
• Hardware Refresh Cycle - het geplande vervangingsritme voor hardware-CI’s en assets
• Software Entitlement - de licentierechten achter software-CI’s
• Perpetual vs Subscription License - de twee manieren waarop software-CI’s worden betaald
• Per-User Licensing - seat-gebaseerde licenties gekoppeld aan gebruikers in plaats van onderdelen