THE SOFTWARE SIMPLIST

Web Services Wisdom.

December 2006

Clatoro's NetBlog points to a survey showing that "Typical SOA Development Takes 3-6 Months". First of all, statistics can be doctored to show whatever you want. Second, seeing as the definition of what exactly constitutes SOA is unclear (is WS-* in or out?) the value in comparing that to your current SOA effort is questionable. Finally, does that development include testing, deployment, support, etc, or is this just pie-in-the-sky coding?

Bottom line, don't believe it for one second. Just getting a handle on the coupling between the applications and systems in your enterprise can take a couple of years. It's worth it, but don't kid yourself - it takes time.

Posted by Udi Dahan at 04:37 PM  Permalink |

ZapThink recently posted some parallels between SOA and Lego. I think that a lot of what was written there is fine in terms of market-speak but one point, hidden somewhere in the middle, deserves a lot more attention:

"...without architecture, a bunch of Services is little more than, well, a bunch of Services"

And like we already know, architecture isn't easy. Good architecture is damned hard. So, why the focus on services? Well, for those practicing architecture, the concept of a service fills in the top level abstraction we were looking for to describe large-scale systems. Unfortunately, the marketing guys got hold of the term and then the circus began.

Bottom line, then:

Don't start mucking around with services until you have a solid architectural foundation.

Posted by Udi Dahan at 03:32 PM  Permalink |

Jon recently wrote up a nice review of a talk he attended on Domain-Driven Design (DDD). In his review, he raised the following questions:

"Now something that really got me buzzing was something Eric said in passing about reuse. He was talking about context, and how domain-driven design and model development almost always apply to a particular context. A model is used in solving a problem in a particular context. What Eric said is that sometimes these models are wildly successful-the model really works in solving a set of problems. And what happens then? People start using the model out of context, to solve other problems. And what happens then? A lot of ugliness and failures. The model was created for a purpose, and is now being abused because it's being used out of context.

The problem I see is this: SOA encourages reuse, and so the chance of a good model being used out of context is increased dramatically. What are people doing about this? Is anyone working on domain-driven design in an SOA context? Do we need strict governance systems around the reuse of services to prevent models from being abused? Doesn't SOA make domain-driven design more difficult?"

First let me respond by saying that I am working with DDD in an SOA context. Second, although there is some buzz around the reuse possibilities of SOA, I'm firmly in the "you use a service, you don't reuse it" camp. In my experience, a service that encapsulates a DDD context works well, while services that cross context boundaries lead to tight coupling. This has to do with the business level cohesiveness requirements found in a context.

To the question of whether SOA makes DDD more difficult I'd have to say that the answer is yes and no. If you are trying to take an entire enterprise model and divide it up between services, you'll have a hard time. If you take a given set of services and try to do DDD within each of them, you may find that a mistake in assigning responsibility to services will become apparent in the domain model. I see that each one gives feedback to the other, keeping you from veering to far off the golden path.

Posted by Udi Dahan at 04:11 PM  Permalink |