Written by Technical Team | Last updated 21.10.2026 | 14 minute read
Large digital programmes are rarely delivered by a single organisation, even when the contract appears to say otherwise. A prime supplier may hold the commercial relationship, carry the contractual risk and provide most of the delivery capacity, but the team doing the work often includes software vendors, specialist consultancies, independent experts, infrastructure providers, implementation partners and smaller technology companies.
That structure is becoming increasingly visible in public-sector technology procurement. Government policy has encouraged greater participation by SMEs for some time, while procurement guidance increasingly recognises that large suppliers cannot sensibly maintain every specialist capability required by a complex digital programme. Social value requirements add another dimension, particularly as their weighting increases on larger central-government procurements from 2027.
The interesting question is no longer whether a large programme should contain multiple suppliers. In many cases it already does. The more useful question is whether those suppliers operate as a coherent delivery system or as a contractual hierarchy.
A poorly designed supply chain adds hand-offs, duplicated governance and arguments about responsibility. A well-designed supplier ecosystem does something quite different: it lets the programme combine scale with specialist capability while retaining clear accountability.
Making that work requires considerably more than adding subcontractors to a resource plan.
Supplier ecosystems often begin in the commercial model. A prime commits to a level of SME participation, identifies several partner organisations and allocates work packages or headcount between them. That may satisfy a procurement requirement, but it says very little about whether the resulting delivery model is technically sound.
The starting point should instead be the capability model for the programme.
Consider a large NHS platform involving identity, clinical data exchange, workflow services, APIs, analytics and integrations with local systems. The delivery team might need substantial numbers of software engineers, testers, product managers and delivery managers. It may also need much smaller concentrations of expertise in areas such as FHIR, terminology, clinical safety, Spine services, GP Connect, EPR integration, information governance, legacy messaging or NHS architecture.
Those requirements do not follow the same staffing curve.
A programme might legitimately need forty general software engineers but only two engineers with deep experience of a particular interoperability problem. Attempting to source every capability through the same staffing model creates predictable distortions. Scarce specialists either become expensive permanent bench capacity for the prime or, more commonly, the programme tries to approximate specialist knowledge using people whose experience is adjacent rather than direct.
The latter often appears economical until implementation begins.
Integration provides a good example. An engineer familiar with REST APIs can understand the mechanics of a FHIR endpoint quickly. That does not automatically mean they understand NHS-specific profiles, patient identity, terminology bindings, provenance, consent, local workflow behaviour, supplier-specific constraints or the operational consequences of a partially successful transaction. Those details tend not to appear in architecture diagrams, yet they determine whether the integration works reliably in production.
The ecosystem should therefore be mapped against areas where experience has disproportionate value.
One useful way to do this is to separate capabilities into three categories: capabilities required continuously and at scale; capabilities needed intermittently but repeatedly; and capabilities required at a small number of technically consequential points. The first group generally belongs within the prime’s core delivery organisation. The second can often be provided through stable specialist partners. The third may require only a handful of practitioners, but those people should be brought in before the relevant architectural decisions are made.
Timing matters as much as quantity. A specialist brought in to review an implementation three months after the interface contract has been agreed is being used as an auditor. The same person involved during discovery can influence the boundary design, error model, observability approach, data semantics and assurance plan before those decisions become expensive to reverse.
This is where an ecosystem becomes more than a method of distributing expenditure. It changes the capability available to the programme at the point decisions are made.
The commercial structure needs to follow that design rather than determine it.
Key point: Effective supplier ecosystems in large digital transformation programmes should be designed around capability, not simply subcontractor spend or SME targets. The strongest public-sector technology delivery models combine the scale and accountability of a prime supplier with specialist digital, cloud, integration and NHS expertise at the point it is needed, while keeping teams, tooling and engineering standards integrated.
Most ecosystem problems are not caused by technical incompatibility between suppliers. They come from organisational boundaries leaking into everyday delivery.
The symptoms are familiar: separate backlogs, separate stand-ups, supplier-specific Jira projects, architecture decisions disappearing into management meetings, duplicated delivery reporting and work being passed between companies through service requests rather than conversations.
Once this happens, supplier boundaries become part of the system architecture.
An engineer working for supplier A identifies a problem in a service owned by supplier B. Rather than pairing with the relevant engineer, the issue moves through a delivery manager, an account lead and a formal dependency process. A problem that could have been diagnosed in forty minutes becomes a three-day coordination task.
The technical solution is usually straightforward: organise teams around products or outcomes rather than employers.
A multidisciplinary team responsible for a clinical integration service might contain engineers from the prime, an interoperability specialist from another supplier, NHS product colleagues and a user researcher employed by a third organisation. Their employer should be largely irrelevant to the team’s operating model.
They should share the same backlog, ceremonies, engineering standards and definition of done. They should work in the same repositories unless there is a genuine security reason not to. They should have access to the same development environments, architecture material, operational telemetry and collaboration tools.
Several practical details make a disproportionate difference:
Code ownership deserves particular attention. Supplier ecosystems work badly when components become territorial. If one company alone can safely modify a service because nobody else understands it, the programme has created a dependency rather than acquired a capability.
Shared code review, pairing and deliberate knowledge transfer reduce that risk. A specialist may lead the initial implementation of a difficult component, but engineers from the wider team should work alongside them. The objective is not to eliminate specialist knowledge; it is to prevent specialist knowledge becoming inaccessible.
The same principle applies to architecture.
Large programmes often create architecture boards partly to coordinate multiple suppliers. These can become a substitute for engineers talking to one another. Formal architectural governance has value where decisions affect security, safety, data or programme-wide standards, but routine design should remain close to implementation.
A healthy pattern is for engineers and architects from different suppliers to collaborate on the decision, record it in an ADR and escalate only where a broader trade-off genuinely needs programme-level authority. Architecture should control risk without turning supplier interaction into a committee process.
One of the easiest ways to waste a specialist partner is to procure expertise and then deploy it as generic capacity.
A programme identifies the need for deep interoperability, architecture or platform experience. The individual joins a large squad and is immediately allocated ordinary backlog tickets because that is how the resource-management system works. Their utilisation looks excellent. Their distinctive value has largely disappeared.
Specialist capability works best when attached to a problem with enough scope to exercise judgement.
That does not necessarily mean creating isolated work packages. In many cases the specialist should remain embedded in the wider team. The difference is that their purpose is explicit.
An interoperability specialist might be accountable for helping the programme establish a consistent FHIR implementation approach across several teams. That could include profiling, terminology decisions, validation tooling, interface patterns, conformance testing, supplier engagement and reviews of individual implementations. They may write code, but their contribution is wider than the tickets they personally close.
A senior engineer brought in because of experience with a particular national service might help shape authentication flows, error handling, non-functional testing and operational monitoring before supporting individual teams implementing those patterns.
The value lies partly in avoiding work.
A practitioner who has seen the same failure mode several times can stop a team spending two sprints discovering it again. That saving will not necessarily appear in a conventional utilisation report because no additional deliverable was produced. The output was a bad decision that never entered production.
This makes performance measurement more difficult.
Counting people, days, story points or tickets naturally favours commodity capacity. Specialist contribution is better evaluated through outcomes such as reduced technical uncertainty, improved reliability, earlier retirement of integration risk, lower defect escape rates, successful assurance, faster diagnosis of production faults and reuse of proven patterns across teams.
For example, suppose a programme is integrating with twenty downstream systems. Measuring the integration team on the number of interfaces completed encourages throughput. Measuring first-time conformance, production failure rates, mean time to diagnose interface faults and reuse of common components gives a better view of engineering quality.
Both measures have a place, but the second group exposes whether specialist expertise is improving the system.
This is also why work-package boundaries need careful design. Handing an entire technical domain to a subcontractor may make commercial management easier, but it can create a black box. At the other extreme, spreading individual specialists randomly across a hundred-person programme can make their impact invisible.
A useful middle ground is to give specialist partners explicit technical responsibilities while keeping delivery integrated. They may own a capability, pattern or difficult component without becoming a separate miniature programme.
The result is closer to internal platform engineering than traditional subcontracting: a small group develops expertise and reusable approaches that improve the work of many delivery teams.
Supplier ecosystems are often designed carefully during procurement and then managed through conventional prime/subcontractor relationships once delivery starts. This is where many of the intended benefits disappear.
The commercial relationship naturally contains asymmetry. The prime holds the customer contract and is accountable for overall performance. That does not require every operational interaction to follow the contractual hierarchy.
Good ecosystem governance separates contractual accountability from delivery collaboration.
The prime should maintain responsibility for commercial management, consolidated reporting, overall delivery risk and contractual obligations. Individual delivery teams should still be able to work directly across organisational boundaries.
That sounds obvious, but it affects everything from meeting structures to incident management.
During a production incident, for example, the incident commander should be chosen according to operational responsibility, not employer. Engineers should be able to inspect relevant logs and traces without waiting for another supplier to extract them. If a specialist vendor owns part of the diagnosis, they need sufficient telemetry to reason about the complete request path rather than only their own component.
The same principle applies to risk.
Passing risk down a supply chain rarely removes it from the programme. If a small specialist supplier is contractually required to absorb a level of demand volatility, liability or payment delay that it cannot realistically manage, the apparent transfer simply creates a fragile dependency.
Large suppliers are generally better placed to absorb programme-level uncertainty. Specialist suppliers are better placed to own technical risks within their area of expertise. The contract should reflect that difference.
Commercial terms also affect engineering behaviour more than is sometimes acknowledged.
A subcontractor operating under very short termination notice and uncertain monthly demand will rationally avoid investing heavily in programme-specific capability. A partner with reasonable visibility of upcoming demand can retain the right people, develop knowledge and participate properly in planning.
Prompt payment has a similar operational effect. A large prime may regard thirty-day payment as routine. For a smaller firm carrying several senior practitioners on a programme, extended payment cycles materially alter working capital requirements. Commercial friction eventually becomes delivery friction.
Forecasting therefore matters. Specialist suppliers do not usually have hundreds of interchangeable people available at short notice. If a programme expects access to a named architect or engineer with unusual experience, resource planning needs to happen earlier than it would for generic capacity.
A functioning ecosystem usually has several planning horizons. Delivery teams manage sprint-level work. Programme leadership maintains a view of capabilities required over the next quarter. Commercial teams look further ahead for significant ramp-ups, extensions or likely changes in specialist demand.
This also makes mobilisation and demobilisation less disruptive.
When specialists leave, handover should not consist of producing a document in their final week. Knowledge transfer is most effective when it happens continuously through joint design, code review, pairing, operational support and shared ownership. Exit planning then becomes verification that knowledge has spread rather than an emergency attempt to extract it.
The Procurement Act’s approach to prompt payment, public-sector expectations around fair treatment of subcontractors and government guidance on supply-chain management all point in this direction, but compliance is the minimum. A well-run prime treats the health of the supplier ecosystem as an operational dependency.
If one critical specialist supplier is unable to retain people because forecasts are unreliable, onboarding takes months or invoices remain unresolved, the programme has a resilience problem.
It is easy to measure whether an ecosystem exists. Supplier count, SME spend and subcontract value are readily available from commercial systems. Those figures can demonstrate participation, but they do not show whether the arrangement has improved the programme.
Delivery measures should test the original reason for creating a mixed supplier model.
If specialist organisations were included to provide scarce expertise, look for evidence that difficult decisions are being made earlier and with fewer reversals. If the intention was to improve engineering quality, examine escaped defects, reliability and rework. If different suppliers were expected to bring different perspectives, look at how architecture decisions are challenged and whether teams have viable alternatives rather than defaulting to the prime’s existing technology estate.
Supply-chain health is worth measuring directly as well.
Useful indicators include onboarding time, access-provisioning time, payment performance, forecast accuracy, staff retention, unresolved cross-supplier dependencies and feedback from subcontractors about whether they can operate effectively within the programme.
The last measure is particularly useful because formal programme reporting frequently masks friction at supplier boundaries.
A dashboard may show that all major milestones are green while engineers spend substantial time waiting for another organisation to approve changes, provide test data or grant environment access. Asking suppliers periodically where the operating model is slowing delivery can expose those issues early.
Technical metrics can reveal similar problems.
Long lead times between code complete and production may indicate excessive cross-supplier release governance. High reopen rates on integration defects can indicate unclear ownership. Repeated incidents at service boundaries can point to weak interface contracts or insufficient end-to-end testing. A growing number of supplier-specific components doing similar things may suggest that teams are solving problems independently rather than reusing shared patterns.
These are ecosystem defects, not simply engineering defects.
The strongest programmes eventually stop thinking about their suppliers as separate pools of labour. They maintain clear commercial accountability, but the delivery model is organised around products, services and technical capabilities.
A prime supplier provides scale, programme infrastructure and a single point of accountability. Specialist organisations contribute expertise that would be uneconomic or unrealistic to maintain everywhere. The customer retains enough technical authority to understand the system being built and challenge decisions. Engineers work across company boundaries using common tooling, standards and operational practices.
Under those conditions, supplier diversity becomes useful for reasons that have little to do with procurement statistics.
A difficult architecture decision can draw on people who have solved the problem in different contexts. Scarce expertise can be introduced without forcing one organisation to employ every possible specialist. Teams can scale through a large delivery partner without assuming that scale and expertise must come from the same place.
The procurement model creates the opportunity. The operating model determines whether any of that value reaches the live service.
Supplier ecosystems work when the programme is designed so that the best available capability can reach the problem that needs it, without contractual boundaries becoming delivery boundaries. When that happens, the supply chain stops being something that sits behind the contract and becomes part of the engineering system itself.
Is your team looking for help with technology delivery? Click the button below.
Get in touch