Why You Can't Answer "What Does This App Cost?"

Ask a finance partner what an application costs and you get a pause, then a spreadsheet, then a different number from the next person you ask. This is not a data-entry problem. It is a model problem. The money is real, and it is recorded. It just never arrives at the application.

Where the cost actually lands

Trace a typical expense through a service management platform and watch where it stops:

• Contracts attach to a vendor and, if you are lucky, a software product.
• Invoices and expense lines attach to assets and configuration items: a server, a license, a device.
• Labor attaches to a cost center, which is an organization, not a system.

Every one of those records is accurate. None of them points at a business application. Expense lines carry configuration items, and in most instances you will find that not one of those items is an application. The servers know exactly what they cost. The servers do not attend budget meetings.

The money is all there. It's just been carefully filed somewhere the question can't reach.

The three paths that get it there

Cost reaches an application through relationships, and every path depends on a link most CMDBs skip:

1. Infrastructure path. Expense on a server rolls up through the application service it supports to the business application. No service layer, no rollup.
2. Contract path. Contract value flows to the software product, then to the application that uses it. This needs the product and the application to be separate, linked records.
3. Allocation path. Shared costs — a platform team, a data center — are allocated by a rule you write down and defend. Unwritten allocations are just opinions with decimal points.

Estimate versus actual

While the plumbing gets fixed, people will estimate. That is fine, as long as estimates and actuals never share a column. Rules that keep the number honest:

• Label the source. Every figure is either estimated by architecture or invoiced by finance. Never blended silently.
• Actuals win. If an application already has invoiced actuals, skip the estimate entirely. Adding both double-counts, and double-counting is how cost reports lose credibility for a year.
• Spread evenly, state the rule. A multi-year contract is amortized evenly across its term unless finance says otherwise. Use the total contracted amount, including add-ons, excluding tax, and say so on the record.
• Expect permissions. Cost tables are often locked down more tightly than the CMDB. Plan for read access early or the analysis stalls at the first query.

Why it matters for rationalization

A TIME disposition without cost is a feeling. "Eliminate" lands differently when the application costs almost nothing to run, and "tolerate" stops sounding harmless when it quietly costs as much as its replacement. You can rationalize without cost data. You just can't defend it.

Copy this: the cost-path check

COST TRACEABILITY CHECK - per business application A
  infra_path    : A -> application service(s) -> infra CIs with expense lines?
  contract_path : A -> software product(s) -> contracts with a total amount?
  alloc_path    : A -> shared platform(s) -> written allocation rule?
  source        : invoiced actual | architecture estimate | none
  IF source = invoiced actual: skip estimate (no double-count)
  IF no path reaches A: report "cost not traceable" - do not guess
  amortize      : total contracted amount (incl. add-ons, excl. tax),
                  evenly over the term, rule recorded on the record