Showing results for 
Search instead for 
Did you mean: 

Tools for IT Operations Management

Level 9

My last couple posts have focused more on the people and process side of things for IT Operations Management, but the right tools are also very important. Choosing the right tool for IT Operations Management might be one of the hardest things to do in IT. You have a lot of different requirements from a lot of different teams (Virtualization, Storage, Network, Apps, Business Management, etc.),  so it makes matching a single tool very difficult. As you see I said "right tool" and not "right tools" and the reason I said this is because we are usually looking for that one tool that serves all our needs. This is one of the areas I think IT Operations limits their decision making when evaluating tools. Chances are you are not going to find just that one tool that meets all requirements of the multiple teams. I've seen too many times where the virtualization team looks for a ITOM tool, but want it to report on compute, hypervisor, storage, and network. They then limit their search to a tool that can perform all those funtions, even if the tool is only sub-par at all those functions. They then end up with a sub-par tool, because they wanted "one tool to rule all". If they only opened up to selecting multiple tools to get their job done, then they might have had tools that can perform all functions very well.

One thing that is important when selecting multiple tools for IT Operations management is that the tools provide a way of integration. I'm not saying that the tools have to directly integrate, but you need to be able to integrate the tools into your own process. Tools you select should have API's or SDK's that allow you to abstract needed information from the tool programmatically. This will then allow you to feed other groups' information to tools that they might use that don't have direct integration. This allows you to start aggregating information and getting more of an end-to-end few from apps to infrastructure.

I would love to hear from others on what they find important when selecting tools and how you managed integrating multiple tools into your process.

Level 15

Unfortunately, in all the IT environments that I have worked in there has not been an "overall" toolset implemented.  It seems that the overall business had some sort of ERP system and that the IT department had to use a separate tool for each area and try to bridge to the ERP but never actually making the integration.  I look forward to reading more on this subject.

Level 14

Before any tools are purchased, requirements need to be defined.  Prioritize those things of greatest need and focus your research based on those needs.  If money is tight, be sure to take a look at open source tools.

Level 17

Some of the most important factors we look at are scalability, ease of accessing data, and how it "fits" with the other tools we are already using.  If the tool cannot scale well with our growing environment, or if upgrading the tool is tedious in order for it to scale, then that is one roadblock.  If the data collected is not easily accessible, this plays a factor as we tend to use data from several tools to begin putting together an overview of the environment based on the information gathered over all tools.  If the tool only presents the same data we are already collecting with another tool, then it doesn't really fit into the need of the team, it's merely another place to see the exact same thing.  An example of this would be our use of VCOps with SolarWinds.  VCOps provides us a high level overview of our VCenters and ESX hosts, while the guest specific information and statistics are provided by SolarWinds.  This allows us to have a full view into our Virtual environment. 

Level 19

EOC, NPM, NTA, SAM, and VMan (VCOps as well) plus splunk seems to get the job done for me.  Also OpNet for DPI but I'm looking into using new NPM DPI to get rid of it maybe.

Level 13

I'd really like us to have more in this area. More visibility into our storage and virtualization environments would be helpful. Convincing the bean counters of this is always the hardest part.

Level 11

I'm going to have to look into these tools...very interesting management tools.

Level 11

It would seem that there are many tools, but only a few tools that do everything....and for all the "All in one" tools, they are subpar at their multitude of tasks. I don't believe there is really any all in one tool that would be great without having layers and layers of pointless functions/buttons/confusion...I like when a company puts their focus on one thing and does it the best. Thanks.

Level 12

I don't know that I believe in one tool for everything.  I think we're all accustomed to the right tool for the job, regardless of integration or fit with other products.  I like the flexibility of multiple approaches to solving a problem.

Level 14

Everywhere I have been, it has always been the same thing.  Purchase basic tools or tools for the most important things first, and then build from there.  Once the first set of tools is in place, then see what tools integrate with them or can add capability (non-duplicate).  Most places won't just throw all the money at a tool solution at once.  As the purchasing window is about to open, start doing evals to find the tool that best meets your requirements.  If an eval is not offered, it is probably not worth your time. 

Level 9

Scalability is very important, as I've seen a lot of the tools just fall over in large environments.

Level 9

Storage and Virtulization monitoring tools are necessity in most environments.

Level 9

I would agree with you on having a tool that has a focus area. I rather have multiple tools that do a great job, then one tool that is sub-par.

Level 9

great info

Level 11

great info

Level 17

You know things don't work like they used, or people for that matter. It's got to be more than your favorite vendor and their prime sales folks that roll through with that Amex for lunch card you so love. true investigation to determine the extent of use and full capabilities of your purchased tool should be the first step once you enter the market. The step before entering the market is critical as well. That step being, what are we looking for, what do we want it to do, how much should it do, what features can we not live without and what features we can live without until either the next revision or the next back-up / lay over tool is obtained. Big entities get silo'ed and tolls that should be doing lots either do remedial work, or go unused. Small entities have to pick one normally, with a backup being the open source or free option that does not provide much - but you end up sacrificing some of what you need due to budgeting/size/management's weird idea's/etc. I don't know of any mechanic that relies on a single tool to work on anything. In fact you could argue that as their expertise increases so does their Tool Set (comprised of Many). Sometimes all you really need is the tool, and the knowledge to use it. The work at that point does itself and you just guide.

The right baselines, architecture, insight, analysis and tool set. We can even go as far to say that tool set is composed of 1 or 2 main tools/components/apps, and a possible myriad of smaller supporting or simpler apps for drill down.

Level 11

NTA and NPM have been a big help in determining why a slow down occurs. We used to always get calls from an office saying they were slow and we never knew exactly why but with NTA we are able to help 90% of the time. There are times when NTA cant define an ip address but we still know what user is causing the traffic. This tool has helped us in so many ways.

Level 21

I think it's important to build a tools platform or framework.  Once you have that in place it makes it easier for evaluating new tools going forward as you can look for things that will fit well in your established framework.  It helps to have one person or team responsible for the management of said tools while making sure all the necessary teams have buy-in as you move forward with the acquisition and integration of new tools.

Level 11

When evaluating a new tool, whether it's as part of your existing tool portfolio or the new monolithic monster, always evaluate what it takes to get your existing data into the tool, what it will take to keep information current on an ongoing basis, and what people tend to forget, also what it takes to get the accumulated data OUT of the tool.

Too many times, the exit strategy is not part of evaluating a new tool.

Level 12

Agreed, you test with a small subset of your network and everything is fine, and when you go full blast then *BOOM*, everything falls appart.

Level 12

Not only do I agree with most of the posts so far on this subject from API's, responsible parties, strategy, and scope, but I additionally will add that I prefer the "single pane of glass" approach.  It is hard enough finding a tool that does exactly what you need, but to have it be able to interact with your other troubleshooting and analytical tools as well as "play nice", is an even better goal!  A goal I am still trying to acheive!  I went through an extensive eval years ago and the winner of the eval, which included live demos etc, was SolarWinds.  They are the meat of my toolset.  Their "single pane of glass" approach and subsequent acquisitions to the toolset they provide has made alerting, reporting, and troubleshooting Network, user, virtualization, storage, and other issues much simpler.  There is still no "all-in-one" IT Managemetn tool to date that I have found, but NPM, SAM, NCM, VNQM, LEM, Network Engineer's Toolset, VMTurbo, and Riverbed Cascade Express/Pilot/Shark have aided me tremendously in pre and post analysis for user as well as Network and server issues.  Also the reporting is greatly appreciated by IT and upper management within our organization.

Level 18

As mentioned before...requirements and scalability.

I tend to find "tool suites" to be a compromise in the functionality in order to gain better integration.

Past experience has led me to determine a framework with which you are going to support (Solarwinds, OpenView, Tivoli, etc) then

using a unified event messaging format (for scalability) , then pick your point solutions where needed.

Level 14

In my experience, the only way to get one tool to rule them all is to only go with the #1 or #2 provider for absolutely everything, regardless of whether they fit your needs.

But then you miss out on much more capable systems

A good example would be Palo Alto who have left Cisco in their dust, but are relatively new and have limited support in Solarwinds.

Level 12

we have a ton of tools in our arsenal we are not trying to find a way to combine them all into one.

Level 16

A key factor is availability of enterprise quality federal support.  Will all contact with the company always be through level one helpdesk personnel?  Will the salesperson managing the relationship be engaged and stay engaged while we work issues?

Additionally, customization is huge.  We live and die by custom property integration, and expect similar abilities in other enterprise monitoring tools.

Traps are heavily leveraged for integration into NetCool.