The purpose ofThe purpose of this article is to review the strengths and weaknesses of SAP MDG

software. I am writing this review based on my experience implementing SAP MDG, some experience
implementing SAP Netweaver MDM, as well as helping many customers to implement master data
governance and data quality processes, policies and organizational structures. I have over 22 years of
experience helping customer to implement SAP ERP and other tools such as APO. Please note that
the focus of this article is on MDG EhP 6.1. SAP has released MDG EhP 7.0 version, but as of
publication of this article, this version was just released to general availability on May 19, 2014.
Many potential customers are still confused between the two SAP master data management products
MDG and MDM. Although recently SAP released Enterprise MDM bundle that includes both
products as well as other add-ons such as Data Services and Information Steward, these two master
data software packages have different focus areas and strengths.
To understand the differences in capabilities between SAP MDG and MDM, I suggest to closely
referring to the following SAP chart.

As the chart shows, SAP MDG is related to central creation of master data, and MDM to
consolidation of master data. The main purpose of MDG is to help organizations to create data and
MDM to help syndicate/synchronize master data.
What is the difference between the two functions? To take advantage of key MDG strength, it should
be implemented as the system that most master data is originated from SAP MDG must own the
creation process of master data. Since SAP MDG is closely integrated with SAP ERP master data,
this implies that your SAP ERP system should be the system of record of your master data.
In contrast, MDMs focus is on synchronizing or syndicating separate systems with master data
maintained separately in the different business systems. The purpose of MDM is to help integrate the
master data and make sure that data attributes in common have the same values. Data syndicator
system must have strong match-and-merge functions with ability to match data records automatically,
identify differences, combine data records based on pre-defined rules, and refer exceptions to manual
match-and-merge processing. This functionality is lacking in MDG EhP 6.1 (some SAP publications
claim improved match and merge in EhP 7.0, but I have not had a chance to test this function first
hand).
Master data creation system must have strong workflow and data validation capabilities to support
creation of complex master data objects by various functions within your organization. The definition
of data governance is both management of the business process that supports creation and change
of master data within organization as well as application of automated and manual data validation and
enrichment rules. SAP MDM lacks strong workflow and validation functions, SAP MDG has them.
SAP ERP master data is very complex. It is important for a company that implemented SAP ERP to
maintain quality of its master data to assure effectiveness of its ERP environment. Creation of SAP
ERP master data typically involves many people working for many departments. SAP ERP lacks the

functionality to help companies coordinate the creation of master data, validate it and approve it. For
years, large companies developed workarounds to help them manage SAP master data. SAP MDG,
therefore, filled an important gap in the traditional SAP ERP landscape.
This does not mean that SAP MDG should only be used for managing SAP ERP master data. It has
excellent replication and integration capabilities to integrate and distribute data to other systems.
However, when designing the process of integrating with external systems, it is important to
remember that SAP MDG should ultimately own the master data and act as the originator/creator of
data. It should not be implemented in a role of data syndicator.
One of the best strengths of SAP MDG is that it is based on SAP ECC platform and leverages existing
SAP ECC technologies such as IMG, ABAP workflow, BRF+, and Web Dynpro. It is an advantage for
customers who already use SAP ECC they have to learn fewer new technologies, and they can
leverage to a greater extend their existing IT analysts, developers, and external support partners.
Another important MDGs strength is its close integration with SAP ERP master data. In Reuse mode,
SAP MDG can easily update the SAP ERP master data and refer to this master data during the
processing of master data change requests (SAPs term for workflow transactions for creating and
changing master data). In Flex mode the relationship is more complex and requires more complex
data replication and load settings. Still, since MDG supports SAP ERP data models out-of-the-box, it
is relatively simple to setup MDG to update the SAP ERP master data. The same holds true for
implementing MDG in a co-deployment mode versus the Hub mode (i.e., in co-deployment mode is
simpler from integration perspective). For more detailed information on MDG implementation options,
please refer to other MDG related articles in my blog.
Based on my experience with multiple MDG implementation projects, SAP MDG (EhP 6.1) is a stable
product and, once implemented, works well. It has sufficient out-of-the-box functionality to allow
companies implement quickly some basic functions for governing SAP ERP data. It supports decent
customization options allowing to customize the data model, workflows, user interfaces (UI), data
validation rules, and to implement more complex data quality and data quality analytics leveraging
additional Data Services and Information Steward software. As stated before, it also has good data
replication capabilities supporting all of SAP ECC replication options using Web services, ALE, RFC
or flat file. Additional replication functionality is available with Data Services (for complex data
transformation and validation) and SAP PI (SAPs EAI software).
SAP MDGs main weakness is in complexity of its design SAP, AG does not make the most intuitive
easy to setup products, and MDG is not an exception. For example, SAP chose to implement a new
concept of Entity Types with four different setup options instead of leveraging the existing SAP data
dictionary based on a standard relational database technology. An Entity Type can represent a single
data element or a group of data elements that share properties (similar to a table in relational data
dictionary). In my opinion, this technological concept is a little cumbersome to implement and not
intuitive.
Another example is BRF+ technology. BRF+ is a nice tool that allows to setup business rules to run
workflows and validation processes using tables instead of programming, but to configure BRF+, an
analyst must setup three tables and in many cases know how to activate the update BADIs (BADIs
are SAPs object oriented functions).
The most complicated part of SAP MDG is in the relationship between UI, workflow and data model
as demonstrated by the SAPs chart below.

In more complex cases, analyst implementing MDG must be familiar with all four technologies, SAP
Web Dynpro programming or/and Floorplan Manager (SAP graphical UI tool that allows creating
sophisticated UI, but is not very simple to use). This complexity should not surprise anyone already
using SAP ECC. SAP ERP, for example, has more than 3,000 tables with hundreds (or maybe even
thousands) of configuration tables/options.
In conclusion, SAP MDG EhP 6.1 is a very good product for customer already committed to SAP ECC
environment. Its functionality is long overdue to help companies manage their SAP ERP master data.
SAP MDG can effectively integrate with non-SAP systems, but it should be implemented in a role of
central data creator system not data syndication system. SAP MDG can be enhanced by integrating
SAP Data Services and Information Steward for added data validation, enrichment, and data quality
monitoring functions.
Please note my extensive SAP ERP, SAP MDG and data quality experience. You are welcome to
contact me if you have any questions or are looking for a senior consultant to help you with your SAP
implementation and SAP system management needs. this blog is to share my extensive experience

in implementing SAP software for the benefit of end-users and consulting professionals.
Consistent with my approach you get the straight truth with no sales spin about real-world SAP
challenges and solutions! Reading my blog you will learn about creative tailored approaches that
helped many customers implement, uCase

Study: SAP MDG

Implementation at a Large Diversified Chemical Company
Topic: Selection of Master Data Management Software
This is the first article in a series of articles about SAP MDG case studies. This article focuses on the
early phase of software selection and proof of concept.

Project Background
This customer currently has an extensive SAP environment that consists of several SAP ECC
instances, SAP BW, SAP APO, SAP SRM, SAP BOBJ BI, as well as various other SAP and non-SAP
software tools. This customer also has a central SAP ECC instance for master data management and
integrated Lotus Notes work flow and collaboration system in support of its data governance
processes. Customer is in the process of integrating several of its SAP instances into one SAP ECC
instance.
Customer wanted to consider replacing its ECC based master data instance and its Lotus Notes
based governance system with an off-the-shelf master data management tool. Customer was
confused, however, about the various master data management and EIM offerings from SAP.

Solution
The following explanation of the different SAP tools helped this customer to focus on SAP MDG as the
proper solution.
There are some overlapping capabilities between SAP MDM and MDG. By all accounts, MDG is the
tool that SAP is planning to develop and support into the future and MDM is being sunset. However,
MDM still has an advantage in match-and-merge area, and MDG is stronger as a central master data
governance system especially, when there is a need to govern SAP ERP master data.
Match-and-merge is functionality needed to match master data maintained in multiple systems,
harmonize it, and then syndicate the master data back to those systems. Therefore, typically MDM is
better used when there is no one system is the source of master data -- there are multiple systems
that own the same master data and the main functionality of MDM system is to help synchronize this
data.
Please note that SAP MDG EhP 7.0 offers an enhanced data matching and cleansing capabilities
using SAP Hana. This functionality seems to enhance fuzzy match, but it remains to be seen if it is
cable to execute an effective match-and-merge function as described here.
MDG's strength is in its ability to govern master data by being the central system to do this. Data
governance has two important components -- managing work flow and managing the quality of data.
MDG can distribute the data to other systems as needed (and it has excellent integration capabilities
through DRM), but it should be the central source for data creation or at least for enforcing data and
business standards and quality standards.
Data Services is an ETL tool. I call it ETL+, because SAP Data Services has excellent capabilities not
only to move data from one source to another, but also to improve data quality in the process and to
clean data. Data Services is not an alternate tool to MDG and MDM, it is a complementary tool. Data
Services can be used effectively in many scenarios to integrate data between MDG and external
system (with exception of SAP ERP), for data validation (e.g., address validation) in real-time
integrated mode with MDG, and for data cleansing (real-time or batch).
Information Steward is from the same package as Data Services and uses some of the same routines
(e.g., profiling). The main focus of Information Steward is on monitoring data quality. It is also a
complementary tool to MDG and MDM. It is possible to setup data quality dashboards and monitor
whether actual data quality conforms to standards. Information Steward can also manage meta-data
in an enterprise. This functionality is less applicable to ERP data (since meta-data is well defined
within ERP data dictionary), but is very important to help manage meta-data in different business
intelligence and data warehouses.
Based on these definitions, this customer selected to implement SAP MDG EhP 6.1 (EhP 7.0 was not
available at the time) integrated with SAP Data Services 4.1 and Information Steward 4.1.

SAP MDG Proof-of-Concept (POC) Phase

Prior to finalizing their decision, the customer wanted to do a proof-of-concept (POC) project to make
sure that SAP MDG has the capabilities to address main business requirements. I recommend this
approach for customers that have complex business processes and complex IT environments. For
smaller customers with simpler business processes, I often recommend to go straight into pilot
implementation, as a pilot MDG project may not be much more expansive than a POC.

The scope of this POC project included the following:

Standard Vendor Master data model (out-of-the-box SAP MDG data model) with minor
modification of adding one new SAP data element that was not in the standard data model and one
custom data element;
Standard Vendor Master BRF+ workflow with minor modification one parallel approval
process was added to demonstrate parallel work flow process;

No integration with SAP ERP system was implemented, but output data from MDG was
exported for review after activation;

Standard MDG data and process monitoring analytics and KPIs were used to demonstrate
MDG master data governance monitoring capabilities.
After successful completion of this POC, the customer was satisfied that SAP MDG was able to
address its business requirements and replace the central ECC based master data system as well as
Lotus Notes based governance.
In the next article I will describe some of the MDG EhP 6.1 architectural decisions that were made
during the initial phases of MDG implementation.

pgrade, and address many other SAP challenges effectively based on their unique business
requirements.
Sunday, February 16, 2014

Case Study: SAP MDG Architecture Design

This is the second article in a series of SAP MDG case studies. Please refer to my previous blog
article that covers the first phase of this project as well as its background:
http://simonsayssap.blogspot.com/2014/02/case-study-mdg-implementation-atlarge.html
This article focuses on a very interesting aspect of this project analysis and design of SAP internal
architecture. By internal architecture I mean integration of MDG with SAP systems as well as
decisions regarding internal MDG architectural alternatives.

MDG Architecture Related Challenges

As discussed in the Background section of the first case study article, this customer had a very
complex SAP environment with multiple SAP systems.
Internal integration included the consolidated central SAP ECC instance, another ECC instance that
was left as a standalone and not integrated in the foreseeable future, SAP BPC system, SAP BW,
SAP APO, and SAP SRM. The solution also needed to support an interim phase to integrate with the
existing master data SAP ECC instance (eventually MDG was to replace this system).
In terms of functional scope, customer decided that MDG implementation would include all master
data objects including: Finance (Company, chart of accounts, cost centers, and profit centers), Partner
(both customer and vendor), and material master. Customer also needed to manage some nonstandard SAP data that included custom tables related to tax jurisdiction data, as well as manage
configuration data such as Company Code and possibly plant master.

MDG Hub vs. Co-Deployment Decision

The first important architectural decision was between Hub and Co-deployment. SAP supports both
options in implementing MDG.
Hub architecture is depicted in the following graphic.

In this architecture, MDG is setup as a standalone SAP ECC instance. It interfaces with other SAP
ECC instances via ALE interfaces (for reasons discussed later in this article).
Co-deployment architecture for this customer is depicted in the following chart.

As shown in this chart, in this option, MDG is co-located with the central SAP ECC instance.

The main benefits of the Hub deployment were identified as follows:

Flexibility to maintain separate upgrade and patching paths for MDG and ECC instances
MDG was a relatively new solution that may need to be upgraded and patched sooner and more often
than the ERP portion of ECC;

There was no need to do regression testing on ERP for every MDG upgrade and patch;

Higher flexibility for integrating with separate systems;

Easier to maintain reference/configuration data for different ECC transactional systems;

Avoided the conflict between SRM Server and MDG business function activation for Supplier
(SAP note 1491040) it is highly recommended to check for other possible conflicts during your specific
deployment;

May be easier to support dynamic business environment of mergers and divestments; and

SAP strongly recommended the Hub approach for large enterprises and complex landscapes.

The main benefits of the Co-deployment architecture were identified as follows:

Higher maintenance of the additional ECC landscape in terms of:

Security support

Basis support

Infrastructure support

Additional hardware required

Additional effort and complexity of maintaining synchronized configuration (IMG)
environments between SAP ERP/ECC and MDG/ECC instances
This customer agreed with my recommendation implementing MDG in Hub architecture for the
benefits presented above.

Interfaces Between SAP Systems

I recommended leveraging ALE interface technology for all interfaces between SAP MDG and other
SAP systems including the legacy SAP ECC central master data system. ALE is a proven technology
when it comes to interfacing SAP systems. This customers Basis support analysts had considerable
experience implementing and supporting ALE interfaces.
I recommended interfacing other SAP auxiliary systems directly with the SAP ECC central instance.
As depicted in the Hub chart above, these systems included SRM, BW, and APO. These systems
were to be interfaced with SAP ECC using the core-interface (CIF) technology delivered by SAP for
each system. Based on my experience, this is the most stable out-of-the-box way to interface these
systems. This customer had considerable experience using and managing CIF interfaces.
The one exception was the new BPC (SAP BusinessObjects Planning and Consolidation 7.5, version
for SAP NetWeaver). In previous version of BPC, SAP recommended to interface this system with
SAP BW. In earlier versions, BPC gott its master data (e.g., cost center and profit center hierarchies)
from SAP BW structures. However, in version 7.5 that this customer was implementing, BPC was able
to maintain its own master data objects and had capability to support file transfer of master data from
external systems directly into BPC. Initial discussion with customer finance business team and their
BPC implementation partner favored interfacing SAP MDG directly with BPC in a unidirectional mode
i.e., master data would originate in SAP MDG and be transferred via file transfer interface to BPC.
Please note, however, that this portion of implementation was not finalized while I was involved with
this project.
Integration with SAP Solutions Manager ChaRM system was considered in support of management of
configuration objects such as company code information. This interface is depicted in the chart below.

Please note that SAP does not support out-of-the-box interface between SAP MDG and Solution
Manager/ChaRM. I designed custom interface using ChaRMs interface with help desk systems.
The information flow and process steps were designed as follows:

Internal MDG Architecture Decisions

SAP MDG supports two main modes of data movement from Staged to Active databases SAP calls
them Flex and Re-use modes.
Staged data is temporary data that MDG maintains during the change request (CR) governance
process (i.e., when master data created or changed). When the master data is finalized, business
users (typically Information Stewards) activate the data. When the data is activated, it is moved to the
permanent Active database. Active database resides in separate MDG data tables in Flex mode and
in standard ERP tables (e.g., the MARA table for material master) in Re-use mode (hence the name
Re-use for reusing the ERP tables as Active database).
Re-use mode depicted in the following diagram.

In this mode, once the data is activated by a step in the change request (CR), the data is moved
directly into the Active database which is the SAP ERP standard master data tables. Re-use mode
can be implemented for both Hub and Co-deployment implementation alternatives.

The benefits of Re-use mode were identified as follows:

It was easier for users and support personnel to manage and query data in standard ERP
tables that they were already familiar with;

Re-use mode simplified integration did not require secondary messages for updating ERP
tables;

Re-use mode potentially minimized interface errors (fewer interface messages); and
Re-use mode had lower data storage usage (since data was stored in fewer tables throughout
the system).
Flex mode is depicted in the following diagram.

In this mode, Activation of the data moved the data into internal MDG Active database tables
(separate from ERP data dictionary tables). Then the data has to be replicated into the ERP master
data tables or into other external systems. This is typically done using the MDG DRF (data replication
framework) functionality. This mode is also supported in both Hub and Co-deployment.

It is important to note that in MDG EhP 6.1, MDG-F was supported only in Flex mode. It was
explained to me that the reason for this was the implementation of MDG editions (or affectivities) for
financial objects in SAP ERP that did not support this function.

The benefits of Flex mode were identified as follows:

MDG-F only supported Flex mode setting Flex mode for other master data
objects would provide consistency across MDG;

Flex mode provided decoupling between the MDG Data Model and ERP data
dictionary e.g., not every customer enhancement to the MDG data model required
modification to the ERP data dictionary;

Therefore, Flex mode would provide added flexibility to integrate with multiple
SAP and non-SAP systems;

This approach would allow for more effective debugging of update errors
(eliminating possible interface issues between systems);

Update of MDG ECC ERP tables could be turned off at any time with no impact to
MDG environment.
Ultimately, it was recommended and decided to implement MDG in dual mode Flex mode for
financial data and Re-use mode for partner and material data. This approach was to be evaluated
after completion of the initial testing and prior to go-live.
In the next article I will discuss architecture decisions with external systems.