In “Web 2.0 success stories driving WOA and informing SOA”, Dion Hinchcliffe writes about how enterprise SOA can learn from the successes of Web2.0 and WOA^*.

“…since there’s little question that the core ideas behind SOA seem to be the right ones. Rather, it’s been how we’ve gone about designing and implementing SOAs that appears to be at the crux of the issue. As we look at the most successful examples of SOA actually working, we keep being drawn back to the Web itself.”

Along the way Dion points out a couple of differences between the Web and the enterprise which I think are pretty salient and underscore the issue that its not the technology that divides the two hemispheres of the service-oriented world.

“One big issue…is that enterprises are often very much unlike the Web. Many of the aspects that make the Web successful…just don’t exist in the enterprise with it’s wilderness of relational databases, proprietary applications, and silos of every description, despite some success in adding a traditional SOA layer on them.

The article Dion references in the last quote has this great summary graphic:

But in addition to the technical differences between the Web and the Enterprise, I think it is worth mentioning some fundamental cultural differences:

• The participants: When it comes to Web APIs that have been so successful, the conversation is basically between technologists. By-and-large it is technologists that are writing the mashups that demonstrate the success of Web2.0. Conversely with SOA in the enterprise, the conversation is (supposed to be) between technologists and business – and plenty has been written about the lack of success there.
• The success criteria: There are different success criteria for Web2.0 versus enterprise SOA. Very few Web2.0 companies currently make money out of their APIs. Success for Web2.0 is “eyeballs” and VC funding. In the enterprise, SOA success is all about hard ROI.
• The legacy: Most enterprise services must build on legacy applications, whereas Web2.0 applications are mostly greenfields and purpose built for the Web. Legacy applications rarely expose “resources” directly. If you’re lucky, the application exposes API methods which encapsulate an awful lot of business logic around a resource.
• The standards: Also part of the legacy is that WOA is “an emergent set of best practices…not a formal set of standards.” Let’s face it, WS-* are a formal set of standards designed by disparate committees often with competing agendas and ulterior motives. The structure and evolution of these standards has not been optimal for the users.

Fundamentally, I agree that Web2.0 in the enterprise and REST approaches to SOA have a lot of value and can teach us how to do SOA properly. Conversely REST needs to address enterprise concerns more fully. The key is recognizing the commonalities and the differences so that we can hit the sweet spot in between.

* BTW I’m not a big fan of the term WOA to denote “Web Oriented Architecture” or REST-ful approaches to Services. While I understand that distancing REST from WS-* makes good marketing sense, ultimately I think we are all talking about Services – so WOA is really a style of SOA. Jockeying for market position/dominance/discrimination has already got us into such a mess.