More on SOA and Enterprise 2.0

Joe McKendrik posted today about how SOA and Web 2.0 will Stir Disruption. In the article, Joe referenced my previous post, and mentioned that this post focuses too much on the "technical weeds".

This concept of technical weeds is exactly the point I am trying to make about comparing SOA to Enterprise 2.0. My point is that SOA is a technology; it is a way to build and deliver applications. Enterprise 2.0, however, is so much more than that because it represents a completely new way for people to communicate and interact. So, while I am excited about using concepts of SOA to deliver applications, I think that tightly coupling the success (and hype) of SOA to Enterprise 2.0 actually belittles the promise of Enterprise 2.0.

One piece of data that represents the foundation of my beliefs that SOA is possibly being over-hyped are the statistics of SOA based APIs and "Mashups" from the Programmable Web. From Dion Hinchcliffe's post, The growth of mashups continued throughout 2006, as of December 13, 2006 there were 348 APIs registered and 1350 mashups. While these numbers are more impressive than say 0, they are nothing compared with the number of website that were created in the previous revolution which was the World Wide Web. So while I am sure we will continue to see a rise in SOA based applications, I am hopeful that Enterprise 2.0 will be much broader and grander than SOA will ever be.

Comments

[Joe McKendrick]

Bob:

Thanks for your additional comments, I agree that SOA is oversold. An additional post can be found here:
http://fastforwardblog.com/2007/01/29/keep-soa-at-arms-length-from-enterprise-20/

[Anders Tornblad]

I don't really agree with you that SOA is a type of technology, and one sure thing is that SOA is not at all about building applications. SOA, and actually any kind of architecture, when done correctly, is not about technology, but rather is a way of formulating business-level requirements in a way that makes sense to development teams.

SOA provides a way of tracking business-level requirements from business decisions, through business processes, activities, and business capabilities, down to singular services, operations and even information models. The main task for SOA in any enterprise is to enable Business Agility - not sending SOAP messages arount the world (that is for the web servers to handle).

One huge mistake that far too many people do is mistaking SOA for WebServices-based application design. Even though SOA (Service Oriented Architecture) and SOAP (Simple Object Access Protocol) play nicely together, each can surely live without the other.

What you call "Enterprise 2.0", I call SOA.

[Rex]

I personally see a relationship between the concepts but also a clear distinction. I see SOA as architecture to enable BPM & Agile Business. Enterprise 2.0 focuses more on human collaboration.

[Itamar Shamshins]

The inherent problem in this discussion is that while the definition of SOA is usually agreed upon, its scope is not.

Some people treat SOA as a set of architectural concepts for building software applications.

Conversely, I have met self proclaimed SOA experts who will argue that every aspect of the organization can be included into SOA, since business processes (whether computer based or not) can be treated as building blocks for other business processes. Hence, SOA can be applied to all operations conducted in the organization (including, but not limited to, the "human interaction" Bob refers to).

The importance of SOA is directly linked to which interpretation you choose to adopt.

Most will agree that SOA failed to encompass the larger scope of organizational business processes.

My guess is that since addressing the broader scope is still a valid goal, it has been reborn within Enterprise 2.0.

[Shawn DeVries]

SOA is indeed a methodology, a blueprint. We can all agree that SOA does not necessarily imply human collaboration. Plenty of loosely-coupled business services have been orchestrated in production where no human intervention is involved. Of course, if something were to fail in the process you would bake in notification, retries and alerts. But this is where the lines get blurry.

What if to "retry a service call" actually meant "Judy in Accounting has to pull up a screen and clear something off her work queue by validating a customer account number"? When you are dealing with people, processes and systems, the lines between person-to-system collaboration and person-to-person collaboration get blurred. Mix the two aforementioned buzzwords with a host of others like BPM, BPEL and Workflow - you can see why companies get confused as to the scope.

There are "maturity models" in the marketplace that help companies define the scope of a SOA implementation within the enterprise. BearingPoint has a practice around it which I have seen, and models do help companies get a start on SOA.

The concepts of Enterprise 2.0 and SOA do complement each other, but where they complement is yet to be defined in great detail.