Introducing SOA

Tim Bray points to John Crupi’s opinion:

What does this really mean? It means that for SOA to be successful, it must be a “top-down” approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure.

I beg to differ. Obviously, the approach starting out from the top is what everybody wants to do, and what — most of the time, at least — architects and technologists (such as me) agree with easily. And it’s also very obvious that just replacing one protocol (such as IIOP) with another (such as SOAP/HTTP) without changing the communication architecture as well leads to disaster.

Unfortunately, though, when you try to initiate the strategic, high-level, top-down do-it-right approach in any of the large companies I’m familiar with, you’ll run into a wall made of solid brick. No-one will fund a project like that — at least not in Germany, which tends to be extremely conservative in terms of taking IT risks. And to me, that’s a good thing — before I throw an awful lot of money at the consultants, I will want to know what the benefits are, and there’d better be a short-term return on my investment.

From my experience, the best way to approach this is with a mix of high-level vision, introduced top-down, and bottom-up, quick win-scenarios that sort of grow towards each other:

1. Set up some initial guidance and high-level strategy, spending no more than a week on it.
2. Solve the next few small integration or B2B connection problems using ‘SOA technology’.
3. Revise your high-level strategy to reflect what you’ve learned.
4. Rinse and repeat.

Easy enabling of your existing systems to allow them to play a role in your SOA may be a risk. But ignoring your systems sounds like the single worst strategic mistake you can make.