Carlson BCM
Read as text
The board governed availability by a number a handful of people produced.
At a large financial services and insurance institution, availability had become a matter of board-level oversight. I led the availability assessment with a team of specialists in site reliability engineering and IT service management, working alongside the institution’s own experts across site reliability engineering, release, test, change, incident, problem and configuration management.
The operational discipline was real. Every morning, hundreds of people worked through the previous day’s incidents and the ones that had become problems, and every one was examined. What it needed was a dependable way to relate an infrastructure event to the business and the members it affected.
At the center of the program sat a single index. It weighed the members an outage was estimated to affect by the importance of the capability that failed and by the duration of the failure. A handful of people produced it, and every input was a judgment: which capability failed, what it was worth, how many members felt it, and for how long.
The index was subjective. Its inputs were judgments rather than measurements, and nothing in the architecture could reproduce them.
Measuring the truth required an army.
The formula was the right idea. Members, capability importance and duration is exactly how availability should be measured. What the institution could not reliably see was how an infrastructure failure propagated through its business capabilities to the members it served. Honest measurement meant taking every incident and problem ticket to the configuration item behind it, whether a server, a network device, a database or an application, and then working out by hand what that item touched: the business services, the capabilities and the members who felt the failure. Every ticket, every day.
That is not a handful of people. That is an army, and no enterprise sustains an army as its measurement system.
Traditional impact assessment: incident, problem and change records in ServiceNow lead to the configuration item in the CMDB, and what it touched is reconstructed by hand, every ticket.
The institution needed a more reliable and scalable way to establish the business impact of an operational event.
The Carlson BCM perspective: a capability model replaces the army with a structure.
Carlson BCM supplies that kind of structure: strategic, operational and technology architecture wrapped around the service management engine. Importance becomes a governed value score on each capability. Reach comes from relating every configuration item to the business services, capabilities and members it serves. Duration comes from service level indicators measured at the capability, from the moment the member feels the failure.
A capability model also holds the dependencies that reliability objectives require: what every application depends on, and what depends on it. That is what lets a subjective index be complemented, and then replaced, by measurement.
Carlson BCM architectural approach: incident, problem and change records in the ITSM platform lead to the configuration item in the CMDB, which Carlson BCM relates through strategic, operational and technology architecture to every capability and member it serves. The result is business impact intelligence: capabilities affected, operational consequences and value at risk.
Three directions follow from the structure.
Carlson BCM is independent of the systems used to manage and observe technology. Whether operational topology is maintained in a CMDB, discovered through telemetry, or generated dynamically from application and infrastructure behavior, the enterprise still requires a consistent business architecture to establish what those resources support, how they relate, and why their availability matters.
Reliability as an enterprise discipline. Reliability engineered into every portfolio and measured against objectives the business agrees to, at the capabilities members depend on.
Delivery that knows what it touches. Every test and every release planned against the capabilities it puts at risk, rather than the application it happens to change.
Operations that anticipate. Events read through the capability model, so analytics can predict which members a degradation will reach before they feel it.
A capability model is also what relates AIOps findings to the capabilities and members they affect. A correlation engine on its own can tell which events cluster together. It cannot tell which cluster a member felt. Without that relationship, AIOps automates the proxy.
When measuring the truth takes an army, an enterprise buys a cheaper number. The capability model makes the truth the cheaper number.