Really. Small is better.

My reader caught a good post about SOA over at ZDNet this morning. In SOA business case: smaller is better by Joe McKendrick, he quotes heavy hitters from BEA and HP and makes the case for starting small with SOA.

There’s been quite a bit of debate as of late as to whether SOA should start small and incrementally, or be introduced from the top down as a transformative venture. The word out of the recent BEA Systems executives annual Arch 2 Arch customer conference in Nice, France, is ‘start small, and build from there.’

I've been preaching this for a while now, and lately I've gotten some firsthand experience seeing it in action.

We have several customers who are "starting small" with their SOA. In each case, they've identified a single (or small number) of applications and began by adapting those to run within the construct of an SOA.

Why start small?

The first and most obvious reason is budget. Starting small often allows for a budget as small as a few tens of thousands of dollars (including refactoring the app to run as a service, a software infrastructure, and hardware to run it on). Rearchitecting your enterprise's entire infrastructure is often millions of dollars (yep, a TWO order of magnitude difference).

Starting small also allows for learning lessons. Your developers will better understand both SOA in general and how you've chosen to implement it on site. Your IT department will learn about implementation and deployment in incremental steps. And your users won't be confronted with all new systems simultaneously.

Another great benefit of starting small is the ability to show incremental success. Some of our best customer successes have come at customers who started with very small implementations--as small as 10 nodes (of course, being a grid vendor, I measure the size of a project by the number of machines it's running on). As other users and developers see the success of a service running 10 times faster on the grid, they want a piece. They want to replicate that success themselves.

Rather than a corporate mandate to implement a scalable SOA, we have the users themselves clamoring for more applications on the grid. We have developers working on their own to adapt applications. Success begets success--even small success.

When IBM and their grid partners amble up to talk to a CIO to talk SOA, everyone knows it's a multimillion dollar project--and a huge risk. But when a department spends a fraction of their budget, is able to SOA-up an app, and pave the way for further success--they make everyone look good.

By the way, speaking of looking good, our customer who started with a single service oriented app running on 10 nodes is now up to about 400 CPUs, and their grid is growing fast--this is definitely an example of success begetting success.

Technorati tags: soa