Configuration and Asset Management

Why it matters

At 02:00 a storage array in Kestrel Energy's data center reports a failed controller. Which services are at risk? On Tuesday a network engineer wants to replace a switch. What runs behind it? The software vendor announces a license audit. How many installations does Kestrel have, and how many licenses did it buy? Without reliable records, each answer takes hours of asking around — and is often wrong.

Two practices answer these questions. Service configuration management keeps track of the components that make up services and how they depend on each other. IT asset management keeps track of what the organization owns or uses, what it costs and what the contracts say. They share much of their data, which is why they are often handled together, and why this page covers both.

Configuration items

A configuration item (CI) is any component that needs to be managed in order to deliver a service. That is broader than hardware:

• Hardware: servers, switches, routers, storage arrays, laptops.
• Software: operating systems, databases, applications, each in a specific version.
• Cloud resources: virtual machines, managed databases, storage buckets, load balancers.
• Documentation: the service level agreement (SLA), the runbook, the network diagram, the disaster recovery plan.
• Services themselves: the Customer Portal is a CI that other CIs support.

Not everything is worth tracking as a CI. A mouse is not; a firewall is. The test is whether you need to control changes to it and know its relationships to keep a service running.

Attributes and relationships

Each CI has attributes — facts about the CI itself — and relationships to other CIs. The attributes tell you what it is; the relationships tell you why it matters.

CI:            db01
Class:         Database server (virtual)
Status:        In production
Environment:   Production
IP address:    192.0.2.31
OS / software: Ubuntu 24.04 LTS, PostgreSQL 16.4
Owner:         Database team (support group), Hamid Rahimi (CI owner)
Location:      Data center DC1, cluster vc-dc1-02

Relationships
  runs on          vc-dc1-02 (virtualization cluster)
  stores data on   san-01 (storage array)
  connects via     sw-dc1-b (switch)
  used by          Customer Portal (IT service)
  used by          Mobile App API (IT service)
  used by          Billing (IT service)
  documented in    KB-0418 "Portal database failover"

Typical relationship types are "runs on", "depends on", "connects to", "used by", "installed on" and "documented in". Keep the set small and use it consistently; twenty relationship types that each team interprets differently are worse than five that everyone understands.

The CMDB and the configuration management system

A configuration management database (CMDB) is the database that stores CI records, their attributes and their relationships. Most IT service management (ITSM) tools include one: ServiceNow, Jira Service Management (through its Assets feature), TOPdesk and Freshservice all have a CMDB module that is linked to incident, problem and change records.

In practice, configuration information is rarely in one place. The network team keeps device data in its monitoring tool, the cloud team's infrastructure lives in Terraform state, finance has the asset register. The configuration management system (CMS) is the wider set of tools and data sources that together hold the configuration information, with the CMDB as one of them. A good CMS lets you see a combined view without forcing everything into one database.

Service configuration management is the practice that makes sure accurate, reliable information about CIs and their relationships is available when and where it is needed. Its goal is not a complete inventory; it is information good enough to make decisions — about incidents, changes and risk — quickly and correctly.

Service maps and impact analysis

A service map (or dependency map) is a picture of an IT service and the CIs it depends on, built from the relationships in the CMDB. It shows at a glance what supports a service — and therefore what can break it.

With the relationships stored as data, impact analysis becomes a calculation: start at the failed CI and follow the relationships upward to every CI and service that depends on it. This is what an ITSM tool does when the network operations center (NOC) links an alert to a CI:

# Each CI and the CIs it depends on (from the CMDB)
DEPENDS_ON = {
    "Customer Portal": ["app-portal-01", "app-portal-02", "db01"],
    "Mobile App API": ["api01", "db01"],
    "Billing": ["bill-app-01", "db01"],
    "Meter Reading Import": ["bill-app-01", "sftp-01"],
    "app-portal-01": ["sw-dc1-a"],
    "app-portal-02": ["sw-dc1-b"],
    "api01": ["sw-dc1-a"],
    "bill-app-01": ["sw-dc1-a", "san-01"],
    "sftp-01": ["sw-dc1-a"],
    "db01": ["sw-dc1-b", "san-01"],
    "sw-dc1-a": ["rtr-dc1-edge"],
    "sw-dc1-b": ["rtr-dc1-edge"],
}
SERVICES = {"Customer Portal", "Mobile App API", "Billing", "Meter Reading Import"}


def affected_by(failed):
    """Return every CI that depends, directly or indirectly, on `failed`."""
    affected, to_check = set(), [failed]
    while to_check:
        current = to_check.pop()
        for ci, needs in DEPENDS_ON.items():
            if current in needs and ci not in affected:
                affected.add(ci)
                to_check.append(ci)
    return affected


for failed in ("sw-dc1-a", "san-01"):
    affected = affected_by(failed)
    print(f"If {failed} fails:")
    print("  CIs:     ", ", ".join(sorted(affected - SERVICES)))
    print("  Services:", ", ".join(sorted(affected & SERVICES)))

If sw-dc1-a fails:
  CIs:      api01, app-portal-01, bill-app-01, sftp-01
  Services: Billing, Customer Portal, Meter Reading Import, Mobile App API
If san-01 fails:
  CIs:      bill-app-01, db01
  Services: Billing, Customer Portal, Meter Reading Import, Mobile App API

Notice what this simple analysis gets wrong: if sw-dc1-a fails, the Customer Portal still runs on app-portal-02 behind the other switch. It is at risk (no redundancy left), not down. Real CMDBs record redundancy, for example as a cluster CI that needs one of its two members, so the impact can be "degraded" instead of "outage". The storage array, on the other hand, really is a single point of failure for all four services — exactly the kind of finding a service map should make visible before 02:00.

Discovery and keeping it accurate

Automated discovery is the use of tools that scan networks, query devices and read cloud provider interfaces to find CIs and their attributes — and sometimes their relationships, by watching which servers talk to which — and update the CMDB without anyone typing. Discovery tools log in to servers (with a read-only account), poll network devices over Simple Network Management Protocol (SNMP), and call the cloud providers' application programming interfaces (APIs).

The typical failure is the CMDB nobody trusts. A few records are out of date, so engineers check the real systems instead; because nobody uses the CMDB, nobody updates it; within a year it is fiction. Breaking that cycle takes three things: discovery for everything that can be discovered, updates built into the processes that change things (closing a change record updates the CIs it touched), and regular reconciliation — comparing what discovery finds with what the CMDB says, and fixing the differences.

In the cloud, infrastructure described in code is already a kind of configuration record. The gap between that code and reality is configuration drift, and the same rule applies: changes made outside the agreed path make the records wrong. See Infrastructure as Code.

IT asset management

An IT asset is any component with a financial value that contributes to delivering an IT product or service: a laptop, a server, a software license, a cloud subscription, a support contract. IT asset management (ITAM) is the practice of planning and managing the full lifecycle of IT assets, so that the organization gets the most value from them, controls their costs, manages risks, and meets its contractual and legal obligations.

Where configuration management asks "how does this work with everything else?", asset management asks "who owns it, what did it cost, what does the contract say, and when does it go?". Kestrel's 2,000 laptops are assets that finance depreciates over four years; most of them are not interesting as CIs.

The asset lifecycle

The asset lifecycle is the series of stages an asset goes through, from deciding it is needed until it has left the organization:

The last stage is where asset management meets security. A laptop or disk that leaves the organization with readable data is a data breach waiting to happen; see secure disposal in the Security topic for wiping and destruction methods.

Software asset management

Software asset management (SAM) is the part of IT asset management that deals with software licenses: knowing what software is installed and used, what the license terms allow, and whether the two match. Licenses come in many forms — per user, per device, per processor core, per subscription — and the rules for virtual machines and cloud use differ per vendor.

SAM matters for two reasons. Audits: software vendors have the contractual right to check license use, and being under-licensed leads to back payments and penalties. Waste: organizations typically pay for subscriptions nobody uses — licenses of people who left, or of tools tried once. Reclaiming those at the "retire" stage of each user's devices and accounts pays for much of the SAM effort.

CI or asset?

How other practices use the CMDB

• Incident management links each incident to the affected CI, sees at once which services are hit and who supports the CI, and finds recent changes to it — the first question in any outage is "what changed?".
• Change enablement uses the relationships to assess the impact and risk of a change before it is approved, and updates the CIs once it is implemented.
• Problem management looks for patterns: twelve incidents in a quarter on CIs of the same model and firmware version point to a common cause.
• Event management uses dependencies to correlate alerts, so one switch failure produces one alert, not forty.

That is the real test of a CMDB: not how complete it is, but whether people reach for it during an incident or a change because it gives the right answer faster than anything else.