Nearly any Big Data initiative has the objective of transforming an organization's access to data for better and more agile business insights and actions. However, this can only be achieved through the extraction, indexing, storage, and analysis of many different data sources coupled with the flexibility to add more data sources as they become available or as opportunities arise.
To provide the greatest flexibility and avoid vendor lock-in, more organizations are adopting open source technologies like Elasticsearch, MongoDB, Spark, Cassandra, and Hadoop as their common data store. This same approach is at the heart of ITOA.
A Big Data practice provides the flexibility to combine and correlate different data sets and their sources to derive unexpected and new insights. The same objective applies to IT Operations Analytics.
What we've seen for the last couple decades is an accumulation of disjointed tools, resulting in islands of data that prevent you from getting a complete picture of your environment. This is the antithesis of Big Data. If the CIO wants their organization to be data-driven with the ability to provide better performance, availability, and security analysis while making more informed investment decisions, they must design a data-driven monitoring practice. This requires a shift in thinking from today's tool-centric approach to a data-driven model similar to a Big Data initiative.
Tool-centric approaches create data silos, tool bloat, and frequent cross-team dysfunction.
If the CISO wants better security insight, monitoring, and surveillance, they must think in terms of continuous pervasive monitoring and correlated data sources, not in terms of analyzing the data silos of log management, anomaly detection, packet capture systems, or malware monitoring systems.
If the VP of Application Development wants better cross-team collaboration, faster, more reliable and predictable application upgrades and rollouts for both on-premises and cloud-based workloads, they must have a continuous data-driven monitoring architecture and practice. The ITOA monitoring architecture must span the entire application delivery chain, not just the application stack. Because of all the workload interdependencies, without this data an organization will be flying blind resulting in project delays, capacity issues, cross-team dysfunction, and increased costs.
If the VP of Operations wants to cut their mean time to resolution (MTTR) in half, dramatically reduce downtime, and improve end-user experience while instituting a continuous improvement effort, they must have the ability to unify and analyze across operational data sets.
The CIO, security, application, network, and operations teams can achieve these objectives by drawing from the exact same data sets that are the foundation of ITOA. This effort should not be difficult, costly or take years to implement. In fact, this new data-driven approach to IT is actually being accomplished today; we're just codifying the design principles and practices we've observed and learned from our own customers who are the inspiration behind it.
In the next post in this series, I introduce a taxonomy that describes the four data sets that drive ITOA: wire data, machine data, agent data, and synthetic data. Understanding how these data sets are complementary and serve different roles will help you assess your operational stance and existing toolset. How does adopting a data-driven monitoring architecture through IT Operations Analytics benefit different departments within an organization, such as security, application development, and operations?
This prompt doesn't seem malicious.