SOA: business first. Web 2.0: business later

Service oriented architecture and Web 2.0 share a lot of common ground. Both invoke reusable code, both enable the rapid development of mashed-upped (read: composite) applications, and both rely on industry wide standards.

But there's an important difference between the two, according to at least one analyst.

The mantra you hear over and over with SOA (as well as incessantly at this blogsite): Determine what the business requires, then implement the appropriate technology.... Determine what the business requires, then implement the appropriate technology.... Determine what the business requires, then implement the appropriate technology.

However, the rules are a bit different for to the Web 2.0 paradigm. Gartner's David Mitchell Smith, for one, says when it comes to Web 2.0 technologies, 'Just do it.'

We'll assume when we talk about Web 2.0, we're talking about the emerging generation of mashups, collaborative, and social networking applications.

In a recent Webcast on the relationship between Web 2.0 and SOA, Smith put it this way: "You should not wait to do the business case first. There's no reason to not start adopting some of these technologies. Some of these technologies are things you can take advantage of without going full force into changing how you do your business."

That's because in attempting to build the business case first, the advantages of Web 2.0 approaches may be lost. "A lot of non-technology pieces are more difficult. They require changes in behaviors, and changes to how business is done. They're not the kinds of things that are going to happen overnight."

Hmm. That's exactly what a lot of SOA proponents were saying in the early days -- don't fuss around, 'just do it.' Now, a lot of the emphasis is on building business cases first. Is this a good thing? Web 2.0 has a freshness, a revolutionary zeal to it. I'm not advocating that SOA projects go rogue, but are valuable new approaches likely to get mired in organizational uncertainty and inertia before they even get off the ground?

Or, as Paul Kiel just wrote, is SOA a non-starter if the business fundamentals aren't there? "The fundamental problem for IT always starts with a business problem --or always should start with one," Paul observes. "If my mousetrap is working fine, why would I want to risk anything by changing it?  Even if the new spiffy SOA architecture will save the world?  A business problem at hand is the beginning.  When the business folks say 'we have a problem that needs fixing' or 'we have an idea for a new service for our customers' then we get to IT.  The technologists can architect the best way to solve the business problem using technology."