Application portfolio management, the practice of keeping track of an organization’s software applications so you can decide which to invest in, change or retire, can become an endless inventory exercise. A small team can start more usefully: choose one decision, limit the scope, collect the evidence that decision needs, and validate it with the people accountable for the applications and the business outcomes.
Disclosure: I’m Nick Malik. I built Useful EA, a commercial set of architecture tools that includes the Application Portfolio Manager described near the end. The method works the same in a spreadsheet or any other portfolio tool.
How do you start application portfolio management?
Start with one bounded question, such as which applications supporting a business capability need investment, further investigation, migration or retirement review. Then:
- Define the decision and scope.
- Create a minimum application inventory.
- Record the evidence source and confidence for each important field.
- Assess business value and technical fitness separately.
- Inspect costs, dependencies and constraints before assigning a disposition.
- Validate the evidence and proposed decision with accountable owners.
- Record the rationale, action owner, review date and unresolved risks.
The output is not merely a list of applications. It is a traceable decision that can be challenged, updated and acted on.
1. Begin with a decision, not a universal inventory
A complete enterprise inventory may eventually be valuable, but it is rarely the best starting point. Select a bounded area where a decision matters: applications supporting one capability, systems affected by a contract renewal, applications in a modernization initiative, or overlapping systems within one business unit.
Write the decision question before choosing the fields. For example: "Which customer-onboarding applications require investment, migration planning or retirement investigation during the next planning cycle?" This keeps you from collecting data nobody intends to use.
2. Collect the minimum useful application data
The minimum data depends on the decision. These fields are a practical starting point, not a mandatory industry schema.
| Field | Why it matters | Evidence treatment |
|---|---|---|
| Application ID and name | Distinguishes the object being assessed | Confirmed fact |
| Business and technical owners | Identifies accountability | Confirmed or unresolved |
| Lifecycle status | Shows whether the application is active, restricted or retiring | Source and effective date |
| Capabilities or processes supported | Connects the application to business work | Validated relationship or hypothesis |
| Users or user groups | Indicates who depends on it | Count, estimate or named group |
| Business value | Records contribution to business outcomes | Assessment with rationale |
| Technical fitness | Records suitability and maintainability | Assessment with rationale |
| Annual cost | Supports comparison and planning | Actual, allocated estimate or unknown |
| Dependencies | Identifies systems, data or services affected by change | Relationship with confidence |
| Security, regulatory or retention constraints | Prevents unsafe simplification | Confirmed, suspected or unknown |
| Disposition and rationale | Makes the current direction explicit | Decision or recommendation |
| Action owner and target date | Turns analysis into accountable work | Named owner and date |
| Evidence source, confidence and review date | Makes reliability and staleness visible | Source, confidence and date |
If a field does not affect the intended decision, defer it. If a missing field could reverse the decision, mark it as an evidence gap rather than guessing.
3. Separate facts, estimates, unknowns and judgments
Application portfolios mix different kinds of evidence. Treating every cell as equally reliable creates false confidence.
- Confirmed fact: supported by an accountable source or system of record.
- Estimate: a useful approximation whose method and owner are recorded.
- Unknown: information that has not been established.
- Judgment: an assessment supported by criteria and rationale.
- Inference: a conclusion drawn from observations that still needs validation.
Scores can support comparison, but they do not make the decision. Record the assumptions, evidence gaps and override rationale whenever reviewers choose a different disposition from the one a matrix or score suggests.
4. Assess business value and technical fitness separately
Business value asks how important the application is to the organization’s work and outcomes. Technical fitness asks whether the application is suitable, supportable and adaptable enough for its current and expected role.
| Business value | Technical fitness | Typical review question |
|---|---|---|
| High | High | Should we continue, protect or selectively invest? |
| High | Low | What modernization, replacement or risk treatment is justified? |
| Low | High | Is it still needed, or is it a consolidation candidate? |
| Low | Low | Can it be retired, and what must happen first? |
These quadrants are prompts for review, not automatic instructions.
The U.S. Federal CIO Council’s Application Rationalization Playbook uses the same two dimensions in a six-step method: clarify needs and assess readiness, build the application inventory, evaluate business value and technical fit, analyze total cost of ownership, score applications, and decide placement. Bizzdesign’s guide to the playbook names TIME (Tolerate, Invest, Migrate and Eliminate) as one framework for expressing the resulting direction. The labels matter less than using defined criteria consistently and keeping the evidence behind each decision.
5. Treat overlap as an investigation signal
If several applications support the same capability or process, the portfolio may contain overlap. That is not proof of redundancy. The applications may serve different users, jurisdictions, products, data classifications or operating contexts.
Use apparent overlap to ask whether the systems perform the same function, whether their service boundaries are comparable, whether the preferred application can absorb the remaining demand, and what integrations, data, contracts and constraints must be preserved. Only then should an overlap hypothesis become a consolidation or retirement proposal. The application rationalization guide covers that decision in depth, including six tests to pass before retiring an application.
6. Check dependencies and constraints before retirement
A low-value, poor-fit application is not automatically ready for removal. Retirement is a change decision, not a label. Validate:
- incoming and outgoing integrations;
- data ownership, migration and retention;
- downstream reports, processes and users;
- replacement readiness and capacity;
- security, privacy, legal and regulatory constraints;
- contractual implications;
- transition cost, timing and operational risk; and
- the owner of each required action.
Recorded dependencies define what to review. They are not a complete picture of what a change will affect unless the discovery and validation behind them support that claim.
Worked example: why a retirement candidate may need to wait
This example is fictional.
| Application | Business value | Technical fitness | Initial direction |
|---|---|---|---|
| OnboardNow | High | High | Invest selectively |
| ClientEntry | Medium | Low | Migrate |
| Archive Intake | Low | Low | Investigate retirement |
Archive Intake looks like the strongest retirement candidate. A dependency review finds that it stores signed records required under an existing retention policy, feeds a compliance report, and holds data not yet migrated to OnboardNow.
The defensible decision is a conditional retirement: confirm the retention requirement, preserve the required records, replace the report feed, validate the replacement, and assign an accountable retirement owner and review date. Portfolio classification has to lead to owned transition work.
7. Make the decision reviewable
For every proposed disposition, record the evidence and criteria, assumptions and unknowns, accountable reviewers, dissent or override rationale, required actions and owners, dependencies, target date and next review date. This creates an evidence trail without pretending that architecture analysis removes uncertainty.
8. Review continuously, but proportionately
Review records when the decision context changes: a contract or support milestone, a major incident, a control finding, a new strategy, a material cost change, an acquisition, a modernization proposal or a newly discovered dependency. A documented cadence can catch quiet drift, but there is no universally correct interval. Match the cadence to risk, rate of change and the decisions being supported.
Spreadsheet or structured application portfolio tool?
A spreadsheet is a sensible starting point when the scope is small, the fields are stable and one team owns the review. A structured tool becomes more useful when many people update evidence, applications have many relationships, review cycles must be compared, decision history must be kept, or follow-up work must stay connected to decisions. Portfolio size alone should not decide it. The low-cost enterprise architecture tools comparison reviews inexpensive options.
Where Useful EA fits
Application Portfolio Manager is one Useful EA tool for holding this evidence. It is in beta. Each application record has:
- a disposition: planned, pilot, active, sunset or retired;
- one primary capability and any number of supporting capabilities, from a Capability Modeler model;
- department owner and contacts, vendor and version dates;
- annual cost;
- business value and technical fitness, each scored 1 to 5 or left “not assessed”; and
- a feature-fit rating from -2 to +2: how well the application’s features match what the business needs.
Data flows between applications are recorded by people or imported from CSV, not discovered from running systems.
Some of the fields above aren’t built in. There are no built-in evidence-source or confidence fields. Add them as custom fields (yes/no, number or text); they appear in the application form and the CSV export.
To act on the analysis:
- the TIME Quadrant places every scored application by business value and technical fitness, as invest, tolerate, migrate or eliminate, with each one sized by annual cost;
- the Target Report ranks applications with a non-zero fit rating by annual cost multiplied by the size of the fit gap, and lets you mark retirement targets;
- on an application’s form, + Add related work items previews the checklist of work for its disposition, which a person then adds; each work item has an assignee, a due date and an optional repeat; and
- on Corporate accounts, Review Campaigns ask each department’s contacts to confirm ownership and report a recommended action, fit and annual cost. Their answers change an application only when you apply them; a response also updates the application’s Last Validated date, unless the respondent says they don’t own or don’t recognize it.
Accounts are free during the beta; see pricing for what applies after it.
Frequently asked questions
What data should be in an application portfolio?
Collect the data needed for a defined decision. A useful starting set includes application identity, owners, lifecycle, supported capabilities or processes, users, business value, technical fitness, cost, dependencies, constraints, disposition, rationale, evidence source, confidence and review date.
What is the minimum viable application inventory?
The smallest bounded inventory that supports a real decision. It identifies the applications in scope, who is accountable for them, what business work they support, their value and fitness, major costs and constraints, and the evidence needed to review a disposition.
What do Tolerate, Invest, Migrate and Eliminate mean?
TIME is one disposition vocabulary. Tolerate usually means continue under current constraints; Invest means improve or expand; Migrate means move users, data or functions; Eliminate means retire once dependencies, retention and transition requirements are satisfied.
Is TIME the same as business-value and technical-fitness analysis?
No. Business value and technical fitness are assessment dimensions. TIME is one way to express a direction after considering those dimensions and other evidence such as cost, risk, dependencies and strategic fit.
Can application portfolio management begin in a spreadsheet?
Yes. A spreadsheet works for a bounded scope and a few contributors. A structured tool becomes more useful as relationships, repeated reviews, shared ownership and traceability become hard to maintain.
What must be checked before retiring an application?
Owners, users, integrations, data migration and retention, downstream reporting, replacement readiness, security and regulatory constraints, contracts, transition cost, operational risk and accountable action ownership.
How often should an application portfolio be reviewed?
When material events occur, and on a documented cadence suited to risk and rate of change. There is no universal interval that fits every organization.
Sources
Vendor documentation is cited as context for how the market describes these patterns, not as evidence about Useful EA.
- Bizzdesign: US Government Application Rationalization — summary of the Federal CIO Council playbook’s six-step method, and TIME as an example evaluation framework
- GSA: Application Rationalization: A Strategic Approach to Agency Cloud Migration — overview of the Federal CIO Council Application Rationalization Playbook; notes there is no one-size-fits-all process
- ISACA: Achieving Application Rationalization Using COBIT 2019 — scope, inventory, owners, life cycle, usage, business value, quality, total cost of ownership and continuing review
- Info-Tech Research Group: Application Portfolio Management Playbook (hosted by OpenText) — application attributes including owners, lifecycle stage, end users, dependencies and existing documentation