Sizing Guide

DOCUMENT VERSION: 1.3 – 2019-11-13 INTERNAL

RELEASED FOR SAP CUSTOMERS AND SAP PARTNERS

Sizing SAP Master Data Governance 9.0

Internal | SAP Customers

Disclaimer

Some components of this product are based on Java™. Any code change in these components may cause
unpredictable and severe malfunctions and is therefore expressly prohibited, as is any decompilation of these
components.

INTERNAL
Sizing SAP Master Data Governance 9.0
2 Disclaimer
Document History

Version Date Change

1.0 2016-12-14
1.1 2017-11-02 Refinements in chapter “MDG on HANA”
1.2 2018-01-15 Refinements in chapter “Recommendations”
1.3 2019-11-13 Adjusted information classification and layout

INTERNAL
Sizing SAP Master Data Governance 9.0
3 Document History
Table of Contents

1 INTRODUCTION ..................................................................................................................................... 5
1.1 Functions of SAP Master Data Governance ........................................................................................... 5
1.1.1 SAP Master Data Governance for Financials ........................................................................................ 5
1.1.2 SAP Master Data Governance for Supplier .......................................................................................... 6
1.1.3 SAP Master Data Governance for Customer ........................................................................................ 6
1.1.4 SAP Master Data Governance for Material .......................................................................................... 6
1.2 Architecture of SAP Master Data Governance ....................................................................................... 7
1.3 Factors that Influence the Performance ................................................................................................ 7
2 SIZING FUNDAMENTALS AND TERMINOLOGY ....................................................................................... 9
3 INITIAL SIZING FOR SAP MASTER DATA GOVERNANCE ........................................................................ 10
3.1 Assumptions ....................................................................................................................................... 10
3.2 Sizing Guideline for SAP Master Data Governance .............................................................................. 10
3.2.1 Network Load ..................................................................................................................................... 11
3.2.2 Disk Sizing ........................................................................................................................................... 11
3.2.3 Recommendations ............................................................................................................................. 11
3.3 Sizing Guideline for SAP Master Data Governance on SAP HANA ........................................................ 12
4 COMMENTS AND FEEDBACK ............................................................................................................... 13

INTERNAL
Sizing SAP Master Data Governance 9.0
4 Table of Contents
1 INTRODUCTION
Master Data Governance (MDG) supports you in keeping your master data consistent even when your system
landscape is complex and distributed across various locations. MDG enables you to adjust your master data quickly to
reflect legal changes and respond flexibly to new requirements and to business transactions such as takeovers of
other companies. Master Data Governance also enables you to track changes made to master data.

1.1 Functions of SAP Master Data Governance

MDG offers you master data maintenance capabilities through a role-based domain-specific Web Dynpro user
interfaces or through Internet Service Request (ISR) forms. You can access the screens either through SAP Enterprise
Portal or through SAP NetWeaver Business Client. In addition to central maintenance, the maintenance of data from
external sources is supported too. For example, you can upload data into MDG using file or services, and then process
and enrich the data in MDG. You can also use the search capabilities. These include database search, exact or fuzzy
search using the SAP Enterprise Search, HANA search provider, and a fuzzy address search using SAP BusinessObjects
Address Services.

The data in process within so called change requests is stored in a separated repository called staging area, and is to
be transferred to the active area after its approval. The active area can be the operational SAP database or can be
generated within MDG. The data model in the standard delivery is based on SAP Business Suite, including financial
data, business partner data, and material data. It can be extended by the customer. There is available a single item
maintenance as well as mass maintenance.

The data can be validated against certain rules during entry or maintenance. The validation is done with SAP Business
Suite logic, wrapped by the Business Rules Framework (BRF+) and supported by SAP BusinessObjects Data Quality
Services or by external services. Customer specific validation logic can be added. During the validation the system also
checks for duplicates

Approved and activated data changes can be replicated to SAP systems and non-SAP systems. The replication is
controlled by the Data Replication Framework (DRF). This provides the flexibility to replicate the selected data to
specific client systems by defining filters. It supports peer-to-peer communication as well as replication by a broker
like SAP PI for example. The replication can be handled by various means, for example Enterprise Services, ALE / IDOC
or RFC. The DRF supports key mapping and value mapping and it monitors replication activities, failures and so on.

The replication can be started manually, it can be scheduled, or it can be triggered automatically as part of a
workflow. In order to support flexibility in data ownership, some data can be maintained in the MDG hub system and
other data can be added in the client systems after replication.

Change requests organize the data changes and the workflow across various users and they document all changes for
auditing purposes. Typically change requests are for a single master data object. If you want to synchronize multiple
changes, you can cluster them. This allows you to activate all approved change requests at the same time.

1.1.1 SAP Master Data Governance for Financials

MDG for Financials (MDG-F) enables you to manage financial-related master data. You can request, approve, and
execute changes to the data, as well as replicate those changes to decentralized systems by means of enterprise
services, application link enabling (ALE), download, or BW extractor. Web applications for this purpose are available in
the SAP NetWeaver Portal and SAP NetWeaver Business Client.

INTERNAL
Sizing SAP Master Data Governance 9.0
Introduction Error! Reference source not found. 5
MDG for Financials supports the approval process for master data changes, which can include several approval and
revision phases, and the collaboration of all users participating in the master data change. All changes to master data
are documented in the system. This, along with versioning of master data, promotes transparency and facilitates
adherence to statutory rules, especially when central and local users participate in the process.

You can replicate the master data from the system in which you have changed the data (Master Data Governance
hub) to decentralized systems, for example, consolidation, planning, ERP, and non-SAP systems.

1.1.2 SAP Master Data Governance for Supplier

MDG for Supplier (MDG-S) enables you to manage the master data for suppliers and using this process, you can
create, change, and delete supplier master data.

MDG for Supplier also supports the approval process for changes to supplier master data, which can include several
approval and revision phases, and the collaboration of all users participating in the creation and changing of supplier
master data. Data Quality Services such as address validation, duplicate check, data enrichment, as well as merging
process can also be included in the above-mentioned supplier processes.

All changes to master data are documented in the system, which increases transparency and avoids the creation of
duplicate information. In addition, all activities around the creation and maintenance of suppliers occur in the Supplier
Governance work center. Preconfigured workflows are provided to easily set up a distributed governance process
which involves several users.

You can distribute the created or changed master data from the system in which you change the data in MDG for
supplier, to the connected transactional systems, for example, SAP Enterprise Resource Planning (SAP ERP), SAP SRM,
or non-SAP systems.

1.1.3 SAP Master Data Governance for Customer

The main focus of MDG for Customer (MDG-C) is the governance of customer master data in a Master Data
Governance (MDG) hub system and the replication of data to connected systems, such as SAP Enterprise Resource
Planning (SAP ERP), SAP Customer Relationship Management (SAP CRM) systems or to non-SAP systems.

Using MDG for Customer, you can create, change or block customer master data and you can also mark it for deletion.
This process also supports the approval process for changes to customer master data, which can include several
approval and revision phases, as well as the collaboration of all users participating in the maintenance of the customer
master data. Data quality services, such as address validation, duplicate check, and data enrichment can also be
included in this process.

All changes to master data are documented in the system, which increases transparency and avoids the creation of
duplicate information. In addition, all activities around the creation and maintenance of customers occur in the
Customer Governance work center. Preconfigured workflows are provided to easily set up a distributed governance
process which involves several users.

New customers can also be created or changed on client side (SAP ERP, SAP CRM or non-SAP-systems). This customer
data is distributed to the MDG hub system where governance processes are triggered to ensure a high data quality.
The master data from MDG for customer is distributed to the connected transactional systems.

1.1.4 SAP Master Data Governance for Material

You can use MDG for Material (MDG-M) to find, create, change, and delete material master data. The main focus of
this process is the governance of material master data in a Master Data Governance (MDG) hub and the replication of

INTERNAL
Sizing SAP Master Data Governance 9.0
Introduction Error! Reference source not found. 6
master data, cleansed in the master data cleansing process, to connected operational and/or business intelligence
systems.

The processes are workflow-driven and can include several approval and revision phases, as well as the collaboration
of all users participating in the master data maintenance. All changes to master data are documented in the system.
The result is to have an improved process with increased transparency by having the material master data ready in
time and quality, and avoiding the costly creation of duplicate master data records.

All activities for the creation and maintenance of materials occur in one work center. Preconfigured workflows are
provided to enable you to easily set up a governance process involving several users.

1.2 Architecture of SAP Master Data Governance

Figure 1: SAP Master Data Governance

The Master Data Governance applications offer services for data cleansing, data matching and data consolidation.
They support the maintenance of data on a central system as well as data governance processes on client systems.
The client systems are integrated by service-based or by IDOC communication.

The diagram shows a potential structure of an MDG system landscape.

1.3 Factors that Influence the Performance

There are several performance consuming activities within MDG that have a major influence on the overall
performance of all MDG components, for example:

• Creations of change requests

• Standard search
• Complexity of the chosen UI layout (e.g. state of UI building blocks)

For further information see Performance Tweaks https://scn.sap.com/docs/DOC-48193

INTERNAL
Sizing SAP Master Data Governance 9.0
Introduction Error! Reference source not found. 7
• Workflow inbox

For further information see, chapter 3.2.3 Recommendations.

Be aware that this does not include the Enterprise Search, which might have additional influence on the overall
performance. For more information about the Enterprise Search, see Sizing Search and Classification (TREX).

INTERNAL
Sizing SAP Master Data Governance 9.0
Introduction Error! Reference source not found. 8
2 SIZING FUNDAMENTALS AND TERMINOLOGY

SAP provides general sizing information on www.sap.com/sizing. For the purpose of this guide, we assume that you
are familiar with sizing fundamentals. This section explains the most important sizing terms, as these terms are used
extensively in this document.

Sizing
Sizing means determining the hardware requirements of an SAP application, such as network bandwidth, physical
memory, CPU processing power, and I/O capacity. The size of the hardware and database is influenced by both
business aspects and technological aspects. This means that the number of users using the various application
components and the data load they put on the server must be taken into account.

Benchmarking
Sizing information can be determined using SAP Standard Application Benchmarks (www.sap.com/benchmark).
Released for technology partners, benchmarks provide basic sizing recommendations to customers by placing a
substantial load upon a system during the testing of new hardware, system software components, and relational
database management systems (RDBMS). All performance data relevant to the system, user, and business applications
are monitored during a benchmark run and can be used to compare platforms.

SAPS
The SAP Application Performance Standard (SAPS) is a hardware-independent unit that describes the performance of
a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) Benchmark, where
100 SAPS is defined as the computing power to handle 2,000 fully business processed order line items per hour. (For
more information about SAPS, see www.sap.com/benchmark → Measuring in SAPS).

Greenfield Sizing
Greenfield sizing refers to the sizing approach that provides statements about platform-independent requirements of
the hardware resources necessary for representative, standard delivery SAP applications. The initial sizing guidelines
assume optimal system parameter settings, standard business scenarios, and so on.

Expert Sizing
This term refers to a sizing exercise where customer-specific data is being analyzed and used to put more detail on the
sizing result. The main objective is to determine the resource consumption of customized content and applications
(not SAP standard delivery) by comprehensive measurements. More information can be found here.

Configuration and System Landscaping

Hardware resource and optimal system configuration greatly depend on the requirements of the customer-specific
project. This includes the implementation of distribution, security, and high availability solutions by different
approaches using various third-party tools. In the case of high availability through redundant resources, for example,
the final resource requirements must be adjusted accordingly.

INTERNAL
Sizing SAP Master Data Governance 9.0
Sizing Fundamentals and Terminology Error! Reference source not found. 9
3 INITIAL SIZING FOR SAP MASTER DATA GOVERNANCE

There are many parameters that may have an influence on the sizing and performance of an MDG installation. To give
a good estimation of hardware requirements we decided to provide a T-shirt sizing model considering the most
important influencing factors. Additional information will help you to optimize your business processes.

3.1 Assumptions

The business scenarios and measure environment used to create the sizing guide are as follows:

1. Launch the NWBC with the corresponding MDG work center

2. Launch the single application UI for creating a new material, supplier or account
3. Enter basic data specific for the new object, check the request and submit it
4. Activate the change requests and finish the MDG process
5. Changing existing material, supplier or account was done via MDG in a comparable way

• The scenarios are measured separately. For result calculation the process with the highest resource
requirement is taken. This is referred to in 3.2 as a single process per hour.
• A change request always contained only one material, supplier or account.
• The user is active in only one scenario at a given point in time.
• Unused UI building blocks are collapsed.
• Special one-time tasks are not subject of this guide. They may require higher resource consumption but
normally less concurrent users.

3.2 Sizing Guideline for SAP Master Data Governance

In the below tables we have categorized enterprises who will use MDG into three categories – Small, Medium and
Large. Their corresponding Memory and CPU consumption are mentioned – in dependency of each MDG domain.

Table 1 Aggregated Memory Consumption

Category for Enterprises Material [GB] Supplier / Customer [GB] Financials [GB]
Small (0–10 users) 6 6 6
Medium (10–50 users) 10 10 14
Large (50–100 users) 15 15 24

Table 2 CPU Consumption

Category for
Processes per Hour Material [SAPS] Supplier [SAPS] Financials [SAPS]
Enterprises

Small 200 3000 3000 2000

Medium 750 8000 11000 6000

Large 1500 16000 21000 11000

INTERNAL
Sizing SAP Master Data Governance 9.0
Initial Sizing for SAP Master Data Governance Error! Reference source not found. 10
 Note
The most important factor for CPU sizing in MDG is the number of processes per hour – you need to estimate how
many processes your users will run concurrently and then select the right category.

If you want to use several MDG domains in one system, select the appropriate number of processes for each domain
and calculate your requirements accordingly.

Example
You plan to use MDG-M and MDG-S in one MDG instance. Your estimated number of processes for MDG-M are 200
and for MDG-S 400.

200 MDG-M processes (3.000 SAPS) + 400 MDG-S processes (11.000 SAPS) = 14.000 SAPS for MDG.

CPU consumption increases with the complexity of the data model and with the number of active change requests
(change requests in process).

Memory consumption is correlated with the number of concurrent active users.

Note
With MDG7.0 Multiple-Records Processing is available. Even this could be a special one-time task, you may use this
function besides the regular master data governance for mass data processing. Depending on the targeted usage you
may need to enhance your CPU sizing by the corresponding factor.

Example
You plan to use Multi-Records Processing for master data governance. Your estimated number of processes shall be
20 per hour and the number of objects 100 per process. Adjust your CPU consumption per object by 0.5 SAPS.

20 MDG-M processes * 100 objects * 0.5 SAPS = 1.000 SAPS.

Add the additional required number of SAPS to your already estimated CPU consumption in order to meet the sizing
requirements.

3.2.1 Network Load

The average network load per process is 21 kB for all domains.

3.2.2 Disk Sizing

The table below mentions the disk usage for the complete process of the creation of one single object with basic data.

Table 3 Disk Usage

Disk Usage per Create Material [kB] Supplier / Customer [kB] Financials [kB]
MDG 6.5 7.2 2.7
Standard ERP 10.1 17.1 5.2

3.2.3 Recommendations

INTERNAL
Sizing SAP Master Data Governance 9.0
Initial Sizing for SAP Master Data Governance Error! Reference source not found. 11
Keep the number of active change requests per domain as low as possible, e.g. less than 50.000 (ideally < 10.000).

Keep the users’ workflow inbox clean, i.e. define and run regularly workflow clean-up and archiving tasks or reports.

In case you run MDG in a productive client for an extended period of time a large number of finalized change requests
are accumulated. Please follow note 2574330 to remove the finalized change requests from the system's database
reducing the size of the database and optimizing the performance of MDG.

For initial load of objects into the system it is recommended to load directly into active area using packages of less
than 100.000 objects (ideally < 10.000).

MDG is more CPU than memory demanding. Please assure to have the latest revision of CPUs in usage (comparison
e.g. via launch date and/or lithography). The reason is that besides clock speed, CPU performance depends on the
used instruction set.

3.3 Sizing Guideline for SAP Master Data Governance on SAP HANA

If you want to install MDG on a HANA database please follow the sizing guidelines for the SAP Business Suite. The
corresponding SAP note http://service.sap.com/sap/support/notes/1793345 provides detailed information. If you
need an initial estimate you can calculate it with the rules found in this note.

For the calculation of the disk usage of an installed MDG you can refer to Table 3 “Disk usage”. Multiply the required
disk space per object with the number of objects to be created in MDG. After that, transfer the gained value into your
HANA database calculation multiplied by the expected compression rate.

INTERNAL
Sizing SAP Master Data Governance 9.0
Initial Sizing for SAP Master Data Governance Error! Reference source not found. 12
4 COMMENTS AND FEEDBACK

Both are very welcome; please submit them to SAP Master Data Governance community homepage on SCN:
https://scn.sap.com/community/mdm/master-data-governance

INTERNAL
Sizing SAP Master Data Governance 9.0
Comments and Feedback Error! Reference source not found. 13
 www.sap.com/contactsap

© 2019 SAP SE. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National
product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This
document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be
changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All
forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking
statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product
and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.

Internal | SAP Customers