Should I build an application inventory on the CMDB before buying APM?

Yes, build a credible application inventory on what you already have before you buy Application Portfolio Management or Enterprise Architecture modules. Clean ownership, naming and change control on Business Application records create more value than another licence on messy data.

Why this matters

Many teams sit on hundreds of application names in spreadsheets, Power Apps lists and departmental trackers, then hope a new APM module will somehow organise them. It will not. John Sansbury is blunt about this in The Journey to Service Excellence: "The simple fact is that without good component information, most of the other service management processes will be sub-optimised, at best." An application inventory is a slice of service component management. Until owners, support groups and relationships are trustworthy, problem analysis, change impact and service costing all stay guesswork.

ITIL 4 covers this under the Service Configuration Management practice: maintaining accurate information about configuration items so other practices can rely on it. PeopleCert offers an ITIL 4 Practitioner module for that practice for the same reason. Buying APM before the base inventory is trustworthy is buying reporting on data nobody believes.

Practical steps

1. Decide what counts as an application. Agree a plain definition with service owners and architects: a named capability users recognise, with a business owner and a support group. Exclude one-off scripts and personal macros.

2. Put controls in place before the big load. John reverses the usual order on purpose. After outlining identify, record, map and control, he writes: "Step 4 actually needs to be undertaken FIRST and then ensure any changes are subject to operational change management, otherwise you’re chasing a moving target!" Agree who can create or retire a Business Application record, how naming is checked, and that every material inventory change rides through change management.

3. Start where you are. Import the legacy tracker as a candidate list, not as gospel. Mark each row confirmed, duplicate, retire or unknown. Keep what already works. The guiding principle John captions as "Start Where You Are or ‘Don’t Throw the Baby out with the Bathwater’" is exactly this: do not discard usable ownership data just because the old store was a spreadsheet.

4. Record a short mandatory set. Owner (a named person), support group, status (live, planned, retiring), and a stable coalesce key such as a unique short name. Add contract end date and annual cost only from a reliable source, on the contract record or a few custom fields with a steward. Do not invent fields you cannot maintain.

5. Map the relationships that matter. John's distinction helps: "This is the crucial step because it is the relationships and interdependencies that essentially distinguish a component management system from an asset register." For day one, link each confirmed application to the business services it underpins and to the main platforms it runs on. Expand later.

6. Prove the inventory under change and incident load. For two weeks, require major changes and major incidents to name the affected Business Application records. The gaps you find are the real backlog.

7. Only then decide on APM or EA. Use MoSCoW with the people who will own the portfolio view. If the base CMDB inventory already answers leadership's questions, delay the licence.

Vendor note: in ServiceNow, teams often use Business Application records on the base CMDB and CSDM patterns without an EA licence. That can be enough for a first credible inventory, provided ownership and controls are real. Treat vendor feature names as vendor material, not as ITIL mandates.

A short worked example

This is an illustrative example, not a client case. A public-sector IT team inherited about 600 application rows from a Power Apps list and no APM licence. They defined an application as something with a business owner and active users, froze uncontrolled edits, and loaded candidates into Business Application with owner, support group, status and a short-name key. After three workshops they retired 180 duplicates and orphans, linked 220 confirmed apps to catalogue services, and left cost on the contract table until owners signed figures off. Six weeks later, change advisors could name affected applications without a side spreadsheet. Leadership deferred EA licensing because the inventory already answered their first questions.

Common mistakes

1. Loading every legacy row as a live Business Application. You import noise and teach people not to trust the CMDB.
2. Capturing cost and contract dates with no steward. Wrong money fields destroy credibility faster than missing ones.
3. Waiting for APM to invent ownership. A module cannot invent a human owner.
4. Mapping every technical dependency on day one. Start with service links that change and incident teams will use.
5. Treating the CMDB as a project that ends. Without change control on the records, accuracy decays within months.

Where to go next

If you are choosing what to record now versus later, use the MoSCoW approach from John's tools chapters with service owners and architects in the room. On ESM's Exchange, the Service Configuration Management topic and the piece on using MoSCoW to prioritise tool requirements give a shared language for that conversation. The AI Enablement Toolkit MAP step is also useful when you need to follow a value stream across applications, teams and hand-offs before you automate anything.

Readers who want the fuller argument will find it in John Sansbury's The Journey to Service Excellence, available to Exchange members.

Tags: esm-questions, cmdb, service-configuration, itsm, application-portfolio

Sources

• https://www.reddit.com/r/servicenow/comments/1xmtyyf/building_an_application_inventory_on_base_cmdb/

• https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-service-configuration-management-3800

• https://www.axelos.com/certifications/itil-service-management/itil-practices-manager/itil-4-practitioner-service-configuration-management/