Friday, June 22, 2007

Offsite Development and Maintenance of Corporate Applications

Offsite development and maintenance of corporate applications is a reality today. Sure IT organizations are still developing and updating some business critical applications internally but the cost for such development activities are rapidly becoming prohibitive.

Outsourcing has gotten a bad name lately, not because outsourcing is inherently bad, but rather because most IT organizations have handled it badly. Most IT organizations are a captive of their day-to-day operations and really lack the time and skills to disentangle their applications and development/test environments from their infrastructure.

If the IT organizations wishes to outsource their application development, updates or maintenance activities to an offsite development group (even an internal one), it takes months and months to prepare such an endeavor. By that time, the benefits of leveraging offsite or outsourced application development expertise can many times outrun its projected labor and cost savings.

How would you streamline offsite development? How would you turn offsite development into a rapid offsite development process? You certainly don’t want to spend months or years defining such a strategy. If your application, development and test engineers are tied up in such an activity, they are most likely not producing any really worthwhile enterprise deliverables.

Cloning the application, development and test environments is the easiest way to accomplish it. Yeah, I mean simply clone the entire environmentso that the offsite development team doesn’t have to reinstall everything and they can run the environment on commodity hardware or any virtualization environment such as VMware.

Look, I don’t mean simply ghosting an entire server or workstation. Ghosting requires that the hardware profile between the source and target server must be the same or very similar. You want to capture and clone only the necessary parts of the applications and their development/test environments. Ghosting takes everything and usually takes more time than simply re-installing. It’s painful.

Conversely, the offsite development group could return the cloned application with the new functionality or updates applied. Since they had the cloned environment, they would already have run exhaustive unit, functional, system and integration tests. Hence, it would be easy to accept the updated cloned application back into the production environment.

I know that Trigence has a solution that allows an IT organization to capture existing applications and complex development/test environments. Once they’re captured, they become clones of the existing corporate environment. Trigence calls this process encapsulation.

Encapsulation is an activity that captures the application and its dependencies and places them into a capsule. A capsule is a secure and separate environment that effectively “decouples” the application from the operating system and the underlying infrastructure. A development and test environment is a quasi-application that can be encapsulated in the same manner.

Encapsulation also gives you a granular means to select the application and parts of the development and test environments that you really need.

Now it’s easy. You clone the required application and their corresponding development and test environments. If a new application is required, a baseline capsule can be created that includes the standard corporate framework required for all new application development. The offsite development group then has a known baseline from which to start.

These capsules become deliverables that the IT organization ships via standard storage devices. The capsules that contain the applications and the development/test environments are delivered to the offsite development location. Any system administrator can perform the encapsulation activity so the corporate IT organization doesn’t need to engage their application, development or test experts. The encapsulation process could take hours as opposed to weeks and more likely months. Some IT organizations have simply given up trying to perform this activity.

The offsite development group can then easily install these Trigence AE capsules since they come as a single compressed file. They simply expand the capsules and start the application and development/test environments. Again they can run these capsules on commodity hardware or any virtualization solution that they have on hand.

You can add context or update any existing propriety, file or directory in a Trigence AE capsule so all changes are made from the original cloned capsules. The offsite development group can clone the application capsules as many times as necessary in order to run exhaustive testing. The newly cloned capsule can be thrown away should the test fail or somehow corrupt the application.

Furthermore, any changes made in a capsule can be discarded as required. This allows users to create snapshots of the application and then restore the application to any previously created snapshot.

Once the application development efforts are complete and certified via comprehensive testing, the application is delivered back to the IT organization with all the appropriate updates, modifications or new functionality. It’s easy to reintroduce the application as a capsule back into the production environment: restore the compressed capsule, start it, perform a minimum set of functional, system and integration tests and accept the delivered application (that is, the capsule) into the production environment.

Trigence really has made Rapid Offsite (and/or Outsourced) Development a manageable, cost effective reality.

No comments: