By Splunk August 17, 2017
The following case was driven by an executive who was tired of the lack of perceived accountability within their IT organization. See, this executive was in charge of a critical business service called “claims,” and every time there was a hiccup he received an influx of emails, phone calls and meeting requests where individuals raced to prove their group and tool was not at fault, rather than a gathering of forces working towards the same outcome to fix the service hiccup.
This executive invited our Data Sherlock to come in and help him and his organization understand what needed to change. Our Sherlock had one simple suggestion, and that was to stop reviewing horizontal technology metrics and instead adopt a broader service context.
Our Sherlock had brought along a few images to help explain this subtle but business-critical change in perspective. (As a side note: for those of you avid readers, the following images will be familiar from the “Case of the Wrong Metric.” For Data Sherlocks, thinking about the bigger picture is one of our core traits, so these themes may recur.)
In the above image, you see the technology that supported the claims service. As you can see, there is nothing crazy or even complex about the technology because it is, by its very nature, a standard application architecture. Unfortunately, that's the challenge when something goes bump in the night and the service is not responding correctly.
This is where the horizontal tools and the race to prove that any individual technology set was not at fault do nothing for the critical business service. There has to be a better way.
See image 2. As we start to think like the service owner, we can start to see lots of problems. See, the service owner cares about the vertical slice, while the technology owners care about the horizontal slice. This is the crux of the disconnect.
The database owner in this story says, “I am having a good day at 98 percent availability and I am green across the board.” Well, unfortunately the service owner—the executive in charge of delivering revenue to his company—is NOT happy and frankly doesn’t care if the database team thinks they are all green because from where he sits, they are red.
In image 2 we've highlighted the hypervisors in yellow, but in this case, they're sufficient as they are not impacting the claims service which drives revenue. They likely are impacting something, but in this example it's not the claims service and thus they are given a pass. It's the areas shown by the gray, vertical stripe that are the problem for the claims service. In this view, you can see that the database is the problem, not the hypervisors.
This is why companies have to review everything from a service perspective and stop the siloed view of individual technology sets. Companies that adopt this service-based view with Splunk IT Service Intelligence (ITSI) will see their world completely differently—enabling them to address the critical services. This twist in perspective is critical and it's best lead by an executive in charge of the service because if you leave it to technology owners, they'll just say “all is good by me” and—as this example shows—that's not the right route to solve your service challenges.
To end his story, our Sherlock pointed out that 98% was actually a fail while 95% was a pass and that's because of service context provided by Splunk and Splunk ITSI.
Companies need to manage their IT environment by critical business services to ensure they are serving the executives of the business. Once this is done, the relationship will improve dramatically and those irritating emails, phone calls and meeting requests to prove innocence will end.
Case closed.
Z – Data Sherlock
----------------------------------------------------
Thanks!
Michael Zuber