Some time ago a regular reader of my blog contacted me. Let’s call him Pete.
Pete had started using Savision Live Maps and was impressed by the possibilities and the power. So far so good. But the management was also very happy about it and wanted him to deliver dashboards that would envy mission control of NASA
(Picture is borrowed from Wikimedia.)
…and would outsmart the state of the art cockpit of a Boeing 787 Dreamliner…
(Picture is borrowed from Wired.)
And now there was ‘some’ pressure on Pete which is highly understandable. Because dashboards which are nested, show everything into the smallest detail and yet show all interconnectivity as well, aren’t really easy created. So this is what worried Pete to a huge extend. How to deliver dashboards like these? How to elevate PS and VB scripting in order to get there?
So Pete contacted me and asked how to go about it.
Since Pete’s situation isn’t really unique I decided (with his agreement) to write a blog posting about it.
Back to the organization
First of all dashboards like these aren’t going to stick at all. Main reason is the organization behind it isn’t totally up to specs. May sound harsh but hear me out on this one. WHY does the management want a 787 cockpit and mission control? For what purposes? Aimed at what and more important, whom?
And because the management never told him that, Pete would never be able to deliver it . It will never be what they want simply because they don’t know it exactly for themselves. Technology isn’t the answer here, but processes, people and organization.
Anecdote
In order to make it more clear I told Pete an anecdote which happened to me many years ago. It was one of my first lease cars. Brand new but already after a week it was difficult to start it. So to the dealer I went. A mechanic took a look, tried to start the car and experienced the same issues. He told me he would locate the issue and fix it. To my surprise he didn’t open the bonnet of the car but hooked the car to a computer. The computer would locate the issue in a matter of seconds he told me, then he would fix it.
But the computer told him all was just fine. So he ran multiple diagnostics and still the computer told him all was OK. Then he called his superior and together they ran the same diagnostics! After an hour I almost begged them to open the bonnet and to take a look. But no, the computer would them what was wrong. I was getting upset because it took too much time and I had an important appointment. So I opened the bonnet myself and then I had a big laugh!
Even I, a total amateur on cars, saw what was wrong: an air hose was totally cracked which fed into the starting engine. So when trying to start, it got too much air! Both mechanics were totally embarrassed and fixed it with some tape and told me they would order a new part for it.
Metaphor
When I drove to my customer I realized this was a shiny example of computers and their limitations as well. The computer checked the engine while running looking at temperatures, compression/pressure ratio, and the mixture air/fuel. And yes, that was all OK. Within specs. So the computer told them what it measured. But the mechanics using that computer forgot one crucial aspect: the computer had a LIMITED view of the whole car!
Using the car anecdote as a metaphor there are many striking resemblances:
- The car represents the IT services any IT department delivers;
- The driver of the car represents the end-users which ‘consume’ the IT services the IT department delivers;
- The computer running the diagnostics represents the cockpit/flight-control center the managers are demanding;
- The broken air hose represents the root cause of a failure resulting in a disruption of the IT services which affects the end users;
- The mechanics represent the managers looking at the dashboards, telling the end users everything is OK while they experience issues.
Hopefully you’ll see what I am driving at. In Step 5 the managers will realize sooner or later that something is amiss but not shown on their flashy shiny posh dashboards. So they go to the one who built them. It won’t be a nice conversation I am afraid…
Perception management
Therefore it’s better to stay away from situations like that and to start at the foundation, which is perception management. Let management know that no matter what they’re looking at, it will always be a scoped view of reality. Simply because you can’t take everything into consideration. Otherwise you’ll end up with way too many items and loose track and control as well.
A 787 Dreamliner cockpit is an excellent example. Instead of showing everything it shows the status of the systems involved. And yes, the pilots can zoom in into the very detail of the smallest component, but only when required. That’s normal for a cockpit but not for an IT department. When they want such functionality, management must invest heavily. Not only in licenses but also in time and resources and training. This can’t be built by one man!
Too many times I bump into situations like these and I have to make management see what they’re really asking. Which I call perception management. As an outsider it’s easier to get the message across but can be a challenge as well. By telling management how many licenses, time, resources and man hours they require to deliver what they want brings them to their senses, enabling one or more projects which are SMART. Like delivering dashboards depicting the most crucial IT services, composed of the components, monitored by SCOM.
This brings one back to SCOM as well, since the basics (component monitoring) have to be spot on. So only Alerts which means something to the organization are shown and even more important, relevant State Changes (Healthy > Warning > Critical). Since those State Changes will be used on the dashboards. So it’s crucial to get them right.
Where the dashboards ends and people, processes and organization kick in…
Again, this is something that shouldn’t be done by one or more IT persons. Simply because they represent a small piece of the whole puzzle. What about Change Management, Application Owners, DBA’s, end-users, Service Managers, and application developers to name a few?
What about an Alert or a State Change on a Dashboard? Who is going to do what/when and how? How is everything logged and tracked? When is something an incident and when not? Who decides that? How are escalations performed?
What Alerts are scoped to working days and –hours only and what Alerts are processed on a 24/7 hours basis? And why?
As you can see, a dashboard is only a dashboard and nothing more. There is way much more to it, like people, processes and organization. Discuss it with the managers involved. Make them realize a dashboard needs way more attention. Otherwise they’re looking a scoped view of the reality and missing out tons of information and lacking the proper execution when something goes wrong.
The push
Also important: this has to be driven top down. So management has to know this, make it clear as in a project and drive it through the organization. Otherwise it won’t stick and work at all. Budget and resources must be allocated as well.
Recap
As you can see, good relevant dashboards are key to proper monitoring. But nothing more but means to an end. When the proper processes aren’t in place and the organization lacks execution, a dashboard won’t change that. Therefore it’s crucial for organizations to get that on a level as well. Only then dashboards will add value to the organization as a whole.
Want to know more?
Check out these url’s:
- Microsoft has written tons of good information about it:
Core Infrastructure Optimization - A three part series of postings I wrote some time ago (but still valid): http://thoughtsonopsmgr.blogspot.nl/2009/11/opsmgr-where-technology-ends-and.html
.
): 
. ![image_thumb[4]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1ucRfYLzCJIb8Nc85NhhI5BRg04jGxVVzTUHgaT99atZvszN2dj7lNDgNF9GbucEfld6HkwWVWfCZUv4dRIEAxqlKFpY0eg0zf9w40HIokzQLwGrn1cJA5vGOlLafdQHcIv9VSNMfuiYy/s1600-h/image_thumb%25255B4%25255D%25255B2%25255D.png "image_thumb[4]")
.
