Architecting Enterprise Authorization Governance Across ECC, S/4HANA and BTP Landscapes

Explanation

Authorization architecture at enterprise scale is not a single role design exercise; it is an ongoing governance discipline that must survive system upgrades, landscape consolidation, cloud extension projects and organizational change. An architect's responsibility goes beyond building correct PFCG roles for a single S/4HANA instance: it means defining how authorization decisions are made, documented, tested and reviewed across a hybrid landscape that may include classic ECC, S/4HANA private cloud or on-premise, S/4HANA public cloud (with its restricted business role framework), and BTP-based extensions with their own IAS/IPS identity and role-collection model. A core architectural decision is the target role design pattern: single-role composite model versus derived-role hierarchies versus a hybrid catalog-driven model aligned to Fiori business roles in S/4HANA public cloud. Each has different maintenance costs. Derived roles reduce duplication of authorization objects while allowing organizational-level values (company code, plant, purchasing org) to vary per derived child, but they increase the number of objects to test and can create hidden coupling if the master role's menu changes unexpectedly. Composite/business roles aligned to Fiori catalogs and spaces simplify end-user assignment but can obscure the underlying technical authorization objects from auditors unless documentation traceability is maintained. The architecture must document which pattern is used per landscape layer and why, since public cloud environments constrain customization to SAP-delivered business roles and catalogs, meaning the governance model there is largely about catalog/scope-item mapping and extension role creation rather than free-form PFCG object tuning. Governance must also address the boundary between technical and business ownership. Role content (which transactions, Fiori apps, or scope items belong in a role) should be owned by business process owners; the technical implementation (authorization objects, field values, derivation logic) is owned by security engineering. A RACI model prevents both under-provisioning (business complains, security rubber-stamps SAP_ALL-style fixes) and over-provisioning (business never reviews access because security decided everything). Recurring user access reviews and SoD rule set reviews should be scheduled against a defined cadence, ideally supported by a GRC access risk analysis tool, with remediation SLAs tracked as an operational metric, not a one-time audit deliverable. A second major architectural concern is the identity and trust model across systems. In hybrid landscapes, users may be provisioned centrally through an identity provider federated to S/4HANA and to BTP subaccounts via IAS. Role assignment logic (business roles in BTP mapped to identity attributes, PFCG roles mapped to organizational assignment in HR or a similar source of truth) must be reconciled so that a leaver or role-change event propagates consistently to all layers. Failure to design this consistently produces orphaned access: a user removed from an S/4HANA PFCG role but still holding an active BTP role collection with broad scope, or vice versa. Migration and coexistence add further complexity. During ECC-to-S/4HANA transitions, dual-maintenance periods are common; architecture should define a single authoritative role source (even if technically materialized separately per system) and a mapping/traceability matrix so that when S/4HANA introduces new or renamed authorization objects (particularly around Fiori-specific objects and simplified transaction codes), the change impact on existing roles is assessed rather than roles being blindly copied. A common but costly mistake is a lift-and-shift of ECC roles into S/4HANA without re-validating object relevance, resulting in bloated, non-least-privilege roles that undermine both security and system performance monitoring efforts (unnecessarily broad table/BAPI authorizations that also complicate performance and audit trace analysis). Finally, the operating model must define incident response and emergency access processes (firefighter/emergency access management), rollback procedures for role changes (versioned role transport with documented approval gates), and metrics for authorization health, such as trace-based least-privilege coverage, count of critical SoD violations, and average remediation time. These are the levers an architect uses to demonstrate that the authorization program is a managed control, not a static artifact frozen at go-live.

Code example

* Illustrative governance artifact, not executable code:* Example role ownership and change-control matrix entry (documentation pattern) Role: Z_FI_AP_CLERK_APACBusiness Owner: AP Process Lead (APAC)Technical Owner: Security Engineering TeamSoD Risk Class: Medium (Vendor Master change + Invoice Post)Derivation Base: Z_FI_AP_CLERK_TEMPLATEOrg Levels Derived: Company Code (APAC entities only)Change Control:  1. Business owner submits access change request via ticket  2. Security engineer drafts PFCG change in DEV  3. GRC risk analysis run against updated role (pre-transport)  4. Approval by both owners recorded in change ticket  5. Transport to QA, regression test with representative test user  6. Transport to PROD only after signed approvalRollback Plan: Prior role version retained in transport history; revert transport if post-go-live incident raised within 5 business days. * This pattern is deployment-agnostic documentation; actual field names/tools* (e.g., specific GRC product screens) vary by organization and are not* assumed here.

Real project scenario

A multinational manufacturer running ECC for 12 years began an S/4HANA private cloud migration while simultaneously piloting BTP-based extension apps for a subset of plants. The security architect discovered that ECC roles had accumulated years of ad hoc additions with no consistent ownership record, and ad hoc BTP role collections were being created directly by an integration team without security review. The architect introduced a governance model separating business and technical role ownership, established a mapping matrix from legacy ECC roles to redesigned S/4HANA least-privilege roles validated by trace data (per earlier lessons in this topic), and required all new BTP role collections to go through the same change-control gate as PFCG roles, including SoD risk analysis extended conceptually to cover cross-system scenarios (a user with S/4HANA vendor-master access plus a BTP extension role capable of triggering payment-related integration calls). This reduced audit findings significantly at the next compliance review cycle and gave the business a documented, defensible rationale for every access grant.

Common mistakes

• Copying ECC roles into S/4HANA without reassessing authorization object relevance, inflating access beyond least privilege • Treating BTP role collections and PFCG roles as unrelated governance domains, creating cross-system SoD blind spots • Allowing technical teams to own business role content decisions, removing business accountability for access risk • Skipping a formal change-control and approval trail for role modifications, making audits and rollback difficult • Assuming public cloud business role/catalog constraints eliminate the need for governance, when scope-item mapping still requires review • Running SoD/risk analysis only once at go-live instead of on a recurring operational cadence • Failing to define an authoritative identity source of truth, leading to orphaned or duplicated access across systems

Best practices

• Define explicit business and technical ownership for every role, documented and reviewed periodically • Maintain a mapping/traceability matrix when migrating roles from ECC to S/4HANA rather than direct copy • Extend SoD and access risk analysis conceptually across system boundaries, including BTP-provisioned access • Establish a single authoritative identity/HR source of truth feeding role assignment across all layers • Require versioned transport and documented approval gates for all role changes, with a rollback plan • Schedule recurring user access reviews and SoD rule reviews as an operational control, not a one-time audit task • Track authorization health metrics such as SoD violation counts and remediation SLA adherence over time • Clearly document deployment-specific constraints (public cloud business role restrictions vs. on-premise PFCG flexibility) in governance materials

Interview angle

Architect-level interviewers assess whether a candidate can reason about authorization as an ongoing governance program rather than a one-time technical build. Expect questions on how you would design role ownership across business and technical teams, how you reconcile identity and access lifecycle across ECC, S/4HANA and BTP, how you handle SoD analysis in hybrid landscapes, and how you structure change control with rollback for role transports. Strong answers reference concrete artifacts (RACI, mapping matrices, approval gates, recurring review cadence) rather than only naming tools, and clearly separate what differs between on-premise/private cloud flexibility and public cloud business-role constraints.