Ask any large organisation how many applications it runs and the honest answer is usually "more than we think." Tools get bought by departments, inherited in acquisitions, and kept alive long after the person who championed them has left. Each one carries a licence, a maintenance burden, a security exposure and a slice of someone's attention. IT governance is how an organisation decides which technology investments to make and who gets to make them; application portfolio rationalisation is the periodic, deliberate work of looking at everything you own and deciding what to keep, fix, replace or switch off.

The quick version

  • IT governance answers two questions: what technology decisions get made, and who has the right to make them. It is about direction and accountability, not day-to-day delivery.
  • COBIT (from ISACA) is the most-used governance framework, it deliberately separates governance (set direction, monitor) from management (plan, build, run). TOGAF (from The Open Group) is the most-used enterprise architecture method, a repeatable way to design the target technology landscape.
  • Application portfolio rationalisation scores every app on two axes, does it serve the business, and is it technically healthy, then sorts each into keep, invest, replace or retire.
  • The trap is treating this as a one-off cull. It is a standing discipline: portfolios re-bloat within a couple of years if nobody owns the question of what to switch off.

The idea in depth: governance is about decision rights, not control

The most useful definition of IT governance comes from Peter Weill and Jeanne Ross of MIT's Center for Information Systems Research. In IT Governance: How Top Performers Manage IT Decision Rights for Superior Results (Harvard Business School Press, 2004), they frame it not as control but as decision rights: "specifying the decision rights and accountability framework to encourage desirable behaviour in the use of IT." Drawing on a study of roughly 250 enterprises, they reported that firms with above-average IT governance earned materially higher profits than firms with weak governance pursuing the same strategy. Treat the precise multiplier with care, it is one study, now two decades old, and "good governance" and "profit" are both entangled with a dozen other things, but the direction holds up and is widely echoed: who decides turns out to matter as much as what is decided.

The practical move is to make decision rights explicit instead of leaving them to whoever shouts loudest. Write down, for the handful of decisions that matter, which applications the organisation standardises on, how much to spend, what the architecture principles are, who proposes, who decides, and who is merely consulted. Most governance failures aren't bad decisions; they're decisions nobody felt they owned.

COBIT and TOGAF: the two frameworks, and how they differ

Two frameworks dominate this space, and they answer different questions. COBIT, currently COBIT 2019, from the professional body ISACA, is a governance framework whose central, genuinely useful idea is the deliberate separation of governance from management. It organises its 40 governance and management objectives into five domains. One, EDM, Evaluate, Direct and Monitor, holds the five governance objectives: the work of the governing body (the board, an IT steering committee) that sets direction and watches outcomes. The other four (Align/Plan/Organise, Build/Acquire/Implement, Deliver/Service/Support, Monitor/Evaluate/Assess) are management, getting it done. That governance-is-distinct-from-management rule sits among COBIT's six governance-system principles.

In practice, that means you stop running technology decisions through a single committee that does everything. The board evaluates options, directs by setting priorities and risk appetite, and monitors results, and then gets out of the way so management can plan, build and run. When the same group both sets the strategy and grades its own delivery, you have no governance; you have a management meeting wearing a governance badge.

TOGAF, currently TOGAF 10, released by The Open Group on 25 April 2022, answers a different question: how do you actually design the technology landscape you want? Its core is the Architecture Development Method (ADM), a cycle of phases, a Preliminary phase, then Architecture Vision (A), Business Architecture (B), Information Systems Architectures covering data and applications (C), Technology Architecture (D), Opportunities & Solutions (E), Migration Planning (F), Implementation Governance (G) and Architecture Change Management (H), with Requirements Management running through the centre. Phase C is where the application portfolio lives: it is the explicit step where you map what systems you have, what they do, and how they fit the target you're aiming at.

flowchart TD
  G(["Governance, COBIT EDM
Evaluate · Direct · Monitor"]) -->|"sets direction, risk appetite"| M(["Management, APO · BAI · DSS · MEA
plan · build · run · assess"])
  M -->|"reports outcomes back up"| G
  M -->|"designs the target landscape"| T(["Architecture, TOGAF ADM
Vision → Business → Apps/Data → Tech"])
  T -->|"Phase C: application portfolio"| R(["Rationalisation
score · sort · retire"])
How the pieces fit: COBIT governs and separates decide-from-do; TOGAF designs the target; rationalisation is the cleanup inside it. Leaders Loop

An honest limitation. Both frameworks are heavy. COBIT's 40 objectives and TOGAF's full ADM are built for large, regulated enterprises, and applied literally they can generate more documentation than value, the well-worn complaint that an organisation ends up "doing TOGAF" rather than improving anything. The Open Group itself stresses tailoring the method to context. Treat both as a menu of good practice, not a checklist to complete: a two-person startup needs the idea of decision rights and a list of its apps, not a 200-page architecture repository.

Rationalisation: scoring the portfolio on two axes

Governance sets up who decides; rationalisation is one of the highest-value decisions they make. The most widely used tool for it is Gartner's TIME model, Tolerate, Invest, Migrate, Eliminate, which scores each application on two axes and sorts it into one of four actions. The axes are business fit (functional value, does this app actually support what the organisation does?) and technical fit (quality, maintainability, how well it plays with everything else). The quadrants follow naturally: high business value and healthy tech is Invest (double down); healthy tech but low value is Tolerate (leave it, retiring it would cost more than it saves); high value but ailing tech is Migrate (re-platform or replace); and low on both is Eliminate (retire it). It is described across Gartner's research and widely applied in application portfolio management tooling (see this practitioner explainer of the TIME model).

flowchart TD
  Q{"Score each app:
business value? technical health?"}
  Q -->|"high value · healthy tech"| I(["INVEST
double down, fund it"])
  Q -->|"high value · ailing tech"| M(["MIGRATE
re-platform or replace"])
  Q -->|"low value · healthy tech"| T(["TOLERATE
leave it, retiring costs more"])
  Q -->|"low value · ailing tech"| E(["ELIMINATE
switch it off"])
Gartner's TIME model: business value on one axis, technical health on the other, four clear actions. Leaders Loop

Build the inventory first, you cannot rationalise what you cannot see. Pull every application from finance (what are we paying for?), from single sign-on logs (what do people actually log into?), and from the teams themselves. For each, capture two scores and one owner. The scoring conversation is where the value is: it forces the business and IT to agree, often for the first time, on whether a system is genuinely needed or merely familiar.

You cannot rationalise what you cannot see, the inventory is most of the work, and most of the value.

One caution worth stating plainly: you will see eye-catching claims that rationalisation cuts IT costs by some fixed percentage. Those numbers are vendor estimates, not independent findings, and they vary wildly by starting point, so don't put them in a business case. The defensible case is concrete and local: this set of retired apps saves these licence and hosting costs and removes these named risks. Count what you can actually switch off.

A worked example

Take a mid-sized insurer, call it Harbourview, after three acquisitions in five years. (Illustrative figures throughout; this is a teaching example, not a real company.) Nobody can say how many systems exist. The new CIO starts not with a cull but with governance: she stands up an architecture review board under the COBIT idea of EDM, a small group that evaluates and directs, separate from the delivery teams who build, and gives it one first task: produce a single inventory.

The inventory finds 180 applications, and the usual pattern: three separate claims-management systems (one per acquired business), a customer portal nobody has logged into in eight months, and a "reporting tool" costing an illustrative £60,000 a year that duplicates a feature already in the finance suite. Each gets two scores. The claims systems are high value but poor technical fit (ageing, can't share data), Migrate: consolidate onto one. The dead portal is low on both, Eliminate. The duplicate reporting tool is decent tech but redundant, Eliminate too. The core policy-admin platform is high on both, Invest.

flowchart LR
  A(["180 apps
(nobody had counted)"]) --> B(["Inventory
finance + SSO + teams"])
  B --> C{"Score each:
value? health?"}
  C -->|"low/low, dead portal"| D(["Eliminate
switch off"])
  C -->|"high value, poor tech"| E(["Migrate
3 claims systems → 1"])
  C -->|"duplicate of finance suite"| D
  C -->|"high/high, policy admin"| F(["Invest
fund it properly"])
Harbourview's first pass: most of the win comes from a handful of obvious retirements and one consolidation. Leaders Loop

The point of the example isn't the tidy quadrants, it's the order of operations. Harbourview didn't start by buying a tool or hiring consultants to redesign everything. It started by deciding who owned the question (governance), then made the portfolio visible (inventory), then sorted it with a simple shared rule (TIME). The biggest savings came from the least glamorous move: switching off things nobody was using but everyone was paying for.

Frequently asked questions

What's the difference between IT governance and IT management?

Governance decides direction and who holds the decision rights; management plans, builds and runs to deliver against that direction. COBIT 2019 makes the split structural, governance lives in the EDM (Evaluate, Direct, Monitor) domain, management in the other four. The practical test: if the same people set the strategy and grade their own delivery, you don't have governance, you have a management meeting.

Do I need COBIT and TOGAF, or can I just pick one?

They solve different problems and are often used together. COBIT governs, it sets up decision rights, accountability and the separation of deciding from doing. TOGAF designs, it gives you a repeatable method for mapping the current landscape and planning the target. Smaller organisations rarely adopt either in full; they borrow the ideas (explicit decision rights, a maintained application inventory, a simple scoring rule) without the formal apparatus.

What is application portfolio rationalisation, in one line?

Looking at every application you own, scoring each on whether it serves the business and whether it's technically healthy, and deciding to keep, invest in, replace or retire it, then doing it again next year. The hardest and most valuable part is simply building an honest inventory of what exists.

How do I decide what to retire first?

Start with the clear "eliminate" cases: applications low on both business value and technical health, plus anything that duplicates a capability you already pay for elsewhere. These are low-risk, fast wins that fund the harder consolidation work. Cross-check usage data, an app nobody has logged into for months is a strong retirement candidate, regardless of what people say it's for.

Won't a one-off rationalisation just bloat again?

Yes, if you leave it as a project. Portfolios re-accumulate as new tools get bought and acquisitions land. The durable fix is governance: a standing review (the COBIT EDM idea) that owns the question of what to switch off, plus a rule that new applications enter the inventory and old ones are reviewed on a cycle. Rationalisation is a habit, not an event.

Related in the Toolkit

Governing and rationalising a technology estate assumes you understand what the estate is made of, the server-side systems that hold the data and the hosting choices that drive much of the cost you're trying to rationalise. And the discipline of deciding what to keep and what to cut is the same continuous-improvement instinct found in Lean and Kaizen.

Where to go next