Carlson BCMFrom Technology Health to Business Health
Measuring Google’s SRE Against the Carlson BCM Model of Enterprise Service Health
Google’s 2026 Site Reliability Engineering.
Google has spent more than two decades engineering the reliability of the largest technology platforms in the world. Its 2026 edition of Site Reliability Engineering carries that discipline into AI-driven operations and autonomous production agents.
I measured it against the Carlson BCM model of IT service management: 12 enterprise capabilities and 71 business capabilities, the model I apply in observability and service health engineering for the enterprise. Google’s discipline addresses 9 of the 12 deeply and 3 partially. None of the 12 is related, through a governed structure, to the business capabilities, value, accountable roles, and authority of the enterprise it serves.
For a CEO, that is the difference between technology health and business health. The technology organization can know which systems are failing and still be unable to say which business abilities are impaired, what the impairment is worth, or who has the authority to intervene.
Closing that gap is not an engineering upgrade. It is an executive decision about what the enterprise measures, who answers for it, and who is allowed to act, and it becomes urgent the moment AI agents begin to act in production.
Two different problems.
Google engineers reliability for a handful of enormous technology products: Search, YouTube, Maps, Gmail, Cloud. Its problem is scale, across services it builds and owns. Its organizing object is the production service. There is no value chain at the center of that architecture, because those products do not run as one.
An enterprise has every one of Google’s engineering problems, and a second one Google does not. It runs on interconnected value chains. In an insurer: new business, underwriting, policy administration, billing, claims, distribution and finance. Each is made up of enduring business capabilities, and each business capability depends on different products and coverages, roles, channels, applications, data and infrastructure. Much of the estate is packaged software the enterprise cannot modify. Change is governed because regulators require it.
One technology incident can impair several business capabilities at once. One business capability can depend on dozens of systems. The technical topology is not the business topology, and no amount of telemetry turns one into the other.
The measurement.
I assessed Google’s 2026 discipline, as published, against each of the 12 enterprise capabilities on two questions: how deeply it addresses each one, and whether it relates each one to the business it serves.
Google’s engineering is mature where hyperscale demands it. Nine of the 12 enterprise capabilities are addressed deeply, from reliability targets and monitoring to incidents, capacity and continuity. Of the 30 substantive subjects in the 2026 edition, 22 fall within business capabilities the model already held. Google changed how SRE is done. It did not change what SRE must be able to do. Every enterprise should adopt this engineering.
The partial coverage falls exactly where the enterprise differs. Google addresses three enterprise capabilities only partially: Manage Operational Intelligence, Manage Changes and Manage Configurations. Each is where a heterogeneous, regulated estate connects operational evidence, production change and vendor technology to the business.
Business context is acknowledged, never governed. In 4 of the 12, Google names the business decision with real candor. The business decides the reliability target. Responders need business context before an incident begins; after a major cloud outage, Google found its incident commander did not know who the product decision makers were. Scarce AI accelerators are allocated as “a matter of business priority rather than a technical challenge.” Each decision is settled by a policy, a team or a meeting. None is governed by a structure that relates it to the enterprise’s business abilities, value, roles and authority.
No reading of Google’s book produces that last finding. It takes a model of the discipline organized by enduring business abilities, and a model of the enterprise to relate it to.
Where the gap shows.
Three business capabilities from the model show what the measurement means in practice.
Ability to approve production changes. Google has largely replaced the approval gate with platforms and automated change supervision that rolls back on regression. That is excellent engineering for an estate Google builds. An enterprise must still approve changes to systems it does not own, and approval is where business consequence meets authority. The approver needs to know which business capabilities the change touches, what they are worth and who is accountable if they fail. Without that, approval is a signature, not a decision.
Ability to maintain enterprise service topology. Google’s production knowledge graph maps assets, dependencies and ownership across its own platforms. At an insurer, enterprise topology runs from mainframe policy administration to packaged claims systems to cloud services, across many vendors and owners. Mapped only technically, it shows that a database serves many applications. Related to business capabilities, it shows that the same database supports binding, billing and claim payment, and which of those matters most this morning.
Ability to assess recovery objectives. Google is clear that recovery begins with the mission-critical goals a system must support, and that some data recovery decisions belong to executives, customers or counsel. It sets those objectives service by service and dataset by dataset. An enterprise has to set them once, on the business capabilities that depend on the data, so that every recovery plan, test and decision inherits the same priorities and the same authority.
In each case Google’s engineering does the work well. What it lacks is the governed reference that tells the enterprise why the work matters and who decides.
What it means for the executive.
A governed business capability-centric ontology gives the executive four things technical service metrics cannot: the health of the business abilities the enterprise depends on, interventions prioritized by business value, accountable roles known before an incident begins and authority settled before anyone, or anything, acts.
The last of those is becoming the most important. Google’s 2026 edition defines five levels of autonomy for production agents and sets the level system by system. However, technical ability, authority to act, and accountability for the outcome are three distinct concerns, and a level set system by system speaks only to the first. Carlson BCM governs their relationships through the business capability, so an agent’s autonomy is bounded by the authority governing the business capability, not by its technical ability to do the work.
Google’s Site Reliability Engineering is one of the most important disciplines in technology, and every enterprise should adopt it. It was built for the hyperscale technology product. The enterprise is a different problem: functionally rich, organized by value chains, governed by regulation and authority, and running on systems it does not own.
A healthy technology estate does not necessarily mean a healthy business. Until the enterprise can observe, measure and understand the health of its enduring business capabilities, it has only part of the operational picture.
On Wednesday I will share the talk I gave at SREday New York, Observing the Enterprise, Not Just the Stack. It shows how that picture is engineered.
Source: Site Reliability Engineering, second edition, Google (O’Reilly, 2026).