The Wide-Ranging Effects of MDM on BI Systems

When an enterprise first encounters master data management, it often doesn’t have a clear understanding of how MDM will affect the architecture of its business transaction systems or business intelligence systems. This article describes master data patterns in legacy system architectures, a general MDM architecture and some ways the new MDM layer affects the master data patterns in the legacy layers.

Master data patterns in the business transaction layer of the architecture follow the lifecycle of master entities:

• Systems that originate master data,
• Systems that update master data,
• Systems that expire master data and
• Synchronization of master entity state changes across systems.

Points of Master Data Origination

A business transaction layer can have one or more systems that create a master data entity.  For example, a large bank can have 50 to 100 product systems that must create a customer entity to establish an account. In contrast, a large manufacturing company, even though it has multiple product lines, may have a single system of customer creation in an enterprise resource planning system. If, however, a manufacturing company has not integrated its order entry system with its service system, there may be a second point of customer creation in the service system.

In business transaction layers with multiple origination systems, I typically see master data duplicates spread throughout the system population. Occasionally, single origination systems can also have duplication if poor data controls are in place.

After origination, master data migrates downstream to other systems that use it.  For example, a manufacturing company may originate part data in its engineering system, which passes the data to systems that support manufacturing, inventory and sales.  These downstream systems may change master entity attributes or add new ones that reflect their viewpoint on the master data.  For example, an inventory system may add financial classification codes to Part data for asset valuation.  

In business transaction layers with multiple systems that update master data, we typically see master entities in multiple, simultaneous states which are often inconsistent.  The problem can compound if there are multiple levels of dependence.  For example, system A updates ABC; A sends ABC to system B; B updates ABC; B sends ABC to system C.

While master data might never be deleted completely (archived instead), its value and meaning can expire.  For example, an angry customer can close an account and their relationship to a service enterprise.  Or manufacturing company will withdraw products (and service/support) from its markets over time.  When these business events occur, the business transaction system layer should reflect this state change in its master data.

In business transaction layers with multiple points of entry or update, we typically see master entity duplicates in simultaneous, inconsistent states of expiration.

Organizations are well aware of these business transaction master data patterns.  In the old batch days, enterprises sometimes had “circular file” systems that mimicked the manual file systems they replaced. Today, some organizations have data hubs that implement the same concept and attempt to synchronize master data between points of origination, update and expiration.  Other organizations have a spaghetti-like network of point-to-point synchronization.

In business transaction layers with multiple points of entry, update and expiration, I typically find some form of synchronization implemented in a range of complexity and effectiveness.  One problem that confronts these solutions is their ability to change versus the rate of system change (i.e., new systems, system updates and system retirement).

Master data patterns in the BI layer of the architecture follow the process cycle of business intelligence:

• Master data collection,
• Master data integration,
• Master data reporting and
• Synchronization of master data state across systems.

A BI layer can have one or more systems that receive a master data entity from the business transaction layer.  For example, a bank could have a large data warehouse for its commercial business and a large data warehouse for its consumer business.  Product systems in each business area feed customer data into these warehouses.  In other cases, a business transaction system may bypass the organization data warehouse(s) and send customer or product master data directly to a dedicated data mart.

In BI layers with multiple collection points, I typically see master data spread across BI targets - usually a combination of warehouses and marts.   If the timing of source data into collection systems is different, or the source data is inconsistent, then the master data may be in an inconsistent state across BI targets.  Even when there is a single collection point, we can see master data duplicates if there are weak data controls in the collection system; the master data might then spread across a population of downstream data marts.

A BI layer can have one or more points of integration of entity master data from the business transaction layer.  For example, a bank with a large data warehouse for its commercial business and a large data warehouse for its consumer business might have separate integration systems for each warehouse.  In other cases, there may be a hierarchy of data marts where the child tier data marts integrate master data from different source data marts in the parent tier.

Page 1 of 3.