Compare SAP’s master data governance (MDG) architecture options and determine which is suitable for your project. The options work for both a centralized operating model and a federated operating model.
Key Concept
Master data governance (MDG) introduces controls over the data maintenance process, minimizes data quality issues, and eliminates redundant data.
The IT operating model of a company should reflect the business operating model. For example, in a company in which business unit operations are executed by a plan set by the corporate office, it makes more sense for the IT operating model to be centralized. In companies in which business units have control over their operations, it makes sense to have a federated IT operating model.
In either case, clean and non-redundant master data is the key for the decision-making process. SAP provides a master data governance tool (MDG) to accomplish that goal. Most enterprises considering implementation of the MDG solution first struggle to understand if it’s the optimal solution for them. Once that dilemma passes, decision makers must identify the SAP MDG implementation architecture that best meets current needs, aligns with the enterprise roadmap, and minimizes implementation effort, cost, and maintenance.
Following are SAP MDG implementation architecture options suitable for both the centralized operating model and federated operating model.
SAP MDG in a Centralized Operating Model
In a centralized operating model it is common to consolidate global master data for a 360-degree view of customers, vendors, and products, as well as transparency of financial information. In this type of scenario organizations have a centralized SAP ERP Central Component (ECC) system facilitating the management of key global business processes. ECC feeds data to the reporting and analytics applications and other applications to support unique business processes. Some of the applications supporting business-unit specific operations remain to operate at the individual business unit and consume the master data from the enterprise master data management application.
The decision to implement an SAP MDG solution on a centralized ECC system (Figure 1) can be a quick and efficient process that provides:
- A Web-based user interface to maintain master data
- Workflows to better govern the maintenance process of master data
- MDG staging area to hold data for quality checks, final approval, and timely release to the active area of ECC and other applications in corporate and business units
SAP MDG in a Federated Operating Model
- A multi-phase roadmap that includes a vision for a near-term transition to a centralized operating model
- An approach that allows individual business units to control operations locally
Type A: Moving to a Centralized Model
- Select one of the individual business units ECC systems to deploy SAP MDG for centralized management of master data. This option is feasible only if the selected business unit’s ECC system operates in a mode that closely matches the target operating model.
- Alternately, as a best practice, the enterprise can launch a standalone ECC instance at the enterprise level and deploy an MDG solution that meets enterprise-wide requirements on top of that standalone ECC. This cleaner approach is considered a best practice because it eliminates inconsistencies that can arise after merging/consolidating ECC functional configurations across the business units.
Both approaches effectively establish a foundation for master data governance, and both facilitate transition from a federated operating model to a centralized operation model.
This scenario is common across organizations operating similar lines of business. Data overlap exists between these business units because they service the majority of the customers, share competitors, and often buy from the same vendors.
Implementing SAP MDG in a federated ECC environment (Figure 2) provides:
- A Web-based user interface to maintain master data
- Rule-based workflows to govern the maintenance of master data
- An MDG staging area to hold data for final approval and timely release to the active area, the standalone ECC, and other corporate applications
- Distribution of master data from the enterprise MDG/standalone ECC instance to other applications across the enterprise
Figure 2 shows that MDG also supports other type of applications such as Cognos.

Figure 2
Moving to a federated model
Type B: Business Unit Controls Data
This scenario is tailored specifically to an enterprise with a federated operating model wherein all business units control operations locally and then provide all the required information to the corporation for reporting purposes. The imperative difference: individual business units govern/maintain master data locally.
The following illustration demonstrates how each business unit maintains a unique, operational ECC system in addition to reporting applications and other local applications. In this scenario business units continue to maintain the core operations locally and distribute the data to corporate for enterprise reporting needs.
This scenario is common in business units operating a different line of business, business units moving to a unique global location/market, or acquired business units with products/services outside the enterprise core. Very little data overlap exists between these business units because they service different customers, they don’t share competitors, and often buy from unique vendors.
It is feasible — and advantageous — to deploy MDG on top of each unique business unit-owned ECC system. This approach provides each business unit with the MDG system necessary to manage/govern the master/reference data locally. The system can be designed to distribute master data and other essential information to the corporate reporting tools.
Each business unit implements the MDG system on top of the local ECC. This scenario requires more effort because it deploys multiple MDG implementations across the enterprise. MDG simply establishes data maintenance and governance at each business unit level.
In a federated model, the need for centralized maintenance of master data may not be critical. However, if the enterprise decides to consolidate the enterprise-wide master data, a hybrid MDM model can be developed to replicate the data from local MDG applications to the centralized MDM application. This type of scenario is applicable at organizations trying to bring more value from harmonization of the data. A Fortune 500 customer established a similar scenario whereby business units manage the master data at the business unit and replicate the data to the enterprise MDM harmonization system. The enterprise MDM system receives information from multiple business unit applications for harmonization, transparency, and data exchange with external vendors.
SAP MDG implementation in a distributed ECC environment (Figure 3) provides the following:
- A Web-based user interface to maintain master data
- Rule-based workflows to govern the master data maintenance
- An MDG staging area to hold data for final approval and timely release to the active area, plus release to the local business unit ECC and any corporate-level applications
- Distribution of master data from the business unit MDG/ECC instance to corporate applications and other applications in the business unit

Figure 3
MDG in a distributed environment
Mohammad Assad Shaik
Mohammad Assad Shaik is a senior enterprise information management lead. He is an engineer with expertise in computers and IT architecture. Assad provides expertise to medium-sized and large organizations in diverse industries that include oil and gas, consumer goods and services, financial, manufacturing, chemical, high-tech, telecommunications, insurance, power and energy, and safety and security. Assad is the author of Enterprise Master Data Management Using SAP NetWeaver MDM, which is available in paperback from Amazon.com.
You may contact the author at assad.sm@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.