Application Portfolio Model – How We Use This to Identify Quick Wins

Stop Wasting Money: The Enterprise Architect’s Guide to Quick-Win Application Rationalisation

The enterprise application landscape is often less of a strategic asset and more of a chaotic, expensive sprawl. Every Enterprise Architect joining a new organisation recognises the type: overlapping functionality, legacy ‘zombie’ systems running on unsupported tech, and a Total Cost of Ownership (TCO) that is barely understood.

We’re past the point of admiring the problem. Executives aren’t asking for another inventory; they are asking for value realisation and risk reduction. They need a clear, actionable path to save money, right now.

The Application Portfolio Model (APM) shifts from a tedious documentation exercise to a potent weapon. It’s the engine we use at TechArch2Ops to cut through the complexity, identify high-impact savings, and deliver those critical, morale-boosting quick wins.

This article lays out the comprehensive, architectural approach to building a fact-based APM and, more importantly, how to use it to execute immediate value, moving swiftly from Architecture to Operations.

Part 1: The Why? – Aims of the APM

Before we detail the 'how,' we must be crystal clear on the 'why.' The APM is more than a useful artifact; it is a decision-making tool.

The primary aim of a structured APM analysis is to provide the C-suite with the factual evidence needed to answer three non-negotiable questions:

Strategic Question	Strategic Question	APM Deliverable	The Value	APM Deliverable
Where is the financial leakage?	Where is the financial leakage?	Fact-based TCO, licensing, and support costs per application.	TCO Reduction: Pinpoints costly, non-strategic systems ripe for retirement.	Fact-based TCO, licensing, and support costs per application.
What is our biggest operational risk?	What is our biggest operational risk?	Technical health, obsolescence, and security compliance scores.	Risk Mitigation: Highlights systems with unacceptable compliance or support risk.	Technical health, obsolescence, and security compliance scores.
How do we align IT spend to business goals?	How do we align IT spend to business goals?	Business capability alignment and strategic importance scoring.	Investment Prioritisation: Ensures future funding goes to high-value, high-potential applications.	Business capability alignment and strategic importance scoring.

The APM’s power is that it forces a single, unified view of technology, finance, and business strategy. It’s the essential “Discovery” groundwork for any subsequent transformation.

Part 2: Creating the APM – From Inventory to Insight

A successful APM exercise hinges on a structured approach that goes beyond just compiling a spreadsheet. It requires governance, clear definitions, and data quality assurance.

2.1. The Critical Phase: Preparation and Scoping (The Gaps We Found)

Often organisations jump straight to data collection. This is a mistake. The foundation is built here:

• Establish Governance and Ownership: Define the Steering Committee (the decision-makers) and, crucially, mandate that all data is signed off by the Application Owner. Bad data invalidates the entire analysis.

• Define the APM Scope: What is an application? Is it a single codebase, a hosted service, a combination of custom-off-the-shelf (COTS) and bespoke code? This simple definition ensures consistent data collection across the Enterprise. Remember within the scope of the APM that this extends into the Application-Data-Technology Model (see Part 3).

• Select the Tooling: The APM must be a live asset, not a one-off report. Leverage modern APM platforms (ServiceNow, LeanIX, Ardoq) to institutionalise the process and enable dynamic visualisation. In my experience, Excel is sufficient as a starting point, but this will have limitations to get the best value from the insights.

  
  

2.2. The Data Gathering Dimensions: Three Pillars of Truth

For an APM to be effective, you need a balanced scorecard. We assess every application across three core dimensions: Value, Cost, and Risk/Health.

Pillar 1: Business Value (The 'Why' We Use It)

This is where traditional inventories fail. It's not enough to list the user count. We must tie the application to the core operations of the business.

APM Metric	Detail	Strategic Purpose
Business Capability Alignment	Map the application to a Business Capability Map (e.g., Customer Onboarding, Financial Reporting).	Highlights overlaps (duplicate capabilities) and gaps.
Strategic Importance	Score (1-5) how critical the application is to the organisation’s current strategy.	Prioritises investment for mission-critical systems.
User Penetration	Actual number of active users/transactions vs. license count.	Identifies potential license reduction opportunities.

Pillar 2: Financial Cost (The 'How Much' It Costs)

We focus on TCO ensuring all hidden costs are surfaced.

• Run Costs: Licensing, maintenance, support contracts.

• Personnel Costs: FTEs required for operational support (DevOps, L2/L3 support).

• Hidden Costs: Decommissioning costs, data storage/hosting, and shadow IT budgets.

  
  

Pillar 3: Technical Health and Risk (The 'Will It Break?')

This is the Enterprise Architect's mandate: managing the technical debt.

• Technical Obsolescence: Scoring based on version, end-of-life dates, and vendor support status.

• Technical Debt & Quality: A subjective score from the application team/architect on codebase quality and development difficulty

• Security & Compliance: Compliance with internal standards, regulatory frameworks (DORA, NIS2), and recent audit findings.

Part 3: The Architectural Mandate: Integrating the ADT Model

Beyond documenting the applications within the APM, the exercise also provides the foundations to map technical dependencies. An APM that only captures application attributes is an inventory; once the APM maps the Application-Data-Technology (ADT) Model, this becomes a powerful decision engine.

We need to include the supporting technical data because you can’t safely retire an application based on scores alone. You must first understand its risks and its dependency footprint across the data and infrastructure layers.

3.1. Layer 1: The Technology Stack (Infrastructure Dependency)

Integrating infrastructure data provides the factual basis for the Technical Health and an accurate TCO score.

The Data to Capture:

• Hosting Environment: On-prem or specific public cloud details (provider, region).

• Underlying Technology: Specific OS version, database engine, middleware, and runtime versions.

• Support and commercial models: How the services are being sold and service level agreements

• EOL Dates: The explicit End-of-Life date for the OS, database, and hardware components.

How it Drives Rationalisation:

By linking the application to its complete technology stack, you can identify stranded assets. The elimination of one low-value application might enable the immediate decommissioning of an entire, expensive physical or virtual server cluster (and its associated maintenance contracts), delivering a massive, multi-faceted quick win. This is how we realise the full TCO reduction, not just the software license cost.

3.2. Layer 2: The Data Assets (Information Dependency)

In the current regulatory climate, the data an application manages is often its greatest risk and its greatest barrier to retirement.

The Data to Capture:

• Data Domains: Which major business data assets does the application create, use, or store (e.g., Customer PII, Financial Records)?

• Data Classification & Compliance: The data's risk level (Confidential, Restricted) and relevant regulatory mandates (GDPR, HIPAA, DORA).

• Data Flow: Crucially, which other applications consume data from this system (downstream dependencies).

  
  

How it supports the Rationalisation agenda:

Data dependency mapping serves as the detailed analysis and design towards achieving quick wins, projects and roadmaps. Before tagging a system for rationalisation, the map must confirm:

1. No Critical Downstream Consumers: If a high-value application relies on your retirement candidate for data, the retirement becomes a complex data migration project, not a quick win.

2. Compliance-Ready Archiving: If the application stores restricted data, the decommissioning plan must include a defined, compliant process to migrate the required historical data to a designated archive. This ensures the TCO savings are not offset by a massive future compliance fine.

   
   

Part 4: The 'So What?' – Identifying the Quick Wins

The real value of the APM isn't the data; it’s the analysis and visualisation that drives the 'So What?' conversation. This is where we stop documenting and start making decisions.

The single most effective tool for this is the APM Quadrant Model.

4.1. The Strategic Quadrant Model

We use a variation of the classic Technical Health/Risk vs. Business Value matrix. This model immediately turns hundreds of rows of ADT-validated data into a clear visual mandate for action. This analysis is often referred to as a TIME analysis – Transform, Invest, Monitor, Eliminate.

	Low Technical Health (High Risk/Cost)	High Technical Health (Low Risk/Cost)
High Business Value	Modernise/Transform: Mission-critical, but unstable or too costly. Requires immediate investment and strategic re-platforming.	Invest/Maintain: The gold standard. Keep investing in upgrades and maintenance.
Low Business Value	Eliminate/Decommission (The Quick Win Zone): High cost/risk, low strategic importance. Requires immediate retirement.	Tolerate/Monitor: Functional, low-risk, but non-strategic. Keep it running until the business process changes.

4.2. Targeting the Quick Win Zone: Eliminate/Decommission

The best source of quick wins sits squarely in the Eliminate/Decommission quadrant. These high-cost, low-value, and often high-risk systems are the quickest wins for rapid TCO reduction.

Quick Win Tactic 1: Duplicate Functionality

• Leverage: The Business Capability Alignment data.

• Action: Target redundant applications supporting the same capability (e.g. three different reporting tools). The ADT map confirms that the target system can safely absorb the decommissioned system's remaining data and infrastructure load.

• Result: Immediate TCO reduction by eliminating duplicate licenses and support staff.

  
  

Quick Win Tactic 2: Retiring the Red-Zone Risk

• Leverage: The ADT Infrastructure EOL dates and Data Compliance scores.

• Action: Focus on applications in the Eliminate quadrant that also run on obsolete infrastructure or handle Restricted PII.

• Result: Fund the minimal effort to archive the data and pull the plug. The financial saving (licenses, patching efforts, hardware maintenance) is immediate, and the organisational risk profile drops. The ROI is framed as "Risk Avoidance."

  
  

Quick Win Tactic 3: Shadow IT and Zombie Systems

• Leverage: The TCO Deep Dive and Usage/User Penetration data.

• Action: Retire systems with high recurring costs but zero or near-zero active users. The ADT map guarantees that no other production system is secretly depending on this "Zombie."

• Result: Stops the recurring billing instantly. Removal of shadow IT replaces uncontrolled, fragmented spending with strategic, governed investment, minimising enterprise risk and maximising control.

Part 5: The 'So What Next?' – From Analysis to Action

The APM analysis value is achieved if it leads to a funded, executable roadmap. The transition from the quadrant analysis to the delivery plan is where the true value of Architecture to Operations is realised.

5.1. Formalising the Application Roadmap

The quadrant model generates four clear architectural mandates (often called the 4 R's):

1. Retire/Rationalise (The Quick Wins): Immediate focus on decommissioning and consolidation.

2. Re-platform/Modernise: Strategic, high-value applications that need investment to move them out of the high-risk/high-cost quadrant (e.g. moving on-prem to cloud-native).

3. Retain/Maintain: High-value, stable platforms. Focus on steady operations and routine technical upgrades

4. Re-imagine/Invest: Applications supporting new business models or strategic capabilities.

   
   

5.2. Converting Recommendations into a Business Case

For the quick wins to be realised, they need a dedicated, fast-tracked execution plan that operates on the JEDI (Just Effectively Do It) mantra.

• The TCO Business Case: The case for retirement is simple: Cost of Decommissioning vs. Annual TCO Savings.

• The Quick Win Execution Mandate: Separate the Quick Win Retirement plan from the long, complex modernisation programs. Give the retirement team a small budget and a strict mandate to archive the data (per the ADT plan) and power down the system.

  
  

5.3. Institutionalising the APM

The biggest failure of APM projects is the 'shelfware' effect.

• Continuous Governance: Embed the ADT-validated APM Quadrant as the single source of truth for all new investment decisions. Any new application proposal must show which existing capability it is replacing and how it avoids landing in the "Eliminate" quadrant in 18 months.

• KPI Alignment: Tie the APM metrics (e.g., "Reduction in application count" and "Reduction in TCO for the bottom-left quadrant") directly to the technology leadership’s annual KPIs.

  
  

🔑 Conclusion: The APM is Your Action Plan

The Application Portfolio Model, driven by the comprehensive ADT dependency mapping, is more than an IT inventory. It is the blueprint for strategic, financial, and operational clarity. It allows the Enterprise Architect to move from a defensive position (fighting fires) to an offensive position (driving measurable savings).

By establishing a robust, governed APM and focusing the analysis on the high-cost, low-value systems, you can quickly identify, fund, and execute those critical quick wins. This immediate delivery of TCO reduction and risk mitigation builds the essential political capital and financial foundation needed for the larger, more complex transformations ahead.

Stop documenting. Start deciding. The application landscape is waiting to be streamlined, from Architecture to Operations.