There are three broad types of information model
- Operational - optimised for transactions
- Analytical - optimised for querying
- Mastering - optimised for federation
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.
- Don't hard-code information rules into the data schema
- Don't optimise based on a transactional approach
- Party - people, organisations, groups, etc
- Objects - 'Things', Assets, accounts, contracts, products, materials, etc
- Locations - Places, postal, physical, geographical, electronic, social, etc
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
- Parties to Things
- Parties to Locations
- Things to Locations
- (Parties to Things) to Locations (e.g. a persons specific account address)
- Parties to Parties, Asset to Asset, Location to Location
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.