SOA 2.0 : Why a Revision is Really Necessary

Share the article!

I guess I’m a little late to the debate about “SOA 2.0″. However, after going through the arguments, I will have go squarely against the petitioners. The petitioners would have everyone believe that SOA is a well defined idea that has worked wonders in practice. On the contrary, SOA is a term as nebulous as ever, and one in seven SOA endeavors end up in failure. The ideas and concepts behind SOA are just like its WS-NonexistentStandards underpinnings. That is it is careening towards a massive pileup. Joe Mckendrick has a good summary of the current dismal state:

But, if SOA really is so abstract and elusive, what else is there? What’s the alternative? Enterprise computing requires a very deliberate methodology of planning that extends out for years and numerous budget cycles. For companies saddled with patchwork portfolios of various vendors’ incompatible legacy systems xe2x80x94 combined with home-grown systems xe2x80x94 service-oriented architecture and Web services offer a path of least resistance.

Reality is, the industry desperately needs an alternative, that is a revision of the original SOA concepts.

So that we can at least frame the argument, let’s try to figure out exactly what SOA means. From there, we can propose a reformulation, something that goes beyond the simplistic Oracle/Gartner definition. The Oracle/Gartner leads much to desired in that it simply augments that original SOA with Event Driven Architecture (EDA). Now, every vendor has the right to hijack a term to hype up their existing product line. This tactic was practiced extensively for SOA 1.0, so I don’t expect them giving up on that tactic for SOA 2.0.

Nevertheless, I have yet to see a convincing definition of SOA 1.0 in all the years that it has been in existence. However, for arguments sake, let’s take the definition cited by the petitioners. The first definition comes from the OASIS SOA Reference Model group, which defines SOA as:

Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Its too generic a definition, however it does point out the organizational and technical issues that the SOA paradigm addresses. Furthermore, it alludes to a “uniform means”, which implies a standard implementation. A more technological agnostic definition of SOA , quoted by many is as follows:

In Service-Oriented Architecture autonomous, loosely-coupled and coarse-grained services with well-defined interfaces provide business functionality and can be discovered and accessed through a supportive infrastructure. This allows internal and external system integration as well as the flexible reuse of application logic through the composition of services.

I’ve struggled a bit to come up with a “definition of services” and what it means to be “loosely coupled” and “service composability“. However, after you’ve nailed down these concepts, there are emerging concepts that give real meat for the need for “SOA 2.0″. Gregor Hohpe alludes to this emerging paradigm when he says in “SOA and Agility go together like Google and Search“:

The agile emphasis on evolution rather than complex upfront design is a perfect match for SOA because linking Web services into an application is so complex that architects and developers will not really know what they have until the project is complete.

In an earlier piece, I wrote about the “10 Commandments for SOA Salvation“, and it goes as follows:

  1. Thou shalt not disrupt the legacy system.
  2. Thou shalt avoid massive overhauls. Honor incremental partial solutions instead.
  3. Thou shalt worship configuration over customization.
  4. Thou shalt not re-invent the wheel.
  5. Thou shalt not fix what is not broken.
  6. Thou shalt intercept or adapt rather than re-write.
  7. Thou shalt build federations before attempting any integration.
  8. Thou shalt prefer simple recovery over complex prevention.
  9. Thou shalt avoid gratuitously complex standards.
  10. Thou shalt create an architecture of participation. The social aspects of successful SOA tends to dominate the techinical aspects.

Successful SOA deployment in other words requires nimbly avoiding many of the organizational constraints of a legacy computing ecosystem. That is success depends heavily on a more agile process and on technical underpinnings that facilitate this process. So, “SOA 2.0″ goes beyond an architecture for services and moves into the realm of an architecture for participation. So when Richard Veryard first coined the term and proposed his ideas, he was clearly in the right direction. That is, SOA 2.0 involves mechanisms for collaborative composition, uncontrolled reuse, internet wide interoperability and a user centric approach. The key distinction between SOA 1.0 and SOA 2.0 begins with the realization for the need to support a decentralized process:

There are two competing visions of service-oriented architecture (SOA) circulating in the software industry, which we can label as SOA 1.0 and SOA 2.0. Our approach to governance is targeted at SOA 2.0. One of the central questions raised by Christopher Alexander in his latest four-volume work, The Nature of Order, is how to get order without imposing top-down (central) planning, or conversely how to permit and encourage bottom-up innovation without losing order.

SOA 2.0, is about imposing an Architecture of Participation on top of the of the original Services composition concepts of SOA 1.0. So when Mark Little writes “Giving an architectural approach a version number is crazy: it makes no sense at all!” To me it makes perfect sense, the SOA 2.0 architectural approach is a different approach. It in fact is a more sensible approach to Enterprise Architecture. Roger Sessions writes in “A Better Path to Enterprise Architecture“:

…partitioned iteration delivers high-business-value technical solutions as quickly as possible, and at the lowest possible cost. High value. Minimum time. Lowest Cost. That is the bottom line.

There is a lot of truth that the social aspects of successful SOA tends to dominate the techinical aspects. Steve Vinoski writes in The Social Side of Services:

Keep in mind, however, that building service-oriented systems is hard. Even if you get buy-in from the right people, it doesnxe2x80x99t mean that actually building and deploying services will then be trivial. After all, you still have to deal with changes in development processes, training, tools, and perhaps new avenues of technical collaboration with other teams. Nevertheless, actively addressing the social side of the equation greatly increases your chances for success with SOA.

There is certainly an untapped opportunity to apply Web 2.0 social networking technologies in the context and process of implementing SOA across an enterprise. There are a lot of interesting ideas that can emanate from this. as a starting point, one can begin with Lean Software Development principles and apply it to the SOA problem.


Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>