Capabilities Overview

A service answers a business question and is bought as a programme: an AI strategy, a data foundation, an augmented IT department. A capability is what makes that programme hold once it runs: modernising the legacy underneath it, observing it in production, containing an incident, controlling its cost. The two are bought at different moments and by different people, which is why they are listed separately rather than merged into one catalogue.

The one whose absence is already costing you, not the one that is furthest behind. An organisation that cannot see what production is doing gains more from observability than from a modernisation programme it will not be able to measure. An organisation that can see, but cannot deploy without a difficult evening, starts with the delivery chain. The order follows what hurts, and the diagnosis exists to establish that rather than to assume it.

It means every phase ends with something in production and a decision to continue or stop, rather than a single date on which everything changes. A migration moves in waves with the previous environment kept warm; a modernisation replaces one domain at a time behind a stable interface; a new foundation takes one pilot site before the rest. The cost is a longer overall calendar. The gain is that a mistake is discovered on one wave rather than on the whole estate.

Because a control added afterwards is a control that can be removed under deadline pressure, while one built into the chain has to be deliberately taken out, which leaves a trace and requires a decision. In practice this means dependency vulnerabilities blocking at commit, secrets managed outside the repository from the first day, and audit logs produced continuously rather than assembled when an auditor asks. The cost is front-loaded; the alternative is paid later, at a worse moment.

On the journeys the business recognises, not on infrastructure counters. A service level objective set on a payment journey says something a CPU graph never will, and the detection time of a business incident is the number that decides whether customers noticed before the monitoring did. Every measurement we hand over names what it covers, what it excludes, and the period it was taken over, so that it can be contested rather than merely believed.

No, and deciding what stays is part of the work. An application that is stable, understood and rarely changed costs almost nothing to leave alone, and rewriting it converts a known risk into an unknown one. The candidates for modernisation are the ones the business asks to change often and where each change costs more than it should. Locating the debt file by file, rather than averaging it across the estate, is what makes that arbitration possible.

They share the same delivery chain rather than each bringing its own. A modernisation programme uses the gates and the pipeline that the delivery capability built; observability watches what the migration moved; the cost control applies to the platform the whole estate now runs on. That is what keeps them from becoming six parallel projects with six sets of tooling, which is the usual way a capability catalogue turns into an operating cost.