Currently in Chicago where I am building an architecture for a Master Data Management system for an enterprise that is having data quality issues. I have worked with many enterprises who have attempted to architect their own MDM system. This is no simple task and you should consider all options before proceeding.
Many enterprises today purchase a Master Data Management (MDM) system to address their needs to have clean data round a key operational data entity such as customer and product. These systems become a single point of reference for other systems (e.g. order system)
But what happens if the enterprise wants a MDM system to maintain a business entity where there is no MDM system available to purchase? Well, it might be time to build your own MDM system for this specific entity.
There are a number of architectural approaches and patterns to provision a quality single version of the truth with respect to key business entities.
The most common is frequently referred to as a hub pattern due to its central focus of access, but not necessarily the same system of entry (SoE).
Here are some of the most common approaches to Master Data Management.
Each of these hub patterns has its own architecture characteristics, advantages, and disadvantages. As an architect you must decide which hub pattern is appropriate, taking into consideration the current challenges, existing systems, funding, and commitment.
- A virtual hub (aka registry hub) leaves the authoritative data in the source systems
and uses data virtualization techniques to dynamically assemble a master record in
real-time. - A centralized hub (aka transaction hub) stores all authoritative data for an entity and also is the system of entry (SOE). The centralized hub can be seen as the opposite of a virtual hub where the data and system of entry are de-centralized.
- A consolidated hub aggregates authoritative data from source systems using ingestion techniques and stores it within a master data store in the consolidated hub
- A hybrid hub (aka co-existence hub), as indicated by the name, is a combination of the capabilities of a virtual hub, consolidated hub and centralized hub
Invariably, the use of more than one hub pattern is the most likely course of action, either to address different requirements, or as part of a transition program.
These hub patterns require an initial load of data to lay a solid foundation of quality data. Afterward, the capabilities of the hub keep the data synchronized.
Well that is all for now. In my next blog I think I will discuss MDM aware consuming applications.
Good luck, Now Go Architect…
An Enterprise Architect's Musings 