The previously mentioned data model is mostly used in traditional, single fat applications architecture. In the next step, where we come to the SOA era, where we get a flavor of services-based architecture, there is a new data model introduced, named the Canonical Data Model (CDM). It is used in the SOA concept, which advocates the reuse of data structures, attributes, and data types during messaging between various systems and components. The profit of this concept is that it simplifies the definition of the business data, but it could easily become unmanageable. Whatever kind of technology one is using (an ESB, a BPM platform, or just an assembly of services of some kind), standardize the data models of the business objects you exchange. Due to OOPs mindset, in very common scenarios, you end up having some kind of entity, such as customer, order, product, and so on, with a set of IDs, attributes, and associations everyone can agree on. It seems like a very convenient thing to do. Then, anyone who happens to have a model that differs from the canonical one will have to implement a conversion to and from it.

There are benefits to using a canonical data model. For example, CDM promotes the use of a common definition of the objects across the business unit in an organization. This really helps with better communication and understanding, and reduces the chance of ambiguity. Also, integration is very easy and cost effective in this model, in terms of time and the developer's effort.