SOA 2 Point Oh No!

SOA 2 Point Oh No! - The Notion of "SOA 2.0" Is Just Plain Silly By: David Linthicum

Here we go again. While the paint is still wet on this new Web 2.0 stuff, many service oriented architecture SOA vendors and large analysts firms are calling their market service oriented architecture 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 service oriented architecture SOA so SOA 2.0 is illogical since service oriented architecture SOA 1.0 never existed if we're realistic.

Moreover, service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture 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 service oriented architecture SOA is going to take most organizations many years to implement. Unfortunately there are no shortcuts like changing version numbers.