What exists
Assets, services, settings, capacity, owners, current state, and change history.
Vendor-Neutral Category Definition
What Is an Infrastructure Operating Model?
An Infrastructure Operating Model, or IOM, is a live model of an organization’s infrastructure and the rules used to operate it. It brings together what exists, how it connects, who owns it, what should be true, and what changes are allowed.
This page defines the category. AuthorIOM is one commercial implementation of it.
The Need
Infrastructure is one connected system, but most teams operate it in parts.
Cloud, network, security, apps, data, service management, and providers each hold part of the picture.
No single tool explains the full environment. Teams must rebuild that view from dashboards, tickets, diagrams, exports, and memory before they can act.
This creates three common problems:
- Changes take longer because context is missing.
- Risk is found after a change instead of before it.
- Knowledge stays with a few people or providers.
The Definition
An IOM brings facts, relationships, and rules together.
How it works
Connections, dependencies, service paths, shared resources, and likely impact.
What is allowed
Standards, policy, approved patterns, limits, decision rights, and required checks.
Facts + Relationships + Rules = Infrastructure Operating Model
Continuously Reconciled
The IOM stays tied to the real environment.
A useful IOM is not a one-time diagram. It keeps three views in step.
What should be
Approved design, policy, owners, and expected state.
What is
Current settings, connections, capacity, and health.
What happened
Changes, approvals, events, and proof of the result.
The IOM compares intent with running state. Evidence shows whether a change produced the right result.
The Operating Loop
The IOM supports a simple, repeatable cycle.
1ModelKnow the environment.
2ReasonUnderstand the issue or change.
3GovernCheck rules, owners, and risk.
4ApplyUse a connected tool to do the work.
5VerifyConfirm the result and update the model.
Model → Reason → Govern → Apply → Verify → Model
Category Test
A real IOM should be able to answer these questions.
Can it show the environment as a connected system?
It should link assets, services, dependencies, owners, and current state.
Can it show what should be true?
It should hold intent, policy, standards, limits, and approved exceptions.
Can it check a change in context?
It should use the current environment, relationships, and rules before a connected change runs.
Can it verify the result?
It should compare the result with the intended outcome and keep the decision record.
What It Is Not
An IOM does not replace every tool.
Not just a CMDB
A CMDB records items. An IOM must also show live relationships, intent, and operating rules.
Not just observability
Observability shows what is happening. An IOM adds what the signal means and what action is allowed.
Not just automation
Automation performs work. An IOM gives that work context, limits, and a way to verify the result.
Existing tools still do their jobs. The IOM gives them a shared view and a shared operating process.
Model first. Everything else follows.
The Governing Principle
If it can be modeled, it can be governed.
Anything represented in the IOM can be understood and checked. When the needed rules, permission, evidence, and connected change path exist, it can also be governed before action and verified after it. Read it backwards and it becomes a scope question: it can be governed if it is in the model. Coverage is the boundary — what the model does not hold is not governed, which makes the first useful question not can this be governed but what is not in your model today.