Inventory Decay Rate

An EA team records applications with their owner, hosting, data entities, integrations and lifecycle status, and maintains it by emailing owners once a quarter to confirm their entries. Two years later the repository is cited in decisions and nobody knows its error rate.

The arithmetic is unforgiving. If roughly 8% of records change in a quarter and a confirmation round corrects only the 60% of owners who reply, the share of wrong records converges on something like a quarter of the model. The exact figure does not matter; the shape does. Decay is continuous and correction is periodic and partial, so error accumulates towards a steady state above zero.

Why it matters

Past a certain error rate the model becomes negative value rather than low value. Users begin verifying it against reality before trusting it, which costs more than not having it, and the ones who do not verify make decisions on wrong data while believing otherwise.

The rate also sets the model's maximum useful breadth. Every extra attribute is another thing that can go stale, and attributes decay at wildly different speeds: a system's name is nearly static, its owner changes with every reorganisation, its integrations change constantly. A model that treats all attributes as one maintenance task decays at the rate of its fastest-moving field, which is why complete metamodels fail faster than small ones.

Implementation patterns

• Derive rather than ask. Owner from the code repository's owning team, hosting from cloud accounts and tags, integrations from observed traffic or gateway configuration, lifecycle from deployment activity. Anything available from a system of record should never be typed by a human.
• One named source and refresh frequency per attribute. An attribute with no feed is a liability, and the honest response is to delete it.
• Publish freshness per record: the source and the last-verified date, so a stale field is visibly stale rather than quietly wrong.
• Measure the rate directly. Sample 20 applications a quarter, verify every attribute by hand, and publish the error rate per attribute. An EA repository without a measured accuracy number is an unaudited claim, and the per-attribute breakdown tells you which fields to automate first.
• Put the register where the work happens. Inventories embedded in deployment pipelines or access-request flows stay accurate because an error costs the person at the point of pain; standalone repositories do not.
• Attach every attribute to a question somebody asked in the last year. Unasked attributes are pure decay.

Industry example

The pattern is visible wherever a derived inventory and a declared one are compared: an identity provider's list of single sign-on applications and OAuth grants routinely exceeds a surveyed application list by a large margin, because the survey measures awareness and the grants measure usage. The same contrast appears in regulated contexts — DORA's register of information, applicable to EU financial entities since January 2025, is maintained by many firms as a derived artefact precisely because an annually confirmed spreadsheet cannot satisfy a supervisor asking about last month. The lesson is independent of the framework: a register that is not fed is a snapshot with a half-life.

Failure scenarios

• Silent non-response recorded as "unchanged", which converts a missing answer into a false assertion.
• A complete model with a hidden error rate, cited confidently in investment decisions.
• Decay concentrated in the fields that matter, since ownership and hosting change fastest and are exactly what a security or migration question needs.
• A tool purchased to fix a feed problem. The repository was never the constraint, and the new one decays identically.
• Reconciliation theatre, where a quarterly exercise produces a compliance artefact and the numbers are never compared with reality.

Trade-offs

The derived model's real limitation is that it cannot capture why — why a tool was adopted, which business capability an application serves, what the owner intends to do with it. That is the one thing a survey does better, which is why a small human-maintained layer over a derived base is usually the right shape.

When not to use it

If the estate is small enough that the people in one room know it, the room is the inventory and the metric is ceremony. If a model exists only to satisfy an annual audit question with a defined scope, measure that scope and nothing else. And do not measure decay on attributes you have already decided not to maintain — delete them instead, because a published error rate on a field nobody feeds is just a slower way of admitting it should not be there.

Interview question

Q: You inherit an EA repository covering 400 applications with 18 attributes each, maintained by quarterly email. Leadership trusts it. How would you find out whether it should be trusted, and what would you change in the first quarter?

What a strong answer covers: sampling to measure the error rate per attribute before proposing anything, so the argument rests on data rather than suspicion · the distinction between continuous decay and periodic correction, and why non-response recorded as unchanged is the worst mechanic in the system · deleting attributes with no feed rather than trying to maintain them · the derived-versus-declared split and what each is genuinely good for · embedding the register in a workflow people already use · and publishing the accuracy figure alongside the model, which is the change that most alters how it is used.

Quick check

Quiz: Why does recording a non-response as "unchanged" make a repository worse than leaving the field blank? — Because it converts absence of information into a positive assertion, so users cannot distinguish a verified record from an unverified one and the model's error rate becomes invisible.

Flashcard: What sets the maximum useful breadth of an estate model? — The decay rate of its fastest-moving attribute, because a model maintained as one task is only as current as its most volatile field.