Two Operating Models,
One Organisation.

Most mid-to-large IT estates run two operating models. On one side, a product engineering function shipping software via CI/CD, owning its own services, running its own on-call. On the other, a traditional IT operations function running networks, identity, COTS applications, and the long tail — via change tickets, CABs, and service desks.

Two operating models. Two vocabularies. Two definitions of the word "service."

The instinct, when this becomes visible, is to treat it as a problem. Something to reconcile. Something to unify. Pick a side, drag the other one across.

That instinct is misleading. The two-model shape isn't a symptom of an immature IT organisation. It's what a healthy one grows into. Growing into the shape, though, is not the same as being done with it.

Two Models, Because The Work Is Different

Some work is product-shaped and team-owned. A product engineering team owns a product end-to-end — writes the code, ships the change, holds the on-call, decides the release cadence. The operating model that supports this work is fast, self-service, close to the code, iterative. It works because the same people making the change are the ones living with its consequences.

Some work is foundational and shared. The identity provider has an owning team, and it's delivered as a service — but it isn't developed like a product. It's a shared capability every team in the organisation depends on. The network has an owner too, but it's the foundation everything else runs on. The COTS application supporting finance is owned and operated as a service the whole business relies on — the vendor dictates the upgrade cadence, and the organisation's own customisations release around it, not on a product team's rhythm. The operating model that supports this work is coordinated, change-controlled, audit-aware, cadence-managed. It works because a shared IT service cannot afford to move at the speed of the fastest team using it.

Different work. Different constraints. Different model.

The organisations that try to collapse the two — either by pushing product engineering discipline onto the shared IT services, or by pushing service management ceremony onto product teams — usually end up with the worst of both. Product teams start filling in change forms for their own services. The teams running shared IT services start pretending they can deploy on demand when the risk profile doesn't allow it. Nobody is happier. Nobody is faster. Nobody is safer.

The two-model shape is the design, not the defect.

The failure mode isn't having two operating models. It's having two operating models that don't talk to each other.

Two Definitions of the Word "Service"

The vocabulary gap shows up most clearly in the most important word both sides use. In the DevOps world, a service is a technical thing: a deployable unit, an API, a microservice with a repo, a pipeline, and an on-call rota. The definition is precise, bottom-up, and maps one-to-one to something running in production. What it usually lacks is the view upwards — which business outcome that running thing actually serves, and what it costs when it degrades.

In the ITSM world, the service concept is older and considerably more mature. Decades of thinking about what the business actually consumes: a service has customers, a catalogue entry, SLAs, a cost, and an owner accountable to the business. What it often lacks is the live technical linkage downwards — the map from the business service to the components actually running underneath it. Many CMDBs hold the classic application architecture well enough: the servers, the databases, the three-tier estate. Where they fall behind is the cloud-native layer — the deployed components, the containers, the dependencies between microservices that shift with every release and live in the tooling the DevOps teams manage. That's the linkage the CMDB was meant to provide, and for a growing share of the estate, it doesn't.

Where It Breaks

The failure mode is specific and recognisable. Two operating models coexisting is fine. Two operating models that don't share information is where the trouble starts.

An incident begins. The service that's degraded was built by a product engineering team, deployed by their pipeline, and updated three times this week. The incident bridge is being run by the shared IT operations function — because a customer-facing outage crosses organisational boundaries and pulls in the service desk, the customer communications team, and the on-call incident commander. The commander opens their tools and asks the obvious questions: what changed, who owns it, what depends on it, what's the blast radius. The answers exist. They're just not in the tools the commander has.

An auditor arrives. They want to see change control evidence for a set of production services. The traditional IT operations function has that evidence for services it manages — change tickets, CAB minutes, approval records. For the services shipped by product engineering, the evidence exists too — in Git history, deployment logs, pipeline records — but it's in a different shape, using different terminology, and the auditor's checklist wasn't written for it. The audit response becomes a manual reconciliation exercise.

An AI initiative launches. The pilot needs configuration data to reason about the estate — what's running, what depends on what, who owns which service. The data is technically available. Half of it is in the CMDB, half is in the developer portal, and where the two disagree, nobody has a mechanism for deciding which is right. The AI agent starts making recommendations grounded in inconsistent data.

Each of these is a moment where the two operating models needed to share information and didn't.

What "Connected" Actually Looks Like

Connecting the two operating models doesn't mean merging them. It means each side keeps its own model but shares enough of what it knows for the other side to work.

The DevOps side gets automated governance. Change context flows out of pipelines as a natural by-product of deployment — not as a form filled in after the fact. Policy checks run inside CI/CD, meaning the compliance evidence exists at the moment the change is made rather than being reconstructed for the auditor months later. Approvals for standard change patterns are automated; humans handle exceptions. The DevOps side doesn't slow down; it produces the governance signal the rest of the organisation needs, at its own speed.

The ITSM side gets coverage of the layer it currently can't see. Not through more automation for its own sake — most CMDBs are already populated by automated discovery, and the tooling is good at what it was built for. The gap is knowledge, not machinery. The entities that arrived with cloud-native — containers, microservices, the dependencies between them — are understood by the DevOps teams that build and run them, not by the teams that maintain the CMDB, so that layer never gets modelled. Connecting the two sides closes the gap: the pipelines and platform tooling that already know these components write them into the CMDB as a by-product of deploying them. Change records generated from deployment events, not raised as tickets. The ITSM side doesn't sacrifice its operational discipline; it gains the ability to keep up with a moving reality.

The ITSM side also gains something more specific: the capability to release when the business genuinely needs to, rather than when the next change window allows. Not by adopting the DevOps cadence — most ITSM-managed systems shouldn't release on a DevOps cadence, and the business doesn't want them to. By adopting the practices underneath that cadence. Production release cadence is a business decision; pipeline cadence is an operational discipline. The first can stay as slow as the system requires — the second has to run often enough that the path to production stays paved. Infrastructure as code, so environments can be rebuilt from definition rather than reassembled from memory. Pipelines that run often enough on lower environments to stay honest, so when a critical release is called for, the muscle is there. Enough people on the ITSM team fluent in these practices to execute when needed — not all of them, but a durable core. We've made this argument in full in Cattle, Not Pets — For Everything.

The ITSM identity, the change control discipline, the audit posture, the relationship with the business — all preserved. What's added is the ability to actually deliver on demand when the business asks, instead of explaining why it will take three weeks.

And critically, information flows across the boundary in both directions. Developer-owned services appear in the CMDB because deploying them writes the record. Ownership information from the developer portal is accessible to incident response without needing to find the right developer. Change records visible to the CAB include the pipeline-driven changes as well as the ticket-driven ones. Dependency maps reconcile across the two sides so the incident commander, the auditor, and the AI agent are all reasoning about the same picture.

Neither model gives up what makes it work. Both models share enough for the organisation to operate as one.

Where to Start

Two diagnostic prompts. The honest answers reveal how connected your two operating models actually are:

If your incident commander needed the ownership and dependency map for a developer-built service mid-incident, where would they get it — from a system, or from Slack? The answer tells you how much of your operational intelligence is in the connection between the two sides, and how much is in people's heads.

If a critical patch or change was called for on an ITSM-managed system tomorrow, could your ITSM team ship it in 48 hours — or would the change window, the manual steps, and the untested pipeline stretch it into weeks? The answer tells you whether the capability to release on demand is real or theoretical. Traditional ITSM discipline is right for the cadence; but when the cadence needs to change, the underlying practices have to support it.

Neither question is asking whether your DevOps side is mature or whether your ITSM side is disciplined. Both can be true. The question is whether the two sides share enough — and whether the ITSM side has the technical capability underneath it — for the organisation to answer the questions the business, the regulator, and the customer are going to ask.

A dual operating model is the shape. A connected one is the goal.

Bridge the models. Keep the strengths.

Our Service Model Alignment Assessment is built for exactly this question. A focused 3–5 day engagement, a clear read on where the boundary sits and what it's costing you, and a prioritised roadmap for closing the gap without collapsing either side.