Hopefully by now you’ve had the opportunity to determine what was important in your environment. Now we need to figure out how to leverage that information. If you haven’t read the other posts in this series, please visit here to catch up and contribute in the discussion.
Ask yourself what is more important in your environment, the metrics or the message? I’d say the message is much more important than communicating a bunch of metrics without proper context. The message is made up of metrics, but it’s how you group, organize, visualize and present these metrics in the right context that communicates a message. Our next steps will be to take a look at all of this information and boil it down into something more manageable.
Metrics Demystified – Creating a Metrics Data Dictionary or Metrics Catalog
Stare at your sources of data – really – lay them all out on a white board or on little yellow Post-It Notes. For each metric, capture the following information:
- Metric ID- the Metric ID should be a unique identifier assigned to each metric.
- Metric Name- this should be the common name for the metric, understandable to the intended audience.
- Source- this is the source of the metric. It should provide enough information to adequately describe where this metric information resides. System name, IP address, Database name, database table, spreadsheet name and location, application name, etc.
- Freshness- this should describe how frequent the metric is updated such as Real Time, X Minutes, Hourly, Daily, Weekly, etc.
- Access Method- this should provide details on how to access this metric from the identified source. This could be login/password information, database table name, SQL query, screen scrape information, etc.
- Message Category- this should capture the message topic/group this metric aligns to? Find your short list of topics or groups you can assign metrics to (availability, performance, quality, revenue, inventory, sales, etc.) Ask yourself what this metric communicates to someone who see it?
- Importance to Business- this should capture how important this metric is to the Business on a scale from 1-10, with 10 being the most important.
- Importance to IT- this should capture how important this metric is to IT on a scale from 1-10, with 10 being the most important.
- Audience- this should capture who the intended audience is for the metric. Is it for executives, management, and technical staff? The Business? CIO? CEO? Who will use this metric to make a decision about something?
- Measure- this should capture what this metric is measuring. Health, status, volume, trend, quantity, speed/velocity, etc. It should also capture the units of measure.
- Use- this should capture information about how this metric is being used. What reports, graphs, charts, dashboards, presentations, etc. is this feeding into?
- Compliance- this should capture and highlight how this metric may be used in compliance reporting and monitoring efforts for Sarbanes-Oxley (SOX), HIPAA, BASEL II, etc. These metrics and the systems, applications, tools, etc. that generate them may need to be under the appropriate control measures.
- Notes- additional notes and information.
The output of this process is a database, document or spreadsheet that captures all of the above information. Try organizing the metrics by source, message, and importance to business, audience and measure. This data dictionary for your metrics will be used (especially the Metric ID) when creating and mapping events to metrics for monitoring, dashboards, reporting, etc. which I will discuss in part four of this series.
Metrics Data Dictionary or Metrics Catalog
Crafting the Message
Since you’ve already determined what was important, it should be easier to use this metrics catalog to craft and communicate a message in-line with what you determined. Think about what you want the message to accomplish. Provide visibility? Prompt action? Show accomplishments? Communicate status or overall health of something?
An earlier posting on a topic called emotional metrics should be revisited here. Don Page of the Marval Group presented on a topic related to what he called “Emotional Metrics”. These metrics are both positive and negative. They are focused on outcome, action and encourage decision making. They aren’t to be used to create a pretty picture on the wall or screen in the NOC.
Again, know your audience and business. Really think here about the business you’re in and the real objectives of any business – control costs and make money. How do you do that? What makes you money? What costs need to be controlled? What happens if you’re not making money? What happens if costs are out of control? What are the positive/negative outcomes? Whose bonus, commission or compensation is impacted? Those people need the right message communicated to them that prompts them to make a decision on what to do next (or at least we hope so).
Look at your metrics catalog and try to generalize into three to five categories that best communicate the message for each audience. There’s more to talk about here in a future posting on visualizing the message, but most people can’t process a ton of information. The message should be interpreted in less than 10 seconds by a competent person familiar with the environment, terminology, business, etc.
Examples may be something similar to below. These would be the key message categories important to the business. In each of those categories, metrics would be mapped into them to communicate something about each category (see above).
- IT focused message: Availability, Performance, Reliability, Customer Experience, etc.
- Business focused message: Sales, Inventory, Distribution, Customer Satisfaction, etc.
Double check here – are you providing visibility or prompting action? Are you showing accomplishments or business health? Is it nice to know or very important? Can the metrics you selected prompt someone to ask at least two questions? (Is this Good/Bad? Is this Getting Better/Worse? On-Target/Off-Target? Why? Cause? )
Next in the series: You’ve Got Events, Now What? Part IV: Mapping Events to What’s Important and Your Message.
Previous posts in the series available here
Comments on this entry are closed.
This is where most of us always end up into trouble , thr is a vague line between accurate message and speculation.
I have had tons of exp. when a message did not make complete sense OR the message speculated something which was not the root cause. Views?
Yes, I agree. They “typical” monitoring tools group doesn’t go far enough in both design of the monitoring, implementation of the monitoring, operationalizing the monitoring and having a lifecycle of continuous management of the monitoring.
What I mean is that we must work together with the SMEs for what we’re trying to monitor to ensure that we get it right. We must include the front line support, command center, NOC, etc. folks in these discussions. We must establish operational level agreements (OLAs) around what we’re monitoring, what causes events to be generated, what causes events to clear, what the expected and agreed upon actions will be for EACH event (create a ticket, escalate, page out, troubleshoot, etc), etc.
When we just turn on monitoring with default out of the box configurations and expect things to just work, we get the bad rap we deserve. Unfortunately this is the state of so many organizations out there.
Make sense? I’m sure it does, and I know it’s ‘hard’ to do. Nobody likes to leave their comfy cubicle and do it, but this is the only way to make it work in my opinion.
Doug
I totally agree, this is one of the best series I have read for a Service Assurance deployment and its progression to BSM.
Thanks a ton!!
Glad it’s helping! Much of this is the basis for the formal BSM Methodology that I’ve created here for IBM. Maybe we could conduct the workshop for your team? I promise it’ll open the eyes of the monitoring tools team there!
Doug