Continuous Delivery (or putting agility back into SOA)

One of the key principles of SOA is that systems are no longer built to last, but rather built to change. 

The promise being, that if you follow SOA principals, it will not only enable you to more rapidly implement new solutions through re-using existing functionality, but also reduce the time it takes to modify and adapt existing SOA based solutions in response to ever changing business requirements. 

Being able to adapt to changing business requirements is not only important once a system has gone live but is equally important during development. Too often projects experience significant delays due to changes during implementation; a SOA-based approach provides a way to manage this change and help mitigate the risk of project delayed due to change.

Yet, the reality is often different. Often we come across projects that are struggling to get from development into System and Integration Testing (SIT), or beyond SIT into production.

As Jez Humble puts it in his book Continuous Delivery

the most important problem that we face a software professionals is this: if somebody thinks of a good idea, how do we deliver it to users as quickly as possible?

Now if we follow SOA principles, then the design and implementation (i.e. writing code) should be optimized, however what SOA doesn't address is how we build, deploy, test and finally released that code into production. 

And this seems to be an area that has been largely ignored by the vast majority of SOA projects, which are still following a manual, resource intensive and highly error prone process that requires someone to piece together all the relevant components, compile and package them before deploying the end result into a test environment; and then run a series of tests to validate the build. Once over this hurdle the next step is to deploy, configure and test the build in each environment that it must progress through before it reaches production.

We’re not making this statement likely; at Rubicon Red we have had the privilege of working with over 100 Oracle SOA success stories, including helping to rescue many failing projects. This gives us a pretty big sample in which to gauge the overall level of maturity in the industry when implementing SOA projects. 

In addition, we have recently run a series of workshops entitled “Breaking through the SOA Glass Ceiling” (we are planning another series so let us know if you are interested in attending). One of the biggest issues that customers were facing was the complexity of deploying a new release into production (another being to successfully manage and monitor a solution once in production).

At the core of the issue, was the resource intensive nature of building and testing software, meaning this tended to be carried out infrequently, so often developers would work in isolation for days, weeks (or even months) before integrating different components. 

The result? 

Code shared between multiple people and frequent changes often introduce a lot of integration complications, dependency bugs etc. The longer these bugs remain undiscovered, the more effort it takes to troubleshoot and fix, resulting in significant project delays.

Yet, continuous integration and testing (the first part of continuous delivery) has shown to reduce  the risk of project delays, providing better visibility into the overall progress and state of the software development, as well as less issues once deployed into production.

It has also been shown to provide a significant return on investment, due to the impact of finding and fixing integration bugs early in the development process; which saves both time and money over the lifespan of a project.

It is precisely for these reasons that continuous integration and testing as a practice is being widely adopted within the software industry; so you would expect that with SOA which is all about integration to be at the front of the queue!

Now Rubicon Red was founded with the vision of providing Oracle Fusion Middleware customers, a robust SOA adoption methodology incorporating agile development and KPI based governance. So the establishment of best practice around Continuous Delivery has always been a central pillar in our strategy.

We have been using Continuous Integration and Testing internally for some time now, and have extended our platform to provide support for Continuous Delivery. We have recently introduced this to a number of our customers, and the feedback has been incredibly positive.

So much so, that one of our customer suggested that we write a series of blogs about what we have done, to hopefully inspire others as well as share some of the lessons learnt. So expect to see a few more blogs on this topic over the coming months.

In addition, I would love to receive feedback from anyone else on this topic. Particularly if you are implementing (or at least trying to) CIT or Continuous Delivery, what are some of the obstacles you have faced (both technical and organizational) as well as any tips you have to succeed. Many thanks. Matt