As a follow-up to “Observability — Is It IT Voyeurism?”, we want to provide a bit more guidance around the “observer” and the “observed” parts for the technologists who are building these systems. As we discussed, observability doesn’t happen on its own. We noted that observability is the capability of being observed. It’s a delicate dance between the observed entity sharing aspects of its internal workings and state with observer(s) that know how to properly communicate with it.

Object-Oriented Analysis And Design (OOA&D) And Programming Principles

The relationship between the observer and observed must be explicitly built and based on trust. Let’s look at it from an engineering or object-oriented programing (OOP) perspective and then add the IT component to it. The goal is to understand what’s going on with the device, application, or system — the target object. But it is also about the entity’s willingness to share details about what it’s doing that may not be publicly available. The terms for this behavior in OOA&D are encapsulation and abstraction.

In the OOA&D/OOP vernacular, encapsulation is when an object exposes only selected information by design. When defining the object, you identify which characteristics are public (accessible by an external interface) and which are private (accessible only by an internal interface).

Abstraction is used to expose complexity in a way that’s simpler for the observer and safer for the object. The observer can only interact with the object’s selected characteristics and methods. We won’t get into class hierarchy discussion here to avoid this getting too complicated.

Making Yourself Observable

A key benefit of OOA&D and OOP is that you deliberately design objects to expose only what you want external entities to know about them. Software engineers and hardware designers need to expose important characteristics via a defined interface so that the entity can be observed properly, ideally in an automated manner. Acceptable observation is determined by design and via a defined language in which the observed can be engaged. Only if the observer knows the specific language of the observed object can they have a meaningful conversation. If, for example, the observer asks the object a question that the observed doesn’t know how to answer or doesn’t understand, no reply will be provided.

If the object is well designed and well behaved, however, maybe it would respond politely and say, “I’m sorry, I don’t understand your question,” or “These are the only questions I know how to respond to, and you must ask me in this specific way.” Another option is for the developers/designers to provide a listing of all the exposed attributes when asked.

Why It Matters

Understanding the observed entities’ characteristics and behavior from multiple perspectives has always been important — and now more than ever. App developers are heads down building applications that they readily deploy in evolving constructs like containers and microservices. These constructs will bring a sea of changes for all infrastructure technologies including the compute, storage, and network. Modern applications add new constructs like service meshes into the technology mix that previous generation monitoring tools may not recognize, let alone manage. This could even lead to autoremediation if the corrective actions that should be taken under a faulty condition are exposed. These changes are impacting in three distinct ways:

  1. Yesteryear’s operators — now called observers — need to evolve and understand the new paradigm they’ll operate in. While the monitoring fundamentals remain the same, the information that tools collect will have a significantly higher volume, velocity, venue, and value. Increasing digitization is forcing operators to embrace and manage these new deployments seamlessly.
  2. Internal developers must adopt practices and embed ways in which those apps and infrastructure constructs will be observed. As we continue to move towards modern and resilient operations, we need every entity in our environments to become more intelligent. For that to happen, we need observability to be designed into it from the beginning. This is giving rise to open standards like OpenTelemetry that every developer can easily adopt.
  3. Tools alone are insufficient. This is the classic scenario for the people-process-technology relationship. Teams must build processes around how, by whom, and when an observation’s signals will be used, by whom, and when. Likewise, operations must adapt their practices to handle new infrastructure constructs at scale.

We’ll never achieve highly automated and autoremediated operational environments if we don’t practice a common and shared understanding of observability. You can’t manage what you can’t observe!

Join The Conversation

We invite you to reach out to us through social media if you want to provide general feedback. If you prefer more formal or private discussions, email to set up a meeting! Click Carlos at or Naveen at to follow our research and continue the discussion.