SOA What? Big vs. Little vs. Nothing at All

I've just spent the last week immersed in user conferences and briefings, and at every juncture the question of web services and service architectures came up. And every time the issue moved from theory to reality, this little nagging problem kept coming back to cloud the optimism in the room: what is the business case for a big-bang SOA implementation, and who is ready to step up and show what a real ROI for SOA actually looks like? 

There are definitely some answers to these questions, and definitely companies who are not just kicking tires but genuinely investing in the future of SOA. But the relative paucity of companies that today are betting their business on a SOA strategy -- in an enterprise-wide way -- has brought the market to an important inflection point. The need for comprehensive ROI data -- as well as some good info on total cost of ownership -- has never been greater. And until those data -- that elusive business case -- are readily available, the uptake of what I call "Big SOA" is going to be slower than most of its proponents would like. "Little SOA" seems to be where the action is for now -- pilot projects, smaller, discrete implementations, and custom-built composite applications that deliver some immediate value to a specific line of business in need.

The ROI of Little SOA is easy to establish -- these discrete little projects have a lot of potential payback, as they are addressing real pain with a real solution. The problem with Big SOA is that the pain it addresses is one we've gotten much too used to over the years. Costs associated with bad integration, lack of re-use, overall inefficiencies and the inability to truly address business needs with technology solutions have been with us so long that we hardly know they are there. I'm reminded of the problem that companies like Mercury Interactive had years ago when selling their testing tools for the first time. It's hard to sell life insurance to someone who thinks he's immortal, and until the market's heightened awareness of the cost, and prevalence, of failure -- a realistic view of IT mortality -- reached a critical mass, Mercury Interactive fought a hard, uphill battle for recognition. 

I think a similar dynamic is at work with Big SOA: IT departments and their business colleagues have become a little too complacent about the dysfunction that characterizes their day-to-day interactions, and for the most part living with the status quo, however flawed, has become part of the survival strategy for business and IT alike. Until some heightened awareness -- and some solid proof points -- begin to saturate the market and the collective subconscious of users and decision-makers, Big SOA is going to sit on the sidelines watching Little SOA grab all the glory.

Which is fine by me, and not necessarily a bad strategy if you're a customer -- though definitely not the strategy many vendors would prefer. Little SOA is where the pioneers can play without risking the entire IT budget on a bet that was either poorly placed or just placed too early. And, from what I've seen in talking to customers who like Little SOA, as well as the vendors that see the value of starting small, this is going to be the approach that matters for the next year or so.

The alternative to Little SOA is none at all, and I think that's a major disadvantage for all concerned. Service architectures and web services are as inevitable as Moore's Law. What's needed is just a little more time to let the big ROI of Big SOA get established. In the meantime, there's Little SOA to keep us all happy, and that's not a bad thing at all.