From my perspective, analytics certainly is not “advanced reporting”. The newer analytics solutions, specifically in performance management, provide real time intelligence to reduce MTTI/MTTR and even proactive information to prevent problems before they occur. Certainly, this is a lot more than just simple offline analysis and reporting (e.g., when am I going to run out of capacity) as analytics has been characterized in the past. My company’s product, Intergrien Alive is certainly an example of this new breed of systems management solution.
Personally, I do believe that analytics should be its own functional area and it would have interaction with all of the currently defined functional areas. If you want to stay with 6 functional areas, I would do the following:
1) Make Capacity part of the overall “Analytics” functional area, which would include real time analytics solutions as well.
2) Combine “Performance & Capacity” and “Availability and Notification” into one functional area named “Performance & Availability”. This new functional area would include everything in both the existing functions except for Capacity, which goes in the new “Analytics” area.
The reason I’d combine the two areas I suggested is that I consider performance and availability management and alerting to be one functional area once you move capacity planning to the new Analytics functional area. There is not enough differentiation between how performance and availability are managed to keep them as separate functional areas.
Ryan Shopp |
Thanks for the continual commentary! I agree completely, analytics shouldn’t be “advanced reporting” but it’s unfortunately been my experience many companies call it that. I’ve seen numerous times where the “analytics product” is developed on a BI platform (OEM or open source version) to aggregate multiple production instances of their main product into a single , unified view. That is not analytics to me or you! A prime example of analytics is what I have seen numerous times from Opnet in the Performance & Capacity Management functional area.
As for your feedback on the functional areas…I agree, Performance & Availability could and probably should be combined as I’ve previous discussed and then my next thing is to figure out what are the primary capabilities of a true analytics product. Thoughts here?
Glad to see the discussion continuing! Here are some of my thoughts on what makes a true analytics product at the high level (in no particular order):
1) Self Learning – Can determine normal and abnormal behaviors based on analyzing historical IT performance and availability data and adapts this learning over time to account for seasonal changes, infrastructure changes, etc. All algorithms providing the analytics capability are self learning and adaptive. Algorithms are data agnostic and not specific to analysis of particular IT silo components.
2) Automated – Once the system is implemented it does not require expert human intervention to provide the value of the algorithms that comprise the solution. Correlation, problem modeling and dynamic thresholding replace the massive efforts of human experts. A true analytics solution would not be templated or rules-based for specific components.
3) Real Time – The results of the solution’s algorithms are used in real time to alert to abnormal behaviors and to proactively alert to highly probable, future abnormal behaviors. The solution should be able to understand the building patterns of abnormal behaviors that have lead to previous problems and effectively predict them if they re-occur.
4) Cross Silo – Can easily integrate (via a simple API/SDK) with monitoring data sources across all silos of complex business services for holistic analysis. Provides out of the box integrations for the most common monitoring tools. A true analytics solution should not be a monitoring solution, and thus, should not require “rip and replace” of an existing monitoring infrastructure. Integration should be provided to CMDB for automated updates on topology changes.
5) Reduces Alerts – A true analytics solution should provide topology based aggregation of alerts as well as aggregation based on predicted abnormal behaviors. This aggregation reduces the total number of alerts while providing better problem solving context.
6) Algorithmic Sophistication – Algorithms must be sophisticated enough to handle IT performance data with a wide range of distributions. The solution should quickly learn and adapt to infrastructure changes as well as seasonal and other recurring events. This sophistication is critical to reducing false positives. True analytics solutions should be able to model problems when they occur so they can be predicted if the re-occur.
That is a start. I’d certainly be interested in your throughts…