I’ve been enjoying Pat Helland’s blog a lot lately, especially the discussions that are popping up in his comments section. The discussion about SOA reminds me a lot of a few years ago when I spent most of my time doing training and consulting around WebMethods’ EAI product.

I didn’t always succeed, but what I tried to get across to people in those training courses was that the single most important thing they were designing in their solutions were the documents being passed around. Obviously, the processes were required as well, but the most painful failures I saw in EAI solutions on client sites came back to poor document design, not poor business logic implementation.

This focus on documents is a lot harder for most developers than you would think. You’ve heard the saying that goes something like "when the only tool you have is a hammer, the whole world looks like a nail"? I think sometimes OO becomes our hammer, I’ve certainly been guilty of this. I can remember a number of students complaining early in the course that this focus on documents went against everything they knew about OO design, however I can also remember a number of those same students having a lightbulb moment a day or two later. Interestingly, I ran a course for a bunch of non-developers, which I initially dreaded (C’mon, the course was called something like "EAI for Developers"). However, on the whole they seemed much more comfortable giving the documents the highest priority, and that course was one of the most enjoyable in terms of students "getting it"

For mine, this comment from John Cavnar-Johnson is dead on the money:

It’s not enough to have orchestrations, messages, contract, schema, and policy. We need to be able to define business documents that exist separately from the services that exchange them (something that is hard to do today with VS.NET and WSDL). These business documents need to have a conceptual identity separate from the schema that services apply (the schema for a purchase order being submitted for fulfillment is different than the schema for that same PO when it reaches billing). We shouldn’t be burying our knowledge of the actions that a service performs in the name of a web method call or SOAP header. We need to recognize that the authoritative record of the business data has to be in these documents, not in the relational store. The data type of a business element is a minor facet of its meaning, not the very essence of its existence.

Actually, there was a lot of good stuff in John’s comment. Definitely subscribed.

Oh, Pat has also shown up over on Channel 9, with a refreshingly pragmatic discussion about SOA.