How I Read a New Capability

New capabilities are usually presented on their own: a demonstration, a reference architecture, a clean pilot with a motivated team. Enterprises never adopt anything that way. A capability lands on top of a platform that is ageing, a support date that cannot move, an upgrade that cannot wait, and people who are already busy.

Experience has changed how I read a new capability. I still ask whether it works. More often, I ask three other questions. What problem does it actually retire? What does it introduce that someone will have to own? And what does it assume about the organisation expected to run it?

The third question usually decides the outcome. It is also the one a demonstration is least able to answer.

A change that came as a bundle

The clearest example I have is a virtual desktop programme where I worked as integration architect.

The organisation was not new to virtual desktops. It had run them on premises for years. What forced a change was an approaching operating-system support deadline, and the replacement required more capable desktops. The obvious answer was more on-premises hardware. The organisation did not want to add more hardware for this purpose, and support for some of the existing hardware was itself approaching its end.

So the capability on the table, virtual desktops hosted in the cloud, did not arrive alone. It came with an operating-system upgrade, a hardware decision and a shift towards cloud infrastructure. As remote working expanded, the programme also had to accommodate a change in how people accessed the service.

My role sat across that bundle. I was responsible for integration architecture and for coordinating delivery across the workstreams. The judgement I remember most clearly was that the operating-system upgrade and the desktop migration had to run as one programme, not as two projects that happened to share a calendar. Both affected the same desktops and the same users. Planning them together was necessary to coordinate the changes and their impact on the people using the service.

I do not remember a single decisive moment. What I remember is the shape of the work: two changes reaching the same people at the same time, and a programme whose job was to hold them together.

What it retired

The capability addressed a specific problem: meeting the new operating system's requirements without expanding the on-premises hardware estate. The published accounts also describe the ability to expand cloud resources quickly as remote working increased.

That is a meaningful problem to address, but a bounded one. Being precise about the problem a capability solves sets the limits of the value it can offer, and it stops a business case from claiming more than the capability can deliver.

What it introduced

The second question is where business cases tend to go quiet.

The migration was phased. For a period, cloud-hosted and on-premises desktops ran side by side, and the remaining desktops stayed on premises until the maintenance on the existing hardware expired. Both environments had to be operated and supported for as long as they coexisted.

A hybrid period is not a footnote to a capability. It is an operating obligation, and someone has to own it every day it lasts. It belongs in the capability's total cost, even when the architecture at the end looks simpler than the one at the start.

What it assumed, and what it left alone

The third question is the one I now spend most time on, and it is where this programme taught me most.

The approach kept the existing desktop virtualisation software and ran it on cloud infrastructure. The published accounts describe operations management staying the same and users finding the experience virtually unchanged.

This is my reading rather than a documented rationale, but I now see it as the programme's most important characteristic. It limited the additional change required of the organisation. Users did not have to learn a new way of working. Operators did not have to learn a new platform. The infrastructure underneath changed, while the parts people touched every day stayed much the same.

That mattered because of everything else under way. The organisation was upgrading its operating system, changing its infrastructure model and, while the migration was in progress, moving people to remote working. Its capacity to absorb change was already heavily drawn on.

When an organisation is already absorbing substantial change, a capability that preserves established technology and operating practices may be a better choice than one that requires users and operators to change at the same time. A demonstration rarely shows this, because it shows the capability rather than the organisation around it.

Judging the bundle

Looking back, the lesson is not that familiar technology is always the better choice. It is that a capability must be judged alongside the changes it depends on, the obligations it creates and the demands it places on an organisation already in motion.

In practice, that means asking what else must change for the capability to work, who will absorb those changes and how long the transition will last. It means pricing the transition, not only the end state, and recognising that continuity has a value that rarely appears in a business case.

It also changes how I think about integration. The role is not confined to connecting technologies. It includes holding together changes that affect the same users, services and operating environment.

Three questions help make the whole bundle visible. What does this capability retire? What will it introduce that someone must own? What does it assume about the organisation expected to run it?

The demonstration shows what the technology can do. These questions show what the organisation must do in return, and whether it has the capacity to do it now.