Rethinking the IT operating model for the AI era.

The outsourcing market has changed faster than its buyers

Most large IT sourcing arrangements now in force were designed for a market that no longer exists. They were structured around cost reduction: rate cards, volume commitments and offshore leverage. The market into which they will be renewed is organised around different criteria, namely innovation capacity, AI-enabled delivery, security posture and accountability for outcomes.

Four shifts define the current landscape. First, outsourcing has become a strategic instrument rather than a cost lever; organisations select partners for specialised capability they cannot build quickly themselves. Second, AI maturity now differentiates providers materially. Automated code generation, AI-assisted testing and predictive monitoring change quality and cycle times, and providers vary widely in how deeply they have absorbed these methods. Third, cybersecurity has moved from an appendix to a core selection pillar. Zero-trust alignment, segregation of IT and OT environments and continuous monitoring are entry criteria, particularly for critical infrastructure. Fourth, commercial models are moving from effort to outcome, measured through uptime, recovery times, defect rates and user experience, reported transparently.

For asset-intensive and regulated organisations, including utilities, energy, infrastructure and financial services, these shifts arrive at an inconvenient moment. Contract expiries force decisions on compressed timelines, while the existing estate commonly exhibits familiar friction: fragmented architecture across siloed vendors, rigid point-to-point integration, converging IT and OT networks without adequate segmentation, thin internal capability in emerging technologies, and operational demands absorbing the capacity that transformation requires. Renewing the old model into the new market extends those problems for another contract cycle.

The central design choice is the sourcing boundary

An IT operating model answers one question above all others: which capabilities must the organisation own, and which should it source? An error in either direction has structural consequences. Outsource too much and the organisation comes to depend on vendors for its own judgement; architecture drifts toward each vendor's preference, intellectual property accumulates in other firms, and every renewal negotiation starts from dependency. Retain too much and the organisation carries fixed cost and scarce skills in functions the market provides better and more resiliently.

The practical resolution is a deliberate three-band structure.

• Retain — strategic control. Enterprise architecture and design authority, data governance, cyber strategy, demand management. A digital and AI capability for prototyping and early-stage solution shaping, with retained IP, plus vendor and service governance.
• Partner — specialist work packages. Data and analytics engineering, cybersecurity operations, cloud engineering, integration platforms — sized for competition between specialist and integrated providers, with clean boundaries and shared standards.
• Outsource — scalable managed services. Infrastructure and cloud operations, network, business application support, service desk — governed through outcome-based SLAs and XLAs, transparent reporting and a SIAM interaction model.

The retained band deserves the most scrutiny, because it is where most designs are weakest. It must include the design authority, which is the right to decline vendor architecture choices, together with data governance, security strategy and a demand function with genuine authority. It should also include a capability most organisations still lack: an internal digital and AI engine. A small retained team that prototypes, shapes early-stage solutions and builds AI-enabled products changes the organisation's position in a lasting way. It accumulates intellectual property internally, keeps the organisation a competent buyer of what it sources, and provides innovation capacity that operational demands would otherwise absorb. Without it, strategic control is an organisation chart with no one behind it. How such a capability is established is set out in The AI Factory.

The layers around the service towers

Service towers, covering infrastructure and cloud, network, business applications, data foundations and cybersecurity, are the visible part of any operating model. The layers around them determine whether it functions.

• Strategy and demand. Alignment of the IT portfolio with business strategy, and a demand function with the authority to decline requests. Cost opacity in multi-vendor estates is usually a demand-management weakness before it is a pricing one.
• Architecture governance. Standards, design principles and an empowered design authority, with API-first integration patterns that prevent the estate from re-fragmenting one vendor decision at a time.
• Innovation enablement. The digital and AI capability described above, feeding proven concepts into the delivery towers.
• Governance and service integration. Performance, risk, compliance and vendor management operating across all towers, through a SIAM model with defined interaction routines, escalation paths and cross-vendor accountability, so that end-to-end service quality has an owner even where no single vendor owns it.
• Security throughout. Zero-trust architecture, segregation of IT and OT environments, and security embedded in every tower and every contract rather than treated as a separate tower.

From design to market

Most operating model designs do not fail in the design. They fail in translation, in the gap between a coherent target-state description and a procurement package the market can bid against. Three disciplines close that gap.

Work packages designed for competition

Lot structure is strategy. Packaging the estate as a single arrangement produces integrator dependency, priced accordingly. Fragmenting it into many small lots creates an integration burden that no service-integration function can absorb. Each proposed boundary should pass three tests: a specialist provider can bid credibly, an integrated provider can be benchmarked honestly, and every cross-lot interaction is specified before award rather than negotiated after it.

Requirements written as outcomes

Service requirements, KPIs, SLAs and experience-level agreements defined per tower, with non-functional requirements covering availability, continuity, assurance and compliance specified explicitly. A performance regime that cannot be measured transparently from the first day will not be enforced in the third year.

Validation before release

Scoring models tested before tenders are issued. Lot boundaries examined for practicality. Architecture guardrails checked against every requirement set. An RFP is a contract in draft form, and the least expensive moment to correct it is before the market sees it.

A closing observation

The binding constraint on most operating model transformations is not the design, the vendors or the technology. It is the retained organisation's willingness to change how it works. A target model that redraws every vendor boundary while leaving internal decision rights, funding models and demand behaviour untouched will reproduce the existing dysfunction inside the new structure, at the cost of a full procurement cycle. An organisation that is not prepared to build genuine retained capability and enforce its own design authority is better served by negotiating a simpler arrangement and being candid about the dependency it has chosen.