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”.