WebServices dot org

The Continuous 'C'

Several weeks back I gave you a real life experience that typified why our test strategy we call the Three C’s has Complete as one of those C’s. This blog will give you a different real-life experience on why Continuous deserves “C” status.

I was meeting with a Director of development at one of the worlds largest financial institutions. Many of their trading applications have absurd levels of complexity and variability along with, of course, radical performance expectations. Really cool stuff.

A certain critical service was running on a major SOA platform. The vendor released an update to that platform, and the team responsible for this service ran their unit and service level tests -- doing more than most teams I’ve seen. Turns out, they all passed, and in fact the service performed its main function 12 milliseconds faster -- COOL!

Then again, maybe not.

They deployed the patch and watched their entire currency trading system grind to a near halt!

Wait, you sped up the service and slowed down an application? Yes. Turns out the performance of the service prevented timing issues in the orchestration layer from surfacing in use by an application.

Of course it wasn’t obvious to the team that this was in fact the issue -- they were blaming the vendor, then their new code changes looking for how they could have wrecked the performance. They went on for days losing millions until they figured out what was really happening.

The Continuous C solves for this type of problem. Take those same tests you would automate at the orchestration and solution levels and run them on a continuous basis at those points of integration, pre-production. You’ll get immediate notice of this type of issue along with much clearer identification of the root cause.

reprinted from itko.blogspot.com