A detailed 7-step framework aligning SAP master data using TOGAF phases for business and technology integration.
In SAP and other ERP implementations, core master data such as customers, suppliers, materials, and G/L accounts is referenced and updated by multiple applications across the landscape.
When the Single Source of Truth is not clearly defined, and when it is unclear who is allowed to maintain which fields, you inevitably end up with duplicate masters, inconsistencies, and excessive authorizations.
On real projects, the following situations are very common:
These are not isolated configuration mistakes. They are symptoms of having moved forward without an enterprise‑level design for “Master Data × Applications × Authorizations”.
This is precisely the area that Enterprise Architects (EAs) should own and orchestrate.
In this article, using the TOGAF Architecture Development Method (ADM) as a conceptual backbone, I will walk through seven practical steps to design “which master is used in which application, and which roles can do what on it” in the context of an SAP implementation.
The TOGAF ADM is a framework for designing an integrated set of Business, Data, Application, and Technology architectures at the enterprise level.
If you apply the ADM way of thinking, you can structure “Master Data × Applications × Authorizations” into the following seven steps:
The crucial point is: do not start directly with SAP role design.
You first lock down business accountability and data ownership, then define application usage and role policies, and only after that do you break things down into concrete SAP roles and authorization objects.
Start by defining the objectives and guiding principles for master data and authorization design.
As Enterprise Architecture principles, it is helpful to articulate policies such as the following:
By documenting principles at this level as EA standards and guidelines, you can make consistent decisions later when exception requests inevitably arise.
Next, from a Business Architecture perspective, identify “which business processes bear what kind of responsibility for which master data objects”.
Treat master data as “information assets” and organize business accountability using a RACI‑style view.
Examples of key masters (assuming SAP S/4HANA):
Example: Process × Master × RACI for the material master
For the material master, you might define responsibilities like the following:
Once this RACI is agreed, the system team no longer has to shoulder the entire burden of deciding “Which department owns which field of the material master?”
Now take the business‑level responsibilities and break them down on the Data Architecture side to the “attribute” level.
Concretely, you create logical data models for key masters and assign responsible departments and roles for each attribute cluster.
Example: Attribute clusters for the material master
Example: Assigning responsibility by attribute cluster
By making “who owns which attributes” explicit in the data model, you avoid the risky situation where the material master is treated as a shared object that “anyone can change at any time”.
From the Application Architecture viewpoint, clarify “how each application uses which masters”.
Overlay master usage on an application landscape diagram.
Representative applications might include:
For each application, list:
Example: Simple matrix of Applications × Masters × Operations
By this point, you have an EA‑level view of “which masters are used by which applications”, which then becomes the basis for deciding “which applications are allowed to update which masters, and which must not”.
Once data and application responsibilities are visible, you can define “who can do what and to what extent” in a role‑based manner.
At this stage, you stay at the level of business roles, without yet naming SAP‑specific technical roles.
Example business roles (derived from the RACIs and data responsibilities):
Example: Role × Master × Operation matrix for the material master
By defining and approving this matrix as an “enterprise authorization policy”, you can later design SAP roles in a consistent way across modules and projects.
From here, you translate the business roles defined above into SAP roles and authorization structures.
In this article, we will focus on the structural concepts rather than deep SAP configuration details.
In SAP, authorizations are typically designed using a two‑tier structure:
From an Enterprise Architect’s standpoint, your responsibility is to define “which single roles should be grouped under which business role”, while Basis and security specialists handle the detailed authorization objects and field values.
For example, assuming S/4HANA material master, the key classic transactions might include:
For customers and suppliers, you would primarily use transaction BP and relevant Fiori apps, as S/4HANA harmonizes customer and vendor under the Business Partner concept.
At this stage, you map “which business role requires which operations (create / change / display)” back to the Role × Master × Operation matrix.
Example: Production Master Specialist
Example: General User
For Enterprise Architects, the key is to clarify the principles at the business‑role level so that the SAP security team can implement them consistently in concrete authorization objects and values.
If you let “which transactions each role can use” be determined ad‑hoc during the project, cleaning up later becomes extremely painful.
Finally, you need to embed the “Master Data × Applications × Authorizations” design into both the SAP implementation project and the ongoing run phase.
It is essential to keep all of this as EA‑owned standards, not as “one‑off project documents that die after go‑live”.
The Enterprise Architect’s role does not end with the initial design of “Master Data × Applications × Authorizations”.
By applying the same thinking to change requests and new systems, EA protects architectural coherence over the long term.
In SAP programs, attention often gravitates toward individual modules and screens, but the real success factor lies in master data and in the design of “who can touch what and to what extent”.
If you leave these questions entirely to each individual team, you end up with a collection of locally optimized settings that deviate significantly from overall optimization.
By grounding yourself in the TOGAF mindset—organizing master data accountability in Business Architecture, defining attribute‑level ownership in Data Architecture, clarifying application usage patterns in Application Architecture, and then designing role policies at EA level before mapping them into SAP roles—you can design “Master Data × Applications × Authorizations” end‑to‑end in a consistent way.
Enterprise Architects are not just diagram makers; they are the design guides for master data and authorizations, leading the project as a whole.
If you tailor the seven steps in this article to your specific master structures and industry context—whether automotive suppliers, process manufacturing, or trading companies—you can establish an architecture standard that is much more persuasive and easier to govern over time.
Please refer to this article for topics related to Enterprise Architecture (EA).
Enterprise Architecture – Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
A structured guide to the role of Enterprise Architects in SAP programs, aligned with TOGAF…
This article explains how enterprise architects can use TOGAF architecture patterns as reusable assets in…
A practical guide for aligning architecture vision, scope, and roadmap in SAP projects.
A practical guide for Enterprise Architects on using TOGAF Compliance Assessment in SAP implementations.
TOGAF Risk Management is not just about reading the PMO risk register. It is how…
A practical guide to applying TOGAF Capability-Based Planning in SAP projects, helping Enterprise Architects connect…