Application Portfolio Management
Application Portfolio Management (APM) is the practice of inventorying every application an organization owns and assessing each one against business fit, technical health, and cost.
At a glance
Section titled “At a glance”- What it is: A complete application inventory, assessed and classified (e.g. via TIME: Tolerate, Invest, Migrate, Eliminate).
- Why it matters: Most enterprises struggle less with the cost of building new things and more with the cost of never turning anything off.
- For developers: if you’re asked to add a feature to a system already flagged Eliminate or Migrate on the TIME grid, that’s a signal to push back and ask whether the work belongs on its replacement instead.
- When to use it: Ongoing, and specifically before roadmapping or target-operating-model gap analysis.
- When not to use it: As a one-time snapshot — a stale inventory is as misleading as no inventory at all.
- Prerequisites: Business Capability Mapping, since applications are assessed against the capabilities they support.
Mental model
Section titled “Mental model”| Good technical health | Poor technical health | |
|---|---|---|
| Strong business fit | Tolerate | Invest |
| Weak business fit | Migrate | Eliminate |
TIME classifies every application along two axes — how well it fits the business need, and how healthy it is technically — to turn a long list of systems into a short list of decisions.
Step-by-step walkthrough
Section titled “Step-by-step walkthrough”- Build (or refresh) a complete application inventory, including shadow IT.
- Link each application to the business capabilities it supports.
- Score each application on business fit and technical health.
- Classify each application using TIME.
- Feed Migrate/Eliminate items into the transformation roadmap; prioritize funding for Invest items.
- Refresh the inventory on a regular cadence — it decays as systems are added, retired, and replaced.
Worked example
Section titled “Worked example”A legacy claims system with strong business fit but poor technical health (unsupported platform, hard to change):
- Input: TIME assessment scores it high on business fit, low on technical health.
- Process: this combination maps to Invest — modernize rather than tolerate or eliminate.
- Output: the application becomes a funded modernization candidate on the roadmap, instead of being left to degrade further.
Common use cases
Section titled “Common use cases”| Use case | When to use | Notes |
|---|---|---|
| Prioritizing modernization spend | Annual/quarterly planning | Invest/Migrate/Eliminate items become roadmap candidates |
| Finding redundancy | Multiple systems doing the same thing | Link apps to capabilities to expose duplication |
| Baseline for a Target Operating Model | Before gap analysis | Current-state inventory is the baseline TOM compares against |
Advanced details
Section titled “Advanced details”- Data quality is the biggest practical challenge — an inventory missing shadow IT or informally-run systems gives a false sense of completeness.
- Ownership: someone needs to own keeping the inventory current; without an owner it decays within a year.
- APM findings should route through Architecture Governance so Eliminate/Migrate decisions have clear decision rights.
- Technical health signals for TIME: beyond “does it still run,” look for infrastructure-level signals — is the app in a single Azure region with no failover plan, does it autoscale under load or fall over at peak, does it emit telemetry to Application Insights or is it a black box during an incident? Apps with none of these are frequently poor-technical-health candidates even when business fit is strong.
Quick reference
Section titled “Quick reference”| Category | Meaning |
|---|---|
| Tolerate | Acceptable fit and health — no action needed now |
| Invest | Strong business fit, weak technical health — modernize |
| Migrate | Weak business fit, acceptable health — move to a better-fit alternative |
| Eliminate | Weak fit and weak health — retire |
Troubleshooting
Section titled “Troubleshooting”| Symptom | Likely cause | Fix |
|---|---|---|
| Portfolio decisions keep stalling | No clear owner or decision rights | Route decisions through architecture governance |
| Inventory doesn’t match reality | Shadow IT or informally-run systems excluded | Actively discover, not just self-report, applications |
| Same “Eliminate” apps never actually retired | No roadmap link or funding attached | Feed TIME classifications directly into the roadmap, not a separate report |
Check your understanding
Section titled “Check your understanding”- Why does an application with strong business fit but poor technical health land in “Invest” rather than “Tolerate”?
- Think of an application you know — where would it land on the TIME grid, and what would that imply?
Related pages
Section titled “Related pages”Part of Introduction to Enterprise Architecture. See Target Operating Model & Roadmapping for how portfolio decisions feed the roadmap, Business Capability Mapping for the capability view applications are mapped against, and the Glossary for term definitions.