Too Many Tools

I'll make an assumption: if you're a Thwack user and you're reading this post, you've got an interest in systems and applications monitoring. Or maybe you just really want those points. Or that Jambox. Whatever's cool with me.

But if you're a tools geek, this post is for you.

Tool suites aspire to have the ability to monitor everything in your infrastructure, from hardware, through networking and virtualization, right up to the user. But to be honest, I've never seen a single solution that is capable of monitoring the entire environment. Many times this is not a technological problem; organizational structures often encourage multiple solutions to a single problem (e.g., every team purchases a different tool to monitor their systems, when a single tool (or a subset of tools) would suffice). Other times, tool sprawl is the result of staff or contractor turnover; everyone wants to bring the tools they know well with them to a new job, right?

Tool sprawl is a real problem for IT shops. The cost alone of maintaining multiple tools can be staggering. But you also run into the problem of too many tools. You'll likely end up monitoring some systems many times over, and will most certainly miss other systems because there's confusion over who is monitoring what. As a result, you'll end up with more tools than you need, and the job still won't be done.

How do you manage or prevent tool sprawl at work? Do you lean on a single vendor, like SolarWinds, to address every monitoring need that arises? Or do you seek out best-of-breed, point solutions for each monitoring need, and accept the reality that there is no single pane of glass?

Parents
  • It's also where you define your objectives.  There are various domains to monitor: Environmental, Physical, Virtual, Asset, Storage, Network (wired & wireless), OS, Application (i.e. Exchange, SQL Server, etc.), Service (website availability/performance).  Different teams may have a stake in their particular domain, but it's all part of one rich tapestry.  The application and service domains are often the ones facing the brunt of the problems because they're the customer facing domains which are impacted by their dependent domains.  So if you define your monitoring objectives only within a single domain, you only get part of the picture.  This has as much of a technical problem as a political problem.  It's important to be able to understand and analyze the metrics at each level because they affect one another.  Additionally, it's helpful to break down the silos of IT and merge tools to make analysis more thorough, quicker.

Comment
  • It's also where you define your objectives.  There are various domains to monitor: Environmental, Physical, Virtual, Asset, Storage, Network (wired & wireless), OS, Application (i.e. Exchange, SQL Server, etc.), Service (website availability/performance).  Different teams may have a stake in their particular domain, but it's all part of one rich tapestry.  The application and service domains are often the ones facing the brunt of the problems because they're the customer facing domains which are impacted by their dependent domains.  So if you define your monitoring objectives only within a single domain, you only get part of the picture.  This has as much of a technical problem as a political problem.  It's important to be able to understand and analyze the metrics at each level because they affect one another.  Additionally, it's helpful to break down the silos of IT and merge tools to make analysis more thorough, quicker.

Children
No Data
Thwack - Symbolize TM, R, and C