application and the associated configuration files arrive at the next stop in the lifecycle, the configuration files need to be modified to accommodate the differences in the new environment (hostnames, port settings, etc.). While this is a good step toward ensuring a more accurate application environment, the fact that manual edits are involved still introduces a tremendous risk of human error.
And finally, let’s say your infrastructure team has gotten around the problem by writing some perl scripts to automate the deployment of the configuration files and make the changes to accommodate the differences in the environment. What happens when a new version of WebSphere, WebLogic or JBOSS comes out? The scripts most likely have to be rewritten. This solution might work while the number of machines, app server instances and layers in the infrastructure are relatively small, but will it scale?
Enter Application Infrastructure Configuration Management
Application infrastructure encompasses the tools, products and servers that run, support and maintain the operation of an application. Obviously, application servers such as WebSphere, WebLogic and JBOSS are the most common infrastructure elements that require configuration management. However, anything in the environment that has configuration files or settings associated with it, falls into the category of "Application Infrastructure." While the application itself is not considered part of the infrastructure, all artifacts containing configuration information about the application are.
With so many elements requiring configuration management, it raises the question: Who in IT would actually use an AICM solution? While the answer to this question will vary widely among IT shops, the general rule is this: any person that either creates or manages configuration data should have access to AICM tools. This includes developers and infrastructure teams (in both pre-production and production phases of the lifecycle).
In many shops, most of the infrastructure - including systems in the development environment - is guarded zealously by infrastructure teams who would never allow developers to make changes. However, if they are to overcome configuration-related application problems, these organizations must change their culture and allow developers to adjust configuration artifacts if necessary.
AICM solutions eliminate the need for infrastructure teams to be so stringent in their practices, because they provide built-in work-flow capabilities that ensure proper processes are always followed. This enables developers to make required changes in the configuration model, and then send those changes to infrastructure teams for approval and deployment.
Where Traditional CM Tools Fall Short
At first glance, AICM appears to be similar to software configuration management (SCM); controlling, versioning and grouping software-related artifacts, and providing the capability to build processes around them.
While they are similar, SCM and AICM are not the same. To illustrate the difference, consider the evolution of Web content management. We all remember in the 1990s when SCM vendors made a mad dash to the perceived lucrative field of content management. And, we all remember how they fell on their collective faces by trying to address SCM and content management as similar problems. A billion dollar industry did spring up around content management. But it was new companies like Interwoven and Vignette that dominated the market, not retro-fitted SCM solutions.
What these SCM vendors failed to realize was that although the core repository was the same, the contributors and consumers of Web content had a set of requirements that were fundamentally different from those of software developers. The reason that content management vendors like Interwoven and Vignette were successful was that they crafted a solution from the ground up with the specific requirements of Web content contributors and managers in mind.
AICM at its core looks like it