Global SOA - Quality = A World of Trouble?

We have a customer who was a highly advanced and ambitious early adopter of Services-based applications. Prior to adopting some of our best practices and our product for continuous testing, they had come to the point where their Services Group (a shared services team that was the producer of a set of services for an entire division of a company) had to go to an annual release basis.

Much worse, because of the fact that there were so many applications built on top of the shared services platform, and they were so distributed globally, they really couldn’t keep their hands around everyone’s use of these shared services.

They had to make a hard stop on November 1^st of every year, and go into a 6-week procedural test cycle, where any failure anywhere within the entire division would stop the rest of the division from being able to complete the test cycle. And, upon completion (hopefully in that six weeks) to find what could run for that month’s test cycle, finally release all the upgrades to not only the shared services that were built that year, but all of the applications that were depending upon that shared services platform.

Now, hopefully, that gives you some insight into what happens when you try to go to a services approach, but you don’t marry it with very rigorous and continuous automated testing. At the heart of the matter for these guys, SOA lifecycle quality was the missing piece.

When you have a shared set of services being leveraged by a variety of consumers across the globe, the changes that are seemingly irrelevant almost, at the shared services level, can have a catastrophic effect on the applications that depend upon them. The worst part is that the developers of those shared services may not even be aware of the potential catastrophic effects of their application cycles on the service consumers.

All it takes is once or twice of having those unintended consequences show up as huge performance issues, or as huge production outages, or, my worst nightmare, actual bad functional integrity where the business is actually getting the wrong answers (I don’t mind slow answers or no answers -- but wrong answers are worse). No one is sitting with a calculator beside their computer verifying all of the transactions that the system is doing. So if the global system is doing them wrong -- you are in a world of trouble.

So what they had to do was coordinate the release of every one of these applications within this very large division of a large company.

With our solution, taking some good SOA best practices, and using LISA from a continuous testing/continuous integration kind of basis, they are now going to be able to start dismantling this annual release cycle. As they increase the level of automated coverage of shared services and of the applications that depend on them; they have the freedom to change without the unintended consequences catching them off-guard.

So, in a nutshell, continuous SOA Lifecycle Quality testing to prove functional integrity has huge returns for the business. They see the value of going from an annual Big Bang release, to more quarterly releases, then monthly releases or “as needed” releases so that they can realize the agility they expected from SOA, with the reliability required for business.

- John Michelsen, Founder and Chief Architect, iTKO