Business Case for SOA 2

Andrew McAfee recently posted The Case Against the Business Case., which indicates why it's wrong (or at least dangerous) to make a business case in technological terms alone.

"I’ve probably seen hundreds of business cases that identify the benefits of adopting one piece of IT or another, assign a dollar value to those benefits, then ascribe that entire amount to the technology alone when calculating its ROI. The first two steps of this process are at best estimates, and at worst pure speculation. The final step gives no credit and assigns no value to contemporaneous individual- and organization-level changes."

I agree with this absolutely. I remember listening to a presentation on a successful computing project (I forget the details now) which ensured the commercial survival of some dockyard in the Far East. The speaker mentioned, almost as an aside, that there was some minor organization change required as well. And I remember thinking that there could easily be another presentation going on right now in a conference room somewhere else, where the consultants responsible for the organization change were boasting of their success in ensuring the commercial survival of the dockyard, and mentioning the computing project (if at all) as a minor side-condition.

So we have an excellent return on investment, if we just compare the cost of the computing project with the profitability of the dockyard. Presumably we also have an excellent return of investment if we just compare the cost of the organizational change with the profitability of the dockyard. But does the business case still work if you include both? The challenge for business case is scoping - where do you draw the line of what costs and benefits to include. Whose costs and whose benefits? (IT is notorious for neglecting user costs.) And what types of costs and benefits do you even recognise?

This has always been a problem for business case. Here's an example from a paper I wrote on "Reasoning about Systems and their Properties" (September 2000).

"During the 1980 UK mining strike, both sides constructed a plausible argument relating to the productivity of the system: one side claimed that it was more cost-effective to close the pits, the other side claimed that it was more cost-effective to keep them open. Apparently small differences in the way the system was scoped and in the choice of time horizon can have a large effect ..."

Andrew McAfee argues that a business case should be formulated not in terms of absolute business value, but in terms of the business capability you are getting in return for a given IT expenditure. It then becomes a business decision whether (and how much) to invest in a given capability.

This makes a lot of sense in terms of agility and flexibility as well. I have long argued that we should regard adaptability as a special kind of capability: adapt-ability, the ability to adapt. We need to show these capabilities on our business capability models, not just the operational business-as-usual capabilities. And we need to become much more precise about the adaption capability that a given technology (such as SOA) should be able to deliver.