You inherit an estate of 300 applications. What do you record about each and what decision does it support?
Show the full answer Hide the answer
What is being tested
Whether you keep the record small enough to be maintained, and whether every field supports a decision.
What to record — and nothing more
| Field | Decision it supports |
|---|---|
| Capability supported | Duplication and gap analysis |
| Owning team | Who to contact; which applications are orphaned |
| Data entities mastered | Resolving conflicting numbers; deletion and residency |
| Lifecycle stage | Whether to invest, contain or retire |
| Business criticality | Continuity prioritisation and recovery order |
| Integration points | Blast radius of a change or a retirement |
| Technology and version | Obsolescence exposure |
Seven fields. A catalogue with 400 attributes per application is unmaintainable and therefore unmaintained, which is the usual fate.
The lifecycle classification that does the most work
- Invest — differentiating, actively developed.
- Maintain — necessary, stable, minimal change.
- Contain — no new investment, no new integrations, migrate consumers away.
- Retire — with a date and a plan.
The "contain" classification is the load-bearing one. Making it explicit is what stops an application scheduled for retirement quietly acquiring three new dependencies, which is how a system due to be switched off in 2019 is still load-bearing.
What the record immediately reveals
- Duplication. Three applications maintaining customer records; four sending email. Invisible from inside any one of them.
- Orphans. Applications with no owning team — the ones that fail unpatched and are discovered during a security incident.
- Disputed mastership. Where two applications both claim to master an entity, reconciliation problems and conflicting reports follow.
- Integration sprawl. If the count grows with the product of applications rather than their sum, the estate has a topology problem.
- Gaps. Capabilities with no supporting application, usually handled by a spreadsheet somebody maintains personally.
How to gather it without a two-year programme
Start with the top 20% by criticality and spend, which will account for most of the risk and cost. Populate from what already exists — configuration management data, cloud tags, deployment pipelines, network flows — rather than by survey, and use surveys only to fill gaps.
What a strong answer adds
That the record must be maintained by a process, not a project. A catalogue accurate on the day it was produced and misleading ever after is worse than none, because people act on it. Tie updates to events that already happen — a new deployment, a team change, a decommissioning — rather than to an annual refresh nobody funds.