Saturday, February 26, 2011

SOA Information Modelling - the power of MDM

One of the things that happens when people do information modelling is that people concentrate on creating a super-set of information models which represents the 'canonical form' for SOA. I've said before that Single Canonical form isn't the way to go for SOA so its probably worth thinking about what is appropriate. The key point here is that I'm assuming a few things
  1. You are undertaking modelling based on managed information - i.e. you have MDM
  2. Our goal is transactional accuracy not analytical models
So how do we go about it? Well first off lets pick a simple model, the top line model that I've used quite a few times before.


Pretty simple. Now the point here is that there are FOUR information models involved in this simple diagram even before we consider modelling the SOA interactional model
  1. Sales information model
  2. Finance Information model
  3. Distribution model
  4. MDM model
So there are two approaches at this stage. The first is the traditional approach to take a model which includes all of the entities and all of the attributes and creates a real mega-model. The problem with this is that its unstable and complicated.

So what is the next approach? Well its to think about information in two clear ways
  1. MDM information - share the key only
  2. Transactional specific - required to be shared
In our model above for instance in order to send an invoice from Sales to Finance we need to know
  1. The customer - MDM
  2. The products - MDM
  3. The delivery address - MDM
  4. The quantities - transaction specific
  5. The agreed price at time of sale - transaction specific
  6. The order itself - MDM
So this means that the model for this interaction is


The point here is that our modelling for business information between domains is concentrated much more on the entity models than on the attributes and the full details. So which the finance solution may require a confirmation that the invoice address is associated with the customer, it doesn't actually need that relationship sent through as it will have that via its own domain and via MDM. If the customer has specified a default address than this could even be excluded as again its available via MDM if required.

The point here is that the interaction does not need all of the information required for the receiving service to complete the interaction it just needs to supply sufficient information for the receiving service to complete the interaction this is a very important distinction as it means that modelling is concentrated primarily on the top level entities and transaction specific elements and other pieces are accessed either locally, because they are domain specific, or via MDM, as they are authorised.

In other words a better approach to information modelling is to consider MDM as an operational part of information governance and to focus information modelling on enabling MDM to deliver its value.

Technorati Tags: ,

2 comments:

Giovanny Mellizo said...

I am a soa consultant, and i am agree with you in this article, but i have a question. Technically, how you implement a approach where you maintain an MDM as a common logical data dictionary and map every physical object model to it"? If for example I have defined the common logical data dictionary in a generic xml schema, how I can to create a different customization of it, if I need only a few information of this big generic xsd? Is it possible to create a customized instance of a generic xsd in other schema for use it in my service interfaces? Thanks in advance

Steve Jones said...

I think you might misunderstand.

The MDM retains the golden record (e.g. for a customer) and synchronises that to all of the systems.

When one system talks to another about that customer all they do is pass the ID, they don't have to pass anything else so there is no XSD to customise.

When you want to get the information about that customer you call the MDM solution (or an aggregating service) and its only that service which needs the full customer XSD.

Does that make sense?