Today, even entry-level servers are virtualized to handle multiple workloads with ease, forcing systems administrators to get more insight and exert greater efficient control over the hardware environment. And so the choice of hardware platforms is quickly being overshadowed by the choice of systems management platforms.
But a single systems management tool can present limitations for the data center. It might not provide the detail, control or planning capabilities needed for all of the systems in service, and this can drive the adoption of multiple tools, or a shift from one systems management tool to another.
This month, SearchDataCenter.com asked Advisory Board members to discuss the factors they see behind systems management tool changes, how organizations should approach a change, the most important precautions to observe when implementing a change, and the potential problems to avoid.
Robert Crawford, lead systems programmer and mainframe columnist
I think integration is the biggest driver toward changing or consolidating systems management tools. Today’s corporate systems are complicated–the simplest transaction might cross several applications, networks and platforms. To deal with performance, address problems and handle change and configuration management, an enterprise might seek one tool that accommodates the end-to-end environment and presents a consistent view across the chaos.
the tool can be difficult enough, as everyone will want to include their pet item. However, all the participants in the decision should know that the choice of any tool will be, at best, a compromise, and a few features and functions may have to wait. If compromise fails, executive management should be on standby to serve as judge and referee.
After choosing a systems management tool, there should be a period of intense planning that takes into account all the known issues. Change migration should occur incrementally in a way that does not jeopardize the enterprise.
Before buying a systems management tool, IT should be well aware of its limitations. Although there may actually be some “one-size-fits-all” solutions, technicians should be very skeptical of 100% solution claims. If the selected tool doesn’t provide 100% coverage, there should be careful scrutiny of the number and types of interfaces it may have available to connect disparate systems management disciplines.
The technical issues are tough enough, but the political implications may be even worse. Most mature enterprises have islands of system management tools, selected long ago by independent departments with their individual requirements. Over the years, some technicians have become very fond of these tools and are reluctant to let them go. Maybe the best approach is to convince the majority that a change is needed and, in the long run, the change will be for the better, even if it means learning new software.
Bill Bradford, senior systems administrator, SUNHELP.org
When it comes to changing tools, the number one factor I'm seeing right now is cost. Free and open source systems management tools are growing in complexity and features. Along with the growth in features and capability, the user base of those tools grows along with them. This growth results in scripts, plug-ins and other utilities that make an administrator's job easier. That larger user base also means more support! If you can find the answer to a problem in a frequently asked questions, on a webpage, or via an Internet relay chat channel, that's yet another support contract that doesn't need to be renewed.
Approach any change slowly and carefully. Use test environments, have a clearly defined set of required features and test against the list of requirements. Treat systems management tools just like any other critical part of infrastructure, no matter how much it costs. Just because it's free doesn't mean it's going to be easy (at first). Treat the migration like any other big project.
Before you even start a migration from one tool to another, make sure that the new tool does everything you need. Test extensively and ensure that your staff is trained and comfortable with the new software. The worst way to do things is to surprise people with a new interface for systems management first thing on a Monday morning.
Bill Kleyman, virtualization architect, MTM Technologies Inc.
There may be several reasons that drive a company to switch its management software. These reasons range from data center expansion to dissatisfaction with the current solution. Either way, working with some type of system management tool is necessary. Sometimes a system outgrows the toolset available to manage it. This is a natural process of infrastructure expansion, and it demands a systems management product capable of scaling alongside the environment.
One of the best pieces of advice when beginning to look at a new system management solution is to have patience. Since this becomes such an integral part of your system, proper planning, testing and feature exploration must occur. This type of project can be a serious undertaking, so make sure there is a clear need for a change. When approaching a possible change, be ready to examine several products while conducting a few proof-of-concepts (POC) deployments. With a POC done, an organization can see the various benefits of a few solutions and make a better decision on how well this management tool can handle a growing environment.
Never act too quickly when making a decision to change your system management software. A good POC analysis can take a month or more. For example, if an environment has a new solution in place as a pilot, take the time to gather proper metrics and document the product. Fast decisions can lead to serious system management incompatibilities. One of the last things any organization needs is finding out one of its devices is not supported by the software. By understanding and knowing where the organization stands and where it plans to take the IT infrastructure, IT managers can make a much more educated decision in their system management solution.
There are many different system management tools available on the market. Since every environment is unique, selecting the right product is imperative. Whatever the product selection, make sure that this tool is able to perform all (or most) of the functions that will be required in the environment. Remember, environments constantly evolve. Therefore, any management solution must be able to also evolve and scale to your infrastructure.
Robert Rosen, CIO, mainframe user group leader
I don’t see a lot of systems management changes because of the amount of investment made. The only time I’ve seen a change is when the product just doesn’t do what they have a critical need for it to do or it has become too expensive.
When approaching a change, focus on training–you can’t have too much. It often helps if you can hire a consultant who is an expert in the tool to help you in the transition and setup of the new tool. Make sure that any consultant has a good track record in knowledge transfer, because you don’t want to be dependent on the consultant for ever.
One of the first precautions is to make sure that you really need a change in the first place. I’ve seen cases where a company decided to change, because their current product couldn’t do a critical function. It turned out that the product could do it all along, they just didn’t know it. The next precaution is to plan, plan and plan some more. Have a back out (or rollback) plan also. Communicate the change to all stakeholders. Expect and plan for failures.
Remember that deployments may take longer than planned, expected benefits may not appear immediately (if at all), and a lack of knowledge in the new tool causes problems. You can mitigate these issues by planning, training and making sure you have really thought through the process. Know what to do when failures occur, and treat the transition as if your job depends on this being successful, because sometimes, it does.
Chris Steffen, principal technical architect, Kroll Factual Data
The factors pushing an organization to change systems management tools include cost of management, return on investment, ease of use (part of cost of management probably) and the desire to manage through a single pane of glass.
When approaching a tool change, start with a very detailed set of expectations of new tool deliverables. It’s very likely that the organization will need to operate both the old set of tools and the new set of tools, so there will be a learning curve for the entire IT staff.
I don’t think you should hire a third-party consultancy to set up the tools for your environment. Instead, make certain that the group currently managing the old toolset is setting up the new ones. This gives the tool owners experience with the new tool, which will prove invaluable as the management tool environment matures. Also, if the new management system is so difficult that you do not have the expertise in house and requires a third party to set it up, you should probably re-evaluate whether you should use that tool. It should not be so complicated that you have to hire a consultant every time you want to make a change to the system.
There are other precautions to consider when changing systems management tools. One issue is “scope creep,” where C-level executives will think that a new management system will be the solution to all that ails them, and demand so many "changes" that are untenable with the new system. Make it very clear exactly what the system can and cannot do.
Also, be sure that the new tool can do everything that is needed. For example, the vendor may claim that a particular system or device is supported, but is it really? Most third-party management tools will support the basic feature set of a particular device, but some of the more advanced features may not be supported. Talk with the tool vendor and the system/device vendors beforehand to discuss support, and test carefully before committing to a new tool. Expecting it all to work after the final install without the confirmation of functionality prior to the decommissioning of the previous tool is unreasonable (but happens all the time).
There are other things to consider. For example, have realistic expectations of what the new tool can accomplish. It is probably unlikely that the server or router manufacturer will want you to abandon their proprietary tool for a more generic third-party tool, but you can usually accomplish most of the things that you need to with the third-party management system 80% of the time. The other 20% of the time, when your senior team makes server or router upgrades or configuration changes, you may need to pull out the proprietary tool to drill down to the nitty-gritty.
Don’t expect to abandon the individual proprietary tools entirely (certainly not overnight). And don’t relax your upgrades or maintenance on those tools just because of a purchase of a third-party systems management tool. Have continuous checkpoints for as long as a year after the completed install of the third-party systems management suite to figure out which proprietary tools are still being used, how often they are being used, and identify any major gaps that exist with the systems management solution. Once those gaps have been identified, share those gaps with the systems management tool and system/device vendors. Often, device manufacturers work with the management system vendors to improve their tool integration, and that is exactly the kind of feedback that they need to hear.
Finally, work with the systems management vendor to improve their product. There is no possible way that the vendor has accounted for every variable of every environment that its product is going to be installed in, so they cover most of what they believe are the common issues that a traditional IT shop will face. The same is true with configurations and with vendor partners. A good systems management solution should be in constant revision–it should be a very large red flag if it is not. Get involved in beta or evaluation programs, and ask your device vendors to do the same.
Planning and testing
The move from one systems management tool to another can be a difficult and traumatic experience for organizations caught unprepared. The most successful transitions occur only after careful product evaluation and POC efforts take place. A well-planned deployment must be followed up with clear post-deployment monitoring and feedback to both systems and management vendors.