lustratus LiteBytes

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