Getting the Enterprise Canonical Data Model right

re: Getting the Enterprise Canonical Data Model right

ehoff — Sun, 01 Jul 2007 03:50:41 GMT

From your perspective, would you define the canonical data model at the SOAP/XSD level (as in service contract) or are you talking full-blown enterprise data model as in having a single data store (ala SQL/MDM)?

re: Getting the Enterprise Canonical Data Model right

NickMalik — Sun, 01 Jul 2007 05:17:39 GMT

@ehoff,

The enterprise canonical data model is a structure that looks (from a distance, if you squint) like a database model. It has a lot of entities in it. It has all the basic entities that the business uses to do what they need to do. So, in that respect, it is like a single data store...

Only you don't store data in it.

You use it as a model to make sure that everyone agrees about what the entities mean and how they relate.

The enterprise model doesn't contain enough data or enough detail to form the Enterprise Data Warehouse. It is not a model for BI, although it is closely related because the data warehouse will need to use the same 'agreement' formed by this model to understand the data delivered by the source systems.

In fact, if done right, the ECDM will make the development of an Enterprise Data Warehouse MUCH easier because it creates a consistent context for the data in every major system. If data needs to be translated when it leaves a system in order to be part of the canonical model, it will need a very similar translation to be part of the data warehouse.

hope that helps

re: Getting the Enterprise Canonical Data Model right

Mahesh CR — Sun, 01 Jul 2007 13:28:50 GMT

Hi Nick

Your post provides a good heuristic to determine notification granularity first of all. And tying it to a CDM would ensure every provider has a consistent vocabulary to deal with data elements. Neat post, thanks!

Could you elaborate a little on the CDM itself? Is this an entity archetype that is communicated across the organization and fidelity to it enforced via best practice and governance? Where does one start on the CDM, if there are a hundred assorted data models, all loosely representing similar things? How does one version and manage this? Are there organizations that do this?! Any best practices you could share or point out?

Cheers

re: Getting the Enterprise Canonical Data Model right

NickMalik — Sun, 01 Jul 2007 22:15:15 GMT

@Mahesh

You have asked a good question. I'm not sure I have a 'right' answer. I will say this: the ECDM cannot be formed centrally and communicated outward. It has to be formed at the edges and communicated in.

Where one starts is with the business. What does the business understand about their data. If you don't start with the conceptual data model, the canonical data model is unattainable or fictitious.

Normally the business will use different terms for the same entities. Most of the problem of developing the ECDM is in dealing with people, not technology.

re: Getting the Enterprise Canonical Data Model right

Evan — Mon, 02 Jul 2007 05:59:05 GMT

@Nick,

That makes sense. It seems like an attempt to bring together a common "contract" to say, 10k services in a large enterprise.

Do you consider the EDM to be some form of executable contract (ala SOAP/XML, etc) or more an attempt at establishing a set of guidance and documentation across a large set of services.

Evan

re: Getting the Enterprise Canonical Data Model right

NickMalik — Mon, 02 Jul 2007 10:02:13 GMT

@Evan,

Do I consider the ECDM to be an executable contract? Part of one, yes. There is the behavior of the service as part of a message exchange pattern that is entirely outside the ECDM, and then there are the data elements that I pass that are formed from entries within the ECDM.

I view it as more than guidance. It is a consensus, hopefully. An agreement for excellence.

re: Getting the Enterprise Canonical Data Model right

Anthony Jervis — Thu, 05 Jul 2007 15:32:51 GMT

Business objects are the essential data elements that constitute the majority, if not the entirety, of the information which circulates between IT systems.

It seems only logical that the basis for the analysis of an information flow’s structure in an execution contract be based upon these business objects.

The canonical data model should "ideally" be derived from an enterprise-wide business object model (also known as Business Data Model or Semantic Model amoung others)

Briefly on this, an enterprise-wide model contains a detailed, yet high-level view (ie: without system datatypes!), of the objects manipulated by the organization, the relationships between these objects and possibly the objects' lifecycle.

Being derived from the generic enterprise business object model, the canonical data model becomes itself a generic data model that is conventionally used by mediation (or integration) platforms such as EAI or ESB platforms.

In opposition to application or repository/data warehouse data models that are very often specific to the software package and may only be required to hold a limited amount of a business' data (objects & attributes), another goal of the canonical data model is to be an application-independent model or PIM (Platform Independent Model: see MDA principles by OMG).

It is for this reason that canonical data models are preferred by mediation platforms as it provides the following:

- the basis for construction of the canonical data types for business objects (made up of one or many business objects)

- the basis for the standardisation of information flows that use the above mentioned business objects

- an independent format to which the mapping of specific information flow data models can be performed

- an adherence to the recommended hub-and-spoke integration model

In SOA architectures the canonical data model, and in particular the canonical data types, can be used for defining the parameters that make up a service’s signature (transmission of objects as parameters rather than simply a list of values). Indeed, the definition of the different parameters (data & data types), for all request & response messages, can refer to external XSD schemas which represent the complex canonical data types. It will be up to the services, then, to pick from the full set of data as is required to perform their processing.

I think that I may have covered a lot of subjects here, each one can be the subject of one or several articles, but I hope that this may have helped a little to better understand the benefits of ECDM, as a reference structure but also how it can be used as an executable contract in today's information systems.

re: Getting the Enterprise Canonical Data Model right

NickMalik — Thu, 05 Jul 2007 20:47:26 GMT

@Anthony

You use the term Business Object Model. I use the term Conceptual Data Model. We mean the same thing.

Thanks for your contribution.

--- Nick

re: Getting the Enterprise Canonical Data Model right

ajervis — Thu, 05 Jul 2007 21:46:49 GMT

@NickMalik

I would consider the Business Object Model (or Semantic Model) as a higher level of concern than that of the Conceptual Data Model, if only for the sake of taking a step back from IT.

Indeed, what the IT industry calls a Conceptual Data Model is a data model that has a pre-defined scope. The scope, here, is generally that of a target IT solution that a Software Architect is drafting up. In past CASE methodologies, and even in those of today, it remains the role of the Software Architect/Engineer to build the high-level conceptual data model based upon the business' requirements for the target IT solution)

A Business Object Model is one that does not relate to IT <em>at all<em>, and one that is (or should be) drawn up by those that have the business knowlege: that is to say, the business users (with a little help from those who know how draw a meaningful diagram!).

A Business Object Model represents the business knowledge, the business constraints on those business objects and business characteristics (attributes, taxonomies, etc.)

The Conceptual Data Model can be <i>derived</i> in a certain manner from the Business Object Model, regrouping only those objects that fall into the scope of the target IT solution. It is in this model that the objects & attributes are further worked upon and completed to include high-level data and system architecture considerations. From here on we follow the traditional route of software development process: conceptual -> logical -> physical models ... and, I hope, respecting the MDA fashion.

But, I guess we're getting away from the subject of your original article.

Anthony

re: Getting the Enterprise Canonical Data Model right

NickMalik — Fri, 06 Jul 2007 02:51:44 GMT

@Anthony,

Point well taken. I was not using the term correctly. You are right. I should not use the term Conceptual Data Model to refer to the Enterprise Business Object Model.

Thanks,

--- N