Data Assembly Delivers Actionable Information

Register now

Every organization has its share of tools and technologies that generate vast amounts of data for its employees to sort, filter, mash together, split apart or some combination of these activities. We basically do anything and everything to the data in an endless effort to make sense of it for one simple and consistent reason. We do all of this so that we, or someone we will present the data to, can take the results and act on them. When this effort is either not done well or not done at all, the result is wasted time/energy, fire fighting incidents that do not have an immediate impact to business services.
The problem that most of us encounter is not a shortage of data but more often an over abundance of it and a lack of confidence in or knowledge of what it means with regard to business service impact. We have all been in situations where we are presented with data from multiple sources that contradict eachother, but we have no easy way to assess which is the most accurate, which we should use for our decision-making or in what context the data is even relevant.
Let’s consider for example the toothpaste commercials that claim four out of five doctors recommend” a product. To the best of my knowledge, they never state that the doctors are dentists. We don’t even know if they are medical doctors nor do we know if they had to ask 50 doctors before they could finally reach the four out of five objective for the commercial. The bottom line is that we have no way to assess the validity of their claim without more details.
The following three lines of text are each oriented in a different manner using the same exact 22 letters. 



Source: “The CMDB Imperative: How to realize the dream and avoid the nightmares” Copyright 2009 Prentice Hall

As you can see, the first line has no meaning and does not represent intelligible words. The second line does form words, but there is no meaning to them. In the third line, we finally assemble the letters in a manner that they have meaning. The letters have been transformed from raw data into actionable information that can be acted upon. In IT departments, this transformation is aided by the inclusion of the business lifecycle and service level agreement details in the assembly and assessment of the raw data.
Many IT departments within organizations are structured in vertical units where each team is responsible for a particular domain such as server, network, firewall, middleware, database or application. Each of these teams works vigilantly to make sure that they meet their domain-specific uptime objectives so as to deliver the best service they can for their specific domain. They monitor and respond to incidents based on their specific domain rather than business services or configuration management database/ configuration management system intelligence. When incentives are based on these domain-specific metrics, rather than business service performance metrics, the organization will find itself rewarding unnecessary “fire fighting” of incidents that are not improving the quality of their business services. The utilization of the relationships in the that associates raw data with business services helps an organization prioritize efforts and allocate resources in a more efficient and cost-effective manner. 
The figure demonstrates how the lack of an active configuration management systems causes an IT organization to continuously be in fire-fighting mode rather than a targeted business service-driven mode. The top section of the figure (Domain Specific Monitoring – Incident Response) shows the results of monitoring three domains over a period of time. It first illustrates, in the “No Associations” line how an IT organization might have had to take on 10 different efforts to resolve 16 discrete incidents across the three domains. Assuming each incident caused a five minute outage on that IT component, this would have resulted in a perceived business service outage of 50 minutes. The energy expended trying to resolve all of these incidents is immense, costs the organization a tremendous amount of money and causes resources to be taken away from other, potentially more critical efforts. In the second illustration of this section, “Domain Associations,” we presume that the IT organization recognizes that some of the 16 incidents are in clustered environments. This allows them to lower the priority of some incidents and focus on fire fighting only four situations versus 10, resulting in a perceived business service outage of 20 minutes. 

The issue is that individuals in these domain areas don’t always know or have the information available to them to understand the impact that the failure of a technology component has on a business service. For this reason, domain teams will tend to treat most of their items similarly and simply scramble to bring them back online when a failure occurs, with little knowledge of whether or not the component is impacting a business service. What is worse, it is possible that they will prioritize their work in a way that they exert all their efforts to bring an item back online that had no impact to a business service because it occurred during a scheduled maintenance window. While they are working to bring this component online, they might actually be neglecting another component that is vital to a business service and having a major negative impact. So, not only did they expend many resources to resolve an incident, they also are likely to miss their SLA targets on the service that was negatively impacted. 
By introducing into the resolution and prioritization process the relationships that the configuration management systems manages and the SLAs that govern the business services, we can now get a true image of what impact the 16 discrete incidents actually had on the business service. In the example, the real impact to the business service was only five minutes, and it occurred immediately preceding a scheduled maintenance window. In effect, this offers the organization extra time to resolve the incident and even possibly the ability to not escalate the severity of the incident because a scheduled downtime was only minutes away. This is an oversimplified example, but it demonstrates how the allocation of resources can be greatly improved and made more cost-effective if organizations don’t act on raw data from monitoring systems but instead leverage the relationships available in the configuration management systems to assemble and transform the data into actionable information before making costly decisions.
This is not only an IT cost-savings issue. In many ways, the issue is far greater than that because it conveys a perception to the business partner that the IT organization is not in tune with what the business partner needs or is paying for. In the current economic environment where every penny spent is being carefully tracked to ensure that it is returning the most value possible, a perception that the IT organization is out of tune does not bode well for their longevity and opens the door to “punitive outsourcing.” 
Everyone needs to remember that our business partners do not care - nor should they - whether it is a server, or network component or database that has caused an outage to their business service. All they know is that they are not able to transact business during a period of time in which their SLA says they should be able to. As IT professionals, we need to recognize that ultimately, we are judged by our business partners on how well we support them in transacting business at a price point that they are comfortable accommodating.
So what does this all mean, and how can we leverage the vast amounts of data already available to deliver better service quality? It means that IT organizations need to understand the context in which data is being collected and how it will be used before it can be treated as actionable information. There are savings opportunities by reducing data volumes due to redundancy, unreliability or simply because they don’t add value during the service delivery cycle. The raw data should be viewed as the most granular level of abstraction upon which we then add context in order to transform it into actionable information. The CMDB/configuration management systems supports this transformation by assembling the relevant pieces of data into a form that can then be consumed by service management individuals and domain specialists in order to better deliver their services. Without this transformation, domain specialists are left to continuously fire fight incidents without a sense of whether or not their heroic efforts are delivering value or are simply providing their business partner with more reasons to consider outsourcing alternatives.

For reprint and licensing requests for this article, click here.