The importance of capturing historical data, and even more importantly, learning from it.
Many companies are in the midst of a Big Data project to store operational data. How does the event console and event stream data figure into this scheme? And what about the Service Desk?
Taking a step back, we often see two camps in many large IT organizations: the real-time camp (event consoles) and the Big Data camp (throw everything into the data warehouse landfill and mine it with Splunk to uncover insight).
Truth be told, it’s not an either/ or proposition. In IT Operations, you need to work in the “now” AND you need to look back in time to learn what you can from history.
- Event consoles operate in the NOW
- Splunk looks at what happened in the past.
- Reviewing history can be helpful in predicting the future only if the infrastructure doesn’t change and if the landfill (e.g., CMDB) is 100% complete and accurate
(For more on this topic…tune in to our webinar on May 8th presented by Richard Whitehead, former member of Splunk’s advisory board.)
So if you have cloud/hybrid architectures or outsourced infrastructure over which you have no control, you can’t depend on history to repeat itself. Things will always happen which never happened before, and for which you have no rules or models.
So, where does that leave us with respect to Big Data and your Incident Management Process (resolving problems and closing trouble tickets)?
When you talk about workflow – how people do their jobs and fix problems day in and day out, the missing ingredient is the ability to bridge the gap between the past and the present – and crossing the boundary between IT Operations and IT Service Management.
- There is a disconnect between the Event camp and the Big Data camp
- Also, each camp is poorly integrated with the Service Desk, where trouble tickets impose orderly structure around workflow and the way incidents are managed and resolved
In the era of elastic compute, this must change. That’s the beauty and the genius of Incident.MOOG.
Functioning on the one hand as an Event console, Incident.MOOG leverages Big Data analytics (unsupervised machine learning) to reduce the dependence on rules and models so we can apply Big Data analytics in the NOW.
Next, our Situation Room (Facebook Wall-like room) brings the Event Stream into the Enterprise WorkFlow – bringing in the right people at the right time, bridging ITOM and ITSM.
Below is an example of integration between Incident.MOOG and ServiceNow: using simple mouse-click, a link is established between the two systems at the ServiceNow operator’s discretion. Then, when a ServiceNow incident is saved, a link is established back to the Incident.MOOG Situation.
- Incident.MOOG captures knowledge as incidents unfold – working in the NOW
- Incident.MOOG indexes this vast knowledge of operational data in a way that Service Desk folks can use and re-use to help you learn from the PAST
If you add work notes in ServiceNow, they will be added to an Incident thread in Incident.MOOG and vice versa to bridge the ITOM – ITSM gap.
Big Data Analytics can play a role in your incident management process. But you need a 21st century solution that is built around compute agility and multi-party support operating models – Incident.MOOG – to accomplish that!