The MDG Lab

SAP MDG Deployment Options :

 

Implementing SAP Master Data Governance (MDG) isn’t just a technical install—it’s a strategic choice. Depending on your IT landscape and how “centralized” you want your control to be, SAP offers three main paths.

 

 

1. The Co-Deployment Model: Governance from Within s/4

 

TML #4.1 SAP MDG CO-Deployment 

Think of Co-Deployment as “Embedded Excellence.” In this scenario, MDG lives directly inside your existing SAP S/4HANA environment. It operates in the same digital “house” where your daily sales, finance, and procurement transactions occur.

• The Workflow: Data is governed, validated, and approved in the exact same system where it is eventually used.

• The Advantage: Since there is no “middleman,” you don’t have to worry about complex data replication between different systems. It keeps your IT landscape lean and your total cost of ownership (TCO) low.

• The Ideal Match: This is the go-to for organizations running a single-instance SAP S/4HANA strategy. If you want a straightforward setup with minimal integration hurdles, this is your winner.

2. The Hub-Deployment Model: Your Central Command Center

 

TML #4.2 SAP MDG HUB-Deployment 

In a Hub setup, MDG acts as a standalone “Control Tower.” It runs on its own dedicated SAP S/4HANA or ECC system, completely separate from your transactional “spoke” systems.

• The Workflow: Master data is brought into this central hub to be cleaned, consolidated, and validated. Once it passes the test, the SAP Data Replication Framework (DRF) automatically pushes that “gold standard” data out to all your other systems—whether they are SAP or third-party platforms.

• The Advantage: It offers massive flexibility. You can upgrade your MDG hub without touching your ERP systems, and it provides a single source of truth for diverse, global landscapes.

• The Ideal Match: Perfect for large-scale enterprises with a “heterogeneous” landscape (a mix of different systems). If you need to manage data across multiple business units and various software providers, the Hub is your best friend.

Comparison Table: Deployment vs. Governance Scope

 

 

Navigating the Data Layers of SAP S/4HANA: From System Architecture to Daily Transactions

 

TML #4.3 The S/4HANA Data Hierarchy

Understanding the architecture of SAP S/4HANA starts with understanding its data. While a user might only see a “Sales Order,” that single document sits atop a sophisticated hierarchy of system, organizational, and master data.

 

Here is a breakdown of the four essential data types that keep the S/4HANA digital core spinning.

 

1. System Data The Digital Bedrock

 

Before a single business transaction can occur, the system itself must be defined. System Data is the foundational “DNA” of your SAP environment. It doesn’t describe your products; it describes how your software behaves.

• The Technical Landscape: Includes metadata, transport routes, and landscape information (Dev, Test, Production).

2. Organizational Data: The Business Skeleton

Organizational Data represents the legal and physical structure of your enterprise. It is the framework that maps your company’s real-world hierarchy into the digital system.

• Finance (FI): Defines legal entities (Company Codes) and consolidation units.

• Materials Management (MM): Defines physical locations like Plants and Storage Locations, or procurement units like Purchasing Organizations.

• Sales & Distribution (SD): Structures your market reach through Sales Organizations, Distribution Channels, and Divisions.

Pro Tip: Organizational data is relatively static. Once a “Plant” or “Company Code” is set, it rarely changes, providing a stable anchor for all other data types.

3. Master Data: The Single Source of Truth

If Org Data is the skeleton, Master Data is the muscle. This is the core business information—customers, vendors, and materials—that remains consistent over long periods. In S/4HANA, the goal is a “Single Source of Truth.”

• The Business Partner (BP) Approach: S/4HANA mandates the BP model, unifying “Customer” and “Vendor” into one central object.
• Material Master: A 360-degree view of your products, containing everything from weight and dimensions to valuation and sales tax.
• Financial Master Data: This includes the General Ledger (G/L) accounts, cost centers, and profit centers that drive your reporting.

4. Transactional Data: The Pulse of the Business

Finally, we have Transactional Data. This is the high-volume, dynamic data generated by day-to-day operations. It is the “who, what, when, and how much” of every business event.

• Characteristics: It is time-stamped, highly volatile, and dependent on Master Data. You cannot create a Purchase Order (Transaction) without a Vendor (Master Data).
• Lifecycle: While it flows into real-time analytics for immediate decision-making, it is eventually archived once the business process is complete to keep the system lean.
• Examples: Sales orders, journal entries, production orders, and material movements.

 

In SAP MDG, data is stored using a two-layer architecture designed to separate “draft” governance from “active” operational data. This ensures that only high-quality, approved information reaches your production tables.

Here is the breakdown of how data is stored:

1. The Staging Area (The “Draft” Zone)

When you create or change a record in MDG, it is not immediately saved to the standard SAP tables (like MARA or BUT000). Instead, it is stored in the Staging Area.

• Storage Mechanism: MDG automatically generates internal technical tables (often starting with /1MD/ or USMD*) based on your Data Model (e.g., BP, MM, OG).
• Purpose: It holds the data while it is being validated, enriched, and approved through a Change Request (CR).
• Data Isolation: Multiple users can have different Change Requests for the same object without affecting the current active record.

 

2. The Active Area (The “Final” Zone)

 

Once the Change Request is fully approved and activated, the data moves from the Staging Area to the Active Area. Where it goes depends on the Data Model Type:

• Reuse Model (e.g., Business Partner, Material): The data is written directly into the standard SAP backend tables (e.g., MARA for Materials, BUT000 for Business Partners). The system “reuses” existing structures.
• Flex Model (e.g., Financials, Custom Objects): The data stays within the MDG-generated tables but is marked as “Active.” It does not automatically flow into standard ERP tables unless you replicate it.