Imagine for a moment that you’re a software developer who has been charged with adding a new feature into your company’s billing system application that allows bills to be automatically sent to customers via email. You spend weeks, possibly months, working on the new function, and then at some point you move to the unit testing phase. You set up an environment, configure the product with the new feature, and then you run tests to verify that emails with valid billing information are indeed being sent as expected. Once you’re satisfied with the unit testing, it’s time to hand it over to the testing team so they can put it through the paces.

At this point you have come to the time dreaded by just about all teams involved in the application development lifecycle: The Hand-Off.

If any of you reading this have spent time in software development, you’ve undoubtedly dealt with the hand-off that occurs when one team officially passes on new versions of an application or software package to another team. These hand-offs occur between many different teams including development to test, test to QA, and QA to production, but no matter which teams are involved the room for error during these transitions is typically quite large.

So why is this period in the application lifecycle so difficult and error-prone? Well perhaps the biggest reason for complication is that the team that is handing off the updated application must explain, document, or otherwise express the parameters within which the application is expected to work. In an application environment, this means accurately describing the application server topology, application configuration, application dependencies, and more.

If one element in the environment is not precisely and accurately described, then the behavior of the application can be radically changed. In the example above, consider that an SMTP server hostname is part of the application configuration. In your unit testing environment you’ve obviously configured it correctly because you’ve already verified emails are being correctly sent. However, when you hand over the application to the test team, what happens if they make a simple typo when configuring the hostname? How long will it take you or another debugger to track down the reason why all of a sudden emails are no longer being sent?

That is certainly a simplified example, but the point is as developers, testers, and administrators, how much of our time is spent tracking down “bugs” that are really caused by inconsistent configuration? I know I spent quite a bit of time tracking down these types of bugs while I was in development, and I’m pretty sure that if you are in software development that you have too.

So then, if the discussion above is about the problem, what’s the answer? Obviously the answer is that companies need solutions that allow them to internally standardize, preserve, and share application environments and application configurations. If you take a look across many different cloud solutions, this is a problem that many of them attempt to address in some form or fashion. This can be done by allowing the creation of custom virtual images, custom application stacks based on virtual images or simply by allowing sharing and collaboration of application configuration files.

For us in IBM, we’ve tackled this problem by allowing customers to build, deploy, and share patterns with the WebSphere CloudBurst Appliance. Patterns are complete representations of application environments that include the application server topology, configuration, and even the application. These patterns can be built, improved and hardened over time, and shared across an organization. Members of different teams can use and deploy the same patterns, thus ensuring that the resulting application environment is consistent across the different contexts of an organization. In short, patterns provide consistency and repeatability with respect to a company’s interactions with their application environments.

If you want to read more about WebSphere CloudBurst patterns and their role in building up customized application environments, take a look here or watch some of our demonstrations here. Regardless of whether or not WebSphere CloudBurst is right for your particular needs, I’d encourage you to look for solutions that provide capabilities to standardize on and share application environments across your organization. After all, less time spent tracking down pesky configuration errors is more time spent developing and adding new value to your products.