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.

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.

What is Synchronous?

Last week a customer asked me whether I would classify Persistent Chat as synchronous or asynchronous. Good question. My simple answer is both. In fact, chat is the perfect application to bridge the gap between the synchronous and synchronous world. It is synchronous, or real-time, when all members of a team are available and actively participating in a conversation. This is great when your team members are in overlapping time zones but maybe they are unable to sit next to each other due to their physical locations. At the same time, Persistent Chat can be asynchronous since a user can join a conversation after the fact and read through the conversation history, or backchat. This is useful when you are working with a team that is in a different time zone, such as an offshore development team. Or perhaps you are traveling and you simply want to read about what your team did while you were away from the office.

Because of these scenarios, the answer seems fairly complete: Persistent Chat is both synchronous and asynchronous. But consider this: what if Persistent Group Chat actually changes the definition of what is synchronous? Maybe synchronous no longer means a group of people communicating in real time, but instead refers to a group of people being completely in-sync on a topic of conversation. Persistent Chat does this through the persistence of the conversations as well as the filters and intelligent notifications that ensure that people are always up-to-date on information that is important to them. The result is that they are in-sync with their team members, regardless of whether the team is able to communicate in real-time.

In the end, Persistent Chat is the solution that brings teams together around topics, and keeps everyone up-to-date on those topics. Persistent Chat keeps everyone in sync, and therefore Persistent Chat should be considered Synchronous.