Why I hate SOA in less than 200 words.
On JavaZone 2005, I talked about “Why I hate SOA”. I found it hard then, and I’ve still found it hard for a while to express this sentiment concisely. I think I’ve finally got it!
One of the most common inefficiencies I discover in organizations is poorly designed boundaries. I find that people suffer when a boundary is too ridig, not when it is too loosely defined. Contractual interfaces create a “mine versus yours” mentality, where every problem beyond the boundary is not corrected, but instead wrapped in even more code. Almost all such boundaries lead to wrappers, lots of extra crufty code, duplicated decisions and thus a rigid architecture.
When used for a stable interface, a contract-driven approach may be appropriate. However, when I create an interface contract, it takes me many attempts before I get it right. In our profession, a big problem is our tendency to focus too narrowly on your small, and poorly divided, slice of the problem. SOA-thinking for in-house integration encourages this approach, instead of encouraging cooperation and “thinking inside a bigger box”.
Comments:
[Scott P] - Oct 30, 2006
Interesting article – okay, I’ll bite. First let me say that I agree, up-front analysis is always partly wrong. Responsibilities and interfaces will eventually change. Anyone who’s ever created an API or shared component lives in that world.
But, assuming a component has callers outside of a single application, how can you avoid defining a contractual interface? If components didn’t have responsbilities and defined interfaces, developers calling those components would have to understand the internals of every single one of them. In a large system, that’s just not realistic.
Sure it can be taken to an extreme, but what’s your alternative?
Johannes Brodwall - Nov 1, 2006
Good question, Scott.
If you are going to be used by an external application, sooner or later you will have to publish a contractual interface. However, I find that most developers break up their systems into too many applications with external interfaces before this is necessary. As long as you have a well-defined group, it’s no problem to have 20 or more people using continuous integration to stay agile for a long time.
I guess my point is that: Yes, if you need to communicate with an external application, you need a contractual interface. But my experience is people overestimate the need to communicate with the rest of the world. (This is of course an observation from in-house development, I expect shrink wrap to follow different rules)