Template · Enterprise Architecture

Application Portfolio Assessment Template

A fill-in assessment for one application in the estate — business fitness, technical fitness, cost, risk and the disposition decision (invest, tolerate, migrate, eliminate) with the evidence behind it.

Markdown. No sign-up, no email.

One per application. The output of a portfolio review is not a diagram of everything; it is a defensible decision about each thing, with the evidence attached.

Fill the cost and usage rows with measurements. A portfolio review built on opinion produces a roadmap that the first budget conversation dismantles.

Application: _______________ Business owner: _______________ Technical owner: _______________ Assessed by: _______________ Date: _______

1. What it does#

Business capability supported
One-sentence description
Users (number, type)
Usage measured how
Business criticalitycritical / important / routine
Regulatory relevance

If it were switched off tomorrow, who would call, and how quickly? _______________

2. Business fitness (1–5)#

DimensionScoreEvidence
Meets current business need
Users would choose it if given an alternative
Supports where the business is going
Data in it is trusted
Process it supports is still how we work

Business fitness total: ____ / 25

3. Technical fitness (1–5)#

DimensionScoreEvidence
Platform and runtime still vendor-supported
Can be changed safely (tests, environments, deploy path)
Integrations are documented and stable
Skills exist in-house
Security posture (patching, authentication, logging)
Recoverable — backup tested

Technical fitness total: ____ / 30

🔴 Any score of 1 on "vendor-supported" or "recoverable" is a finding in its own right, whatever the totals say. Do not let an average hide an unsupported platform holding regulated data.

4. Cost#

Annual
Licences
Infrastructure
Support and maintenance contract
Internal effort (FTE × cost)
Total cost of ownership

Cost per user / per transaction: _______________ Cost trend over three years: _______________

5. Risk#

RiskPresentNote
Unsupported operating system, runtime or databaseyes / no
Single person understands ityes / no
No test environmentyes / no
Cannot be restored (untested backups)yes / no
Holds personal or regulated datayes / no
Vendor viability concernyes / no
Undocumented integrationsyes / no

Key-person dependency named: _______________

6. Overlap#

Other applications in the estate doing something similar: _______________

Why both exist: _______________

Duplication is usually historical rather than deliberate — an acquisition, a department that bought its own, a project that stopped halfway. Recording the reason is what makes consolidation a decision rather than an argument.

7. Disposition — pick one#

DecisionMeaningChosen
InvestHigh business fitness, high technical fitness. Fund improvement
TolerateHigh business, low technical. Keep, contain the risk, do not extend
MigrateLow business, high technical. Move the capability elsewhere
EliminateLow on both. Retire

Decision: _______________ Rationale, in two sentences: _______________ Estimated effort: _______________ Dependency: what must happen first: _______________ Earliest realistic date: _______

"Tolerate" is a legitimate decision and the most commonly avoided one. Naming it explicitly — with a containment action and a review date — is far better than a roadmap that quietly claims everything will be modernised.

8. If eliminating or migrating#

  • [ ] Data retention requirement identified (how long, in what form)
  • [ ] Archive plan and format agreed
  • [ ] Consumers of its data or interfaces identified and told
  • [ ] Licences to cancel, with notice periods
  • [ ] Decommission date agreed and recorded
  • [ ] Someone owns the shutdown

9. Sign-off#

NameDate
Assessor
Business owner agrees with disposition
Architecture review
Review due again

Back to Enterprise Architecture