One of the trends being discussed in business, among vendors and in the analyst community is the importance of automating the functions performed by IT. Growing demands by the business, tight budgets and compliance pressures together accentuate the need for IT to be more agile, efficient and responsive to business stakeholders.
Naturally, vendors rush into this environment, each touting the unique benefits of its solution set and the urgency to move forward immediately. A key area targeted for IT automation is the area of ‘configuration management.’ As it relates to automating day to day IT functions, configuration management can mean many different things: patch management, server and network management or others.
One of the newer targets for configuration management techniques is the application layer itself. Think about that great stack of software that comprises a contemporary J2EE application—application server, web server, database, middleware and so on—typically from different vendors. But they all adhere to industry standards, right? So they all must plug and play together nicely, right? Not really.
In fact to make the entire stack work effectively, there are many individual configuration files, each one with a long list of their own parameters, which need to be edited, tuned and controlled. And because the set of software is so complex, each element is managed by its own specialist in isolation without much knowledge of the other pieces of the puzzle.
The combination of many software assets, configured manually without much knowledge of dependencies leads to predictable results. Someone makes a change in one area while stability and performance problems show up elsewhere. Once the problem crops up, a team of IT specialists will take hours, maybe days to track down the problem and provide the solution. Analyst firms like Enterprise Management Associates and Forrester Research agree problems in the configuration of the application infrastructure are now one of the leading causes of downtime.
Some vendors and businesses are now focused on a comprehensive approach to tackling this problem. The five building blocks required are easy enough to understand:
- Discovery and mapping —What application element and software assets do I have in my environment? How are they configured, item by item?
- Change monitoring —Inform management not only about the applications that have changed, but tell them how they have changed.
- Release Management —Sometimes called ‘provisioning,’ this relates to the ability to model configuration changes to the application infrastructure and then deploy those changes consistently across all phases of the application life-cycle.
- Auditing and Reporting —Show the business that IT supports corporate governance initiatives, not only at the server and network level, but also at the critically important application layer.
- Integration with the IT environment —Insure that the tools for configuration management of the application infrastructure work seamlessly with your problem management system or your configuration management database.
1.‘Discovery’ is usually where these solutions should start—as long as they do not end there! In order to provide the IT team with a solution to managing the thousands of configuration settings in a J2EE application stack, you need to have a repository of the environment itself, a working model that reflects your application infrastructure. With this repository of data in place, IT can then begin to comprehend how the various elements on the application layer are actually configured. More important, IT can begin to understand the dependencies between, say, how the data base is configured and its impact on the application server. Thus, application configuration problems can be averted before they arise.
2.‘Change Monitoring’ represents a critical component of a configuration management solution for application infrastructure. With so many servers, instances and individual parameters, the number of configuration items quickly runs to the thousands per application.
Change monitoring must identify not only that a component changed, it must also identify exactly where the change was made and on which server(s). Right now, IT specialists comb through text files trying to figure