There is a good ongoing discussion about the “right” number of network monitoring tools in the Enterprise Systems Management group on Linkedin.  You have to subscribe to the group to read the whole discussion, but if you are a member of Linkedin I recommend you look into this large, active community of IT professionals focused on IT operations management.

The discussion about how many monitoring tools an enterprise should have (or how many are too many) touches upon a lot of questions and comments I hear frequently from our customers and prospects.  Reflecting on some of the more recent customer discussions we have had and some of the lessons we have learned in helping them with their network and application monitoring, there are a few points in the discussion I find particularly interesting:

Only collect data you are going to use.  A lot of points are raised about the vast quantity of data that enterprises collect.  In a related comment, there is also the frustration around the relatively common scenario where multiple tools are polling the same network element (for similar information).  In an era of increasing regulation, which prompts enterprises to collect and save more rather than less, and the availably of yet cheaper and cheaper storage, it’s no surprise some companies are experienceing exponential growth in their data collection.  However, in the context of how many monitoring tools are too many, I agree (and have witnessed firsthand) that if you focus on caring only about the data you are going to use, you can by definition get closer to the optimal number of monitoring tools for your specific enterprise or project.

Network monitoring tool selection based on tangible ROI.  I mention this comment since I don’t see users of network monitoring tools stressing ROI enough in their selection process.  It’s a given that the ability to actually measure ROI varies along the broad spectrum of IT Operations Management tools (especially in a pre-sales effort).  However, for the more focused projects and especially projects related to monitoring revenue generating aspects of the business (e.g. a network monitoring tool to calculate when a network service provider may have a chance to upsell a customer based on their bandwidth usage over the month), network operators should look for creative ways to estimate (pre-sales) and validate (post-deployment) the return on an enterprise’s investment.

“Good Enough” monitoring.  In a comment describing major categories of network monitoring tools, a definition of “Good Enough” monitoring tools is offered.  That is, some tools are selected based on a compromise between feature/function and cost/breadth.  If you can monitor “XYZ” application really well but sacrifice something in terms of depth or breadth of some other “hot” feature, should that be acceptable?  What strikes me as important here is that the laser-like focus should be on the end goal.  If you are charged with monitoring some aspect of the network related to an important customer SLA, then find the best tool for the least money that does just that, and don’t be overly concerned with bells and whistles that don’t directly relate to your goal.  Sounds simple, but if you aren’t dilignet you can easily get mired in the weeds and end up with an unnecessarily long selection process.

This Linkedin discussion is good one and as you would suspect there is no succinct conclusion to the broad question, but it is generating a lot of good thinking and relevant questions we deal with on a daily basis.