The Power of One: How Unified SAP Joule Boosts AI Adoption (a technical sight)

[normann]

Short read. Big pictures.

What is ‘Unified SAP Joule’? One Joule for all SAP solutions, independent of the underlying tech stacks. (End users know ‘SAP,’ not SFSF/S4/BS, etc.)

Why unify? Better user acceptance → better adoption. If users don’t accept it, they won’t adopt it.

How to get there? Use the SAP IAM Reference Architecture for SAP Joule as the backbone, following down below:

1) Overview

Everything SAP‑labeled shows up to the corporate IAM/IdP as SAP Cloud Identity (SCI). Inside the SAP domain, identities & authorizations are unified so the landscape can be SAP‑managed later. User management, role/group assignment, and authentication all go through SAP Cloud Identity Services.

 

2) Common Data Model (CDM)

At design time – when activating SAP Joule, each business solution (e.g., S/4HANA) exposes its Joule capabilities via CDM. Joule functions map to business roles; CDM content is deployed to SAP Build Work Zone (WZ); Roles defined in CDM appear as roles in Content Manager.
E.g. S4 HANA Capability <-> S/4 HANA Business Role <-> CDM role <-> Role in WZ <-> Capability in WZ.
Given that, SAP Joule knows at DT what authorizations a user need for which capability.

3) Sync of Authorizations

Roles/groups and identity assignments from business solution (S/4 HANA, SuccessFactors, …) synchronize into Work Zone. Synchronizing groups and assignments into SCI are optional today and may become required if WZ polls SCI. Third‑party IAM can assign groups to users via SCI; Work Zone’s user store is independent of XSUAA.

4) Sync of Identities

Identities flow through SCIM to your identity management, centrally governed across SAP. The Global Unique User Identifier is synchronized from SCI into the business solutions.

5) Authentication Flow

All authentication goes through SAP Cloud Identity Services (IAS), enabling principal propagation behind the scenes (later more). This is the basis for Unified SAP Joule and prepares the path for SAP‑managed connectivity when new services are subscribed.

6) Example: End‑to‑End Authentication

1. User opens Joule.
2. Joule asks IAS to authenticate user; Optional: IAS forwards authentication to Corporate IdP and enriches token with IAS information (GUUID) after authentication (identity federation).
3. User is authenticated to use Joule while Joule knows, which capabilities the user is allowed to use.
4. User is calling a Joule capability (e.g. Create leave request).
5. Joule asks IAS for a token for this specific identity for the business solution of the capability to be called.
6. IAS is handing out the token.
7. Joule can authenticate as the user to the business solution (principal propagation).
8. Joule calling the function module inside the business solution in the name of the user.

This illustrates the importance for all solutions and the BTP within this scenario to trust the same authentication instance (IAS).

7) 3rd‑Party Identity Management (where it fits)

• Identity sources: SFSF (internals), Fieldglass (externals), or AD.
• Synchronization of users between SFSF and SCI.
• GUUID is written back to SFSF.
• Groups originate in SaaS solutions and show as SCI groups can sync to 3rd-party IAM.
• S/4 HANA roles can sync to 3rd‑party IAM.
• Management split:
  • BTP & SaaS via SCI.
  • S/4 HANA via IAM directly plus GUUID provisioning:
    • IAM reads from SCI and provisions to S/4 HANA, or
    • SCI reads from S/4 HANA and writes back UserID+GUUID only;
    • Both option align with the reference architecture.

Final thought

Unify identity and auth once → unlock Joule everywhere. Less friction. More adoption. Happier users. 🎯

Public source for architectural drawings: IAM Reference Architecture for SAP Joule in Architecture Center