Anyone interested in the future of business software will want to read John Hagel’s post on the tensions between service-oriented architecture (SOA) and Web 2.0 and how those tensions might come to be resolved. Despite the fact that SOA and Web 2.0 share a common heritage and a common goal, the proponents of each have formed two distinct camps, with little love lost between them. As Hagel explains, SOA has become the realm of the conservative corporate IT department, while Web 2.0 is the territory of the hacker barbarians trying to storm the gates. The SOAers, says Hagel, focus on “connecting applications and databases,” while the Web 2.0ers “put a lot more emphasis on the opportunity to connect people together and to support their collaborative efforts.”
He continues:
Both sets of technologies share the same vision, but they are deeply skeptical of each other in terms of the approach used to accomplish this vision. Web 2.0 champions dismiss SOAs as much too rigid and slow moving in terms of building platforms for cumulative creation. Here’s the irony. SOAs initially generated significant interest within the enterprise because they appeared to offer a much more flexible and rapid way to build new application functionality relative to traditional enterprise application architectures.
What happened? SOAs were hijacked by an alliance of CIOs and IT consulting firms, each with their own reason for extending the effort required to deploy SOAs … The growing appeal of Web 2.0 technologies [to business managers] in part stems from this hijacking of SOAs.
Hagel suggests that it will likely be the Web 2.0 advocates, bypassing IT departments, that will push companies to take the next step toward simpler, more modular software:
What is required to break this SOA logjam? Two things. First, Web 2.0 technologists need to work on connecting directly with line executives of large enterprises without trying to go through the IT departments. Second, they should avoid the temptation to present grand visions of new architectures and concentrate instead on starting points where these technologies can deliver near-term business impact.
That makes sense – but only if you assume that Web 2.0 collaboration tools, like wikis and tagging, will actually pay off within businesses in a broad and substantial way. There are, as I wrote previously, reasons for caution here. If Web 2.0 technologies fail to fulfill the promises being made for them, they could end up slowing rather than accelerating the transition to the next generation of business software. My own sense is that it may be software-as-a-service (SaaS) providers, more than the Web 2.0 crowd, that will end up breaking the logjam, not only through their discrete application services but through integration platforms like Salesforce.com’s AppExchange. I hope Hagel in the future will offer his view about the role of SaaS in the evolution of the web-services model.
I wrote in post below we need canoes to link our islands of data and applications. Instead SOA is a big ship. The Titanic.
http://dealarchitect.typepad.com/deal_architect/2006/03/soa_sos.html
IBM positions 13 (yes 13) Tivoli and Websphere products as its SOA. SAP does not expect even half its customer base to make the SOA move till 2010, and it has been building SOA for years already. The SIs are counting on a $ 500 billion transition market. Everything is multi- multi…in the mean time young Valley kids are putting together mashups in hours…
SOA as currently defined – SOS
I’m starting to sound a bit quixotic in my attempts to alter perceptions about SOA etc in the blogosphere etc, but what the hell:
Hagel is a top-notch thinker, but there’s some conflations in his thinking here that can’t go un-addressed.
1) SOA != Web Services technology. SOA is an *approach* to IT that centres on representing and combining assets as services. You can use WS-* if you like – but you don’t have to.
2) Web 2.0 != REST technology (a different approach to WS-* protocols used for wiring services together). Web 2.0 is more about philosophy, design centres (architecture of participation, etc) than it is about a protocol set.
Hagel spends a fair amount of time talking about the antagonism between two camps but in reality the antagonism, such as it exists, is between two camps of proponents fixated on application protocols (the aforementioned WS-* and REST-type approaches).
Interestingly Hagel himself nails the most important aspect of the relationship between Web 2.0 and SOA concepts in the same article: “Both Web 2.0 and SOA technologies re-conceive software as services. Perhaps even more importantly, they view services as platforms.”
There’s so much fixation on the deep tech underpinnings here, rather than the bigger picture: and it’s that fixation – rather than tedious protocol nerd mud-wrestlings – that is the real danger to this emerging wave of innovation. The real interesting thing is not “A or B?” it’s that *this is about a new alphabet*.
When we talk about „young Valley kids .. putting together mashups in hours” we are really referring to them building composite applications based on services provided by others. They are effectively reaping the advantages of USING an SOA rather than creating one. Creating an SOA is altogether more difficult – I am sure that Amazon or Google, for instance, did not create their external services in a few hours. This is why many companies are struggling with the concept; they can sense the possibilities, but have a devil of a job putting together an ROI justification.