AI Architect learning guide · SAP Business AI · 2026
From user intent to governed AI action
SAP's Business AI reference architecture is a communication tool before it's a technical
one: four layers that give architects a shared language for placing any AI capability —
from a Joule prompt down to the BTP services that run it. This guide walks the layers,
traces a real request through all four, contrasts the SAP stack with a DIY enterprise AI
factory, and ends with the readiness sequence that predicts most of a Joule project's
difficulty.
4
Layers: user experience, process, foundation, platform
6
Knowledge domains in the learning map
5
Orchestration modules in one GenAI Hub pipeline call
0
Inbound connections needed by Edge Integration Cell
The study map orders SAP Business AI from strategic foundations through architecture,
agentic AI, data, hybrid landscapes, and enablement. This page covers the linked topics
in depth; the other pills are the adjacent nodes to pull next.
1️⃣ Strategic foundations
Why SAP Business AI exists, the EA's shift from architect to transformation guide, deterministic vs probabilistic use-case selection, adoption obstacles.
Why Business AIEA role shiftDeterministic vs probabilisticAdoption obstacles
2️⃣ Reference architecture
The four-layer model, AI Foundation + Generative AI Hub, Vector Engine + RAG, the end-to-end workflow, common pitfalls. Covered below ↓
Business Data Cloud (zero-copy, data products), Knowledge Graph grounding, the unified semantic layer, Delta Sharing to hyperscaler AI services.
Business Data CloudKnowledge GraphSemantic layerDelta Sharing
5️⃣ Hybrid & platform
Hybrid deployment patterns, Edge Integration Cell on hyperscalers, GenAI on SAP BTP (RA0005), identity and access with IAS/IPS. Edge Cell below ↓
Hybrid patternsEdge Integration CellGenAI on BTPIAS / IPS
6️⃣ Enablement & governance
Architecture Center reference architectures, Discovery Center Business AI features, accelerators and enablement tools, the learning and certification landscape.
User intent enters at the top; an AI-supported business action comes back up. Click any
layer for the deep dive.
The four-layer SAP Business AI reference architecture. Diagram from the source study conversation.
Inside the build lane: Generative AI on SAP BTP (RA0005)
🏗️ CAP is the center of gravity
The Cloud Application Programming Model hosts application and domain logic — with the CAP LLM Plugin and Cloud SDK for AI plugging in, and LangChain hosted inside the architecture rather than beside it.
🚪 GenAI Hub is the model gateway
Secure, standardized access to foundation models on BTP or from Azure, Google, and AWS — plus a Prompt Registry and Prompt Optimization. The SAP analog of a hand-built LLM gateway.
🔗 One pipeline call, five modules
Orchestration composes grounding, templating, translation, data masking (with unmasking on the way back), and content filtering into a single Harmonized API call — the LLM middleware factory teams usually hand-roll.
🗄️ One database, all retrieval engines
HANA Cloud carries the Vector Engine (the RAG substrate) and the Knowledge Graph Engine (RDF + relational) — relational, graph, spatial, vector, and document workloads converge, so grounding needs no separate vector-DB estate.
One architecture, six scenario overlays: basic prompting → semantic search & embeddings →
RAG → A2A interoperability → agents for structured data → multi-tenant SaaS GenAI apps —
a maturity progression from "call a model" to "multi-agent, multi-tenant." Runtime choice:
Cloud Foundry (polyglot cloud-native) or Kyma (managed Kubernetes).
How a request flows
One question, four layers, five governance checkpoints
The finance scenario from the source materials: a user asks Joule,
"Show me all overdue invoices for customer ACME and summarize any trends."
Watch it traverse the stack.
Simulated — illustrates the lifecyclegovernance checkpoints 0/5
Press "Trace the request" to follow the ACME query through the stack…
Identity-before-retrieval, centralized model governance, and continuous audit are exactly
what a DIY factory stack must build and maintain itself — the strongest card in the
"route system-of-record use cases through SAP" argument.
Strategy
SAP stack vs. enterprise AI factory — and the seams between them
Each SAP layer has a factory-side counterpart, and the stacks interoperate at defined
seams: the A2A protocol at the agent layer, partner models into the GenAI Hub, and
Delta Sharing at the data layer. The architecture conversation is three lanes, not two.
The SAP Business AI stack and the enterprise AI factory, layer by layer, with the three interoperability seams. Diagram from the source study conversation.
🧩 Lane 1 — Extend Joule
The use case fits Joule's extension points: custom skills and agents, document grounding, Work Zone surfacing. UX and Process layers stay SAP-delivered; your design decisions concentrate in Foundation and Platform.
🏗️ Lane 2 — Build on RA0005
Doesn't fit Joule but must stay inside SAP governance: factory-like freedom (any partner model, LangChain, Kyma/Kubernetes) while the model perimeter, masking, filtering, and identity remain SAP-governed.
🏭 Lane 3 — External factory
Build in the enterprise AI factory and connect through the seams — A2A for agent interoperability, Delta Sharing for zero-copy data access — rather than re-platforming.
🔁 The recurring pattern
Across agents (Agent Hub), data (Delta Sharing), and integration (Edge Integration Cell), SAP centralizes the control plane and lets you keep the data / execution plane sovereign. Recognizing this repeated split is worth more than any single reference architecture.
Use case
Edge Integration Cell: cloud governance, sovereign execution
A typical enterprise still runs SAP PI/PO on-premise while expanding into cloud analytics
and event-driven integration. Three roadblocks stop a straight move to cloud Integration
Suite: data-residency law, a no-inbound-access security policy, and latency to distant
BTP regions. EIC resolves all three by splitting design time from runtime.
Inbound connections: 0 (outbound-only)Design & monitoring: cloud (BTP)Execution: your network
# Integration landscape (cloud-only Integration Suite)
1. Model iFlows in Integration Suite on SAP BTP.
2. Execute them in the BTP region — sensitive data leaves
the corporate network for processing.
3. Open inbound firewall paths so cloud runtimes can reach
on-premise systems.
4. Accept the nearest available BTP region — e.g. a RISE
customer on GCP Canada executing flows from Iowa, adding
latency and a border crossing.
5. Regulated data (health, financial, manufacturing IP)
can't comply → workloads stay stuck on legacy PI/PO.
The three roadblocks: residency law, no-inbound security policy, latency to distant regions.
# Integration landscape (with Edge Integration Cell)
1. Model iFlows in Integration Suite on SAP BTP — design
time and monitoring stay cloud-managed.
2. Deploy them to the EIC runtime inside your own network
(private hyperscaler VPC or on-premise Kubernetes).
3. The runtime calls back to BTP over secure, outbound-only
channels — nothing external can initiate a connection in.
4. Flows execute next to the systems they integrate: local
latency, data never leaves unless explicitly allowed.
5. Regulated workloads comply — the processing itself stays
inside, not just the connectivity.
"No doors": a materially different posture from a Cloud Connector-style tunnel.
# Integration landscape
1. Model iFlows in Integration Suite on SAP BTP.
2. Execute them in the BTP region — sensitive data leaves
the corporate network for processing.
3. Open inbound firewall paths so cloud runtimes can reach
on-premise systems.
4. Accept the nearest available BTP region, adding latency
and a border crossing.
5. Regulated data can't comply → workloads stay stuck on
legacy PI/PO.2. Deploy them to the EIC runtime inside your own network
(private VPC or on-premise Kubernetes).
3. Outbound-only channels back to BTP — no inbound paths,
no firewall holes.
4. Flows execute next to the systems they integrate — local
latency, local jurisdiction.
5. Regulated workloads comply; PI/PO retires on a phased,
not big-bang, migration.
USE CASEPI/PO modernization — retire legacy middleware, keep execution local
Cloud-managed design time, event-driven patterns, end-to-end monitoring, phased migration
USE CASELatency optimization — where BTP has no local region
e.g. RISE on GCP Canada executing locally instead of from Iowa
USE CASEOn-prem / private cloud integration — S/4HANA or ECC to cloud apps
"Without punching holes in firewalls"
USE CASERegulatory compliance — data-sensitive regions and industries
e.g. a Middle East healthcare provider processing patient flows locally under national data-protection law
USE CASEIndustrial / IoT edge — no internet dependency at all
Logistics hub: conveyor sensor data processed at the edge, synced with SAP EWM
ROLLOUTThree-step deployment — prepare, activate, bootstrap
Isolated network + Kubernetes cluster (EKS/AKS/GKE/on-prem) → activate EIC in the BTP subaccount with Edge Lifecycle Management roles + SSO technical user → add an Edge Node; the runtime ships with PostgreSQL and Redis
The AI relevance is growing, not incidental: grounding pipelines are integration flows,
and once agents touch regulated data, "where does the pipeline execute" becomes an
AI-governance question. EIC is Pattern 1 — the resilient edge — in the hybrid-landscape
lesson: you don't have to choose between on-premise control and cloud innovation.
Get started
Joule integration readiness, in order
Identity appears at every stage — prerequisite, wiring, sync jobs, role-based testing, and
expansion governance. The fastest diagnostic question an architect can ask:
💬How many IAS tenants do you have, and do all target applications trust the production one?
The answer predicts most of the project's difficulty.
Unify identity first
A unified Joule setup requires all participating applications to authenticate against the same IAS production tenant. Enterprise identity has usually "evolved over time, across multiple systems and tenants" — aligning it before activation discussions is where the EA earns their keep. Reference: the CIO Guide on Identity Lifecycle in SAP Landscapes.
Design the BTP subaccounts
Dev/test/prod segregation gives secure isolation, lifecycle management, and a controlled rollout path. This is also where your RA0005 build-lane decisions will live later.
Configure Cloud Identity Services, then each target system
Authentication and trust relationships first; then target-system configuration — a repeatable step performed once per backend Joule talks to (SuccessFactors, S/4HANA Cloud, …). Architectural consistency across the landscape is what makes this scale.
Wire Work Zone and sync jobs, then run the Joule Booster
User/role sync ensures people see Joule in the right context with authorizations respected. The Booster automates remaining configuration so the baseline matches SAP's recommended setup. Three setup missions: unified Joule instance, Joule for SuccessFactors, Joule with S/4HANA Cloud Public Edition.
Pilot small, validate by business role
Start with a focused set of applications and user groups; route issues through the CA-Joule ticket component; consider SAP or partner experts for "complex or historically grown landscapes." Before production: final validation by business role, so every user sees exactly what their authorizations allow — no rollout surprises.
Expand: agents, M365 Copilot, document grounding
Joule graduates from feature to capability: additional SAP-delivered or custom agents across lines of business, Microsoft 365 Copilot integration with enterprise identity intact, and document grounding over approved enterprise content. Position the SAP Joule Readiness Service early — not after technical issues surface mid-activation.
