Problem to Solve – My company has many different IT and business solutions and it is difficult to a get a “single pane of glass” service dashboard to see how everything is performing.   What can we do?

I will admit that I am still a fan of Meat Loaf. Yes, both the 70’s singer and the dinner option. 😛  While I seriously doubt that Meat Loaf’s “Paradise by the Dashboard Light“ teenage anthem really had anything to do with IT services or dashboards, we are going use it anyway.   (YouTube link – https://www.youtube.com/watch?v=SmPMMitJDYg)    Do you have any idea how few catchy phrases have the word dashboard in them?

The funny thing is that my experiences with expectations regarding the concept of dashboards, has been anything but “paradise“.  To be honest, each person / role / skill set / executive / group have all had their own perspective of what a dashboard is .. and what it should look like.    Dashboards are most definitely not a “one size fits all” type of discussion.   I have seen multiple variations on scope and requirements.   Requests range anywhere from collecting information from many different business systems, an easy to use GUI, creation of their own data sets, Geo IP for Cybersecurity views, etc.  Quite simply, it has been a topic with many opinions and views.  For this article, we are going to focus dashboards and the notion of “critical business services“.

So What is a Service?

Generally speaking, a service within IT is any component or dependency that is critical and necessary for a business function to operate properly.   If I am the business service owner or application manager, I really only want to know that there is a problem with anything relating to MY SERVICE as it relates to what my company offers customers.   A service can be made up of any combination of the interfaces, sub-interfaces, QoS priority, application TCP/UDP ports, subnets, critical URL’s, key enabler protocols (like DHCP, DNS, LDAP), Databases, etc.   We try to guide our customers to consider all of the things that make up their critical services, and then construct dashboards to that type of model.   We call this type of model a service dashboard.   One popular reference that I often use to describe the value of a service approach is DNS.   Again, if I am the service owner, I do not necessarily care that my company’s DNS servers are having issues.  A real world example is when I launch my browser to access http://www.espn.com to view fantasy football statistics, and I get a “cannot find the server” message. While I might be annoyed by this error message, it doesn’t really affect my world at work.    On the other hand, if the DNS query requesting “webserver12.acme.com” (within my business critical multi-tier application) experiences a failure, all of a sudden you have my full attention.

Why is this valuable?  In keeping with the example, if your company’s DNS servers in general are having issues, that is really someone else’s responsibility to identify the problem and restore proper working DNS functionality for the corporation.   My focus as the ‘service owner’ is to be aware of things that may be affecting my specific service.    I really only care about the individual DNS queries that web and application servers are making to communicate with database servers within my service environment in this example.   The reason being that if the DNS queries (for my environment) are experiencing failures, that will affect the overall performance of my application and service.   This same concept applies to any of the individual pieces of the service, such as web servers, application servers, database servers, authentication, virtualized components, etc.

Integration with other Dashboards

Yes, I know I just said focus on critical service dashboards, and then immediately brought up the word “integration”.    As I mentioned before, there is usually not a single dashboard (or data set) that will be “everything” for “everyone“.   That being said, taking a “service dashboard” approach and adding this critical information into a larger business environment dashboard is not a bad idea.    Our approach is always letting the business problem you are trying to solve dictate the requirements and eventual solution.  Sometimes this means taking data from different and unrelated data sets, and that usually involves an API.   See my previous API article “If you’re API and you know it, clap your hands”.

Why is this valuable?   Having the ability to bring key pieces of information from different solutions and data sets into an aggregated view helps you make good business decisions.  This is a good thing.    For example, you may want to see local weather information, next to a dashboard about shipping product, that also integrates your services dashboard, next to utilization and device statistics.  The value is being able to view different pieces of key information to make educated decisions.   

Must be able to Triage ASAP

Again, taking the “I am the business service owner” perspective, so I want the ability to triage issues with my business service as quickly as possible.    Obviously, the quicker that you can identify “probable cause” to service impacting issues, the quicker that you will resolve and restore services back to normal.    We find that our customers most critical business services are almost always Multi-Tier applications.    You can probably name several in your mind without much thought …  email, ERP Systems, HR management, e-commerce, etc.   Please take a look at this previous article regarding the specific “Challenges of Multi-Tier applications”.

Why is this Valuable?   An example may work best for this situation.  Let’s assume that you have an e-commerce application that provides an order entry portal for customers to enter their orders.    If this service becomes available, the real question to ask is “how much money would it cost your company for every minute of the service outage?”.   The speed at which you can identify the probable cause to an issue becomes the key consideration.   The quicker you identify the problem, the quicker you can restore the service, and this process is called “service triage”.

So is it Really Paradise?

Well the word “Paradise” relating to dashboards may be a stretch, but as the old adage goes, “Don’t let perfection be the enemy of good”.  There is still significant business and IT value to be gleaned using a dashboard.

Points to Ponder

• What has your experience been like with creating or leveraging dashboard technology?
• Was the use case closer to being “something flashy and cool”, or did the dashboard provide key insights to business?