SOA is Dead, Long Live Web 2.0

For a long time I have been wondering what the business benefits of SOA are, and the truth is that I can find very few. SOA primarily benefits software publishers, in my opinion, by enabling a more rational development methodology and by tackling sticky integration issues once and for all. There are some ancillary benefits to end users, like incremental product upgrades in the form of services upgrades, but in the end the bulk of the benefits go to the people who make and implement software not use it.

The Web 2.0 revolution, and it really is a revolution, is where the enterprise software industry should be focusing our attention. It is here that customers see the benefits modern architectures enabled by SOA, but SOA alone doesn’t go far enough to be called anything more than an enabler of Web 2.0, the other critical components being REST and scripting, which end up feeding from one another.

The more technical of you would argue that REST and scripting benefit publishers as well, but what I would argue is that scripting is a direct enabler of end user services in the form of applets and with REST you have the ability to componentize application services without regard for state and this enables a new class of applications that are uniquely assembled at end points to provide users with applications that not only fit their requirements a lot better but are vastly less complex. A major ideological stumbling block for enterprise software companies is that everything we have done for 30 years has depended upon state as imposed by formal language theory, in other words, no message or event is every completely self contained, whereas in the REST world that the web lives in every message is self contained and complete. The computer scientists among you will debate the completeness or validity of what I just wrote, but I’d ask you not to just for the purposes of focusing on the theme not the details.

This debate is much longer than just one post, but it’s a debate we should be having because this SOA thing has been ongoing for the better part of 5 years and we still don’t have substantive end user benefits to show for it. In the interests of giving credit where credit is due, the move to SOA does enable an entirely new architecture (jeez, I am beginning to hate that word) while not being completely disruptive with regard to upgrade paths.

Technorati Tags: , , , ,

11 thoughts on SOA is Dead, Long Live Web 2.0

  1. Given the investment Microsoft has made in SOA you may find it odd that I (partially) agree with you. In and of itself SOA arguably has questionable business value — naysayers (often in the CFO’s office) say that it’s largely about refactoring and creating an ‘elegant’ enterprise software architecture.

    That having been said, the business value arrives when you put a ‘composition’ surface on top of SOA, that is, when you make it possible to string together these well-factored services — quickly — into a business application. Your SOA-enabled infrastructure suddenly gives you agility and responsiveness to changing business conditions.

    In a nutshell: BPM is the payoff of SOA.

  2. REST is important to the next generation of Web 2.0 applications, but so are traditional SOA concepts and standards. REST has its place in providing the consumer-facing aspect of next-gen applications/services, with SOA/WS-* providing the back-end “enabling” services.

    The either/or debate regarding REST and SOA(WS-*, more particularly) has alwasy confused me, as I consider these to be complimentary rather than conflicting technologies.

    Most of the benefits of REST regarding scalability, lack of server-side state, etc, can apply to WS-* standards, given you have an actual WS-* stack to work with. Most complaints regarding WS-*/SOA seem to stem from:

    1. Lack of available tools.
    2. Cost of available tools.
    3. Complexity of underlying standards.

    #1 and #2 are obvious complaints, but new open source tools and lower-priced product offerings in the SOA/WS-* arena are quickly changing this. #3 shouldn’t really be an issue at all, because any SOA/WS-* stack worth its salt should shield you from the underlying standards in use. The layered approach to WS-* standards is designed exactly for this, in fact. After all, how many web developers spend significant parts of their day trudging through the RFC specifications for the TCP and IP protocols, or DNS for that matter?

    SOA Versus REST:

    Most of the benefits of SOA/WS-* are not available within REST, making the REST model inadequate for B2B services, enterprise service connectivity, or anything where reliability is of critical importance. REST simply doesn’t offer the capabilities needed to operate critical services with absolute safety and reliability, such as transactions, publish/subscribe message routing, layered security models, consistent interaction scenarios regardless of underlying security model, support for varying security policies and contexts, etc.

    While these sort reliability/security features may not be necessary for consumer-facing Web Services, they are of critical importance for B2B operations, “mash-up” services that integrate other enterprise services (airline ticketing mashups such as FareChase are a good example), etc. REST may be suitable for small transactions such as end-user eBay purchases, but no larger organization should risk making millions of dollars in purchases/transactions, gathering critical/time-sensitive data, etc over a REST interface. The risks are just too great.

    Regarding the “Simplicity” of REST:

    It seems REST is frequently mentioned due to its supposed “simplicity” over SOA/WS-*, but this isn’t really the case. REST relies on the XML and XSD standards, both of which are of significant complexity (especially when character set encodings, HTTP URI encodings, service discovery, etc are taken into account).

    There’s a great presentation online that highlights some of the differences between SOA/WS-* and REST (pointing out some of these issues such as URI encodings, etc). It has several highly informational slides discussing these and other points related to the “simplicity” of REST. It is available at:

    (The presentation doesn’t get interesting until around slide 9, but points out alot of the complexity issues that can creep into any REST implementation. These issues go beyond simple “complexity”, also affecting reliability and especially security)

    Where will this lead?

    I personally feel that alot of this debate regarding REST versus WS-*/SOA will soon be irelevant, as most WS-* stack makers have either already added REST interfaces or are in the process of doing so. My company has offered both REST and WS-* stack capabilities in our Packaged Mashup Platform for over a year, for example.

  3. One additional comment, I’m not sure this debate should be framed “SOA versus REST”, but rather “WS-* versus REST”. SOA is more about abstract concepts and how a platform is constructed than the underlying standards in use. Just a thought..

  4. Pingback Venture Chronicles
  5. I would disagree with the notion that there are *very few* benefits of SOA. I work at a start-up and we have plenty of customers who have assembled composite application solutions to their problem and benefited from the underlying principles of SOA (re-use, loose-coupling, yada, yada), but the key is that they (the customers) frame the solution in terms of how quickly and effectively it solved the problem, and not based on just SOA buzz words. I also don’t understand why you’d separate scripting from SOA — there’s no reason to assume both can’t coexist.

  6. So the reduction in time to market with new apps that becomes accretive over time is NOT a good use of IT resources in global companies. And that after Dennis Moore saying SAP is a platform company coming to terms with itself [my interpretation] here: ? (sorry about that – the link is humungously long)

    Bit then I wonder whether you’re saying this because it is a great ‘get of jail free’ card for why SOA isn’t selling to the enterprise and thereby jeopardising the investment in NetWeaver? I know that all the companies who’ve asked me to do something that provides their spin on it all have the same problem. SOA stinks of blue sky and no-one has really figured out how to solve that perception. Being an enabler has always been at the heart of the SOA story, which in turn is only good ol’ integration given a fresh twist and a dash of BPM.

    Where is the automatic integration in the new web 2.0 stuff? A lot of closed APIs ought there, regardless of the ‘goodness’ of the service. Assumjing we agree that web 2.0 apps are largely interesting and useful with the added benefit of ultra fast delivery, then do we not in fact have a very strong case for SOA? I think so.

    In this case, the argument for me is that web 2.0 gets the user out of a whole bunch of straitjackets that make process improvement a lottery at best. Now we have the means to allow users to work the way really want, assembling apps that are super connected the way that is most effective for them. But — we need SOA at the heart, because this is how we get all those apps connected to our systems in the shortest possible time, without losing the integrations we aready have.

    As a starter for 10.

  7. Pingback » SOA at rock bottom | Software as services |
  8. Pingback Michael Platt's WebLog
  9. Pingback David's blog

Comments are closed