This chapter describes how IT operations organised itself before AI took part in it. The baseline matters because every claim of later chapters about what AI changes is a claim about a difference, and a difference cannot be stated without the thing it differs from. The chapter concerns all five operations functions defined in Chapter 4: O1 Observe, because the first reliability practices were ways of deciding what to look at; O2 Diagnose, because the runbook and the incident review are older than any model; O3 Change, because the change advisory board and the deployment pipeline are rival answers to the same risk; O4 Restore, because scripted remediation has a long history before agents; and O5 Sustain, because toil, capacity and learning were named and measured before AI could do any of them.
Six operating models are described: the system administrator with a runbook, service management, DevOps, site reliability engineering (SRE), platform engineering and the first generation of AIOps, the application of machine learning to operational data. For each the chapter asks what it got right and which scarcity it answered. The second question is the book's own reading and is stated as such: each model took its shape from something that was in short supply, whether expert time, knowledge of what had changed, flow between teams, reliability engineering skill or attention to signals. A practice outlives the scarcity that produced it, and AI loosens several of those scarcities at once. Knowing which one a practice answered tells the reader what to keep, what to automate and what to retire.
The table gives every stage in the lineage and the scarcity it answered.
Primary topics explored
- A lineage of operating models
- First-generation AIOps
- What each model got right
- The scarcity behind the shape
- First-generation AIOps
- Lessons from other domains
About AI Operations
AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue and AI Purple.
CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 2: What Operations Did Before: Runbooks, ITIL, DevOps, SRE and AIOps in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Operations in Question” and is one of 35 drawn from the manuscript.