Modernisation begins with a business capability

I start by identifying the capability that needs to improve, the people who own it and the dependencies that constrain it.

That account shapes the sequence of work. Some legacy systems can remain dependable while other capabilities change; others create dependencies that need to be addressed first. An enterprise roadmap should make those choices understandable to the people funding and operating the business.

Application thinking persists because it fits the way technology is usually funded and managed. Vendor support deadlines set much of the agenda, budgets are organised around systems, and progress is easy to count in applications retired or migrated. Capabilities are harder to see because they cut across systems and functions. Order handling, for example, may depend on several platforms owned by different teams, none of which is accountable for the whole experience. A programme defined by systems can therefore succeed on its own terms while the business capability it was meant to improve stays exactly as it was.

I work from a capability map that the business recognises as its own. Each capability has a named business owner and is assessed on two dimensions: how important it is to the strategy and how well it is currently supported. Investment is sequenced by the gap between those assessments and by the dependencies between capabilities. Every item on the roadmap then states the improvement it is meant to deliver and the measure its owner will use to judge it. That gives technology and business leaders a shared basis for prioritisation, rather than competing lists of projects.

Consider an organisation planning to replace an ageing order management system. Framed as a replacement, the work becomes a like-for-like migration with a new interface. Framed as a capability, the question changes: what does the business need from order handling, whether faster quotes, flexible pricing or reliable delivery promises? Suppose reliable promises depend on inventory data held in another system that is known to be inaccurate. That data would need attention first, because a new order platform built on poor inventory information would simply make an existing problem more visible to customers.

Capability maps can become abstract artefacts that business leaders admire once and never consult again. I guard against that by keeping the map in the language the business already uses, limiting its depth and testing it regularly against real investment choices. The other risk is that capability framing ignores genuine technical exposure, such as a platform approaching the end of vendor support. I do not hide that risk. I show it as a dependency on the capabilities it underpins, which makes clear to business owners why some technical work must come before the improvements they want.

This approach asks business leaders to accept named ownership of capabilities, including the uncomfortable parts such as data quality and process discipline. It asks finance to fund capability improvement across several years, recognising that annual project approvals tend to fragment work that needs to be sequenced as a whole. It asks the board to request evidence of capability progress rather than lists of system milestones. For the chief information officer, it means accepting that the technology function will be judged by business outcomes it influences but cannot deliver alone.

Framing modernisation around capabilities also changes who owns the outcome. A business leader who sponsors a capability will defend its priority when budgets tighten and will notice when it fails to arrive. That shared ownership is what keeps a multi-year programme coherent after the original business case has been forgotten.