Technology portfolio rationalization is not an IT cost-reduction exercise. Done correctly, it is a business architecture exercise that starts with capability strategy and ends with a defensible investment thesis for every application in the enterprise.
The ProblemWhy Portfolios Get Irrational
The average large enterprise runs between 500 and 1,000 applications. A significant portion of those applications duplicate functionality, support capabilities that no longer matter strategically, or exist only because no one had authority — or political will — to decommission them.
The accumulation is not accidental. It is the natural result of decentralized procurement, M&A activity that adds portfolios without integrating them, and transformation programs that deploy new systems without retiring old ones. Each decision made sense locally. The aggregate does not.
A business architect's role in rationalization is to provide the capability framework that makes application decisions legible to the business. Without that frame, rationalization becomes an IT-led cost exercise that the business does not trust — because it cannot see what it is losing or why.
The Core FrameworkThe TIME Model: Four Dispositions
The TIME model — Tolerate, Invest, Migrate, Eliminate — is the standard classification framework for application rationalization. Each application in the portfolio receives one of four dispositions based on its business value and its technical health. The matrix below shows how those two dimensions interact.
High value, poor tech health. Rebuild or re-platform on modern stack. Priority investment case.
High value, solid foundation. Invest in capability extension and integration.
High value, strong platform. Strategic asset — prioritize feature and API investment.
Marginal value, high debt. Unless unique, decommission and absorb capability elsewhere.
Adequate value and health. Run as-is. No new investment; maintain and monitor.
Good tech, moderate value. Hold and reassess as strategy evolves.
Low value, poor health. Retire. No business case for remediation or replacement.
Low value despite adequate health. Decommission — technical health does not justify retention.
Low value, high health. Low-cost to run. Tolerate short-term while building exit path.
Acting on the Classification
Classifying applications is straightforward. Acting on the classification is not. Each disposition has a different organizational implication, cost profile, and required governance decision.
Extend and Integrate
Increase capability coverage. Build APIs. Add integrations. Expand to adjacent capabilities. This is your platform of record.
Run Stable, Watch
No new feature investment. Maintain current functionality. Define the trigger condition that would move it to Migrate or Eliminate.
Replace the Platform, Keep the Capability
The business capability matters. The application does not. Find or build a better vessel and plan a structured migration.
Decommission and Absorb
Map any residual capability to an Invest-rated system. Build the decommission business case. Set a hard retirement date.
"Most organizations can eliminate 20–30% of their application portfolio in the first rationalization cycle without losing any meaningful capability. The value is not just cost — it is the operational clarity that comes from fewer systems, fewer integrations, and fewer support contracts."
Consistent finding in enterprise rationalization engagements across financial services and industrial sectorsAssessment Criteria for Every Application
Business value and technical health are the two axes — but each is composed of multiple measurable factors. A credible rationalization exercise scores every application against these criteria explicitly, not subjectively.
Capability Criticality
Which business capabilities does this application support? Are those capabilities in the strategic core, a differentiating zone, or a commodity function? Applications supporting differentiating capabilities score higher regardless of user count.
User Adoption and Process Integration
How deeply is the application embedded in how work gets done? A widely used application supporting a commodity process scores lower than a narrowly used application embedded in a critical workflow.
Architecture and Integration Fitness
Does the application have documented APIs? Can it integrate with the enterprise data model? Is it built on a supported technology stack with an active vendor roadmap? Closed, proprietary systems score poorly.
Cost and Supportability
What does this application cost to run — license, support, integration maintenance, and staffing? Applications with high run costs and low business value have an obvious rationalization case. Hidden costs (custom integrations, manual workarounds) must be surfaced.
Governance by Disposition
Rationalization produces a point-in-time classification. Governance ensures the portfolio stays rational over time. Each disposition requires a different review cadence and a different owner.
| Disposition | Review Cadence | Decision Owner | Exit Trigger |
|---|---|---|---|
| Invest | Annual strategic review + quarterly roadmap check-in | Business Capability Owner + CTO | Capability becomes commodity; better platform emerges |
| Tolerate | Annual review against capability strategy | Enterprise Architect + Business Owner | Cost threshold exceeded; strategy shift affects supported capability |
| Migrate | Monthly milestone check until migration complete | Program Manager + Business Owner | Migration complete — reclassify to Invest or Eliminate |
| Eliminate | Quarterly decommission progress review | CTO + Business Sponsor | Retirement date reached — application removed from portfolio |