Application portfolio management stalls when it inventories everything before deciding anything. A narrower approach reaches a decision in a quarter.
Application portfolio management has an image problem, and it is partly deserved. The classic approach — inventory every application, score each one on business fit and technical health, build a rationalization matrix, present it — takes a long time and often arrives after the questions that prompted it have been answered some other way.
The underlying discipline is sound. The sequencing is usually wrong.
Why the inventory-first approach stalls
Three things reliably go wrong.
The inventory is never complete, and completeness becomes the goal. Every time you think you have the list, someone surfaces twelve more applications in a business unit that procured them directly. Chasing the last 10% consumes months and produces almost no decision value, because the applications nobody can find are rarely the expensive ones.
Scoring without a decision in view invites debate. If nobody knows what the score will be used for, every owner argues that their application scores higher than you think. The conversation becomes about methodology.
The output arrives after the decision. The CFO asked a question in Q1. The portfolio analysis lands in Q4. By then someone has made a call with worse information, and the analysis becomes a document rather than an input.
Start from the decision, not the inventory
Flip it. Ask what decision needs making in the next two quarters, then collect only the data that decision requires.
Common decisions that genuinely need portfolio data:
- We are consolidating after an acquisition — which overlapping applications do we keep?
- Our maintenance spend is growing faster than the IT budget — what can we retire?
- We are moving to cloud — what is the migration order, and what should not migrate at all?
- A vendor is sunsetting a product we depend on — what is actually affected?
- We need to reduce the number of systems holding customer data — which ones are they?
Each of these needs a different and much smaller dataset than a full portfolio assessment. The consolidation question needs capability overlap and contract dates, not technical health scores for everything. The cloud question needs hosting, dependency and compliance data for a defined set.
The data that earns its keep
Across most of these decisions, a small set of attributes does the heavy lifting:
- Business capability supported — the basis of every overlap conversation
- Business owner and technical owner — if neither exists, that is a finding
- Annual cost — license, support, hosting, and the internal effort to keep it running
- Contract renewal or end-of-support date — this creates the natural decision calendar
- User count and usage trend — often the fastest route to retirement candidates
- Data classification — whether it holds regulated or sensitive data
- Integration count — the best available proxy for how hard it is to remove
That is seven attributes. You can gather them for 150 applications in weeks. Gathering thirty attributes for 900 applications takes a year and answers no question sooner.
Where ServiceNow APM fits
If you run ServiceNow, the APM capability gives you a reasonable place to hold this — business applications linked to capabilities, lifecycle dates, cost and risk indicators, with the relationship to your CMDB already available.
The caution is the same as with any portfolio tooling: it will faithfully store whatever quality of data you put in it. The platform does not create ownership. If the application records have no owner and the cost data was estimated once in 2023, the dashboards will be confidently wrong. Decide ownership and data sourcing before you configure, and point discovery and your financial systems at the fields they can populate automatically so the manual set stays small enough to maintain.
A one-quarter shape
Weeks 1–2: fix the decision. Write down the question, who will answer it, and when. Get agreement that this analysis is the input to that answer.
Weeks 2–5: scope and gather. Identify the applications genuinely in scope — usually far fewer than all of them — and collect the small attribute set. Use what already exists: contract records, financial systems, discovery data, identity logs for usage.
Weeks 5–8: analyze against the decision. Overlap, cost, risk and dependency analysis aimed at the specific question. Resist the pull toward a general-purpose scoring model.
Weeks 8–10: recommend and decide. Options with trade-offs, a recommendation, and a decision meeting on the calendar before the analysis starts.
Weeks 10–12: set up the ongoing routine. Now — and only now — decide what to maintain permanently. You will know which attributes were useful because you just used them.
That last step is where APM becomes a capability rather than a project. But it works far better after a decision has proved which data mattered, rather than before, when every attribute looks equally plausible.
The test
A portfolio program is working if someone outside IT has used its output to make a decision in the last quarter. If the only consumers are the architects who maintain it, it has become a map of the territory that nobody navigates by.
Narrow it, point it at a live decision, and let the permanent scope grow out of what proved useful.