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, pdf).

"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.

Technorati Tags: business case ROI SOA service-oriented

Agility and Variation

There are several strands of agile development and quality management that are concerned with reducing (some measure of) variation in order to maximize (some measure of) performance and (some measure of) quality. Much of this thinking is derived from the quality guru W. Edwards Deming.

David J. Anderson, a follower of Goldratt's Theory of Constraints (TOC), has been discussing this recently in his Agile Management Weblog (links don't always work).

• Driving Variation Out
• Deming and Goldratt
  
• Reducing Variation in FDD

So I was interested to read Anderson's account of a Sushi Lunch, where he complained about the inflexible and unresponsive service provided in a top Japanese restaurant, and the dissatisfaction experienced especially by a junior member of the Anderson family. Anderson senior interprets this in terms of the Theory of Constraints:

This restaurant had a broken organizational structure and poor separation of responsibilities. The "Anderson lunch project" should rightly have been the responsibility of the waiter who should have been playing the project manager role (and maybe the program manager role). The waiter should have analyzed our requirements and understood our priorities. This should have been communicated to the chefs and the order of production of our sushi should have been negotiated against the competing orders at the time. The sushi chefs should have been purely responsible for the production of sushi. They should not have had any project management, program management or scheduling responsibility.

But I don't think this tells the whole story. It seems to me that the restaurant was unable and/or unwilling to accommodate the demand variation caused by the Anderson toddler. A supply-side optimization led directly to a poor demand-side experience, and indirectly to a supply-side disruption.

Traditional operational managers often believe their primary task is to achieve supply-side productivity by reducing variation. This view of the primary task encourages them to suppress demand-side variation, and to ignore demand-side signals that would complicate or contradict this view of the primary task.

What are the implications of this for service-oriented architectures? We now have technologies that support greater flexibility in managing design-side variation in relation to supply-side variation. From a business point of view, this is one of the main benefits of SOA technologies.

Technorati Tags: Deming SOA serviceoriented

dotBiz

I have just come across an interesting talk by Shai Agassi of SAP, entitled Achieving Enterprise Agility.

Slides (pdf) from Accelerating Change 2004. Voicetrack (various formats, 18mB audio, 38 minutes) courtesy of IT Conversations.

The first 10 minutes or so provides some business background, including airline examples. Then he starts talking about composition, which I think is the most significant part of his talk. He has a vision of what he calls dotBiz (roughly equivalent to the Service-Based Business), for which he makes massive estimates of market size from around 2008 onwards. (After about 25 minutes he starts to rush through the rest of his material. It's probably not worth listening beyond this point.)

From the slides, you might get the impression of a ho-hum nothing-special software product architecture. But his talk implies something much more radical: a stratification of business.

At the top of the stack are niche companies with small solution-oriented microprocesses. This are assembled from "composites" - he refers to a "conveyor belt" of partly-assembled (orchestrated?) subprocesses. Below this are tens of thousands of business objects exposed as web services. These then sit on top of a layered enterprise platform, presumably supporting supply-side composition.

Agassi then characterizes the historical position of the big four, roughly as follows:

• IBM outsourcing non-core process - "on-demand" understood primarily in terms of variable volume of standardized process
• Microsoft preferred for local non-scaleable solutions, but not taken seriously for enterprise solutions - "start here but don't know whether it can scale"
• Oracle specializing in supporting big one-off differentiated process - "stuff you want to build on your own"
• SAP specializing in non-differentiated non-core process - "best practices that always run"

In other words, each represents a different mix of differentiation, integration and scale. Agassi's characterization provides a possible explanation of the current strategy of the big four: all trying to converge onto the same central ground, using SOA to get the best of all three worlds: differentiation, integration and scale. However, in this presentation, he doesn't get to the most interesting question: how business stratification helps this agenda.