SOA in the real world: Is 'First catch your executive sponsor' the only way?

Mrs Beeton, the 19th century cook and writer, famously started her recipe for rabbit pie with the line, "First catch your rabbit". Some explanations of how to adopt SOA sound depressingly similar with something along the line "First get your senior sponsor" and just as with rabbit catching, it is easier said than done. The big bang approach to SOA - with its requirement for a top level management sponsor, major long term commitment and notions such as integration competency centers - may be the ideal but I believe that CIOs who are willing to bet their career on SOA before the approach is proven in their business are still as rare as rabbits running towards Victorian writers bearing large cooking pots.

Luckily, this is not the only way of adopting SOA and Joe McKendrick spotted what looks like an excellent event which includes a session outlining some of the different approaches.

Entitled "Building SOA in Cost-Constrained Environments" (and unfortunately that is the world the vast majority of us live in), Jonathan Mack, Senior Architect, 1800FLOWERS.COM summarizes different approaches as follows:

1. Bite the big bullet and go for the big bang;
2. Implement one key SOA element at a time (e.g. Message broker, then portal for on-the-glass composites, then ESB for process orchestration and finally BPEL for full BPM;
3. Slip in the back door - build an SOA under the cover of meeting business functional requirements and
4. Minimalist SOA - expose only a limited number of activities as services while focusing investment on cleaning up and improving existing processes.

Approach 1, I have already covered - good if it works but hard to find the people willing to go along for the ride. The alternatives are of course variations on the incremental approach and they are potentially complementary in many cases. Point 3 in particular, to my mind is the only way most of us are going to implement SOA - as part of meeting business functional requirements - whether through the back-door or front door (and frankly the business requirement owner doesn't much care whether we use SOA or anything else so long as it works and is on time and under budget!). This is because within our cost constrained environment, there is going to be little opportunity to spend money on something positioned as a long term architecture generating long term returns (jam tomorrow) - the money is allocated to projects that generate benefit for the business today.

Given this, there are two characteristics to look for in candidates for early SOA projects:

• It must have sufficient scope for the benefits of SOA to be visible (simple problems can be solved in many ways and it is hard to differentiate between the results from different approaches).
• It must matter to the business: if the project is invisible or a toy, however good the return on investment it isn't going to convince anybody.

Or to put it another way, it doesn't need to be big bang but it does need to be a big enough bang to prove the SOA business case.