Recap: what is federated governance?
Federated governance is an alternative to managing master data completely centrally in an organization's system landscape. A federated approach balances central and de-central master data processes based on a clear data ownership model to make sure that data is created and changed exactly where it is best understood. Accordingly, in federated governance you have a core data owner (system) that is responsible for the enterprise-wide relevant master data attributes (core data), and you have de-central application data owners (systems) each of which is responsible for individual application-specific segments of the master data (application data).
As a White Paper by Bloor puts it: "This federated approach to master data allows local applications to manage the master data that they need for their local needs, while still conforming to the global standards that central office needs [...]."
Federated governance with SAP Master Data Governance on SAP S/4HANA 2023
As outlined in my recent blog post, SAP Master Data Governance (MDG) on SAP S/4HANA 2023 enables federated governance for business partner (incl. customer and supplier) data with MDG as the core data owner. Business partner data covered here includes core data such as addresses, roles, identification numbers, bank accounts, plus application data such as procurement, sales, and financial data.
Who can benefit from this deployment variant?
Organizations that already run SAP S/4HANA and have various SAP S/4HANA systems in their landscape can use federated governance to better balance central and decentral master data management activities in a networking landscape.
What are the main benefits?
Federated governance enables a faster time to value due to fewer upfront harmonization needs and increases the overall reach of master data management, for example, by covering application data (in the realm of application data owners) that was left untouched in centrally managed MDG.
What are the key processes (from the core data owner’s perspective)?
In a federated set-up, the creation or change of business partner (customer, supplier) data can start centrally or de-centrally (both for single and mass maintenance), for example in:
- SAP Master Data Governance on SAP S/4HANA (core data owner or application data owner)
- SAP applications (e.g., SAP S/4HANA, SAP Ariba Supplier Lifecycle and Performance)
- Non-SAP applications
The consolidation of master data always starts in the core data owner:
- All relevant data from source system(s) are imported to the core data owner.
- Core data is matched and merged.
- Application data is replicated to the respective application data owners for merging.
The end-to-end process monitoring in the core data owner includes all process steps across participating systems. It displays the progress of already executed steps.
Fig.: SAP Fiori Launchpad with Process Path Overview app
Fig.: Visualization of steps in single processing
Fig.: Visualization of steps in mass processing
Fig.: Process analytics to monitor and analyze MDG processes across systems
What are the key processes (from the application data owners’ perspective)?
Application data owners can be connected via SOAP integration. Systems consuming data only from core data owner can be integrated either via SOAP or MDI (Master Data Integration) or RFC/IDOC.
- There can be several application data owners in the system landscape.
- During the federation process, the core data owner informs all application data owners enabling them to check and enhance their data.
- Incoming data is checked (without merge) and corrected, if required.
- The application data owners process incoming matches from the core data owner and decide on merging their data with the best record.
- The application data owners replicate the changes on their data back to the core data owner.
- At the end of the federation process the application data owners receive the validated record from the core data owner.
Fig.: Example process flow in federation with SAP Master Data Governance on SAP S/4HANA as core data owner
In this example, the creation / change of a business partner is initiated in the SAP Sales Cloud (which participates in the federated scenario, but neither as a core data owner nor as an application data owner). You can see the interaction (process flows) between SAP Sales Cloud, SAP Master Data Governance on SAP S/4HANA (core data owner), the regional application data owners, and other applications.
How is this implemented (rough sketch)?
To use federated MDG, the following prerequisites must be met:
- Cloud-ready mode is active (as outlined in this blog post).
- You configured SAP Build Process Automation on SAP Business Technology Platform (BTP) for the usage of workflow.
Setting up federated governance with SAP Master Data Governance on SAP S/4HANA consists of the following basic steps:
- Set up federation in SAP Master Data Governance
- Define the core data owner
- Define application data owners
- Choose predefined processes and workflows
- Adapt as necessary
- Configure master data ownership
- Done once, centrally in SAP Master Data Integration
- For example, defining core data owner by assigning the relevant system to field group “Central” as data owner
- Use predefined MDG process templates
- Provided in SAP Customizing, for the core data owner and for application data owners
- Apply workflow templates
- Approval, rework, review
Fig.: Defining data ownership
Data ownership can be defined for each system in the landscape. There is one core data owner and several application data owners in the system landscape. It is defined by Field Groups like, e.g., Central, Identification, Bank account, etc. A Field Group, e.g., Identification, can be assigned to several systems, appropriate filter settings avoid overlaps. When defining ownership on a hierarchical structure, the definition applies from the selected node down to the leaves.
Fig: Process templates for core data owner and application data owner
Process automation
The process templates are geared towards automation: In addition to process templates for manual intervention, there are templates for automation for both core data owner and for application data owners.
- For core data owner: automating consolidation of source records and maintenance of business partner data. This includes client maintenance processes (decentralized maintenance) as well as single and mass request processes.
- For application data owners: automating approval and merging of business partners within the inbound process, while automating mass and single request processing for business partner data. Includes derivations of organizational data, that is, derivation of the values of fields or creation and update of dependent entities (for example, create organizational purchasing data when a supplier is created). When a derivation scenario is executed in federated master data governance in an inbound process with goal Inbound Process Approve or Inbound Process Merge, the data ownership is checked. If you want to derive data that is not owned by the current system, you get a notification, and the derivation scenario is not executed.
Summary
Today, most companies take a monolithic approach to master data management, using, for example, one central SAP MDG system to manage key master data for the entire enterprise, and this is perfectly fine. In fact, there are companies that prefer a more modular approach where master data management is well balanced between central and de-central systems. For these companies, federated governance with SAP Master Data Governance on SAP S/4HANA as core data owner can be the right choice, and there is an evolutionary path to get there.
More information
For details about federated governance with SAP Master Data Governance on SAP S/4HANA as core data owner, see:
To stay up to date with MDG, simply follow the SAP Community Topic Page for SAP Master Data Governance, join the Questions & Answers forum and Blog space, and check the MDG roadmap for all deployment versions.
Best,
Markus
- SAP Managed Tags:
5 Comments
