Writing
OSM Series · 07

Truth vs Turf: Why CMDB, EA and PMO Wars Make Us Blind

Operations, Enterprise Architecture and the PMO each guard their own models until detail hardens into bunkers. They aren’t rivals - they’re lenses on one service graph, and turf wars blur the shared truth we need to make good decisions.

14 November 2025 5 min read Subscribe

We’ve all sat in that meeting.

Operations defend the CMDB like the last wall between uptime and chaos. Enterprise Architects arrive with capability maps and target states. The PMO turns up with a spreadsheet temple of cost categories and gates.

Each discipline has a valid purpose - run the now, design the next, fund the change - but over time their tools hardened into bunkers. Detail piled on detail. Rules grew teeth.

The work became less about seeing truth together and more about protecting the system that protects us.

That’s control theatre: models and processes that look like control yet deliver very little of it.

An ornate gilded theatre proscenium lit by a chandelier, with the red velvet curtain still closed across the stage.
Photo by Gwen King on Unsplash

The result?

  • Slow decisions
  • Stale data
  • Duplicated modelling
  • Portfolio bets made without live service visibility

We don’t need more completeness. We need shared visibility.

CMDBs, EA platforms, PMO cost models - these are lenses on one system. Keep the borders up and truth gets blurry.

Three Lenses, One System

These are not competing worldviews; they’re altitudes on the same model.

Operations / CMDB

Current-state fidelity for availability, change, compliance, audit. The horizon is now.

Enterprise Architecture

Capabilities, principles, patterns, target states, roadmaps. The horizon is next.

Portfolio / PMO

Funding, risk, benefits, governance. The horizon is investment.

More lenses exist - later articles cover these - but these three dominate the struggle.

How Turf Wars Show Up

Here are typical manifestations of turf protection:

Detail Gravity

Each team adds more fields to “prove value”. Signal: Attribute completeness dashboards. Cost: Faster staleness, slower impact assessment.

Gatekeeping as Risk Management

Controls and handoffs multiply. Signal: More checkpoints than decisions. Cost: Latency and workarounds.

Map Worship Over Territory

Slides and screenshots treated as truth. Signal: Meetings about the model, not the service. Cost: Bad bets, brittle change.

Metric Vanity

Counting CIs, artefacts, or gates. Signal: Big numbers, small insight. Cost: Misplaced effort, busywork.

Integration Tax

Translation layers everywhere. Signal: Monthly reconciliation marathons. Cost: Drift, duplication, friction.

Diagnosis: Control theatre. We’ve optimised for protecting our system rather than seeing the system.

Minimal Viable Truth (MVT): The Smallest Model That Makes Big Decisions

Two white arrows painted on asphalt pointing in opposite directions, separated by a single painted dividing line.
Photo by Claudio Schwarz on Unsplash

Completeness is the wrong goal. Decision-ready truth is the right one.

Define an MVT - the smallest, freshest model that reliably answers the ten canonical questions:

  1. What is it?
  2. Who owns it?
  3. Where does it run?
  4. What service does it enable?
  5. Who uses it?
  6. What does it depend on, and who depends on it?
  7. What controls and risks apply?
  8. What does it cost (order-of-magnitude is fine)?
  9. What changes are in flight or planned?
  10. How healthy is it right now?

Use the single post-it method: If the answer doesn’t fit on one side of a post-it, it’s too much.

If your model requires side files and hallway conversations, you don’t have visibility - you have trivia.

One Service Graph, Many Contracts

Unify on a single service graph and let roles view it through their own lenses.

Practically:

Stable IDs and simple relationships

Standardise on two verbs:

  • A contains B
  • A consumes B

Layered detail

Start with MVT, then add overlays for cost, risk, controls, contracts.

Event-driven freshness

Incidents, changes, deployments, gates automatically update the graph.

Federation over centralisation

Discovery, cloud inventories, EA repos, CI/CD, finance feed the graph.

Finance as an overlay

PMO cost models attach to the same IDs - not a separate spreadsheet temple.

APIs and webhooks

Push events, pull overlays, avoid batch reconciliation theatre.

The aim is simplicity, timeliness, clarity - and a graph that everyone can trust.

Metrics That Matter

Drop vanity metrics like:

  • items discovered
  • fields completed
  • diagrams published

Instead measure:

  • Freshness: % entities updated in n days
  • Coverage: % top services with complete dependency chains
  • Decision speed: time to impact assessment
  • Cross-lens traceability: incidents ↔ capabilities, investments ↔ services
  • Portfolio coupling: % business cases tied to live, owned services
  • Outcome adoption: how often the model is used in CAB, QBR, portfolio

If these trend upward, your model is earning trust. If not, you’re adding nouns, not value.

Governance That Scales

When aligned to MVT concepts, governance becomes light and scalable:

  • Single product owner for the service model
  • Shared backlog for gaps, overlays, integrations
  • Guardrails for “enough” - detail must justify its decision value

This ends multi-discipline sprawl. The model becomes a product, not a battleground.

In Practice

Everyone uses the same model - but through the lens suited to their discipline.

Following the chain of relationships across roles reveals real dependencies and risks. It surfaces truths normally hidden by turf boundaries.

It becomes Truth instead of Turf.

The OSM Angle: Making One System Usable

OSM treats the enterprise as a network of services, with the service model as the backbone of how value flows.

OSM enables roles to use their own lens without forking the truth.

Core Principles

  • Service is the unit of value
  • One backbone, layered views
  • Two simple relationship verbs
  • Event-driven freshness
  • Decision over description

How OSM Resolves Turf Wars

  • Shared IDs and language
  • Automatic traceability
  • One product-owned model
  • Overlays instead of silos

The Service Intelligence Base (SIB)

The SIB is a practical realisation of this approach - a lightweight service graph with overlays for risk, cost, controls, and patterns.

Federated, event-driven, role-specific views. No rip-and-replace required.

Working Practices

  • CAB and QBR use the same views
  • PMO overlays create immediate run/change splits
  • EA patterns expressed as to-be overlays with measurable deltas

What OSM Is Not

  • Not a heavyweight framework
  • Not a vendor platform
  • Not another silo

It’s a way to unify what you already have - with clearer contracts and shared truth.

Turf Wars Are Futile

CMDB, EA and PMO aren’t rivals; they’re lenses on one service model.

Turf wars create control theatre that slows decisions and hides truth.

Unite around a service graph. Define Minimal Viable Truth. Wire events for freshness. Measure decision speed and traceability, not attribute counts.

Start small. Use it in anger. Retire vanity metrics.

Get new articles by email
← All writing OSM Series · Originally published at strategenz.com
Start a conversation

Want to explore what this could look like in your organisation?

We'll dive in and find out whether there's something worth doing - and tell you honestly if there isn't.