Through evolving legacy modernization, a clear need for automation arose to bring actionable insights to IT and DevOps teams.
Through evolving legacy modernization, a clear need for automation arose to bring actionable insights to IT and DevOps teams. Unified monitoring, log management and event management vendors are finding ways to embrace Observability in their tech stacks. And while the overall functionality doesn’t change, these adjustments have led to confusion between IT and DevOps teams. IT Operations and Service Management (ITOSM) professionals are skeptical that Observability is a marketing ploy rather than a tool that actually implements technological change. DevOps professionals, on the other hand, are hesitant of the idea of repurposing legacy tools. So what should vendors do when transitioning standard monitoring technology to use Observability in a meaningful way? Observability imperative: the road to discovery The original concept of Observability is based on Control Theory, where a system is considered observable if there’s enough quality data gathered that a person can view how each system reacts to one another, or put another way, you can infer the state of a system from its inputs and outputs. Observability has a different context when referring to DevOps. And in order to understand DevOps teams’ sudden captivation of Observability, we need to explore the origin from an IT perspective. In 2013, interest in Application Performance Monitoring (APM) began to grow for ITOSM professionals. Because of the overall influence IT has on business success, applications to link IT throughout the business and to customers grew. With each application, event data and end user experience latency metrics were collected, and within minutes, managers had ingestible data to create analyses and detect problems. Meanwhile, markets pressured application developers to improve agility, accelerating the process for improved digital capabilities.
