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-at-large.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 non-standard 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 customer’s 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 ChaRM’s 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.

Case 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.