Canonical form, comical services?

In the EAI heydey, canonical data models were all the rage. Combined together with Brokers, they became the hub of the enterprise, or in technical terms, the bottleneck. Usually version 1.0 got off without too much trouble, it was 2.0, or 1.1 that couldn't extricate itself from 1.0. Steve Jones gives some background with his post "Single Canonical form - not for SOA".

Canonical data models are the anti-pattern at the opposite end of the spectrum from "A billion little services can't be wrong". When running away from the total lack of cohesion of little services, you may just end up in spaghetti land where not only is it cohesive, it's monolithic, something that SOA was supposed to get us away from.

One of the things going against single canonical form is that the business isn't single-faceted. Different departments give different meanings to the same terms. Sales has an entirely different view of "Customer" than does Accounting. By trying to integrate both perspectives into a single model, you end up either with the lowest common denominator (which is pretty uselss - Id, name, and address don't give us much), or an amalgam of properties from both domains with no way of knowing (come version 1.1) which are used where.

By modeling your SOA according to the structure of the business, you'll find that both the Accounting Service and the Sales Service have a customer entitiy in them. Yet besides the minor commonalities in basic data, these entities are totally different. If you were to design your services using OO principles, you'd find the Customer class in the domain model to have very different behavior from one service to the next. This is to be expected since the business rules in each domain are so very different.

This also gets back to the "re-use" fallacy of SOA. It would seem that concentrating all customer data in a single service, we could reap the benefits of re-use by employing that service anywhere customers are needed. Hurray! Lower costs, faster turn-around, business agility, right? Well, it turns out that giving each entity in a single canonical model its own service brings you the worst of both worlds. "A billion little services", each a slice of the giant ball of spaghetti.

In my recent podcast on Business & Autonomous Components, I described how keeping coherent business processes localized to a single service leads to better service decomposition and interaction.

Don't let yourself be led astray by the siren song of re-use and historically ineffective techniques like single canonical form. The services they bring may make you smile, but not in a good way.

Posted by Udi Dahan at 06:14 PM  Permalink