The Business Impact of IT

Enterprise 2.0 vs. SOA

by Andrew McAfee on May 20, 2006

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 description language. Each interaction is self-contained and loosely coupled, so that each interaction is independent of any other interaction.

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.

‘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 behindmost 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.

Your definitions of – and comparisons between – SOA and Enterprise 2.0 Social Software identify some important differences. It seems to me that for the true potential of Enterprise 2.0 to emerge, business leaders need to be educated and be willing to support/admit the value of freeform social software as an enterprise software tool that delivers real personal and team productivity gains.

Do have any case studies or examples that could help illustrate the impact that enterprise class social software has on personal and/or team productivity?

http://www.greatwriting.com/blog Randall Cronk

“Even SOA proponents agree that there’s no recent tech breakthroughs that make it a more achievable vision now than it was before . . . ”

I disagree. You might check out space-based virtualization schemes like that of my client GigaSpaces. They encapsulate both middleware and legacy apps in dynamically extensible runtime environments that talk to each other via a JavaSpaces implementation. You can pretty much turn anything into a service without doing a major rewrite or creating a lot of upfront rules. Given that kind of freedom, you might find SOA and Enterprise 2.0 more philosophically in tune than is first apparent. See my post here: http://www.greatwriting.com/blog/2006/05/soa-is-achievable.html

Your definitions of – and comparisons between – SOA and Enterprise 2.0 Social Software identify some important differences. It seems to me that for the true potential of Enterprise 2.0 to emerge, business leaders need to be educated and be willing to support/admit the value of freeform social software as an enterprise software tool that delivers real personal and team productivity gains.

Paul Reeves

2 points:
1. unstructured data invites a non-egalitarian system as it discourages usage by people unable to quickly and effectively parse poorly written text (good writing is revision and sweat).

2. Structures evolve from previous structures. I do not think they emerge. The lack of structure in data means the data is not useful in the enterprise. Enterprise wikis, for example, should provide configurable structures and workflows for data to be truly useful. Provide a decision making template that groups can use to propose, debate, select and monitor a policy over time and you have a killer app.
As long as the structure provides for basic and complex data types, it can evolve as necessary.

http://Spooler_Go_83.blogspot.com Spooler_Go_83

http://Spooler_Go_91.blogspot.com Spooler_Go_91

http://cd6495a39500ced7d1fc.info cd6495a39500ced7d1fc689c001b3aca

http://blog.stxfwaip.com/yzorzniq mokqiua

http://blog.zajvdq.com/rfiqvmkxzs maklfili

http://www.mobile-gsm.com kris

The reason this is so confusing is the use of ORIENTED in the TLA. WhatÂ’s that about? Is it akin to some form of IT sexual orientation? Is it an optional response? WTF does it mean?? IMO it should be services BASED architecture. Much easier to understand and closer to reality from what I see in the field.

http://socialmediagroup.com/2009/07/09/is-e20-optional/ Is E2.0 Optional? | Social Media Group

[…] sessions I was able to attend however, were outstanding. I have long been a proponent of all things Enterprise 2.0 and it was refreshing to be in the company of a group of like-minded people. The conference is […]

ciao!,
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.