The 11 Layers Between Joule and Your SAP Data
Joule isn't a feature toggle. It's an 11-step integration spanning IAS, BTP, Work Zone, and S/4HANA — and each layer is a governance gap nobody is auditing.
I've lost count of how many conversations I've had where someone tells me they're "turning on Joule" like it's a Fiori checkbox. It isn't. Not even close.
Joule runs on BTP. It authenticates through IAS. It renders through Work Zone. It consumes content from S/4HANA via Fiori Launchpad exposure. Between the user's question and the system's answer, the request crosses 11 distinct integration layers, four trust boundaries, and at least three separate authorization models.
Most Joule pilots I've seen stall somewhere between step 5 and step 8. And almost none of them have governance across the full chain.
The Actual Architecture
I'm going to walk through all 11 steps because the detail matters. This is what your integration team will spend weeks on, and what your security team should be auditing but probably isn't.
Identity and Trust (Steps 1–4)
Step 1 is IAS setup. Joule needs Global User ID consistency across every system in the chain. If your IAS tenant was configured years ago with a different naming convention than your S/4HANA user master, you're going to hit identity resolution failures that surface as mysterious "authorization" errors in Joule — even though the real problem is that BTP and S/4HANA disagree about who the user is.
Step 2 is the three-way trust chain: BTP trusts IAS, IAS trusts S/4HANA, and S/4HANA trusts BTP. Miss any leg of this triangle and the secure communication channel doesn't establish. I've seen teams spend two weeks debugging connectivity issues that turned out to be a missing trust configuration between IAS and a specific S/4HANA tenant.
Step 3 is user attribute mapping — email, roles, UUID, group membership. Joule uses this context to determine what the user can see and do. If the mapping is wrong, Joule either blocks legitimate users or, worse, grants access to data the user shouldn't reach. The second failure mode is worse because it's silent.
Step 4 is trusted domain configuration. Cross-domain communication between IAS and BTP has to be explicitly whitelisted. This is a security boundary that most organizations set up correctly during initial deployment and then never look at again — even as their landscape evolves.
Platform Foundation (Steps 5–7)
Step 5 is BTP setup — global account, subaccount, entitlements. Straightforward if your BTP landscape is clean. Painful if you have sprawling subaccounts from old projects, trial entitlements mixed with production, or subaccounts in the wrong region. (That last one is the sovereignty problem I keep hitting with Canadian customers — the subaccount was created in US East during a PoC and nobody moved it to Canada Central when the project went to production.)
Step 6 is SAP Build Work Zone, and this is where most pilots die. Work Zone is Joule's backbone for navigation, role-based access, and content federation. Without it, Joule is a chatbot floating in space — it can answer questions but it can't navigate your application landscape, can't enforce role-based content restrictions, and can't federate across multiple S/4HANA systems.
The number of teams I've talked to who deployed BTP, configured Joule, and then discovered they needed an entire Work Zone implementation they hadn't budgeted for is alarming. This dependency isn't obvious from SAP's marketing materials.
Step 7 is the Joule Booster — an automation layer that creates the Joule formation, wires system landscape connections, and runs initial configs. This usually works. When it doesn't, the error messages are cryptic and the documentation is thin. But relative to steps 5 and 6, this is the easy part.
Data and Content Exposure (Steps 8–9)
Step 8 is where S/4HANA becomes a content provider. It exposes business roles, app content, and data access to BTP. This is how Joule "knows" your SAP landscape — it consumes the catalog of available applications, roles, and data structures that S/4HANA publishes.
Here's the governance problem: every role you expose is a data surface you're making available to AI. If you expose too many roles, Joule can surface data to users based on their BTP role mapping rather than their granular SAP authorizations. If you expose too few, Joule is useless. Getting this balance right requires someone who understands both the SAP authorization model and the BTP content federation model. That person rarely exists on the project team.
Step 9 exposes Fiori Launchpad content to BTP. Joule doesn't read S/4HANA directly — it reads Fiori content that's been federated through BTP. This enables context-aware responses and in-app navigation, but it also means your Fiori content catalog becomes your AI's knowledge boundary. If an app isn't exposed, Joule can't reference it. If it is exposed without proper authorization controls, Joule can reference it to anyone.
Connectivity and Activation (Steps 10–11)
Step 10 is destinations and connectivity — the OAuth flows, SAML assertions, and API endpoint configurations that wire everything together. Most security audits I've reviewed cover this layer adequately for human access patterns. Almost none consider the machine-to-machine patterns that Joule introduces. The OAuth tokens Joule uses to call S/4HANA BAPIs — are they scoped to specific API groups, or do they have broad access? Are they rotated? Are the token lifetimes appropriate for AI workloads that might make hundreds of calls per user session?
Step 11 is the Joule plugin activation in Fiori Launchpad. This is the moment it becomes visible to users. By this point, you've built an 11-layer integration chain that most of your organization doesn't know exists.
The Four Governance Gaps
After walking through this architecture with multiple organizations, the same four gaps show up repeatedly:
Identity propagation breaks. The Global User ID resolves correctly in IAS and BTP but maps to a different authorization profile in S/4HANA. The user gets AI-generated answers based on data their SAP role shouldn't access. Nobody notices because the data looks correct — it's just not authorized for that user.
Sovereignty fails silently. S/4HANA is in Canada Central. The BTP subaccount is in US East (from the PoC that became production). Every Joule interaction for Canadian users now routes through US infrastructure. The CISO thinks sovereignty is enforced because they checked the Azure region. They didn't check the BTP region.
Observability stops at layer boundaries. BTP logs Joule requests. S/4HANA logs BAPI calls. But there's no correlated trace connecting a specific Joule prompt to the specific BAPI it triggered and the specific data it returned. When a data exposure incident happens — and it will — the investigation requires manually stitching together logs from four platforms. That takes days, if it's even possible.
Content exposure creeps. The initial Fiori content exposure is carefully scoped. Then a project team needs Joule to access a new app. They expose it. Then another team does the same. Over 18 months, the content surface area grows far beyond what was originally authorized, but nobody does a periodic review because the content provider configuration isn't covered by any existing audit process.
Why This Matters Now
SAP's API Policy FAQ from April 2026 makes it explicit: AI can assist SAP, but it cannot autonomously run SAP. The execution boundary is drawn. But enforcing that boundary requires governance across all 11 layers — not just at the model layer or the API layer, but across the identity chain, the content federation, the authorization model, and the connectivity infrastructure.
Meanwhile, the ODP extraction ban (SAP Note 3255746) is forcing data pipeline rebuilds, and the ECC 2027 deadline is forcing migration decisions. Every SAP-on-Azure enterprise is juggling three enforcement actions simultaneously, and Joule integration governance is landing on top of all of it.
The question isn't whether to deploy Joule. The question is whether your governance model can keep up with the 11-layer architecture you're building when you do.
We assess governance readiness across the full SAP-on-Azure landscape — 9 domains, 50+ assessment points, from AI sovereignty and identity governance to integration reliability and data extraction compliance. If you're deploying Joule or any AI agent against SAP data, we can tell you where the gaps are before an auditor does.
How governed is your SAP estate?
The Governance Readiness Score measures your SAP on Azure environment across 9 domains — from AI sovereignty to data extraction compliance. Get your score.
Get Your Governance Score