Web 2.0 and SOA: Are they related?

I read a blog entry today that stated that Service Oriented Architecture (SOA) and Web 2.0 are Disruptive Innovations. The writer referenced various benefits of SOA, such as Situational Software, RSS, and Mashups; several terms that many people have never heard of before. Situational Software was defined as "Rapid Software Development" by non-programmers to solve particular business problems on-the-fly using components that exist somewhere on the Internet. Mashups refer to applications built using open APIs available on the internet. RSS, which most people know, was also referenced as a way to syndicate content and easily include this content in other applications. The post referenced Web 2.0 applications such as Linked In, Wikipedia, Google's "Office 2.0", and others.

Then, the writer referred to Clay Christensen's definition of Disruptive Innovation and stated that Web 2.0 and SOA are Disruptive Innovations based on Christensen's definition.

While I thought the post was interesting, it fell victim to what I think is over-heated hype about Web 2.0 and SOA. Granted, Web 2.0 will change the way we work, interact, and purchase software. We already see this today in applications such as Linked In and Wikipedia. Because of these applications and things like Office 2.0, sure, maybe you could classify Web 2.0 as a disruptive innovation. But what I am missing is the connection between SOA and Web 2.0 and how SOA also, by default, ends up in the disruptive category. I mean, can we really compare SOA's impact with the introduction of the telephone (one of Christensen's examples of a disruptive innovation)?

Specifically, here is my problem with this over-hype: Web 2.0 is great. SOA is great. Nobody will deny that. In fact, as a CTO I try to employ as many of these concepts as possible. I write about Social Networking (arguably a Web 2.0 application) and we attempt to integrate these concepts with our products. When we design new products, we attempt to build them using a Service-Oriented Architecture. But is SOA disruptive? To me SOA is an evolution of concepts that have been around for decades. Software developers have long been figuring out ways to componentize what they build so that they can utilize these components in different ways. The fact that we now access these components through HTTP and Web Services is great, and makes programming much easier and more extensible. But is this disruptive over something like the CORBA or RMI or HTTP programs we wrote years ago? Back then we could write distributed components that programs from multiple languages could access, and these services could be published into directories. Now we have programs based on Web Services, and these programs can be published using Web Services Description Languages (WSDL) in various services directories. And we have applications that allow semi-fluent technologists to easily incorporate logic from these services into programs. But is this disruptive? Does this change markets or create new ones? I don't think so. At least not yet.

There is a stronger argument in classifying Web 2.0 as disruptive, but I fail to see the tight connection between SOA and Web 2.0. Sure, it is possible that Linked-In is built on a Service-Oriented Architecture. But it might not be. For all we know it might be a simple CGI application that is monolithic and has all of its logic written in one place. And what about Wikipedia or any of the new Office 2.0 applications that you can run from companies such as Google? Are these built using SOA? Again, maybe they are, maybe they are not. But does it matter? End-users don't care. My point here is that there is not a direct relationship between Web 2.0 and SOA. The only reason Web 2.0 can be considered disruptive in my opinion is because of the functionality it deploys to the end user, but not necessarily because of the building blocks on which it is built. With that said, in my opinion AJAX has a much bigger impact on Web 2.0's success than SOA, since AJAX allows desktop-like functionality from within a browser application. Once this becomes richer, then maybe Web 2.0 will be truly disruptive.

Finally, what does the development process have to do with this? The writer referenced the way that applications are built, and that longer, planned out software development cycles are a thing of the past. I don't buy it. First of all, software developers have been using iterative and agile development processes for years. Extreme Programming has been around long before SOA and Web 2.0 were invented and hyped. One of the major premises of these development methodologies is that it is more beneficial and productive to release software early and often in order to get feedback from users. We have been using agile methods in our company for years, and it works. The fact that Google releases software in this way does not make it more or less disruptive in my opinion. Nor is it something that is unique to Web 2.0.

To be sure, we will all benefit from Web 2.0 and SOA. Maybe I am just cynical because I have lived through a couple cycles of hype. But at this point I think Web 2.0 and SOA are simply new ways to think of and do things, but not yet earth shattering. Web 2.0 might be edging close to this category, but SOA is not there yet.

Comments

[Shawn DeVries]

Bob, my only argument is that there are businesses using the principles of SOA to gain market advantage over their competition. If there was no real ROI associated with loosely-coupled business process automation then it would be an extremely hard sell to the people setting the budgets. Tools and methodologies are one thing, hard $$ savings and gains are something else. So, one could say that this is "market disruption", maybe not technical disruption.

When you talk about "feedback from users" graphic-driven service, orchestration and workflow toolsets are key. Luckily, the offerings out in the marketplace are maturing and the overhead to implement these tools are dropping rapidly.

Most line-of-business directors have a hard time grasping concepts from lines of code but they DO understand business process flows and visual business diagrams. When you can basically click "execute" on the diagram itself, directly in front of these folks, it becomes a powerful collaborative development cycle between IT and the business.