Understanding an Observability Framework
“At CDW, we frame observability maturity as four levels,” says Beckendorf.
Level 1 is monitoring. At this level, teams pinpoint where issues occur, he says. “IT teams can detect whether systems are up or down, network engineers watch network alerts, database admins monitor queries, and so on.”
Level 2 is early observability. “At Level 2, enterprises begin to unify telemetry data and correlate signals across domains,” Beckendorf says. “Instead of simply asking what’s broken, teams can begin to answer, why is it breaking?”
“By Level 3 and 4, organizations achieve richer correlation, governance and, in some cases, predictive capabilities,” he says.
Level 5, the ultimate goal for many, is automation and self-healing, although Beckendorf notes that the costs to reach Level 5 may outweigh the benefits: “Typically, only hyperscale operators like AWS or Netflix-level businesses need this top tier.”
WATCH: Learn how observability can optimize performance and enhance efficiency.
Most enterprises today hover around Level 1, but they’d be far better protected between Level 2 and 3. To get started, they should plug known blind spots, such as unreliable network visibility or gaps in application telemetry, before aiming for predictive, AI-driven dashboards.
“Focus on critical workloads that directly impact revenue, compliance, or customer trust; for example, electronic medical record systems in healthcare, core banking applications in finance, or reservation systems in travel. All of these demand deeper visibility,” he says.
This is where prioritization is important. For instance, legacy applications that see minimal use may not warrant the same investment.
Why People, Process and Politics Can Be the Hardest Obstacles
Teams may worry most about getting their arms around data and tools, but “the real hurdles are often organizational,” says Beckendorf. “Many enterprises struggle with siloed teams, decentralized purchasing and tool sprawl.
“It comes down to people, process and politics. I’ve seen employees resist giving up tools they’ve used for decades, even though rationalization would save millions.”
“People will die on that hill,” he says. “In some cases, employees resist adoption so strongly that they try to undermine new tools or prove them ineffective. This can become a major cultural problem, and it’s why observability is as much about leadership as it is about dashboards and metrics.”
Beckendorf recommends that IT leaders give resistant employees all the tools and training they need to feel comfortable with change and promote consistency.
READ MORE: Observability and AI can optimize IT operations, data pipelines and model performance.
A Clear Process That Streamlines Success
To help IT leaders achieve observability, CDW has developed a structured process:
- Conduct an assessment. “CDW begins by evaluating a client’s current environment, identifying blind spots, redundant tools and gaps in governance.”
- Create a unified architecture that aligns with business priorities and digital experience goals.
- Advise on the right set of tools and consolidate overlapping platforms. This is the “tool rationalization phase,” which often leads to big cost savings.
- Align to the customer’s operating model. CDW confirms that the observability plan aligns with ITIL, ITSM, DevOps and SRE practices.
- Develop a roadmap. With CDW’s help, teams create a phased deployment strategy, focusing first on high-value applications (“crown jewels”) while deprioritizing legacy systems with limited business impact.
- Operationalize and manage changes. CDW helps teams put observability into practice and address any cultural resistance as the new process rolls out.
“This approach is designed to meet customers where they are before advancing toward higher levels of maturity,” says Beckendorf.
