Lustratus LiteBytes

Archive for the ‘SOA testing’ Category

Some of our recent research at Lustratus has given me the opportunity to talk to a lot of end user companies trying to get going with SOA, and a range of different roles within these users spanning all the way from the programmers to business people.

As a result, I am beginning to wonder whether the only option for SOA implementation is the Stealth model.

Leaving aside those visionary companies who are able to write off large investments on the latest new idea, or on a belief, most companies are forced to take a pragmatic view. As outlined in the Lustratus 2008 forecasts, there is a definite fracturing of SOA-related decision making between the archtiect bodies that see the value clearly, and the business-driven projects that own the budgets but do not see the need to include SOA costs in their business cases. When you think about it, this attitude from the business side of the house is not unreasonable – after all, what does SOA mean to a business unit? The discussions often go like this.

You will get get business agility and flexibility – the ability to respond faster to market changes.

- Oh yeah? When? How much do I have to invest before this happens? When do we reach critical mass? How long do I have to wait? Prove it!

The P&L will improve because we will reduce redundant code and wont write so much new stuff.

- When? What is the payback time? Why have you guys been building duplicate programs anyway? And how does that increase my project budget now, to cover the extra costs you want me to include?

But it is all for the best – honest!

- Do I HAVE to use SOA? Can I do what my project needs without? All I care about is this project, its allocated budget and the returns.

The problem is that SOA actually asks the business user for a lot of faith, just like other major infrastructure changes fo the past. One way around this impasse that many users have started to employ is the ‘SOA by Stealth’ approach. The first step is to get the SOA infrastructure assembled – ESB, Registry etc. These components can sometimes be slipped into projects without arousing suspicion, usually by claiming that the particular project needs it. Breaking the infrastructure up this way avoids the problems caused by a sudden large investment. Then, as each project is done programmers try to gradually turn pieces of functionality into SOA services – as many as can be done without drawing too much attention and impacting the budget too much.

The idea is that eventually it will become possible for IT to assemble the evidence that SOA is actually delivering benefits, at which point it becomes much easier to convince project budget holders to allocate some investment to it. In other words, the hope is that once the boulder starts rolling it

Steve

I generally don’t get too upset about surveys stating the obvious – what is obvious to me may not be to somebody else and vice versa.

However I think Aberdeen’s report on SOA testing as reported on by Joe McKendrick in his ebizq blog needs some comment.  It should be said in the report’s defence that it does make a valid if incredibly obvious point.  To quote Joe:

“New research from Aberdeen Group shows that to effectively test and provide QA to SOA, companies are testing not only vertically (using unit and functional testing as their benchmark for quality) but are also testing horizontally across an entire business process. In addition, in successful testing/QA environments, there is close involvement of the business user in more phases of the development lifecycle”

And from the report itself:

“It isn’t enough to just deploy automation, and it isn’t enough to simply rely on functional tests.  QA for composite applications needs a horizontal, process-oriented view, not the vertical unit-test methods used in the past.”

The insight is what any professional software developer has known to be good practice for years: when you deploy a new system you need to do “integration testing” and “system testing” – testing all the pieces of the final system work together and checking that it works against spec (which should involve business users).  If the system is distributed the testing will need to cover that added complexity (the horizontal, process-oriented view as referred to).  That this is promoted as something new amazes me.

Don’t get me wrong on this: In SOA, testing is an even more important than usual aspect of your software development process because a fault introduced in one service may result in down stream problems across multiple systems which use that service.  As many organisations adopt SOA, they will need to scale-up the sophistication of how they test software and detect problems in live software.  These are areas which certainly justify survey based analysis.  However, Aberdeen’s conclusions as reported by Joe seem to stay in the realm of the obvious.

Ronan