Going for Continuous Delivery with Commercial Off-The-Shelf Apps

no matter what kind of it applications you’re running, getting a feature, fix or change delivered to production successfully is, for more organizations, still a painfully slow, error-prone and expensive process. and as more and more of these apps move from being in-house “support services” to becoming your customer-facing presence, so this problem moves from being an in-house efficiency issue to one of business survival in an increasingly competitive landscape.

this transition is largely what has driven, and is driving, the rapid increase in adoption of agile, devops and continuous delivery . i quite frequently run into the misconception that the techniques and principles behind these initiatives apply mainly or only to in-house developed custom applications, but they’re actually just as applicable to other types of apps.

here, i’d like to talk about how we can apply some of the principles of agile, devops and continuous delivery also to commercial off-the-shelf (cots) applications…and reap many benefits.

cots challenges

before any misconception arises: delivering features, fixes and changes faster with cots systems is not easy. unlike in-house applications, over which you generally have a significant degree of influence, cots apps are typically “take it or leave it”, and are usually very complex and time-consuming to install and configure.

in consequence, companies typically have only a couple of environments in which the cots stack is running: perhaps one or two test environments, one qa/uat environment and maybe one more for pre-production (as well as, obviously, prod itself). these have usually been manually set up “at the dawn of time” – not infrequently by people who are no longer with the organization – and it is often impossible to reproduce their configuration accurately. and certainly not quickly or automatically!

bottlenecks as multiple teams wait for an environment to become available, time lost to finding and fixing misconfigurations, inexplicable differences in behaviour between environments etc. are pretty much guaranteed.

why “bottom-up” automation is the wrong approach

obviously, teams managing cots applications are well aware of this problem, and many of the ones we speak to are trying to automate the provisioning of their cots stacks to give them more flexibility.

when we talk to such teams, it’s pretty common to hear them taking a “bottom-up” view of the problem: first create the virtual machines, then configure the os, then install any prerequisites, then the cots app, only then add any standard company-specific configuration and finally deploy a bit of business logic and associated configuration.

this is a natural enough approach if you’re thinking about the whole cots stack as “one big blob of code and config”, but this is not generally the most effective way to think about it if you’re trying to focus on maximizing business value .

consider these three observations:

1. the “top layer” – the app-specific business logic and config, and to a lesser extent the shared company-specific configuration – is where the majority of the business value lies
2. the top layer is contributed by one or more groups often distinct from the group managing the “bottom part” of the stack
3. the top layer will change independently of , and far more frequently than, the bottom part of the stack

accelerating the business value layer with xl deploy

in order to get maximum acceleration and business value out of your agile, devops and continuous delivery initiatives for cots, you need to focus on automation that makes the top layer of your cots stacks – the part that actually differentiates your company from your competitors, the part that your customers interact with and derive value from – portable. this is exactly what xl deploy and similar tools are designed for.

introducing a deployment automation tool like xl deploy to manage the business value layer of your cots application allows you to do the following:

• the cots infra team can concentrate on the “bottom part of the stack”: on providing a robust, versioned standard install that can automatically be provisioned in a virtual or cloud environment.
  there should only be a very small number of such “standard installs” that need to be supported at any given time, allowing the cots infra team to focus on more important tasks such as optimizing your customer-facing production installations.
• the less customized this bottom part of the stack is, the more options you will have to move some, or even all, or your environments to saas providers or other externally-hosted options.
• this will make it much easier for you to spin up as many environments as needed for the teams working on the business value layer, thus eliminating resource conflicts, configuration “bug hunts” and other current pain points.

result

the result? the bottlenecks that plague feature/fix/change delivery in today’s cots environments are largely eliminated, allowing the business logic teams to work much more efficiently.

automation of any kind will help with this, but introducing tools that specifically focus on the business value layer adds a key additional benefit: by splitting the top layer from the commodity part of the stack, you can test and develop features, fixes and changes much, much faster. modifying the top layer of a cots stack is much quicker than having to provision a whole environment from scratch.