The IOM library
Peer contributions from members and industry practitioners — implementation patterns, field reports, and analysis that advance the practice of infrastructure governance. Reviewed for rigor and neutrality, published openly.
An Infrastructure Operating Model is the authoritative layer that defines what infrastructure exists, what it is intended to do, and what actions are legitimate — before execution occurs.
Published whitepapers
Vendor-neutral, practitioner-grounded, and tied to the standard. The founding set of papers behind the Infrastructure Operating Model.
The IOM Standard
The normative specification implementations conform to. The whitepapers below make the argument; the standard defines the requirements. Read this first.
v1.0 draft · Proposed vendor-neutral standard · CC BY 4.0
Representation Is Not Authority
Representation and authority are different functions. A twin tells you what exists; only an IOM tells you what is legitimate — the real category boundary.
Download the whitepaper (PDF) → Word (.docx) →Why AI Needs an Infrastructure Operating Model
AI-driven infrastructure stalls because tools describe what happened, not what the system is. The IOM is the authoritative model AI needs to act safely.
Download the whitepaper (PDF) → Word (.docx) →Twelve Tools, One Missing Layer
Even if one vendor delivered all twelve capabilities, you’d still need an IOM. The vendor-neutral analysis of why authority isn’t integration — and why no platform can simply add it.
Download the whitepaper (PDF) → Word (.docx) →Intelligent Control Plane or Operating Model?
A smarter control plane improves how infrastructure is executed — but execution is not authorization. Why governed autonomy needs an operating model above the control plane.
Download the whitepaper (PDF) → Word (.docx) →Frameworks Describe. Something Must Govern.
TOGAF, Zachman, ArchiMate and SAFe were built to describe architecture, not enforce it. The missing element isn’t another framework — it’s an authority layer that keeps intent and reality reconciled.
Download the whitepaper (PDF) → Word (.docx) →Security Is an Operating-Model Problem
Security fails not for lack of tools but because it runs on static assumptions in a continuously changing estate. The IOM is the authority layer that makes preventive security — and real observability — possible.
Download the whitepaper (PDF) → Word (.docx) →From Tool Aggregation to Infrastructure Authority
What an IOM is actually made of, and the phased, low-risk path to adopting it — moving from tool aggregation to an authoritative operating layer.
Download the whitepaper (PDF) → Word (.docx) →AIOps Is an Operating-Model Problem
AIOps reasons over telemetry, which records what happened, never what was intended. What AIOps becomes when it consumes an authority layer instead of trying to infer one.
Download the whitepaper (PDF) → Word (.docx) →IaC Declares How. An IOM Declares What’s Allowed.
Infrastructure as Code declares how to build; an Infrastructure Operating Model declares what is allowed — and validates the plan before a single resource is created. Why IaC becomes the IOM’s execution arm, not its rival.
Download the whitepaper (PDF) → Word (.docx) →Members and industry professionals
Publishing is open to IOM members and to qualified practitioners working in infrastructure, platform, security, and architecture. You do not need to be a member to submit — you need something worth reading.
Every submission is reviewed by the working group for rigor and neutrality before it appears. A byline carries the author's name and organization; the review is what makes the byline worth something.
And what we don't
- ✓
Implementation patterns & field reports
Real experience operating the capabilities the standard defines — what worked, what didn't, and the evidence.
- ✓
Analysis grounded in the standard
Original thinking that extends or pressure-tests the operating-model concept.
- —
Not product marketing
Vendor pitches, feature lists, and thinly-disguised sales collateral are declined. Neutrality is the point.
From submission to byline
A light editorial process that protects the library's signal without slowing good work down.
Propose
Submit a title and abstract, plus a draft or outline. Tell us the topic and your perspective.
Review
The working group reviews for rigor, originality, and vendor-neutrality — not for agreement.
Revise
Editors may suggest revisions. You keep authorship; we help it land.
Publish
Accepted whitepapers are listed in the library under your name and organization.
Propose a whitepaper
Send a title, an abstract, and a link to your draft. If you don't have a draft yet, an outline is fine — we'll talk before you invest the writing time.
Questions about fit? Ask the editors.