SOA and WOA

The debate sorrounding SOA(Service Oriented Architechture) and WOA(Web Oriented Architecture) is getting fiercer by the day and the blogosphere is abuzz with pundits claiming that WOA is the *in* thing citing plethora of reasons like simplicity, cost-effectiveness, decreased time to market, better manageability and so on. So, where does that lead SOA to - on the way to extinction? I don't think so.

To set the record straight, there seems to be a lot of misconceptions about both SOA and WOA - may think of them as a technology or an offshoot thereof. This is fundamentally wrong. They are, in fact, different architectural styles, or simply put two different way of doing things. And like similar styles in the same ecosystem, each has its own advantages and shorcomings. To simply put one ahead of the other, which is what is happening, is fundamentaly flawed.

Recently, while perusing an article in InformationWeek I came across some interesting stats about SOA. Let me share them with you.

"IT pros have expressed skepticism about SOA's promised return on investment. A 2007 InformationWeek Web survey of 278 IT pros found that 32% of those using SOA said those projects fell short of expectations. Of those, 58% said their SOA projects introduced more complexity into their IT environments, and 30% said they cost more than expected. Out of all respondents using SOAs, just 10% said the results exceeded expectations."

These are what the figures say, but what is indeed the fact? Well, the fact is that for a relatively new concept as SOA to stake claim to its usefulness in the market, it needs to spend a fair share of time in the market. If you look back 10-15 years from now, you will realize that its precursors like DCOM, CORBA had received the same lukewarm response. I do not put blame on organizations when they claim that the cost of implementing SOA far outweighs its usefullness, but such a statement can only be true for a small organization with relatively smaller number of offerings in their portfolio and when there aren't any pressing complexities. In such cases, it might make sense to go with an alternative to SOA, perhaps WOA.

Interestingly, Gartner Research defines WOA as "a subset of SOA". If you're using WOA, you are in anyway using SOA but not vice-versa. This again brings to fore the fact the debate between the two is on flawed grounds. In fact, for enterprises it is more of a choice between the two - or still better a mix of both, depending on their tech landscape. When it comes to service-enable a company's offerings, SOA (or WOA for that matter) should not be the default choice. A comprehensive study of what needs to be achieved is of utmost importance and this must the done first. Only after considerable thought has gone into this a choice should me made. For start ups and small companies that do not need complex integrations among disparate systems, WOA should be the approach, inasmuch as it is less complex and inexpensive to implement. Investing big money to set up SOA when such a set up serves no real advantage is totally uncalled for. For large oraganizations where huge integration setups are needed, WOA will be unsuaitable. It makes more sense to invest upfront on SOA and then reap the fruits in the long run.

So, it is not as much about SOA vs WOA as it is about the choice between the two. The approach should depend on what is desired and exactly what should be used to reach that goal. Ideally, a design should start with WOA and then add up SOA as and when the need so arises. In conclusion, the two are not diametric as they have been falsely portrayed to be, but are complementary.