Business Agility and SOA

April 24, 2008

It’s rare to find an article or blog post about SOA that doesn’t have the word ‘agility’ somewhere. It seems that the two words are inextricably linked. The problem is that a lot unimaginative folk make ‘agility’ the centrepiece of any business proposal featuring a service oriented solution. For reasons I’ll present here, agility-based proposals risk being rejected.

By all means, include agility in your proposals, but there’s a few reasons why you shouldn’t make it the headline

Agility is unachievable – I.T. will always be a bottleneck.
No matter how agile you become, it will never be agile enough. If it currently takes you 3months to deliver a solution and you can reduce this to 1 month because of SOA – everyone will be happy with the improved agility. Until next week. When someone needs something in 3 weeks not 4. As the organisation becomes more agile, people will begin to see more and more possibilities. Unfortunately, coming up with new ideas will always be quicker than implementing them. This is particularly true when people begin to truly innovate and seek revolution rather than evolution.

Of course “more agility” is better than “less agility” – but (sorry for the cliché) agility is an endless journey not a destination.

Agility is not tangible.
Agility is an abstract concept and as such it can’t be measured. If you can’t measure it then you surely can’t calculate ROI so why make it the centrepiece of your proposal?

To make the concept meaningful and measurable you need to operationalize it. In some cases this is relatively easy to do but in many cases it could be very difficult, not least because there are no metrics for the “current situation” so you can’t quantify improvements.

Agility is a long term goal.
Increased agility is a long term goal. Its hard to say how “long term” but anecdotal evidence seems to suggest 3 maybe 5 years. Its almost impossible to calculate any meaningful ROI figures that far in advance.

And there’s another complication. Say you produce a perfect SOA today and 3 years down the track you have perfectly accurate and indisputable metrics to show that the business is more agile. How do you calculate the percentage improvement you can attribute to SOA vs. the improvement derived from other things (e.g. better productivity tools).

Businesses are already agile enough.
This may sound controversial but isn’t really. In my career I have yet to see any organisation pass up a lucrative business opportunity because IT couldn’t deliver a solution. Businesses will bring in an army of temps, develop spreadsheets, Access databases, paper forms – you name it. It will all be glued together with “swivel chair integration#”, file extracts/imports and countless reports. Hardly and optimal solution but it will work. Businesses have an amazing ability to mobilise to exploit opportunities – with or without IT help.

# if you’re not familiar with the term it basically means a person sitting in a swivel chair and spinning around manually re-entering the data into multiple applications.

Businesses don’t invest in agility.
Think about it. If the business asked you for something and you gave them two estimates, one for a quick and dirty solution and one for a more considered long term solution, which one would they choose. Most probably the first one. Most businesses are only concerned with the “here and now”. It doesn’t matter if you can do it quicker next time – if they have to wait longer now. If they’re not interested in agility now, why have a proposal that says “we’ll give you agility in X years?”.

So there you have it. When you create a proposal it has to be credible. Make no mistake, most business managers are astute. If you put something into your proposal that can easily be dismissed then the whole proposal will struggle to be approved. This is especially the case if the reader dismisses the ‘headline’ item.