The Enterprise has Left the Building

The Enterprise Has Left the Building 

A New Lens for IT Governance When the Operating Enterprise and the Legal Enterprise Are Strangers 

By Rajwardhan Purohit | ITIL Master | Global Ambassador, ITIL & DevOps | Principal Capability Architect 

The Enterprise You Think You're Managing Doesn't Exist Anymore 

Picture a mid-sized children's apparel retailer. It has a registered office, a board of directors, a CFO, and an IT department. On paper, it is a single, bounded organisation. 

Now look at how it actually operates. 

Its products are designed in-house but manufactured by two contract factories whose production schedules, inventory positions, and quality checkpoints are managed - and partially governed - by the retailer's own systems. It sells through five online marketplaces, each with its own fulfilment SLA, returns API, and seller compliance framework. A third-party logistics provider manages its warehousing, inventory orchestration, and last-mile coordination. That 3PL, in turn, contracts with multiple courier and delivery agencies who physically move goods to customers and collect returns. The retailer's ERP talks to the 3PL's WMS. The 3PL's system talks to the courier's tracking API. The marketplace's demand signal feeds back into the contract manufacturer's production planning. 

The legal enterprise is one company.

The operating enterprise spans twelve. 

 

 

 

 

 

 

 

Now consider a regional hospital network.

Four hospitals across different cities. Ambulance services operated by a contracted professional agency. Pathology samples collected from patient homes by one contractor, analysed by a separate laboratory network, with reports flowing back digitally. Specialist consultants who visit on fixed schedules or on-call basis - employed by nobody, credentialed by the hospital, critical to patient outcomes. Medical equipment under AMC contracts managed by a facilities support company. Housekeeping and security staff from third-party agencies. And sitting above all of this: a hospital management information system, a patient care platform, and a clinical data repository - all proprietary, all critical, all owned by the legal entity. 

The CEO of this hospital network cannot point to an org chart that reflects how care is actually delivered. 

These are not edge cases. They are the dominant operational model of the modern enterprise -in retail, healthcare, financial services, logistics, hospitality, and manufacturing. The data confirms the scale of this shift: according to Deloitte's 2024 Global Outsourcing Survey, 80% of executives plan to maintain or increase investment in third-party outsourcing, and 50% are now using outsourced services for front-office capabilities - sales, marketing, and R&D - 

domains once considered core and internal [1]. Separately, Deloitte's survey data indicates that organisations now report an average of 76% of IT work delivered by external providers, shared services, or other non-employee models[2]. The global outsourcing market, spanning IT services and business processes, exceeded $1 trillion in 2025[3]. 

The Operating Enterprise is not a trend. It is the present state of business. 

The Structural Shift: Two Enterprises, One IT Problem 

For most of IT governance history, a foundational assumption has gone unquestioned: the enterprise has a boundary. Inside the boundary are systems, people, processes, and data you own, control, and are accountable for. Outside the boundary are suppliers and partners you manage at the edges through contracts and SLAs. 

That assumption is broken. 

 

 

 

 

In the modern operating enterprise, the boundary is not a wall - it is a membrane. Data flows across it continuously. Decisions made by a partner's AI model affect your service delivery. A vulnerability in your logistics provider's API is your customer's problem. A pathology lab's reporting latency is your hospital's clinical risk. An ambulance agency's dispatch system failure is your patient's emergency. 

The distinction I want to name explicitly - because it has profound implications for how we think about IT governance - is this: 

IT governance, as currently practiced and as frameworks currently describe it, is designed almost entirely for the Legal Enterprise. It assumes you can mandate standards, own systems of record, enforce policies, and audit processes. In the Operating Enterprise, none of those assumptions hold cleanly. You govern through contracts, not authority. You observe through APIs, not direct instrumentation. You assure through SLAs, not internal policy. 

This is not a minor gap. It is a category difference. And it demands a different way of thinking about what IT governance actually means. 

What the Operating Enterprise Actually Requires 

When you govern IT across organisational boundaries - rather than within them - ten distinct capability challenges emerge. They are not well-served by any single existing framework, though several frameworks touch their edges. 

1. API Contract Governance: In the Operating Enterprise, the API is the integration contract. But unlike a legal contract, an API changes - versions deprecate, endpoints shift, data schemas evolve. When your 3PL updates their WMS API without adequate notice, your order management system breaks. Governing API lifecycles across organisational boundaries -including APIs you consume but don't own - is a discipline almost entirely absent from mainstream IT governance frameworks. Gartner's growing API Management market[4] reflects the technical urgency; the governance dimension remains largely unaddressed. 

2. Multi-Party SLA Decomposition: Your customer-facing SLA is a composite of five underlying partner SLAs. When a delivery fails, which SLA was breached - the 3PL's, the courier's, or the marketplace’s? Most organisations cannot answer this question with data. They resolve it with phone calls. Decomposing end-to-end service commitments into attributable, measurable component SLAs - and flowing accountability through the chain - is fundamental to operating in this model. 

3. Cross-Boundary Observability: Observability, the ability to understand the internal state of a system from its external outputs, is well-established within a single organisation's technology stack. It breaks down at the organisational boundary. You can instrument your own systems; you cannot instrument your partner's. When a transaction traverses your platform, the3PL's WMS, and the courier's mobile app before reaching your customer, your observability stops at your firewall. Beyond it, you are dependent on your partner's dashboards, their incident notifications, and your customer's complaints. 

4. Federated Identity and Access Governance: In the Operating Enterprise, identity is not contained within a single directory. Contract workers, partner system users, API clients, and automated agents all need governed access to systems that span multiple legal entities. Zero-Trust architectures address this within a single security perimeter. Federated identity governance - across organisational boundaries, with different compliance regimes and regulatory environments - is significantly more complex. Notably, Deloitte's survey found that 81% of executives already outsource at least some cybersecurity capability to third parties[1], yet the identity and access governance models to secure those relationships remain immature in most organisations. 

5. Data Governance Across the Mesh: Master data does not respect legal boundaries. A patient record originates in your hospital's HIS, is enriched by a diagnostic lab's report, is updated by a specialist consultant's clinical notes, and is accessed by an ambulance crew's mobile system. Who owns that data? Who is responsible for its accuracy? Who can access it, when, and under what consent framework? Data governance in the Operating Enterprise is not a data management problem. It is a multi-party governance problem. 

6. Software Supply Chain and SBOM: The software your organisation runs is itself a supply chain. Third-party libraries, SaaS platforms, partner-provided integrations, and embedded components from technology vendors all carry their own vulnerability profiles, license obligations, and update dependencies. Software Bill of Materials (SBOM) thinking -understanding what your software is actually made of, and by whom - is becoming a regulatory expectation in multiple jurisdictions. In the Operating Enterprise, this extends beyond your own code to the software your partners run on your behalf. 

7. Ecosystem Resilience and Concentration Risk: Business continuity planning still largely assumes that the organisation failing is yours. In the Operating Enterprise, your most consequential single point of failure may be a partner. What happens when your sole 3PLdeclares bankruptcy? When your pathology network's systems go down across all sites simultaneously? When your primary marketplace changes its seller API with 48 hours’ notice? Resilience in this model requires mapping and managing dependency risk across the operating network - not just your own infrastructure. 

8. Multi-Party Incident Governance: When an incident occurs in the Operating Enterprise, it rarely has a single owner. The failure attribution question - who caused this, who is responsible for remediation, who compensates the customer - is simultaneously a technical, contractual, and reputational question. Incident management processes are designed for internal accountability. They do not naturally extend to situations where five organisations are each pointing at the others. 

9. AI Governance Across Boundaries: Increasingly, decisions within the Operating Enterprise are being made - or influenced - by AI models that no single party owns. Your logistics partner’s route optimisation algorithm affects your delivery SLA. Your marketplace's demand forecasting model affects your inventory planning. Your diagnostic lab's AI-assisted pathology flagging affects clinical decisions in your hospital. Governing AI in this context means establishing accountability for decisions made by systems you did not build, cannot inspect, and may not fully understand. Deloitte's 2024 survey found that 83% of executives are now leveraging AI as part of their outsourced services - yet the same survey notes that tangible governance frameworks for this remain limited in most organisations[1]. 

10. Commercial and Technical Governance - Designed Together: The most persistent failure in Operating Enterprise governance is that commercial contracts and technical architecture are designed in isolation. The legal team negotiates SLAs that the technical team has never seen. The technology integration is built before anyone has asked who owns the data it generates. Underpinning contracts - a concept ITIL introduced - must be redesigned for the API era: technically precise, operationally enforceable, and continuously verifiable rather than reviewed annually. 

The Wrong Conclusion - and the Right One 

If reading the ten capability challenges above led you toward one of two conclusions – either "ITIL doesn't cover this, so it's irrelevant" or "we just need more certifications" - both are wrong. And in the Operating Enterprise, both are expensive mistakes. 

Let me be direct about what I have observed across two decades of global IT delivery: the organisations that struggle most in complex, externalised operating models are not the ones without frameworks. They are the ones where frameworks became performance rather than 

capability. Where the certificate arrived but the understanding didn't follow. Where ITIL's Supplier Management practice was implemented as a vendor scorecard exercise rather than as a genuine governance discipline for organisations whose systems are load-bearing parts of your own service delivery. I have written about this pattern at length - the gap between ITSM theatre and ITSM substance is real, and it is widest precisely in the organisations that most need the capability[5]. 

The Operating Enterprise does not forgive shallow framework knowledge. When a P1 incident spans three external organisations at 2am, you need practitioners who genuinely understand service relationships, escalation paths, impact attribution, and stakeholder communication -not people who passed a multiple-choice exam on those topics. When your contract manufacturer’s ERP integration breaks and your inventory position become unreliable across five marketplaces simultaneously, you need someone who can think in value streams, identify the break in the value chain, and coordinate recovery across parties none of whom report to you. That capability comes from deep framework fluency, not from a certificate on the wall. 

This is where ITIL - understood properly rather than implemented superficially - remains genuinely relevant to the modern Operating Enterprise. Its Partners and Suppliers dimension, its value chain thinking, its underpinning contract concepts, its service relationship models  - these are not legacy constructs designed for a simpler world. They are foundational governance instincts that apply with greater force when you cannot control the organisations delivering your service. The DevOps Institute's SRE and Observability curricula address the technical nervous system of the distributed enterprise - how you maintain visibility and resilience across systems you don't fully own. PRINCE2 provides the structural governance discipline needed when transformation programmes span legal boundaries and organisational objectives that don’t naturally align. 

What these frameworks do not yet do - and this is a practitioner's honest observation, not a criticism - is provide ready-made answers for the seams: multi-party SLA decomposition, cross-boundary incident attribution, API contract governance, ecosystem resilience mapping. That thinking must be built by practitioners who understand the frameworks deeply enough to extend them. A practitioner who has genuinely internalised ITIL's service management principles can reason their way to a workable multi-party incident governance model. One who memorised the framework to pass an exam cannot. 

The practical implication for IT leadership is this: if your organisation operates in the model described in this paper, your investment case for framework capability is stronger, not weaker. But the investment must be in genuine organisational capability - in practitioners who can apply governance thinking across boundaries, not just within them. The Value Delivery Office model, which I have explored separately [6], offers one organisational pattern for how that integrated capability can be structured and sustained. The question is not whether to invest. It is whether your investment produces capability or theatre. 

In the Operating Enterprise, that distinction is not academic. It shows up in your customer’s experience, your partner's behaviour, and your board's risk exposure. 

• Stop thinking about IT governance as a boundary problem. The question is not "what happens inside our systems" but "what happens across the mesh of systems that collectively deliver our service." This reframes changes almost everything: what you monitor, what you contract for, what you audit, what you staff for, and what you certify your teams in. 

• Design your commercial contracts as technical governance instruments. An underpinning contract that does not specify API versioning obligations, data schema change notification windows, observability data sharing requirements, and incident response participation expectations is not fit for purpose in the Operating Enterprise. Legal and technical teams must design these together, not in sequence. 

• Build cross-boundary observability as a first-class capability. Synthetic transaction monitoring, partner-facing SLA dashboards, and shared incident data protocols are not nice-to-have integrations. They are the nervous system of the Operating Enterprise. Without them, you are managing by exception - which means managing by crisis. 

• Govern your ecosystem as a managed entity, not a collection of contracts. The OperatingEnterprise has health metrics just as a system does: partner API reliability, ecosystem dependency concentration, supply chain vulnerability exposure, partner capability maturity. These should be on the CIO's dashboard alongside system uptime and incident counts. 

• Invest in the capability layer, not just the framework layer. Frameworks provide vocabulary and structure. Capability is what your people can actually do when the 3PL's system goes down at 11pm on a Friday and three organisations need to coordinate an incident response across two-time zones. The distance between framework knowledge and operational capability is where most organisations live, and where the real investment is needed. 

A Closing Provocation 

The ITIL certification on your wall - and I say this as someone whose professional life is intertwined with these frameworks - certifies that you understand how to govern IT within a legal enterprise. That is genuinely valuable. It is also genuinely insufficient for the world most organisations now operate in. 

The Operating Enterprise is not a future state. It is the present reality for most organisations of any scale. It is running on a combination of well-designed API integrations, hastily written underpinning contracts, shared messaging groups, and the individual heroism of people who understand both sides of organisational boundaries. 

The frameworks are evolving. The conversation in the global ITSM community is moving. But the gap between where frameworks currently stand and where the Operating Enterprise currently operates is real, consequential, and worth naming honestly. 

The question for IT leaders is not whether to engage with frameworks like ITIL, DevOps, or PRINCE2. The question is whether you are applying them to the enterprise that actually exists or to the enterprise that appears on your org chart. 

References 

[1] Deloitte. (2024). Global Outsourcing Survey 2024: Multidimensional Sourcing -Orchestrating the Extended Workforce Ecosystem. Deloitte Global.https://www.deloitte.com/global/en/issues/work/global-outsourcing-survey.html 

[2] Emapta. (2026). 25+ Must-Know Outsourcing Statistics for 2026, citing Deloitte Global Outsourcing Survey data. https://emapta.com/blog/outsourcing-statistics/ 

[3] ISG / Grand View Research, as cited in: Digital Minds BPO. (2026). 60+ Outsourcing Statistics for 2026. https://digitalmindsbpo.com/blog/outsourcing-statistics/ 

[4] Gartner. (2025). Magic Quadrant for API Management (Pillai, Santoro, Schwent, Carter).October 2025. Referenced via: https://konghq.com/resources/reports/gartner-magic-quadrant-full-lifecycle-api-management 

About: 

Rajwardhan Purohit is Capability Architect and Evangelist of the Capabilities-as-a-Service (CaaS) framework-reimagining how organizations build, activate, and scale human potential in the digital age. He has 25+ years of rich global experience in IT delivery, program management, and served as Head of Innovation at British Council, SSC(GBS) in his last role. Rajwardhan is currently Global Ambassador for ITIL4 and DevOps, and certified ITIL4 Maturity Consultant, Tool Assessor, ITIL4 Managing Professional, and accredited trainer. View expressed in this article are his personal 

All brands, logos, products named in article are property of their respective organizations. This is technology assisted content.