Here we go again. While the paint is still wet on this new Web 2.0 stuff, many SOA vendors and large analysts firms are calling their market SOA 2.0. It's one of the silliest things I've heard in a long while, and both the analysts and vendors who use this term should be ashamed of themselves.

I get Web 2.0 because the Web is well over 10-years-old and we've been successful in using this pervasive technology and now we're moving to newer and more exciting stuff such as AJAX and RSS thus the new version number. However, we've yet to get large-scale traction with SOA so SOA 2.0 is illogical since SOA 1.0 never existed if we're realistic.

Moreover, SOA is an architectural concept, not a software product, and to put a version number on something like that shows you don't understand the notion in the first place. SOA is a journey, not a project or product, and to try to make it such is to demean the core concept and the value it can bring. My larger concern, however, is that hype like SOA 2.0 could cause many of those moving towards SOA to become disenchanted and ignore the architectural issues, and hurt their business.

I suspect the marketing guys are at it again and that that's where this thing came from. Once again the people who buy the technology have to get involved and push back against this kind of foolishness or else you'll see it again and again. As such, I urge you to tell your vendors that SOA 2.0 is silly, and if they use the term they'll lose creditability. If enough hear that, the term will die, and other new marketing words like "SOA 3.0," "SOA Next Generation," and "SOA-nator" won't show up either.

SOA (No Version Number)
A SOA is a strategic framework of technology that allows all interesting systems, inside and outside an organization, to expose and access well-defined services and the information bound to those service that may be further abstracted to orchestration layers and composite applications for solution development. This is not a product, not a piece of software; this is an architectural concept. Am I clear?

The primary benefits of a SOA include:

• Reusing services/behaviors or the ability to leverage application behavior from application to application without a significant amount of re-coding or integration. In other words, using the same application functionality (behavior) over and over again, without having to port the code, leveraging remote application behavior as if it existed locally.
• Agility, or the ability to change business processes on top of existing services and information flows, quickly, and as needed to support a changing business.
• Monitoring, or the ability to monitor points of information and points of service in real-time, to determine the well being of an enterprise or trading community. Moreover, the ability to change processes to adjust processes for the benefit of the organization in real-time.
• Extend reach, or the ability to expose certain enterprises processes to other external entities for the purpose of inter-enterprise collaboration or shared processes. This is, in essence, next-generation supply chain integration.

The notion of a SOA isn't new at all. Attempts to share common processes, information, and services have a long history, one that began more than 10 years ago with multi-tier client/server - a set of shared services on a common server that provided the enterprise with an infrastructure for reuse and now provides for integration - and the distributed object movement. "Reusability" is a valuable objective. In the case of a SOA it's reuse of service and information bound to those services. A common set of services among enterprise applications invites reusability and, as a result, significantly reduces the need for redundant application services.

What is unique about a SOA is that it's as much a strategy as a set of technologies, and it's really more of a journey than a destination. Moreover, it's a notion that depends on specific technologies or standards such as Web Services, but really requires many different kinds of technologies and standards for a complete SOA.

SOA as a Discipline
What's clear about SOA is that while we are now beginning to see tactical successes, the large-scale benefits of leveraging this concept have yet to be understood by most organizations. Truth be told, it's going to take time before we can brag about the benefits of SOA, and perhaps the hype will have died down by then, thus some of the confusion that's around today. This confusion includes the number of WS-* standards that are around, many of which are redundant and conflicting. But that's another column or blog.

While SOA 2.0 is a silly notion, we look to evolving our thinking to a place where SOA is more "the architecture," not "an architecture." And there's a difference. What's more, we have to understand that systemic changes such as using SOA is going to take most organizations many years to implement. Unfortunately there are no shortcuts like changing version numbers.