Master Data Governance: Architecture and Use

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 12, 2026 · 17 min read

Where This Article Sits#

References#

1) The Master Data Governance Landscape#

SAP Master Data Governance combines distinct capabilities addressing different phases of the master data lifecycle. Understanding which capability applies to a given requirement prevents misscoping.

These capabilities operate together in a governance pipeline, not independently. They are not substitutes.

2) How It Connects to S/4HANA#

MDG is embedded in SAP S/4HANA — not a separate SaaS service bolted on. Every deployment involves an S/4HANA system acting as the MDG platform, either exclusively (hub) or alongside transactional work (co-deployment).

                    ┌─────────────────────────────────────┐
                    │        MDG Hub (S/4HANA)            │
                    │                                     │
  Source Systems ──►│  Consolidation  ──►  Central Gov.  │
  (ECC, legacy)     │  (dedup, match)     (CR workflow)   │
                    │                         │           │
                    │                    Activation &     │
                    │                    Staging Area     │
                    │                         │           │
                    └─────────────────────────┼───────────┘
                                              │
                            ┌─────────────────▼──────────────────────┐
                            │    Data Replication Framework (DRF)    │
                            │   IDocs / SOA / RFC / File             │
                            └─────┬──────────┬──────────┬────────────┘
                                  │          │          │
                         ┌────────▼──┐  ┌────▼────┐  ┌─▼──────────┐
                         │ S/4HANA   │  │ Legacy  │  │ Non-SAP    │
                         │ (client)  │  │ SAP ECC │  │ via MDI /  │
                         └───────────┘  └─────────┘  │ Event Mesh │
                                                      └────────────┘

In cloud scenarios, SAP Master Data Integration (MDI) on BTP sits between MDG and cloud line-of-business applications, using the SAP One Domain Model to normalize data across the intelligent suite. SAP Cloud Integration (CPI) handles legacy and non-SAP system connections as middleware.

Key point: DRF is the distribution backbone in all MDG deployments — even co-deployment scenarios using MDG-F (Flex mode) require DRF configuration to distribute data to consuming processes.

3) Maturity Map#

Cloud-ready mode was introduced with SAP S/4HANA 2023 and follows clean core principles; classic mode remains available for all domains from earlier releases.

4) Requirements Checklist#

The MDG Consolidation and Central Governance documentation describes the change request model that all checklists below are designed to scope.

Deployment model prerequisites#

Data domain and scope prerequisites#

Workflow and governance process prerequisites#

Integration and distribution prerequisites#

Data quality management prerequisites#

5) Decision Criteria#

The three questions to ask first#

Q1. What specific, measurable master data problem is driving this project?

MDG implementations without a concrete problem statement routinely lose momentum after initial design workshops. Before selecting any deployment model, the project sponsor must articulate the pain point in measurable terms: number of duplicate records, failed integrations per month, audit findings, or data-related posting errors. If the answer is “data quality is generally poor,” that is a research finding, not a project scope.

Q2. Who owns the master data and where does it currently live?

MDG does not replace data ownership — it formalizes and enforces it. If the organization has not agreed on which system is the master of record for each domain, no workflow configuration will resolve the underlying political problem. Data residency requirements (GDPR, local regulations) also affect whether MDG Cloud Edition on BTP is permitted or whether on-premise deployment is mandatory.

Q3. Is there a named sponsor with budget authority and organizational authority over the data-owning business units?

MDG spans multiple business units — Finance owns G/L accounts, Procurement owns vendor data, Sales owns customer data. Implementations without a cross-functional sponsor who can commit named data owners and approvers from each domain stall at workflow design.

Domain selection by project context#

Per the MDG S/4HANA FAQ, the recommended starting point varies by organizational context:

Licensing and cost#

Note: detailed pricing for hub vs. co-deployment infrastructure is not publicly documented by SAP; engage the SAP licensing team or an SAP partner for specific cost modelling.

6) Common Failures#

The following failures are documented patterns at the requirements stage, not implementation bugs. See the MDG on S/4HANA FAQ for additional integration and scoping guidance.

Failure 1: Scope assumption — treating MDG as a data migration tool

MDG’s consolidation capability handles deduplication and best-record selection, making it useful during data migration phases. Projects that treat MDG purely as a migration tool fail to scope the central governance and distribution layers that deliver ongoing value. MDG is configured, migration completes, and MDG is then effectively abandoned — governance workflows never go live because the business case for post-migration operation was never established. Always scope MDG for steady-state governance, not just initial load.

Failure 2: No committed data owners before workflow design begins

Change request workflows require named approvers. Workshop participants often agree conceptually on who should approve what, but without explicit commitment from business unit managers, the workflow design contains placeholder roles that are never filled. This surfaces during testing when approval steps have no assignees and change requests stall. Confirm named data owners and their backup arrangements in writing before BRFplus workflow configuration starts.

Failure 3: Exception handling omitted from workflow design

BRFplus workflows are configured for the happy path — creation and approval of standard change requests. Rejection paths, escalation timers, and handling for incomplete submissions are regularly skipped. In production, rejected change requests with no escalation path sit in queues indefinitely, blocking master data distribution. Every workflow must have explicitly designed rejection, timeout, and escalation branches before go-live.

Failure 4: DRF configuration scope underestimated

Projects identify the MDG hub and the primary receiving system but miss additional targets: reporting systems, archived legacy ECC instances, third-party middleware. DRF requires a separate replication configuration per target, including field mapping and error handling. Discovering additional target systems during integration testing — rather than requirements — extends the timeline and requires rework of the replication design. Run a complete system landscape inventory before DRF design begins.

Failure 5: Data governance delay — quality rules defined too late

BRFplus data quality rules require concrete definitions from the business: what constitutes a valid address, which fields are mandatory for which business partner roles, acceptable ranges for financial account attributes. These definitions depend on business input that data teams cannot substitute. When quality rule definition is deferred to after system configuration, the go-live date slips or the system goes live with placeholder checks that do not enforce real governance. Initiate quality rule workshops in parallel with technical design, not after it.

Failure 6: Classic mode and cloud-ready mode coexistence mismanaged

Organizations upgrading to S/4HANA 2023 and adopting cloud-ready mode for business partner while retaining classic mode for other domains must maintain two parallel governance configurations. The coexistence is supported, but it requires a clear migration plan with explicit cutover criteria. Projects that begin cloud-ready mode adoption without documenting the classic-to-cloud-ready migration boundary end up with inconsistent governance behavior — some records governed through cloud-ready workflows, others still routed through classic mode.

Failure 7: MDI integration architecture not scoped until post-go-live

When an organization runs both on-premise MDG and SAP cloud LoB applications (SuccessFactors, Ariba, field service), MDI on BTP is the integration hub for synchronizing master data across these systems. Projects that go live with DRF-only replication without designing the MDI architecture later discover that cloud LoB applications are receiving master data through ad-hoc point-to-point connections or not at all. MDI scope must be assessed during requirements, even if implementation is phased.

FAQ#

Q: Does MDG run on SAP S/4HANA Cloud (public cloud) or only on S/4HANA on-premise?

MDG classic mode and cloud-ready mode are available on SAP S/4HANA on-premise and SAP S/4HANA Private Cloud Edition. They are not available on SAP S/4HANA Cloud (public cloud / multi-tenant). For organizations on S/4HANA public cloud, SAP Master Data Governance Cloud Edition (SaaS on BTP ABAP Environment) is the relevant option, currently scoped to the business partner domain.

Q: What licenses are required for MDG, and is it included in a standard S/4HANA contract?

MDG on SAP S/4HANA is generally included in S/4HANA licensing for standard domains in most packages, but the exact entitlement depends on the specific edition and contract. MDG Cloud Edition requires a separate SaaS subscription. SAP Master Data Integration (MDI) on BTP is a separate service. Always verify entitlement with the SAP account executive before scoping — do not assume MDG is included without explicit confirmation.

Q: When should MDG be descoped from a project?

MDG should be descoped when the organization cannot commit named data owners and approvers to operate governance workflows after go-live. Without committed human governance, MDG becomes an expensive change request queue that no one processes. It should also be descoped if the master data domain is fully managed by a third-party system with no requirement for centralized S/4HANA governance, or if organizational maturity for formalized data governance does not yet exist.

Q: What is the difference between hub deployment and co-deployment, and how do I choose?

Hub deployment provisions a dedicated SAP S/4HANA instance running only MDG processes. It provides clear separation of governance from transactional workloads and supports larger multi-system landscapes. Co-deployment activates MDG on an existing S/4HANA transactional instance, eliminating a separate system and removing cross-system replication latency. Co-deployment is preferred when the organization standardizes on a single S/4HANA instance; hub deployment is preferred in complex multi-system landscapes where governance must be independent of any single transactional system.

Q: How should the MDG requirement be documented in a business case or scope document?

The MDG requirement should document: (a) the specific master data domain in scope, (b) the governance problem expressed as a measurable current-state metric, (c) the named data owner(s) and their organizational position, (d) the target systems that will receive governed master data via DRF, and (e) the deployment model selected with rationale. A scope document that states only “implement MDG for master data quality” has insufficient specificity to begin design workshops.

Q: Can MDG coexist with classic mode and cloud-ready mode at the same time?

Yes, coexistence of classic mode and cloud-ready mode is supported on SAP S/4HANA 2023. Organizations adopting cloud-ready mode for business partner can continue operating classic mode for product and financial domains simultaneously. The coexistence requires explicit configuration to route change requests to the correct mode, and a migration plan should document when classic-mode configurations will be retired.

Q: How does federated master data governance differ from centralized MDG hub governance?

In centralized hub governance, a single MDG instance is the authoritative master and all change requests flow through it before distribution. In federated governance (available from S/4HANA 2023), data ownership is distributed: a core data owner manages core attributes (name, address, identifiers) while application data owners manage their application-specific attributes independently. The core data owner coordinates the process and distributes the final state. Federated governance suits large enterprises where different business units have legitimate ownership of distinct attribute sets.

Summary#

SAP Master Data Governance provides the workflow, quality, and distribution infrastructure needed to turn master data management from an aspiration into an operational process. The architecture choices — hub vs. co-deployment, classic vs. cloud-ready mode, centralized vs. federated governance — reflect organizational, landscape, and roadmap constraints that must be surfaced in requirements.

The most dangerous assumption in MDG implementations is that the technology solves the governance problem. MDG operationalizes governance that humans must define and commit to. Before configuring a single workflow, a project needs named data owners, defined change processes, scoped domains, and a complete inventory of systems that will receive distributed data. The SAP MDG product documentation details the capabilities; getting these four organizational inputs in place before design is the highest-value activity a consultant can perform on an MDG engagement.

What to Read Next#