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.