As with all technological processes, an effective configuration management (CM) process needs much more than just...
money for configuration management software -- it also requires a change in how people within the organization work and a change in the processes used in the packaging and implementation of code into the IT operations environment.
The biggest issues tend to revolve around cases of not invented here syndrome. Current processes around CM will generally involve highly separated teams of people (e.g., developers, testers and operations staff) who will have built up their own sets of tools. The tools selected by each group meet their own needs and provide the best solution for their immediate problems.
However, the CM process should involve all teams, which makes problems apparent. The tools that developers use do not provide the testers with enough information on what has been done; the operations staff has little to no visibility into what has happened in either development or test. Problems that should not be there in the first place devolve into it's their fault arguments that do nothing to help the business.
Therefore, the disparate teams need to be pulled together, and the tools chosen to manage the end-to-end configuration management processes must be inclusive and enable full collaboration between the groups, while enabling them to continue to use their own point tools where this is necessary.
How to select configuration management software
This means that the chosen configuration management software must be open and flexible; it must be capable of easily integrating into other tools while maintaining full details of activity along the complete process. A key part of CM is feedback loops -- problems identified in operations have to be fed back to the developers effectively and rapidly, along with details of how important this issue is to the business. This requires the CM tools to tie into the help desk -- this is where the real scale of problems with code in the operational environment can be best seen. Developers then must have to deal with issues that are the highest business priority -- rather than issues that are the most technically challenging.
The next factor to consider in selecting configuration management software is the complexity of the organization's IT platform. If the organization is small and only has a few tens of applications running, a reasonably simple set of configuration management software will be adequate. However, larger organizations with hybrid platforms and thousands of applications will need a set of tools that are not only fit for purpose now, but are also capable of embracing changes in the IT platform down the line.
Look for configuration management software that is already capable of adequately dealing with applications and functions residing on public clouds as well as physical platforms and private cloud. Ensure that tools work with virtual machines as well as containers. Talk to the vendor about where they see the IT world going, and what plans they have in place for the future. Those that effectively just say "we'll be doing more of the same" will be the vendors that are likely to struggle as IT continues to change. Look for vendors that have a vision that they can articulate fully and effectively.
Cost is always an issue, and it's no different for configuration management software. However, there is a cost to doing nothing, and a cost to doing something to a suboptimal level. Estimate the true impact on the business of poorly implemented applications and functions. Create a balanced argument that looks at the actual cost of the configuration management software over its lifetime against the value that it will provide to the organization. Do not just go for the cheapest option -- this generally ends up being the most expensive option when everything is taken into account.
Is your IT platform homogeneous or heterogeneous? If homogeneous, is it likely to stay that way? If so, choosing a set of CM tools that focus on that particular platform -- whether it be Windows, Linux or any other -- would be more valuable than going for a set of tools that are built to support a heterogeneous environment.
However, if you're working against a highly heterogeneous environment, it's unwise to go for a collection of specific tools targeted at each platform. In order to maintain full visibility of the overall IT platform, tools that manage a heterogeneous environment are advised.
Open source tools vs proprietary tools
The complexity of the tools themselves can be daunting. Consider the existing and future skills base in the organization. Is the staff highly technical; capable of using script languages and writing code in, for example, Ruby, Python or Bash? If so, and if this is likely to remain the case for the foreseeable future, then open source configuration management tools may be a good option for your organization.
If there is a noticeable drain in the technical capabilities of the IT team, or if the organization is aiming more toward an IT as a service model, then commercial software with highly visual graphical user interfaces that hide the underlying complexity of CM would likely be suitable for your company.
Open source configuration management tools, although free of a licence and maintenance charge, are only effective as free tools if you have the skills to maintain the tools and to fully understand how they work. Most organizations are better served by going for an open source subscription model, where a technology vendor provides enterprise-level support for the open source configuration management tools. This is how Linux managed to become a major force as an operating system -- the last thing you want for your organization is to end up with a highly modified open source platform that becomes unsupported and unsupportable.
This brings us to customization. Many IT teams have become too accustomed to taking a base technology and modifying it to suit their perceived specific needs. In reality, upward of 90% of processes within an organization -- not just IT -- are basically the same. The ultimate aim is to make the processes more effective and more efficient -- and this is where configuration management software packages provide the automation capabilities to make this happen. As soon as the tools are customized, the platform becomes nonstandard which ushers in additional risks and costs. Tools should only be customized where it is completely necessary and at an abstracted level, so that any changes (e.g., patches and upgrades) to the base tools can still be implemented without the customization impacting these necessary updates.
With the breadth of CM tools available on the market, whether they are proprietary or open source configuration management tools, possessing a reasonable set of objectives helps to narrow down those tools that should be on your list.
Read about Ansible's newest configuration management tool offering.
Find out if your enterprise needs configuration management and how will benefit your company.
Learn why the configuration management process is so vital for organizations today.