Topic 6.6 — Vendor & Service Integration Management (SIAM)

In a health and care estate stitched together from dozens of suppliers, the service your patients and clinicians actually experience is only as good as the seams between vendors — so someone must own the end-to-end whole that no single contract describes.

Why this matters in health and care#

No modern NHS trust or integrated care system (ICS) runs on one supplier. A single clinical workflow — a GP referral that becomes an outpatient appointment, a letter, a test result and a prescription — can traverse an electronic patient record from one vendor, an integration engine from another, a hosting platform from a third, a network provider, a national spine service, and a managed-service desk run by a fourth party you have never met. The contract for each part may be sound. The service the patient receives lives in the gaps between them.

This is the run-and-operate side of the commercial relationship, and it is where value is either realized or quietly lost. Procurement and commercial teams (see Topic 6.3 — Procurement & Commercial) buy well, award the contract, and hand over a signed agreement; what happens across the years that follow — whether suppliers cooperate or blame each other, whether an outage is fixed in an hour or festers for a week, whether you can ever leave — is the work of vendor and service integration management. Get it wrong and the failure is not abstract. A pathology interface that silently drops results, a shared care record that shows a stale allergy, an authentication service that locks clinicians out at handover: these are patient-safety events that begin as integration problems (see Topic 1.6 — Clinical Safety & Risk Management).

The stakes are sharpened by three features of the sector. Public money demands that the outcomes bought are the outcomes delivered, and that service credits and value are actively pursued, not left on the table. Statutory duties for data protection, clinical safety and cyber security must flow down an entire supply chain, including sub-contractors you did not choose (see Topic 1.7 — Information Governance, Data Protection & Cyber Security). And the concentration of critical services into a handful of large suppliers means that one vendor's ransomware incident, insolvency or capacity failure can take a whole region offline. Managing suppliers as a portfolio — not one contract at a time — is now a resilience duty, not an administrative one.

Core concepts#

Service integration and management (SIAM) is a management approach for coordinating multiple service providers and integrating them to deliver a single, end-to-end service to the business. It emerged as a discipline precisely because organizations moved away from a single prime contractor towards a multi-sourced operating model, and then discovered that someone still had to make the parts behave as a whole. SIAM is not a product you buy; it is an operating model with defined roles, processes and governance. The authoritative reference is the Scopism SIAM Body of Knowledge, which sits alongside ITIL and the wider practice of IT service management (ITSM) rather than replacing them.

A SIAM model has three layers. The customer, or retained organization, keeps the accountabilities that can never be outsourced: strategy, demand, architecture, commercial ownership, and the final duty of care to patients. The service integrator is the layer — an internal team, an external supplier, or a hybrid — that coordinates the providers, owns cross-cutting processes such as major-incident management, and holds the end-to-end view. The service providers, often organized into service towers (hosting, end-user computing, clinical applications, networks), each deliver a defined slice. These are SIAM terms of art rather than encyclopedia entries, so they are named here in plain language and grounded in the SIAM body of knowledge.

Underneath sit the commercial mechanics. Outsourcing and its data-and-process variant, business process outsourcing, describe delegating work to an external provider; managed services describe the ongoing, subscription-style operation of systems on your behalf. Performance is governed by a service-level agreement (SLA) — a measurable, usually contractual commitment — increasingly complemented by an experience-level agreement (XLA), which measures the outcome a user actually experiences rather than the component metric a supplier finds convenient to hit. XLA has no settled encyclopedia entry; treat it as an emerging practice, not a standard.

Two risk concepts frame the topic. Third-party management is the discipline of overseeing external providers and, crucially, their own sub-contractors — the fourth parties deep in the supply chain. Supply chain risk management addresses the failures that propagate through that chain, and concentration risk — a term borrowed from banking — captures the danger of depending too heavily on a single supplier, platform or region. Managing these is what keeps a convenient sourcing decision from becoming a systemic vulnerability. Finally, avoiding vendor lock-in and driving continual improvement are the two forward-looking duties that stop a live service from ossifying.

Best practices#

1. Name the accountable owner for the end-to-end service, not just for each contract. The defining failure of multi-sourcing is that everyone owns a box and no one owns the arrows between them. Establish a retained-organization role — often a service-integration lead or a supplier-management office — that is accountable for the whole clinical or business service as the user experiences it, with the authority to convene suppliers and arbitrate. This owner holds the end-to-end SLA even where no single vendor can, and is the person a board can ask "why was the referral system down for six hours?" and get an answer rather than a round of finger-pointing.

2. Choose and design the SIAM model deliberately, then write it into the contracts. Decide early whether the service integrator is internal, external or a hybrid, and be honest about the trade-off: an internal integrator keeps control and knowledge but demands scarce capability; an external one buys maturity but adds a layer to govern and a potential conflict of interest if it also runs a tower. Define the towers, the cross-cutting processes the integrator owns, and the collaboration obligations of every provider. Crucially, these obligations must appear in each provider's contract — a duty to cooperate, to attend the integrator's major-incident bridge, to share data — because a supplier will do at run-time only what it was bought to do at award-time (see Topic 6.3 — Procurement & Commercial).

3. Segment your suppliers and spend your attention where it counts. Not every vendor deserves the same governance; treating a commodity license reseller like a strategic EPR partner wastes effort and starves the relationships that matter. Use a segmentation model such as the Kraljic matrix to sort suppliers by business criticality and market difficulty into strategic, leverage, bottleneck and commodity categories, and match the governance rhythm to the segment — quarterly executive business reviews for strategic partners, light-touch performance monitoring for commodities. This is also how you focus assurance, relationship investment and exit planning on the few suppliers whose failure would genuinely hurt.

4. Manage outcomes and experience, not just component metrics. A supplier estate can hit every individual SLA — 99.9% server uptime, tickets closed within target — while the clinician's actual day is miserable and the pathway is broken end to end. Complement component SLAs with experience-level agreements and end-to-end measures that reflect what patients and staff experience, and beware "watermelon" reporting: green on the outside, red on the inside. Where a metric can be met by gaming (closing and reopening tickets, reclassifying severity), redesign it so the supplier's incentive aligns with the outcome you actually want.

5. Run one integrated incident and problem process across all suppliers. When an incident spans several vendors, the "swivel-chair" problem — each supplier insisting the fault lies elsewhere while the service stays down — is the single most damaging pattern in multi-sourcing. Give the service integrator the authority to declare a major incident, pull every relevant provider onto one bridge, and drive resolution regardless of whose component is at fault, with a no-fault "fix first, apportion blame later" rule. This mirrors the internal ITIL disciplines your service-management function already runs (see Topic 3.8 — Service Management & Live Operations), extended across the contractual boundary so a supply chain behaves as one operations team during a crisis.

6. Make contract and performance management an active, evidenced discipline. A contract left in a drawer after signature is money and leverage abandoned. Hold structured performance reviews against the SLAs, track and actually claim service credits where they are due, maintain a shared risk-and-issue register, and keep an auditable record of performance that will matter at renewal or dispute. Service credits are not the point — they are a signal and a lever; a mature relationship uses persistent underperformance to trigger improvement plans and, ultimately, exit, not merely to bank a small rebate (see Topic 6.4 — Governance & Assurance).

7. Flow clinical-safety, data-protection and cyber obligations all the way down the chain. Your statutory duties do not stop at your prime supplier; they must reach the sub-contractor hosting the data and the open-source library inside the product. Require flow-down of clinical-safety obligations under the relevant standards, data-processing terms, and cyber controls aligned to NCSC supply-chain guidance, and demand visibility of fourth parties so you know who is really in the chain. Assess concentration risk explicitly — if three of your critical services sit on one hyperscaler region or one managed-service provider, a single failure is a regional outage, and the mitigation is a decision the board must take knowingly (see Topic 3.9 — Business Continuity & Disaster Recovery).

8. Plan the exit before you are desperate to take it. The cheapest time to secure your ability to leave is before you sign; the moment you most need it, all your leverage is gone. Maintain a live exit plan for every critical supplier covering data extraction in open, documented formats, knowledge transfer, transition support obligations, and the assets and licenses you would need to re-provision elsewhere. Real portability is proven, not promised — test that you can export your data and stand it up somewhere else, because a contractual right to your data in a proprietary dump is not the same as being able to use it (see Topic 4.0 — Technical Architecture, Cloud & Legacy, on avoiding vendor lock-in in practice).

Questions to discuss with your team#

1. When an incident crosses three suppliers at 2am, who has the authority to make them all act as one team — and does every contract oblige them to answer the call? This matters because the swivel-chair failure is not a technical gap but an authority gap: suppliers behave rationally when they defend their own SLA and deflect blame, and only a designated integrator with contractual backing can override that. Debate honestly whether such a role exists in your organization today, whether it has real authority or merely convenes and pleads, and whether your provider contracts actually require cooperation on a shared major-incident bridge or merely encourage it. Consider the hardest cases — a fault that spans a national service, a hosting provider and an application vendor, where the root cause is genuinely ambiguous for the first hour. Look at whether you operate a no-fault "restore first, apportion later" rule, or whether resolution stalls while commercial teams argue about liability. A good answer names the accountable integrator, points to the contract clauses that compel cooperation, and can describe a recent cross-supplier incident where the model held — or admits candidly that last time, it did not.

2. Which suppliers could we genuinely not survive the sudden loss of — and what would we actually do the morning they failed? This forces the concentration-risk conversation that sourcing convenience tends to bury: the estate accretes dependencies on a few strategic partners and a handful of platforms, and the aggregate exposure is rarely mapped until an incident reveals it. Discuss which vendors are single points of failure for a clinical service, whether the dependency is contractual, technical or knowledge-based, and how deep into the fourth-party chain the real risk sits — the sub-processor, the offshore support team, the one hyperscaler region. Weigh the trade-off honestly: consolidation buys efficiency, integration and better pricing, while diversification buys resilience at a cost, and the right answer is a deliberate board choice, not an accident of past procurements. Consider whether your exit and continuity plans for these suppliers are tested or merely written, and whether you could extract and re-host your data if a supplier went insolvent next week. An honest answer distinguishes the suppliers you manage from the few whose failure is an existential event, and shows that the residual risk on the latter has been consciously accepted at the right level.

3. Are we measuring what our clinicians and patients experience, or only what our suppliers find easy to report green? This question surfaces the gap between component SLAs and real outcomes, which is where multi-sourced services quietly disappoint even while every dashboard is green. Explore where "watermelon" reporting hides in your estate — the individually-met metrics that add up to a broken pathway, the tickets closed by asking the user to try again, the uptime measured on a server no clinician touches. Debate whether you have any true end-to-end or experience-level measures, who owns them, and whether suppliers are incentivized on the outcome you want or on a proxy they can game. Consider the tension that richer, experience-based measurement costs money and effort and can be contested by suppliers whose credits depend on the old metric. A strong answer can point to at least one end-to-end measure that reflects the user's reality, explains how it is governed across suppliers, and is candid about where current SLAs reward the wrong behavior and need renegotiating at the next break point.

4. Who should run our integration layer — an internal team, an external supplier, or a hybrid — and have we been honest about the conflict of interest that choice creates? The make-or-buy decision for the service integrator itself is often made by default rather than deliberately, and it shapes every relationship that follows. Debate the real trade-off: an internal integrator keeps knowledge and control inside the retained organization but demands scarce, expensive capability that a trust may not be able to hold; an external integrator buys maturity and tooling quickly but adds a layer to govern, and becomes acutely problematic if that same supplier also runs a service tower and is effectively marking its own homework. Consider the middle cases — a hybrid where the retained organization owns accountability and arbitration while a partner provides the operational machinery — and whether your organization has the commercial and technical seniority to direct an integrator rather than be led by it. Look honestly at where the integration knowledge actually lives today, and what happens to your end-to-end view if that integrator's contract ends. An honest answer names who integrates, explains why that model was chosen for your context rather than inherited, and can point to the safeguards that stop an integrator who also delivers services from grading its own performance.

5. Do our statutory duties for clinical safety, data protection and cyber security actually reach the fourth parties deep in the chain — or do they stop at the prime we signed with? This matters because accountability for a patient-safety or data-breach event does not follow the contract; it stays with the retained organization even when the failure occurred three tiers down, in a sub-processor or an offshore support team you never chose. Explore whether your flow-down clauses are real and tested — whether clinical-safety obligations under the relevant standards, data-processing terms and cyber controls are genuinely contractually imposed on sub-contractors, and whether you have any visibility of who those sub-contractors are. Discuss the tension that primes resist exposing their supply chain as commercially sensitive, while you cannot assess a risk you cannot see, and that demanding fourth-party transparency can slow procurement and narrow the market. Consider the concrete failure — the open-source library inside a product, the hosting sub-contractor, the third-party analytics tool — and whether an incident there would find your obligations enforceable or merely aspirational. A strong answer shows that flow-down is written, evidenced and occasionally audited, not assumed, and can name where in the chain visibility currently runs out.

6. Once the contract is signed, who actively manages it — claiming credits, driving improvement, and holding suppliers to the value we bought — rather than filing it in a drawer? The defining leakage in multi-sourcing happens after award, when procurement's attention moves on and no one owns the years of run-and-operate where value is realized or quietly lost. Debate whether you hold structured performance reviews against the SLAs, whether you actually track and claim the service credits you are owed, and whether persistent underperformance triggers an improvement plan or is simply absorbed. Consider the tension that chasing credits can sour a relationship you depend on, and that a mature approach treats credits as a signal and a lever for improvement rather than a rebate to bank — but that suppliers learn quickly which customers never check. Look at whether you maintain an auditable record of performance that will matter at renewal or dispute, and whether continual improvement is a contractual expectation or an occasional favor. An honest answer describes who owns each strategic relationship, points to a recent case where evidenced performance management changed a supplier's behavior, and admits candidly where contracts are running unmanaged and value is leaking year on year.

In practice: a health & care example#

Northmoor Integrated Care System runs a digital estate typical of its scale: a hosted electronic patient record from one major vendor, a shared care record platform from another, an integration engine and interface layer from a specialist, national services from NHS England, connectivity from a network provider, and a managed service desk operated by a systems integrator whose first-line support is itself sub-contracted offshore. Each contract was procured separately over a decade, each has its own SLA, and — until recently — each was governed by a different manager in a different directorate.

The problem announces itself on a Monday. Clinicians report that GP referrals are arriving in the acute trust with missing attachments, sometimes hours late. The EPR vendor reports 100% uptime and closes the ticket. The integration supplier says its engine is passing every message it receives. The shared care record vendor says the same. The network provider shows no faults. Every supplier is green; the referral pathway is amber-going-red; and no one owns the arrow between the boxes. For nine days, patients wait while the tickets bounce.

Northmoor's response is to stand up a service-integration function inside the retained organization, led by a head of supplier and service management with a small team and, critically, board-mandated authority. They first segment the estate — the EPR, shared care record and integration supplier are designated strategic, the network provider a bottleneck supplier, the license resellers commodity — and set a governance rhythm to match. They then rewrite the operational schedule appended to each strategic contract at its next break clause to include a duty to join the integrator's major-incident bridge within thirty minutes and to share diagnostic data on request. An end-to-end "referral delivered complete and on time" measure is defined and reported alongside the component SLAs, owned by the integrator, not any single vendor.

The test comes six months later, when result messages start silently failing. This time the integrator declares a major incident within the hour, convenes all three strategic suppliers plus the network provider on one bridge under a no-fault rule, and drives them to trace the message end to end. The root cause turns out to be a character-encoding change the integration supplier deployed that the EPR could not parse — a fault that lived precisely in the seam no single supplier could see. It is fixed in four hours, a joint problem record captures the fix, and a service credit is claimed and reinvested in a shared regression-test suite. Meanwhile, the ICS quietly notes that all three strategic suppliers host in the same cloud region, records the concentration risk on the board assurance framework, and commissions a tested data-extraction exercise so that, if it ever needs to move, portability is proven rather than promised.

Sector lenses#

Startup#

A digital-health startup usually sits on the other side of this topic — it is the supplier being integrated, and its commercial future depends on being a good citizen in someone else's SIAM model. Winning NHS work increasingly means proving you will join a major-incident bridge, expose your sub-processors, flow down clinical-safety and data-protection obligations, and hand data back cleanly at exit, so building those cooperation capabilities early is a competitive advantage, not overhead. Internally, a startup is also a consumer of critical third parties — its own cloud host, payment processor and authentication provider — and carries real concentration risk with almost no leverage over vendors far larger than itself. The discipline that scales is to keep the dependency map current, avoid architectural lock-in where a cheap switching cost is available, and be honest with customers about the fourth parties in your own chain.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home or domiciliary-care agency, a single-site clinic — carries the same statutory duties for clinical safety, data protection and cyber security as a large trust, but manages a stack of suppliers with no dedicated IT function and little contractual leverage. In practice the whole SIAM discipline collapses onto one or two people who also do other jobs, so the realistic move is to identify the two or three suppliers a clinical day genuinely depends on — the clinical system, the connectivity, the shared-record link — and manage those relationships deliberately while accepting a lighter touch on the rest. Concentration risk is acute and unavoidable: a single practice management system or one broadband line can be a total single point of failure, and the mitigation is often operational (a downtime procedure, a second connection) rather than a second supplier. Exit and portability matter just as much here, because a small provider locked into a proprietary record has even less power to move, so the questions to press a supplier on are data export in an open format and what happens if the contract ends. A small health-tech supplier past the startup stage faces the mirror image: it must satisfy the cooperation, flow-down and exit obligations its NHS customers now demand, without the compliance team a larger vendor would have.

Enterprise#

A large trust, provider collaborative or ICS is the archetypal SIAM customer: dozens of suppliers, a long-lived estate assembled by successive procurements, and services whose end-to-end behavior no one fully owns. The realistic goal is a functioning retained organization with a genuine service-integration capability, supplier segmentation so attention flows to the strategic few, and cross-cutting incident and problem management that works across contractual boundaries — not a fantasy of perfectly aligned SLAs. The hardest work is contractual and cultural: retrofitting collaboration duties into legacy agreements as break clauses allow, and shifting suppliers from defending their box to owning their share of the whole. At this scale the biggest resilience gains come from mapping concentration risk across the portfolio and testing exit for the handful of suppliers whose failure would be a regional event.

Government#

A national body — NHS England, a devolved health department, or a framework operator such as the Crown Commercial Service — shapes the environment in which every trust manages its suppliers. Its leverage is to set expectations through the Government Commercial Function's Sourcing Playbook and standard terms, to make cooperation, portability and supply-chain assurance the market default rather than something each buyer negotiates alone from weakness. Government also carries the systemic view: it can see, as an individual trust cannot, when a single supplier or platform has become a critical third party for the whole system, and it must manage that concentration as a national resilience matter. Its duty is to ensure that framework design, assurance regimes and national services reduce lock-in and single points of failure rather than entrenching them (see Topic 9.1 — Working with Local & National Governments).

Common failure modes#

• The accountability vacuum. Every supplier owns a component and none owns the end-to-end service, so cross-boundary problems have no home. Name an accountable integrator with real authority.
• The swivel-chair incident. Suppliers deflect blame while the service stays down and no one is empowered to make them cooperate. Mandate a single major-incident bridge and a no-fault "restore first" rule in every contract.
• Watermelon SLAs. Every component metric is green while the actual service is red; suppliers report to the metric, not the outcome. Add end-to-end and experience-level measures the integrator owns.
• Uniform governance. Treating a commodity reseller and a strategic EPR partner alike wastes effort and starves the relationships that matter. Segment suppliers and match the governance rhythm to criticality.
• The contract in the drawer. After signature no one manages performance, claims credits, or drives improvement, so value leaks year on year. Run active, evidenced contract management.
• Invisible fourth parties. Obligations are flowed down to the prime but stop there, leaving unknown sub-contractors holding the data or the risk. Demand supply-chain visibility and flow controls to the bottom.
• Unmanaged concentration. Critical services quietly consolidate onto one supplier, platform or region until a single failure becomes systemic. Map and consciously accept concentration risk at board level.
• The theoretical exit. A contractual right to your data that has never been tested is not portability. Prove data extraction and re-hosting before you need it.

Maturity model#

Checklist#

• A named retained-organization role is accountable for the end-to-end service and holds the end-to-end SLA.
• The SIAM model — integrator, towers, cross-cutting processes — is defined and written into supplier contracts.
• Suppliers are segmented by criticality, with a governance rhythm matched to each segment.
• End-to-end and experience-level measures complement component SLAs and are owned by the integrator.
• A single cross-supplier major-incident process exists, with a no-fault "restore first" rule contractually mandated.
• Contract performance is actively reviewed, service credits are tracked and claimed, and improvement plans are triggered.
• Clinical-safety, data-protection and cyber obligations are flowed down to sub-contractors, with fourth-party visibility.
• Concentration risk across suppliers, platforms and regions is mapped and consciously accepted at board level.
• A live exit plan exists for every critical supplier, covering data, knowledge and transition support.
• Data extraction and re-hosting have been tested, not just contractually promised, for critical services.

Key sources#

• Scopism — SIAM Body of Knowledge and SIAM Professional Body of Knowledge — the definitive open reference for service integration and management roles, structures and processes.
• AXELOS — ITIL 4 — IT service management practices for incident, problem, change and supplier management that SIAM extends across suppliers.
• UK Government Commercial Function — The Sourcing Playbook and Outsourcing Playbook — public-sector guidance on sourcing, contract management and exit.
• Crown Commercial Service — framework agreements and standard terms for public-sector technology and managed-service procurement.
• National Cyber Security Centre (NCSC) — Supply chain security guidance — assessing and managing cyber risk across suppliers and sub-contractors.
• HM Government / Cabinet Office — guidance on managing critical third parties and concentration risk in public services.
• NHS England — clinical safety standards DCB0129/DCB0160 and data-processing requirements to be flowed down to suppliers.

References#

1. Service integration and management — Wikipedia — https://en.wikipedia.org/wiki/Service_integration_and_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
4. Outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Outsourcing
5. Business process outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Business_process_outsourcing
6. Managed services — Wikipedia — https://en.wikipedia.org/wiki/Managed_services
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Third-party management — Wikipedia — https://en.wikipedia.org/wiki/Third-party_management
9. Supply chain — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain
10. Supply chain risk management — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_risk_management
11. Concentration risk — Wikipedia — https://en.wikipedia.org/wiki/Concentration_risk
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Continual improvement process — Wikipedia — https://en.wikipedia.org/wiki/Continual_improvement_process
14. Kraljic matrix — Wikipedia — https://en.wikipedia.org/wiki/Kraljic_matrix
15. Scopism — SIAM Body of Knowledge — https://www.scopism.com/
16. AXELOS — ITIL 4 — https://www.axelos.com/certifications/itil-service-management
17. UK Government Commercial Function — The Sourcing Playbook — GOV.UK — https://www.gov.uk/government/publications/the-sourcing-playbook
18. National Cyber Security Centre — Supply chain security guidance — NCSC — https://www.ncsc.gov.uk/collection/supply-chain-security
19. Crown Commercial Service — GOV.UK — https://www.gov.uk/government/organisations/crown-commercial-service