SOAPful and RESTful SOA: co-existing in the enterprise

Joe McKendrick points to a post by Tim Bray where answers the question "What do you think we should do about SOA?" The context is a Rails conference. Tim says:

Don't do anything. 'SOA' may have meant something once but it's just vendor bull**** now.

That's not an unusual attitude. There are many who feel that way and I have sympathies that run in that direction, even though I write quite a bit about products from these very vendors. But I think it's a lot more complex than the arguments you typically hear around this topic. Here are a few data points:

• I was talking to the CIO of a medium sized insurance company yesterday who told me that SOA has changed how he does business. Most of his projects are now under $10,000. He has very few big project left. He attributes this completely to the use of SOAP-based Web services inside his shop and within the insurance industry. Interestingly, he has registries, but didn't know if his organization was using Web services management tools.
• Vendors do overpromise, but what else is new? I had a PR shop for one SOA vendor call me up and say that their client "delivered SOA governance." I asked for two cases. SOA is a development methodology in the same sense the object orientation is a development methodology and there can be SOAPful and RESTful services that co-exist within well designed service oriented architectures.
• My comment about vendors shouldn't be construed to mean that there's no value in the tools. Many REST proponents don't appreciate the scale of many of the IT shops who are trying to use SOA. Having been CIO of a place with lots of moving parts, I have a great appreciation for tools that manage complexity. I don't want to have to keep track of services in a spreadsheet, a home grown database, or a plain, old Web page. I can't afford to build security policies for hundreds of services on a case-by-case basis. These are real needs that today's tools address.
• I'm convinced that RESTful Web services would make more headway in the enterprise if there were a standard for description and discovery. Many REST proponents have avoided these topics, almost as a badge of honor. I was an early proponent of using simple, Web-based techniques to make more services available, but for that to happen, we have to be willing to layer additional functionality on top of that simplicity. The lack of description and discovery means that sophisticated intermediation cannot happen. That puts RESTful services out of the running in organizations that needs scale.

I, for one, don't believe this is an either-or kind of problem. I think that SOAPful SOA and RESTful SOA can and should co-exist. Complex Web services deployments work well for large organization with mature governance and planning functions. They aren't the answer for building HousingMaps.com. Both techniques have their place. Smart shops will use them where they fit best.