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…

Steve Henning
Integrien Corporation

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?

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.

Steve Henning
<a href="http://www.integrien.com" rel="nofollow">www.integrien.com</a>