08/22/09 :: [SOA] SOA is Failing [permalink]

Apologies for not blogging, I am (really) swamped working on a SOA project...

As I was letting my main computer install some of the latest Vista security updates, while I looked for the the first time in 2 months at my google reader, and as you could guess, (Microsoft's) Dave Chappell's latest post caught my eye. Not sure why I missed his interview in 2008 but he basically explained then and now that "SOA is failing".

Dave and I have a long history. I related several times this incident in my previous posts but for the readers who don't know about it, I was sitting next to Dave at an Indigo (i.e. WCF) SDR (Software Design Review) back in 2004 or thereabout. At some point we engaged the conversation and I explained to Dave some of my views on how "orchestration" related to Service Orientation (i.e. as a Service Implementation technology and not (really) as a Service Orchestration technology). The difference is subtle and I explained many times my views on that question. At that point, Dave explained to me that I was wasting my career trying to say things that differed with what Microsoft was saying. He also spent a fair bit of time in the 2006-2007 timeframe explaining the Microsoft world why they should not look at SCA, in particular by rejecting the idea that an interoperable assembly mechanism had any value (thank you Dave, what an accomplishment !)

He did use these words "wasting your career". I guess he did not waste his.

Watching Dave's presentation is worth its dose of humor: "Object works as a design paradigm", "Reuse of business services does not work..., but... technical reuse, i.e .Net/JEE works", "ESB is just a bunch of vendors trying to sell you their good old integration gears", "Data access reuse works" ... and Dave goes on and on and on.

The astute reader would have probably made the connection that, indeed, the Connected System Division at Microsoft was failing so much that it had to put under the SQL Server division. What a demotion! I bet there are some partner architects that must feel a bit bitter about that. Ah...unless it is because "Data Access reuse works"? What do you think Dave?

How could a company that is unable to deliver a WSDL-first capability in its SOA tool set would understand anything about Service Orientation? I feel sad that Microsoft customers have to go through this kind of flawed arguments simply because Microsoft can't deliver something that can make them successful with Service Orientation:

Object works as a design paradigm: but of course Dave, this is why all enterprise application software is made up of Customer, Account, Product ... classes. We all know that. This is also why you add a couple of annotation to a "class" and voila, WCF spits out a service, and what a "service" that is.

ESB is just about integration: but of course Dave, and do you have the slightest idea about what loose coupling is and how WCF lets you achieve loose coupling? WCF is so loosely coupled that it can't even do WSDL-first or requires shared "stuff" between the consumers and the providers. Well done guys.

Reuse of business services does not work: but Dave, how can you implement a Business Service with WCF? have you even tried? can you show any example? Have you looked what they are doing with SCA? They even have events nowadays.

Data Access reuse works: but of course Dave, CRUD is a well know pattern that provides an infinite amount of reuse, actually you can reuse CRUD operations so much that every single consumer is going to implement the same logic, CRUDing around, and then when the data changes... ah badaboom, all client breaks.

 What an accomplished career Dave !! I am jealous.

I'll never repeat it enough, SOA is unfamiliar, it does require that you scratch your head a bit, oh, not that much. What does not work is trying to do what you have been doing for 20 or 30 years with SOA technologies. It is not the SOA technologies that do not work, it is what you have been doing. Object Orientation does not work (with information) but loose coupling works, provided that you understand what it means. The reuse of business service works, provided that you understand how to build, version, govern and fund business services. Ah, and data access? no it does not work, exposing data access services to consumers is like pouring concrete over your enterprise applications, it looks smooth and slick until the day you need to change a few things.

Lots of things are changing if you want to build a service oriented architecture:

  • Governance not just Project management
  • Strategy and Goals not just Requirements
  • Selection not just Specification
  • Contract and Quality of Service not just Functionality
  • Policies not just Rules
  • Resources not just Data
  • Lifecycles not just implementations
  • Events not just messages
  • Inter-actions not just invocations
  • Assembly not just Composition
  • Federative not just Monolithic
  • Forward versioning not just versioning
  • Certification not just Test
  • Publication not just Documentation
  • Provision not just Deploy
  • Threat not just Security
  • Accountability not just Organization
  • ...

The key to reuse Dave, because you seem to have no idea whatsoever about reuse, loose coupling and SOA, the key is forward versioning. What you have to understand Dave (sorry that's something that Microsoft is not saying) is that in SOA, what you reuse, is not an asset that was built last year, no, the old consumers of a service reuse a new version that was just built for a new consumer. Reuse is "forward" not "backward". As a consumer (and service provider) I prepare myself to allow the service to evolve without disruption in the consumption. What a lack of imagination! This is what happens in real life, as a consumer of physical services I rarely get impacted by changes in the services I consume (education, health, banking, insurance, groceries...). Life would be nightmare if we had to be notified of everything that is changing let alone do something about it. Reuse happens when versioning becomes seamless.

If you want to fail at SOA, I suggest that you follow Dave's advice to the letter: object, data access, ESB,...