BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Avoid a Canonical Data Model

Avoid a Canonical Data Model

Standardizing on common models for business objects that are exchanged within an enterprise, e.g. Customer, Order and Product together with the attributes and associations they have, might seem like a compelling goal to achieve but for Stefan Tilkov this creation of Canonical Data Models (CDMs) is a horrible idea which he strongly advices against.

Tilkov, co-founder and principal consultant at innoQ, in his experience sees how organisations are notorious in creating work based on bad assumptions and notes that CDM as he defines it will require numerous meetings and coordination between all parties involved. Commonly the result of all this work is models containing lots of optional attributes and strange behaviour to satisfy the needs and restrictions from all systems intended to use the models.

To avoid such models Tilkov refers to bounded context, a concept from Domain-Driven Design (DDD), for dividing a large model into smaller contexts thus allowing for business objects to be modelled differently and according to the need in each context. He emphasizes that this is important for large systems but even more so for an enterprise-wide architecture; all systems don’t have the same needs and should be allowed a design according to their respective need.

For organisations that still are aiming for CDMs Tilkov has some guidance to address problems that might arise:

  • Allow for independently specified parts enabling parts being defined by different teams.
  • Standardize on formats and create building blocks smaller than business objects instead of a large consistent model, allowing for teams to add these building blocks together as suited for their needs.
  • Don’t push models onto teams; instead let them pull a model into their context when they see a value in doing so.

For Tilkov an enterprise architect should avoid centralization and CDMs, instead establishing a minimal set of overarching goals and delegating much of the responsibilities down to the teams and the people within the teams.

Back in 2008 Bill Poole wrote about centralised vs. decentralised data from a SOA perspective. Based on the disadvantages he saw with a centralised model and from his own experiences he favoured a decentralised view which caused some debate.

Rate this Article

Adoption
Style

BT