The issue of ‘Web 2.0 vs. SOA’ has been getting a lot of coverage recently (Michael Platt’s Weblog has a good summary of posts on the topic). I’d like to narrow the discussion by focusing on the differences between SOA (service-oriented architecture) and Enterprise 2.0.
Many people have pointed out that unclear definitions in this arena make clear comparisons difficult, so let’s start by defining terms. SOA first:
From xml.com: SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.
From whatis.com: SOA defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. Service interactions are defined using a
A whole additional page of SOA definitions is here, and they’re all fairly consistent. SOA is a modular software architecture, and the modules are pieces of code designed to interact with each other.
Now, since I was the first to write extensively about Enterprise 2.01 I feel I’m entitled to define it:
Enterprise 2.0 is the use of freeform social software within companies.
‘Freeform’ in this case means that the software is most or all of the following:
- Free of up-front workflow
- Egalitarian, or indifferent to formal organizational identities
- Accepting of many types of data
‘Social’ means that there’s always a person on at least one end of the wire with Enterprise 2.0 technologies. With wikis, prediction markets, blogs, del.icio.us, and other Web 2.0 technologies with clear enterprise applications people are doing all the interacting and providing some or all of the content; the IT is just doing housekeeping and/or bookkeeping.
Jeff Nolan insightfully points out that Web 2.0 is greatly aided by things like scripting and REST architectures, and I agree that Enterprise 2.0 applications are a lot easier to use if users can drag and drop and do other cool AJAX-enabled things from within the browser. But to me these components aren’t even enabling technologies, since Enterprise 2.0 could happen without them. They’re clearly accelerating technologies, but keep in mind that the first wiki was built in 1994 and put on the Web in 1995, well before the initial XML spec was submitted.
Programmers could build fully-functional wikis, blogs, tagging systems, and prediction markets by carving them out of solid COBOL and serving them through the first Netscape browser. They’d be clunky, but they’d work. And I bet they’d draw users, too, because they’d tap into our desire to use technology to interact with each other, and also tap into the good stuff that emerges when we do so. As I wrote earlier, I think of Web 2.0 as the era when technologists really woke up to this; Enterprise 2.0 will be the era when business leaders join them.
A big part of the reason that Enterprise 2.0 tools work so well is that whatever information processing shortcomings we humans have, we are extremely flexible, tolerant of minor errors, able to react on the fly and interpolate missing data, and eager for spontaneity and serendipity.
Absolutely none of those things are true of computers. They remain, to use Joseph Campbell‘s great phrase "like Old Testament gods: lots of rules and no mercy."
SOA is largely about getting these rules in place up front so that subsequent computer-computer interactions become easier. Lots of writing about SOA has stressed the need for ex ante standards, centralization, and governance. In fact, most thoughtful writers about SOA spend much more time discussing philosophies and approaches than they do tools and technologies (they all acknowledge, though, that a few advances like XML have been tremendously important).
So both SOA and Enterprise 2.0 are really philosophies; the former about letting computers interact with each other without humans, the latter about letting humans interact with each other via computers. And advocates for both say they’re right around the corner, and point to examples on the Internet to buttress their claims. So what’s the big difference?
To me, one huge difference is the difference in claims vs. evidence between the two.
When I started my doctorate in 1994 and began trying to educate myself about IT’s impact on business, one of the things I kept reading was that legacy stovepipe systems, legacy spaghetti, point-to-point connections, and all the other prevalent anti-patterns of corporate IT were on the brink of being replaced by modular, loosely coupled, ‘hot-swappable’ pieces of code. This change was coming about, it was argued, because of a combination of better tools for developers, more common standards, compelling business cases, and philosophy shifts on the part of technologists.
Over the years I kept reading the same article (Heck, I even wrote it once.) The terms kept changing — from objects to modules to components to EAI to Web Services to SOA — but the concepts and arguments were remarkably consistent.
And while it’s unquestionably become easier over the past twelve years to integrate applications both within and across the firewall, it’s still very, very far from easy. As a 2005 article I wrote in Sloan Management Review argues, this is essentially because it takes a long time to get all of Campbell’s rules in place, and having 95% of them in place yields the same result — failure — as having 5% of then in place.
Even SOA proponents agree that there’s no recent tech breakthroughs that make it a more achievable vision now than it was before (the Wikipedia entry for SOA states that it’s an evolution, not a revolution). In fact, most proponents take pains to say that the philosophy is highly technology-independent.
So I’m really not sure why we should greet SOA with reduced skepticism compared to its direct predecessors. Are technology buyers only now aware of the benefits of loose coupling? Are they suddenly less pressed for time on integration projects, and so more inclined to trade off short term efficiency for potential long-term benefits? Has IT governance suddenly become much more centralized, to the point that SOA approaches can be effectively mandated?
Are technology sellers now more willing to put aside their differences and make their offerings truly interoperable (and therefore more interchangeable)? Have standards bodies gained more enforcement power or clout than they had before?
Claims about the power and benefits of SOA and its predecessors have been running ahead of reality for years. Claims about the power and benefits of freeform social software, on the other hand, mostly cropped up in the wake of real-world examples.
It’s true that predictions about Enterprise 2.0 are to date running ahead of the reality behind most firewalls, but at least we Enterprise 2.0 proponents have several up-and-running, powerful, productive, and worldwide examples that we can point to and say "See — that’s what I mean!" If SOA proponents can only point to public APIs and mashups (cool and productive though they are), I think that makes the case about how far the vision is from the reality.
A second difference between SOA and Enterprise 2.0 (which I think is closely connected to the first one) is that a service oriented architecture has to be imposed up front, while an Enterprise 2.0 environment emerges over time. Imposing structure takes time. It also takes a great deal of thoroughness, tenacity, and attention to detail, and a clear vision of where you want to go. Letting structure emerge requires none of these; it requires only a few mechanisms to let patterns and structure become apparent.
I want to stress again: I don’t believe that imposed structure is necessarily bad, or Orwellian, or misguided. I got started studying technologies that impose structure, and I still think they’re incredibly useful tools for business leaders. But I do think it’s critical for leaders to be clear about when they’re imposing structure and when they’re letting it emerge. And considering SOA and Enterprise 2.0 to be somehow parallel philosophies, or two sides of the same coin, is a great way to lose that clarity.
1I thought I coined the phrase ‘Enterprise 2.0’ but tag searching on Technorati shows me that the UK Internet consultant Stuart Eccles posted about ‘Enterprise2.0’ on February 20, 2006. My first post on Enterprise 2.0 appeared on March 24, 2006.