The highly regarded Gartner's chief fellow and group VP Daryl Plummer has a well-written article that appears in the current issue of Optimize Magazine titled, "Web Services At A Crossroads." He points out :

Service-oriented architectures (SOA) users fall into two camps: One group advocates using Web services to build complex internal systems known as enterprise SOAs, while the other one seeks to use emerging Web technologies in tandem with Web services to create flexible external applications.

Pointing to wasted efforts in trying to force web services to deliver enterprise-level capabilities they were never intended to handle, he puts across some impressive statistics:

Only 20% of all enterprise systems built today require the kind of robustness that standards-based web services provide and fewer than 30% of IT groups have the resources to implement all the standards that truly enterprise-capable Web services will require. Worse, most of the standards are nowhere near ready to be used consistently by mainstream IT. He adds, "web technologies groups are now forcing the acknowledgment that web services will indeed use mechanisms other than SOAP, WSDL, or even Universal Description, Discovery, and Integration (UDDI). Instead, standards such as Plain Old XML (POX) over HTTP and Representational State Transfer (REST) are asserting themselves as legitimate and very credible ways of delivering on the value proposition of Web services.

I am not so convinced about the last point - yes, I did indeed read James Governor's note welcoming this shift as seen by Plummer. I believe that the fundamental distinction between web services and SOA are centered around quality of service (QOS) management; the fact that SOA is an architectural construct, and not just a standardized protocol-leveraging technology, should not be lost in the discussions.

The points that Daryl Plummer make on performance issues and technical competencies are indeed important, but certainly not more important than recognizing the fact that fundamentally, web services and SOA are very different in their nature, in their solution options, and in the respective technology's ability to provide benefits. SOA by definition can be implemented using any service-based technology. The OASIS SOA Reference Model Technical Committee is working on defining SOA independently of any specific technologies and the SOA blueprints committee is coming up with many demonstrable models.

The difficulties that Daryl highlights in adopting SOA are indeed real; the very slow progress being made by standards bodies are a matter of concern and the vendor community is pushing things along in its own way. One can clearly see that currently the top five enterprise vendors out in the market are pursuing SOA in their own ways. With all these attendant difficulties in adopting SOA across the industry, I still think that the solution lies in identifying the issues that come in the way of adopting and overcoming the barriers rather than diluting the basic theme; it's not theme for the sake of it.

The value that can be delivered for enterprises adopting these technologies (web services/SOA) would begin to significantly vary over a period of time. In a way Plummer is indeed right; he is just talking about web services being at crossroads and not necessarily SOA. With SOA-related spending expected to increase significantly, one hopes that the discipline gets stronger and stronger and gear towards delivering better and better business value.