There are three broad types of information model

  1. Operational – optimised for transactions
  2. Analytical – optimised for querying
  3. Mastering – optimised for federation

The point is that MDM isn’t about optimising for either Analytical or Operational models its set up to model across all of these domains, multiple different types of Operational model and multiple types of analytical solutions.  This means that good MDM models are those which are portable across operational environments and which can transform operational information into multiple analytical structures.

MDM models therefore need to focus not on optimising local performance but on optimising federated performance.  There are a couple of key pieces that this requires.

  1. Don’t hard-code information rules into the data schema
  2. Don’t optimise based on a transactional approach

The way that good MDM models solve this is by having an abstract model which is based around the three core things that MDM solutions have to master

POLE information model - abstract

  • Party – people, organisations, groups, etc
  • Objects – ‘Things’, Assets, accounts, contracts, products, materials, etc
  • Locations – Places, postal, physical, geographical, electronic, social, etc

The final letter ‘E’ stands for ‘Events’ which is what the transactions are.  This model for information covers everything that you could want to master and provides you with a very simple way of ensuring that all relationships can be mastered.  A Customer to Contract relationship in a transactional system might be a child table, in MDM however we’d look to split it up to have the Contract considered as an ‘Object’ and the instance of the contract being a Party to Object relationship tied to the customer and the contract with the contract identifier being stored on the relationship.

Now this might sound a little more complex than transactional relationships but its done for a good reason.  While in a single transactional system it might be fine to view everything from a customer perspective this is liable not to be the same in a risk or account system.  The account system might view the contract as the primary thing with customers attached to it.  Had the MDM solution chosen to take the approach laid down by the customer system this new accounting view would be difficult to reconcile, as would the analytical view that wants to consolidate and query based on contract types.

So the POLE therefore is the firm centre around which the communication takes place.  This has to map between multiple system, not all of them under the companies control and must therefore structurally be set up to cope with any relationship.  Questions of restrictions ‘A contract must always have at least one customer’ can be left to information business rules within the MDM tool and not coded into the data schema.

This last point is critical when creating a good MDM model, the data schema is always the most expensive and difficult thing to change, especially as its impact on integration can be significant if not all consuming.   So after our three core elements we are then left with

That really is it from an entity perspective then you’ve got the relationships for those entities (and remember a relationship can be just the keys to do the match) which means
  1. Parties to Things
  2. Parties to Locations
  3. Things to Locations
  4. (Parties to Things) to Locations (e.g. a persons specific account address)
  5. Parties to Parties, Asset to Asset, Location to Location

Its really that simple and in that simplicity is where the real power of POLE comes in.  When looking recently at a complex model for the CPG space where massive numbers of transactional systems have different views on the world it was possible to come up with a simplified view based on POLE that much better represented what we had to master.

The end result was as follows (well this is the powerpoint of it, you wouldn’t expect us to give everything away!).

Now on a one slide PPT its a bit complex, but the point is that we’ve split everything into the three key groups and then we have a standard set of relationships that apply to all of them.  This is really important as it means that we don’t have the issues that some older MDM models have where pieces like ‘social media’ are an after thought, here we can do channel shifting from physical addresses to social media straight away with just a change in the information rules.  This simple model covers all of our mastering requirements for what is a very complex solution that does integration into SAP and other operational solutions as well as providing a clean feed for analytical solutions.

POLE gives a clear structure for information to be attached to.  This was also the theme of ‘Mastering the Information Ocean‘ which also covers how at Capgemini we then classify these entities and attributes to determine what information is in scope for MDM and what is best left where it is.

So next time you start an MDM project be clear on your POLE and how you get your information to dance around it.