For any good developer, applications are like children. You spend countless hours nurturing them and preparing them for the real world. Sometimes they frustrate you, other times they give you tremendous pleasure. And in the end, you’re just downright proud.
You eagerly anticipate the day when your application can leave the house and enrich the world. But when that day comes, that’s not what happens at all. Instead, you get an angry phone call, because your application isn’t enriching anyone. In fact, its poor behavior is causing dread and anguish in your IT department. You’re accused of being a lousy parent. And you can’t believe your ears, because your application passed every test with flying colors before you unleashed it on the cold, hard world.
The problem isn’t that you’re a bad parent. In fact, you prepared your application to perform perfectly in your own environment. The problem is, when the application left the house, it was faced with foreign environment for which it was totally unprepared. As a result, it did not function as an "upstanding citizen" within that environment and became a problem child.
For developers of J2EE applications, this is an all-too familiar scenario. Your code is perfect, but the infrastructure team hasn’t configured its production environment properly, so it does not match the configurations in your development environment. As a result, your application misbehaves and has to be taken off line. It’s not your fault, but it is your problem.
To date, reconciling configuration settings has been a manual process; one that is error prone, resulting in application downtime and massive consumption of IT department resources. It also is a constant source of friction between developers and infrastructure teams.
Many IT organizations today are eliminating these issues by implementing new automated Application Infrastructure Configuration Management (AICM) solutions. These solutions impose strict configuration-management discipline on IT personnel across all environments - development, test, certification, production and hot standby - so that applications always behave the way they should.
The first step on the road to stopping applications from being deployed into improperly configured environments is admitting that the problem exists. Unfortunately, many organizations continue to live in denial.
The reality of J2EE development is that sending the application itself out into the real world is never enough. In order for it to behave reliably and predictably, you must also provide very specific instructions on how to configure the environment in which it runs.
Feel like you’re doing that already? Then why do your infrastructure people call you all the time complaining that your child is incorrigible?
If you have a good release process in place, you probably already have a method for capturing configuration settings and passing them along to players in the process downstream. This method can be as simple as a spreadsheet that describes various property settings, release notes, or some other document that describes configuration settings.
One problem with this approach, however, is that it still relies on human beings to translate what is in the document to what is actually configured in the application environment. As we’re all painfully aware, humans are an error prone species. And as long as we rely on humans to manually input and manage configurations, there are going to be frequent configuration errors.
A second problem is that this method relies on you, the developer, to update the documents that describe configuration and keep them accurate. With application environments becoming more complex, the opportunity for "fat fingering" configurations grows exponentially. Furthermore, even if you deliver a perfect configuration document, someone downstream is likely to screw it up and point the finger of guilt at you anyway.
In rare instances, developers pass along the actual configuration files they used during testing to drive the application environment. The problem with this approach, however, is that even when the