Held from April 20–24, Hannover Messe is the world’s leading industrial trade fair.

On day one, Christian Klein, CEO of SAP SE, stopped by the SAP booth before joining German Chancellor Friedrich Merz and other industrial leaders on the center stage to discuss the importance of moving from AI ambition to real-world execution.

And visitors to the SAP booth experienced that shift firsthand, following the production of the ginger shot.

Packaged in a neat blue box, the ginger shot was refreshing but that wasn’t the only takeaway. The real takeaway was how SAP’s new set of AI-powered manufacturing and supply chain innovations can deliver connected end-to-end supply chain business processes powered by AI.

Supply chain orchestration​

From AI and data and then using SAP’s agentic AI, visitors saw what supply chain orchestration looks like in practice. SAP uses agentic AI, trusted data, and applications to help manufacturers sense, analyze, and act in real time.

Orchestrate your supply chain as a single, connected system using AI and data to sense, analyze, and act in real time

Learn more

At the booth, visitors saw human operators interact with an ANYbotics robot through Joule using natural language to run live, remote field service inspections; Uhlmann’s high-tech glass-fronted packing machine, PacXplorer, in action opposite the CNC machine from DMG MORI that was creating spare parts for the PacXplorer; and, at end of the production cycle, AIMBO’s robot handling the picking and packing of the ginger shot. Both AIMBO and ANYbotics are part of SAP’s growing network of physical AI partnerships.

In addition to many tours held in German and English, day one also saw tours in Japanese, Chinese, and Portuguese—Brazil was the partner country at Hannover Messe 2026.

Equipped with headphones to block out the noise of the crowds at the booth, visitors heard how SAP’s AI can deliver trusted orchestration and smarter execution for manufacturing and supply chain management.

Live AI use cases demonstrate functions and benefits​

Operations and insights use case​

Here, visitors experienced SAP’s vision of supply chain orchestration. In this vision, supply chain orchestration acts as the nerve center of the enterprise. It uses external alerts such as natural disasters, port congestions, or supplier routes to optimize enterprise logistics and planning using agents.

Benefits can include faster response times with AI-assisted monitoring and automated alerts; improved decision-making with data-driven, operational decisions powered by integrated business AI capabilities; and seamless integration with end-to-end connectivity from supply chain planning through to manufacturing execution and quality control.

Top AI functions

• Production Planning and Operating Agent can assist with order release and real-time monitoring.
• A physical AI robot inspects hazards, analyzes inspection data, and identifies root causes.
• Supply optimization analysis helps summarize insights, analyze, and explain the time-series optimization planning run.

Smart production use case​

DMG MORI demonstrated production at its CNC machine—as part of an end-to-end process—from engineering to planning to production.

As the white robotic arm of the CNC machine silently moved the pusher spare part after the milling process, visitors learned about the benefits of integration, from design to tool management, CNC programs to SAP Digital Manufacturing as part of a seamless, integrated process. The production operator dashboard offers the operator on the machine AI capabilities and insights to operational and maintenance information.

The process then continues through to logistics execution with SAP Logistics Management, which helps combine warehousing and transportation capabilities for smaller warehouses.  This features an AI-powered logistics assistant that can cut through the noise, automatically gathering, summarizing, and prioritizing critical shipment information. It can also provide real-time shipping prices, bringing to life trusted orchestration and smarter execution.

Top AI functions

• Joule with SAP Logistics Management uses natural language to help streamline warehouse and transportation operations.
• Joule’s integrated AI agents can provide manufacturing information and support decision-making throughout the workflow.

Intelligent packaging use case​

Uhlmann’s PacXplorer and SAP highlighted a fully integrated, high-speed packaging line from SAP S/4HANA, to SAP Digital Manufacturing, down to Uhlmann’s automation layer to produce the packaged ginger shot. The ginger shots were moved away from the line by a mobile autonomous robot from Symovo. This use case showed visitors how SAP supports regulated industries such as pharma and life sciences.  

Highlighted benefits include increased operational speed with higher throughput thanks to decreased order processing time, built-in regulatory compliance, reduced manual intervention, inventory transparency, and data integrity across the entire production chain.

Top AI functions

• Condition monitoring-led services can enhance asset uptime and service efficiency by combining AI-driven insights and seamless collaboration across the service ecosystem.
• AI-empowered flow analysis enables quick process modeling and engineering optimization.
• Intelligent exception handling is embedded in agent-driven processes.
• Joule’s integrated AI agents can support decision-making throughout the workflow.
• Joule can help power order and line insights.

Humanoid use case​

At the final stop before getting their ginger shots, visitors watched an intelligent humanoid robot perform physical tasks at the end of the packaging line, bridging the gap between digital planning and physical execution, highlighting SAP’s Project Embodied AI.

Benefits of humanoids include increased operational speed with higher throughput due to a decreased order processing time; increased business uptime and cost efficiency especially in areas dangerous or difficult for humans; inventory transparency with real-time data integrity across the warehouse; and physical-digital alignment eliminating misalignment between planning and execution.

Top AI functions

• Joule and Joule Studio can enable robots to understand the physical world, make autonomous decisions, and learn from their environment for smarter operations.

More than a quick refuel​

At the end of their visit, visitors got so much more than a quick refuel to slake their thirst. Following the creation of the ginger shot from recipe development and planning to production with mixing, filling, and packing, visitors came away with a clear understanding of how SAP is connecting insight to execution with trusted orchestration and smarter execution. And, it is this trusted orchestration and smarter execution that is building the resilience every manufacturer needs in today’s world.

Let's use Claude Code to build an SAP Extensions app. With a grounded spec, it built our prototype in less than thirty minutes. A Financial Risk Analyzer built as a CAP backend with a Fiori Elements frontend that reads GL transaction data, runs anomaly detection through SAP AI Core, and surfaces risk classifications in a List Report. The full source is on GitHub.

Excitement is not just getting code done fast but code that's reliable and truly works for the enterprise. Claude fully tested the app. Then I opened it and got a blank page. Several debugging rounds later the page showed up but columns came up empty, buttons did nothing, and the risk data never reached the frontend. It was not one bug. Several issues including deprecated annotations the runtime silently ignored, naming mismatches between the controller and what Fiori Elements actually looks for, and OData wiring that looked correct but had no execution path in V4.

The SAP MCP Servers Advantage​

Frontier models aren't lacking intelligence. They're really good. But SDKs, APIs, tools, and frameworks evolve rapidly. New library versions ship constantly, yet these models are trained on specifications that become obsolete by the time they ship. They can't be trained at the speed that tools and frameworks evolve. The challenge becomes feeding the model with the right context, grounded in best practices and sources of truth that are up to date.

SAP MCP servers give the coding agent real-time access to domain expertise. Not static documentation, but callable tools it consults while it works. Skills complement them with procedural knowledge: your team's deploy process, review checklist, CDS modeling conventions.

For my SAP projects, three MCP servers made the biggest difference:

• CAP MCP Server: guides CDS entity modeling, service definitions, and backend patterns according to current CAP conventions
• Fiori MCP Server: ensures Fiori Elements applications follow SAP UX guidelines, annotation patterns, and page configurations
• UI5 MCP Server: provides UI5 Web Components guidance, control usage, and binding patterns

Once I equipped Claude Code with these servers, it stopped guessing at SAP conventions. It checked. The agent queried the CAP MCP server before defining an entity, consulted the Fiori MCP server before configuring a list report page, and validated control usage against the UI5 MCP server before writing a view.

The Development Loop, Before and After​

Here is how that improves the development loop:

We ran a two-pass review. First: Claude reviews the prototype using only its training knowledge. Second: we validate every recommendation against the three MCP servers.

27% of Recommendations Were Wrong​

Without the SAP MCP servers, the coding agent general knowledge produced 15 recommendations. But four were wrong:

A 27% error rate on architectural decisions from a frontier model. These aren't cosmetic. Renaming an entity breaks every OData URL, KPI facets on the wrong floorplan crash at runtime, and cuid would force a restructure of the entire data ingestion from SAP.

The Button That Did Nothing: Wiring Unbound Actions​

The Analyze Risks button was the worst offender. The agent had wired it via a UI.DataFieldForAction CDS annotation pointing to an unbound action:

// ❌ Without MCP: DataFieldForAction for unbound action
annotate RiskService.GLTransactions with @(
  UI.LineItem: [
    // ... data field columns ...
    { $Type: 'UI.DataFieldForAction', Action: 'RiskService.analyzeRisks', Label: '{i18n>Analyze}' }
  ]
);

The button rendered in the toolbar. Looked correct. But clicking it? Nothing. No network request, no error, completely silent (a classic 'needle in a haystack' problem, as my colleague recently wrote about). The Fiori MCP server flags this pattern: UI.DataFieldForAction with an unbound action has no execution path in OData V4. The runtime renders the button but never wires it. With MCP, the agent was guided to a manifest custom action instead:

// ✅ With Fiori MCP: manifest custom action for unbound actions
"controlConfiguration": {
  "@com.sap.vocabularies.UI.v1.LineItem": {
    "actions": {
      "analyzeRisksAction": {
        "press": "risk.analysis.ext.controller.ListReportExt.analyzeRisks",
        "text": "{{AnalyzeRisks}}",
        "requiresSelection": false
      }
    }
  }
}

Virtual Fields: The Performance Bug MCP Would Have Prevented​

This one cost us real debugging time. The Fiori Elements list report loaded slowly and the browser console was full of errors:

Failed to drill-down into (...)/anomalyScoreResult, invalid segment: anomalyScoreResult

Hundreds of these, one per row per render cycle. The root cause: the after('READ') handler only set virtual fields when a cached prediction existed. Before the user clicks "Analyze," the cache is empty, so the handler left the fields unset:

// ❌ Before: virtual fields missing from response when uncached
this.after('READ', 'GLTransactions', (results) => {
    for (const row of results) {
      const cached = riskCache.get(`${row.DocumentNumber}_${row.LineItem}`);
      if (cached) {
        row.riskClassification = cached.riskClassification;
        row.criticality        = cached.criticality;
        // ...
      }
      // No else: fields left undefined
    }
});

OData V4's $select included these fields because the annotations reference them. But the server omitted them from the response payload because they were undefined. The client then failed the property drill-down on every row, every read, producing both the console noise and measurable performance degradation.

The fix is one else branch:

// ✅ With Fiori MCP: virtual fields always present in OData response
this.after('READ', 'GLTransactions', (results) => {
    for (const row of results) {
      const cached = riskCache.get(`${row.DocumentNumber}_${row.LineItem}`);
      row.riskClassification = cached ? cached.riskClassification : null;
      row.riskExplanation    = cached ? cached.riskExplanation    : null;
      row.anomalyScoreResult = cached ? cached.anomalyScoreResult : null;
      row.criticality        = cached ? cached.criticality        : 0;
    }
});

This is exactly the kind of bug that sits at the intersection of CAP virtual field semantics and OData V4 client behavior. General training knowledge does not cover it. An MCP-grounded agent that understands how CAP serializes virtual fields into OData responses would not leave them undefined.

Criticality Values: One Number, Wrong Dashboard​

Without Fiori MCP, the agent got the criticality mapping wrong:

// ❌ Without MCP: agent guessed criticality values
const RISK_LABELS = {
  "Normal": {
    criticality: 0  // Agent assumed 0 = positive/green
  },
  "High_Amount_Deviation": { criticality: 1 },
  "New_Combination": { criticality: 2 }
};

The Fiori MCP server returned the actual OData V4 vocabulary values. 0 means Neutral (grey), 3 means Positive (green). One number, but it determines whether your risk dashboard communicates anything at all:

// ✅ With Fiori MCP: grounded in OData V4 vocabulary
const RISK_LABELS = {
  "Normal": {
    criticality: 3  // 3 = Positive/green per OData spec
  },
  "High_Amount_Deviation": { criticality: 1 },
  "New_Combination": { criticality: 2 }
};

CDS Enum Types and Naming Conventions​

But the CAP MCP server went further than just correcting the value. It confirmed that CDS enum types are the right pattern for fields with a fixed set of valid states, and flagged a detail you won't find in most training data: Integer enums require explicit values. Omit them and the CDS compiler errors out:

// ❌ Without MCP: raw types, no documentation, no compiler safety
virtual riskClassification : String;
virtual criticality        : Integer;

// ✅ With CAP MCP: enum types with explicit values
type Criticality : Integer enum {
  Neutral  = 0;
  Negative = 1;  // red
  Critical = 2;  // orange
  Positive = 3;  // green
};

type RiskClassification : String enum {
  Normal          = 'Normal';
  UnusualAmount   = 'Unusual Amount';
  HighAmountNew   = 'High Amount + New Pattern';
  // ... 10 more classifications
};

virtual riskClassification : RiskClassification;
virtual criticality        : Criticality;

The enum is the source of truth, not a comment, not a wiki page, not tribal knowledge.

Naming conventions were another quiet catch. The 24 ML feature columns came from the Python model using snake_case: anomaly_score, peer_amount_stddev, posting_delay_days. But every CDS example the CAP MCP server returned used camelCase. That's not a style preference. It's how Fiori Elements generates labels. Rename anomaly_score to anomalyScore and the table header reads "Anomaly Score" automatically. Keep snake_case and you ship a professional risk dashboard with column headers like anomaly_score.

Beyond MCP: Playwright and the Filter Bar​

Code that compiles isn't code that works. Playwright MCP gave the agent eyes on the running application. Without browser access, the coding agent couldn't catch blank pages or broken wiring. I'd open the app, see the failure, paste the error back, and repeat. With Playwright, the agent launched a headless browser, took screenshots, and iterated without waiting for me. That's the concrete mechanism behind agentic engineering: coding agents that create, test, iterate, and debug independently.

One of the first things Playwright caught was a usability problem no linter would flag. Twenty-four fields in the filter bar. My Financial Risk Analyzer has 24 ML feature columns (anomalyScore, peerAmountStddev, postingDelayDays) and every single one showed up as a filter option. Nobody filters risk transactions by peerAmountStddev. The Fiori MCP server pointed to @UI.HiddenFilter:

// ❌ Without Fiori MCP: feature columns clutter the filter bar (28 fields)
anomalyScore @title: '{i18n>feat_anomalyScore}' @UI.Importance: #Low;

// ✅ With Fiori MCP: hidden from filters, still available in table personalization
anomalyScore @title: '{i18n>feat_anomalyScore}' @UI.Importance: #Low @UI.HiddenFilter;

For date and amount fields, Fiori MCP pointed to Capabilities.FilterRestrictions, not something you'll find in a typical CAP tutorial:

// ✅ Fiori MCP: 'SingleRange' enables date/amount range pickers
annotate RiskService.GLTransactions with @(
  Capabilities.FilterRestrictions: {
    FilterExpressionRestrictions: [
      { Property: PostingDate, AllowedExpressions: 'SingleRange' },
      { Property: Amount,      AllowedExpressions: 'SingleRange' }
    ]
  }
);

Four focused filter fields with proper range sliders instead of twenty-four. That's the line between a demo and a tool someone uses daily.

How to Equip Your Agent to Get It Right​

In practice, four configuration layers work together:

// .claude/settings.json: MCP server configuration
{
  "mcpServers": {
    "cap": { "command": "npx", "args": ["@cap-js/mcp-server"] },
    "fiori": { "command": "npx", "args": ["@sap-ux/fiori-mcp-server"] },
    "ui5": { "command": "npx", "args": ["@ui5/mcp-server"] },
    "playwright": { "command": "npx", "args": ["@anthropic-ai/playwright-mcp", "--headless"] }
  }
}

# AGENTS.md: SAP project instructions

For SAP-code specific, query SAP MCP servers before writing code.

- **/sap-cap**: queries CAP MCP for CDS entities, types, and services
- **/sap-fiori**: queries Fiori MCP for annotations and Fiori Elements config
- **/sap-ui5**: queries UI5 MCP for controllers, XML views, and controls

That's it. Edit a file under app/, the Fiori skill loads. Edit a service definition under srv/, the CAP skill loads. Edit a controller, the UI5 skill loads. No routing tables, no guessing which server to query. The path does the work.

It's important to keep in mind to only adopt MCP servers that have been verified from a security standpoint. Only install servers you trust.

Still, correct SAP patterns aren't enough if the architecture is wrong. That's why you need to ensure your spec doesn't have any gaps and covers solid enterprise architecture principles, including zero-trust.

Beyond Correctness: Architecture Principles​

I reviewed the working Financial Risk Analyzer, the one MCP had gotten right on the first pass, and found an unscoped OData endpoint and no input validation. The SAP patterns were correct but security was missing. And security was just the first gap. Performance efficiency, reliability, scalability: the principles you apply before designing any enterprise solution weren't considered for the generated code.

I needed a system design methodology. Traditionally, I'd write the technical specification with a certain level of detail. Even documenting just the important parts would take time. That led me to a spec-driven-development tool (e.g., superpowers).

Before I let the agent produce any code, an SDD tool when grounded with your architecture principles, will interview you and ensure there are no gaps from the security posture, performance budgets, reliability expectations, scalability constraints. Those were some of the fundamental pillars I'd define as an architect before designing any solution.

The difference was immediate. With a complete spec shaped by architecture principles along with SAP MCP skills, the agent didn't just write correct SAP code. It wrote code that reflected the non-functional requirements an enterprise application actually needs. Every session inherited that spec. No context rot. No re-explaining the same constraints.

The agent built a working Risk Service with a correct CDS entity, proper annotations, functional action handler. But it shipped without any authorization:

// ❌ Without architecture principles: wide open
service RiskService {
  entity GLTransactions as projection on risk.GLTransactions;
  action analyzeRisks() returns array of GLTransactions;
}

Every authenticated user could trigger AI Core inference. The CAP MCP server confirmed the two-level pattern: service-level access control plus action-level role restriction. That's not something you discover from CDS syntax guides. It comes from thinking about who should access what:

// ✅ With CAP MCP: service + action level authorization
service RiskService @(requires: 'authenticated-user') {
  @readonly
  entity GLTransactions as projection on risk.GLTransactions;

  @(requires: 'RiskAnalyst')
  action analyzeRisks() returns array of GLTransactions;
}

authenticated-user locks down the OData endpoint. RiskAnalyst restricts the expensive AI Core call to users who actually need it. The MCP server didn't invent the security requirement. The architecture spec did. MCP made sure the implementation followed current CAP conventions.

Secure the Code Your Agent Writes. It Won't Do It for You.​

Even after equipping your agent, we should always assume code is untrusted. MCP servers teach convention. An SDD tool improves the spec's quality. Still, the security scan flagged 53 vulnerabilities! The agent had scaffolded the project with older versions of the libraries instead of pulling @latest, and those older versions carried vulnerable dependencies underneath.

The spec never told the agent to use @latest or run npm audit after scaffolding. Security starts in the spec: install dependencies at their latest versions, audit what's underneath, and make that a gate before any application code is written.

That covers what the agent produces. What about what you feed it? Anything it reads becomes model context, including files you didn't intend to share. List .env, default-env.json, and service keys in .claudeignore to keep them out of the agent's view. Only expose data the agent needs. Never enter personal or customer data into prompts.

Protect What Your Agent Sends​

When the coding agent sends code to a model provider, it carries business logic and intellectual property. I need a contractual guarantee that none of it gets used for training or sold to a third party. Going direct to model providers doesn't give me that through a single agreement. Running through SAP's Gen AI Hub does. SAP's agreements with providers ensure your data stays yours.

That same infrastructure solves a second problem. Agentic workflows benefit from multiple frontier models. Strengths vary by task, and a second opinion from a different model is a real advantage. LiteLLM gives me a single gateway into Gen AI Hub: one integration point, one SAP API key, every frontier model available immediately, at volume pricing SAP negotiates with hyperscalers. Behind that gateway, Gen AI Hub handles content filters and PII masking on every request, guardrails I'd otherwise have built myself.

# litellm_config.yaml: single gateway to SAP Gen AI Hub
model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: sap_ai_core/anthropic--claude-4.6-sonnet
  - model_name: claude-opus
    litellm_params:
      model: sap_ai_core/anthropic--claude-4.6-opus

The full-stack picture: Fiori on the frontend, CAP on the backend, Gen AI Hub for intelligent services, BTP for runtime and backing services like Destination and HANA Cloud. The coding agent works across this entire stack, guided at every layer by SAP-specific tooling.

What This Means For Your Team​

The prototypes made one thing clear: agents write code fast, but they're working from training data that's already stale. SDKs and API specs change. The code written by AI compiles, but breaks at runtime, and AI can't fix them easily without several iterations leading to an enormous waste of time and effort.

SAP's extension ecosystem has always been powerful, and it has always demanded deep professional knowledge to get right. That knowledge barrier is real. It is why SAP projects take months and why extension backlogs grow faster than teams can deliver.

MCP servers do not eliminate that barrier. They democratize access to it. The servers encode the same best practices that senior SAP architects carry: CDS conventions, annotation semantics, authorization patterns, controller extension boundaries. An agent equipped with these servers reflects that expertise, even when the developer driving the session is building their first Fiori app.

Here's what that workflow looks like end to end:

To see the complete implementation (CAP backend, Fiori Elements frontend, and AI Core integration) explore the source code on GitHub. Your SAP investment already includes the platform. The question is whether you equip your agents to use it.

References​

SAP MCP Servers

• CAP MCP Server: MCP server for SAP Cloud Application Programming Model (CAP) development
• Fiori MCP Server: Helps AI models create and modify SAP Fiori applications
• UI5 MCP Server: UI5 Web Components development assistance

Agentic Engineering & Spec-Driven Development

• Finding the Needle: AI-Assisted Debugging Across Thousands of Lines and Megabytes of Logs: How a coding agent resolved an intermittent auth failure across Kubernetes and SAP AI Core in 60 minutes instead of 12+ hours, by correlating logs and tracing credential conflicts no single engineer could spot at once
• superpowers: Spec-driven development framework that guides coding agents through structured requirements gathering
• GSD: Meta-prompting, context engineering, and spec-driven development system for coding agents
• OpenSpec: Spec-driven development tool that adds a lightweight specification layer before code is written

Developer Tooling MCP Servers

• Playwright MCP: Headless browser automation for coding agents. Navigate, screenshot, and verify UI

SAP Platform

• LiteLLM SAP Provider: Gateway to SAP AI Foundation via Gen AI Hub
• Claude Code Documentation: Official Claude Code docs, skills, MCP, and quickstart guides

TL;DR: Intermittent HTTP 400, full agent flow only, every isolated test passing. Root cause: two conflicting sets of SAP AI Core credentials coexisting silently in the same Kubernetes secret - standalone production vars that the SDK prioritised over the staging service key, causing every token request to fetch from the wrong OAuth endpoint. The agent connected to staging with a production token. SAP's proxy rejected it: tenant not found. We were stuck. Nothing pointed anywhere obvious. A team of 2–3 engineers would have spent 12–15 hours total on this. Claude Code did it in 60 minutes, on claude-sonnet-4.5, averaging ~20 tokens of human input per turn.

We've encoded the debugging patterns into a reusable Claude Code skill you can drop into your own projects.

The prompt that unlocked it:

"I have a bug that only reproduces in the full system flow. Here is the error and the logs. Read the code end-to-end, correlate log timestamps across all components, trace the full execution path from startup through the failure point. Use process of elimination - what do the logs rule out, what does the code rule out, what remains. Generate tests that reproduce the failure condition, not just unit tests for individual functions, but tests that exercise the sequence and state that leads to the bug."

What We Were Dealing With​

Quick SAP Context: SAP AI Core is SAP's managed AI/ML runtime on SAP Business Technology Platform (BTP). It handles model serving, training, and inference at enterprise scale. Authentication uses service keys (JSON blobs containing OAuth client credentials) that get injected into your applications via the SAP AI SDK. The SDK supports two credential paths: a composite service key JSON, or individual environment variables. This flexibility is convenient — and, as we discovered, a source of subtle bugs when both coexist.

WebRTC based voice agent on Kubernetes, connected to SAP AI Core to reach a Speech to Speech model. Every staging deployment failing with HTTP 400: server rejected WebSocket connection. Live environment fine. Every isolated test passed. Direct WebSocket, raw SDK connect, synthetic session - all worked. Endpoint, headers, token format - all correct. The failure only appeared in the full agent flow, and only sometimes. The kind of intermittent bug where you can't even confirm it's real without spending half a day first. We tried everything we could think of. Nothing pointed anywhere obvious. That's when we handed it to Claude Code - not with a neat hypothesis, just the error, the logs, and "figure it out."

The Scale Problem​

The codebase spans multiple modules. Startup touches auth, plugin initialization, session construction, and model factory - each in a different file. Kubernetes adds environment variable injection from secrets, adding ordering sensitivity on top. The logs aren't a single file. They're timestamped output from the agent worker, WebRTC room, WebSocket handshake, and OAuth exchange - all interleaved. The signal was matching a WebSocket rejection at T+8s to a token fetch at T+0.2s during prewarm. Across multiple streams. Manually. Not hard to reason about - hard to hold all at once. Thousands of lines of code, megabytes of logs, a bug that only fires under a specific sequence.

What Claude Code Found​

The Kubernetes secret had been populated with two overlapping sets of AI Core credentials:

1. AICORE_SERVICE_KEY - the staging service key JSON (correct, for the STS model Live staging endpoint)
2. AICORE_AUTH_URL, AICORE_BASE_URL, AICORE_CLIENT_ID, AICORE_CLIENT_SECRET - standalone production credentials from a different service, left in by mistake

The SAP AI SDK's credential resolution priority: when individual AICORE_* vars are present in the environment, the SDK uses them directly and does not parse the service key JSON at all. The standalone vars pointed to SAP's production AI Core. The SDK fetched a production OAuth token. That token was then sent to the staging STS model endpoint. SAP's staging proxy decoded the JWT, found a tenant it didn't recognise, and returned:

HTTP 400 Bad Request
{"error": "Missing Tenant Id"}

The error was perfectly accurate. It just didn't name the cause.

What made this so hard to find: the conflict was invisible at the code level. _init_aicore_env(service_key) looked correct. But the SDK reads environment variables at token-fetch time, not at parse time. In the full agent flow, prewarm_auth() fires early during pod startup before model initialisation. The K8s secret injects all vars simultaneously at pod start. Isolated tests called setup directly and never triggered prewarm - the bug lived entirely in the gap between how tests run and how the agent actually starts in the cluster.

The fix: remove the conflicting standalone vars from the secret entirely. Keep only AICORE_SERVICE_KEY and AICORE_RESOURCE_GROUP - everything else is derived at runtime. Plus a defence-in-depth change to _init_aicore_env to detect credential changes and invalidate the token cache before overwriting env vars, so even if both paths are ever present again a credential switch forces a fresh token.

Then without being asked - Claude Code argued against its own fix. "Are there other code paths that could fetch a token before _init_aicore_env runs?" Traced the callers, confirmed prewarm_auth() now correctly initialises from the service key before fetching, wrote two regression tests that reproduce the exact startup sequence that triggers the conflict.

The Numbers​

• 617K output tokens - code written, hypotheses reasoned, tests generated
• 166K token peak context - codebase, logs, SDK source, all held simultaneously at peak
• 54K input tokens - everything the human typed, entire session, ~20 tokens per turn
• 12–15 hours → 60 minutes

Twenty tokens of human input per turn driving 617K tokens of reasoning and fixing.

One more thing: this ran across multiple days. Claude Code's automatic context compaction summarized earlier history as the session grew, keeping the window within limits without losing conclusions. Without it, a multi-day investigation stalls. With it, the session just keeps going.

Governance First​

Claude Code was routed through an internal LLM gateway. Every token in, every token out, every model call logged, attributed, and visible centrally. No API keys scattered across laptops. No blind spots on spend. No model version drift across teams. For enterprise environments, the ability to answer "what did our AI tooling do last month, who used it" without scraping individual machines is non-negotiable.

On top of that:

• Short-lived SSO credentials for cluster access - rotated per session, same permissions as the engineer's terminal
• Explicit approval gates for every write - nothing touched the cluster without a human reviewing first
• Read-only MCP access for logs and code - observe everything, change nothing without approval

The governance layer isn't friction. It's what makes it safe to give the AI real access to real systems in the first place. Get that right first. Then give it access. In that order.

The Setup​

GitHub MCP server - full repo read access. Claude Code traced imports, followed call chains, read any file without being handed anything manually.

Kubernetes context - kubectl from the shell session, short-lived SSO token from our Gardener cluster, same permissions as the engineer's terminal. Every write operation required explicit approval. Reads ran uninterrupted.

We run on Gardener - SAP's opinionated Kubernetes distribution with its own concepts (shoot clusters, seed clusters, gardenlets). Claude Code doesn't know Gardener out of the box. We dropped a documentation link into the session. It read it and reasoned correctly from there. General rule: if your infrastructure deviates from vanilla, hand it the docs.

Memory on by default via .claude/ in the repo root. Findings carried across sessions - no re-running tests already run, no re-reading files already understood.

What Actually Made It Work​

The plan came first. Before any code was written or command run, Claude Code produced a plan - hypotheses, layers to eliminate, sequence to follow. We reviewed it and pushed back on assumptions that didn't match how the system actually behaves at runtime. That review was the highest-leverage moment in the session. A wrong plan executed fast still produces the wrong result. A few minutes challenging the plan saved hours of misdirected work.

We kept correcting it mid-investigation. Claude Code made assumptions about startup sequence, which environment variables were authoritative, what test results implied. Several were wrong. Saying "that's not how this works" changed direction immediately. It doesn't defend wrong assumptions - it incorporates corrections and re-traces. Human operational knowledge combined with AI tracing is what got there in 60 minutes. Neither alone would have.

We gave it operational context, not just code. Claude Code reads code structure. It can't know runtime behavior - deployment order, environment injection timing, what actually happens when the pod starts. Telling it "this variable comes from the K8s secret, not the code" cut entire categories of wrong hypotheses before they started. Think of it as onboarding a very fast engineer who has read all the code but never run the system.

No context-switching penalty. This is the real reason it's fast. A human loses the mental model a little every time they switch between files, log streams, and components. Rebuilding it costs minutes each time and compounds over hours. Claude Code held the full startup sequence, token cache state, log timestamps, and test results in context simultaneously for the entire session. It wasn't faster because it worked in parallel. It was faster because it never lost the thread.

So What? — Patterns You Can Apply Today​

This wasn't just about one bug. Here's what engineers should take away:

1. SDK credential priority matters. Any SDK that supports multiple credential sources (env vars, files, service keys) has a resolution order. Know it. Document it. Add startup validation that fails fast if conflicting credentials are detected.

2. Test startup, not just functions. Unit tests that call init() directly don't catch prewarm race conditions. Write integration tests that mimic actual container startup sequence.

3. HTTP 400 ≠ bad request body. In multi-tenant OAuth systems, 400 often means "valid request, wrong context." Decode the JWT, check the issuer/audience, compare to the endpoint you're calling.

4. AI debugging works best with full context. Don't feed the AI one file at a time. Give it the error, logs, and codebase access simultaneously. The bug is often in the gap between components.

5. Human operational knowledge is irreplaceable. AI can trace code and correlate logs. It can't know that your K8s secrets get injected after container start, or that prewarm runs before init. Tell it.

Try It​

If you have a bug that only shows up in the full system flow - give Claude Code the error, the logs, and codebase access together, not sequentially. Ask it to correlate timestamps, trace from startup to failure, use process of elimination.

Tell it to generate tests that reproduce the failure condition, not just unit tests for individual functions.

Review the plan it produces before you let it run. Push back on anything that doesn't match how your system behaves at runtime. Give it the operational context it can't get from reading code alone - deployment sequence, environment assumptions, how you actually test things.

Set up MCP access. Use short-lived credentials. Gate writes behind approval. Enable memory. Hand it docs for anything non-vanilla.

Then watch it curl through logs, write and validate tests and re-direct it when needed (i.e. provide more context) while sipping your coffee….

The Claude Code Skill - Reusable Debugging Pattern​

We've encoded the hard-won patterns from this debugging session into a reusable Claude Code skill. Drop this into your .claude/commands/ directory and invoke it whenever you hit an HTTP 400 in any authenticated distributed system.

---
name: debug-http400
description: Diagnose HTTP 400 errors in systems that use OAuth tokens, service keys, API gateways, or multi-provider credential configs. Goes beyond "bad request" — encodes hard-won patterns where 400 is caused by correct-but-wrong-environment tokens, credential mixing, proxy masking, and startup auth race conditions.
argument-hint: [error message, endpoint, or affected component]
---

You are debugging an HTTP 400 error. The context is: $ARGUMENTS

HTTP 400 in authenticated distributed systems almost never means "malformed request body".
It usually means **the request is structurally valid but contextually wrong** — wrong environment,
wrong token, wrong endpoint, mixed credentials. Work through every phase below.

---

## Phase 1: Establish What 400 Actually Means Here

First, determine which layer is returning the 400:

- **Your own validation code** — a required field is missing or wrong type
- **An API gateway / proxy** — the gateway rejected it before it reached the upstream service
- **The upstream service itself** — the service received the request but rejected it
- **An auth server** — the token request itself returned 400 (malformed grant, wrong client_id)

How to tell:
- Check response headers for gateway fingerprints (`x-envoy`, `x-kong`, `via`, `x-request-id` patterns)
- Check if the response body is HTML or a generic error page (proxy) vs structured JSON (service)
- Check if the 400 comes back instantly (proxy reject) or after a round-trip delay (service reject)
- Check whether the same request works against the service directly (bypassing the gateway)

**If it is a gateway/proxy 400:** the upstream error is being masked. The real error is likely a
401 or 403 that the proxy is converting. Do not debug the request body — debug the token.

---

## Phase 2: Read All Credential and Config Code First

Before forming hypotheses, read the entire credential resolution path:

- How are credentials loaded? (env vars, JSON service key, file mount, secret store)
- Is there a priority order? Which credential source wins when multiple are present?
- Is there any startup / prewarm code that fetches and caches a token early?
- Are tokens cached in memory? What is the TTL? When is the cache invalidated?
- Are there multiple credential sets (staging + prod, service A + service B) that could coexist?

Read ALL config/secret files that could be active — not just the one you think is in use.

---

## Phase 3: Fan Out — All HTTP 400 Hypotheses

Generate all plausible causes before investigating any single one:

### 🔑 Credential & Token Hypotheses

**H1 — Token from wrong environment**
Token is valid and well-formed, but was issued by staging auth and sent to prod endpoint (or vice versa).

**H2 — Credential mixing: composite key + individual vars coexist**
A service key JSON (composite) and individual auth vars are both present. The SDK resolves them in a fixed priority order.

**H3 — Prewarm auth race: token cached before config is fully loaded**
Auth is fetched eagerly at startup before env vars are fully set.

**H4 — Wrong OAuth grant type or missing parameter**
The token request itself returns 400.

**H5 — Expired or revoked token sent**
Token was valid when cached, expired server-side before local TTL.

### 🌐 Gateway & Proxy Hypotheses

**H6 — Enterprise proxy is masking the real error**
Proxies sometimes convert upstream 401/403 into 400.

**H7 — Wrong base URL: request routed to wrong environment**

**H8 — Missing or malformed required header**

### 📦 Request Body Hypotheses

**H9 — Body encoding or content-type mismatch**

**H10 — Payload too large or silently truncated upstream**

---

## Phase 4: Eliminate in Parallel

For each hypothesis, gather evidence that confirms or rules it out.

## Phase 5: Root Cause Statement

Write out what exactly triggers the 400 and why it returns 400 instead of 401/403.

## Phase 6: Fix with Minimal Blast Radius

Fix only the confirmed root cause. Verify ALL secret/config files.

## Phase 7: Prevent Recurrence

Add fast-fail validation, cache invalidation, and observability.

Key insight encoded in this skill: HTTP 400 in authenticated distributed systems almost never means "malformed request body." It usually means the request is structurally valid but contextually wrong — wrong environment, wrong token, wrong endpoint, mixed credentials. The skill walks through 10 hypotheses in parallel, ensuring you don't get tunnel-visioned on the wrong layer.

Helpful Links​

This Post:

• Read on Medium - Shortened version with discussion

Claude Code & MCP:

• Claude Code Documentation - Official guide
• Model Context Protocol (MCP) - The protocol that enables Claude Code to access external tools and data
• MCP Servers Directory - Pre-built MCP servers for GitHub, Kubernetes, databases, and more
• Claude Code Skills/Commands - How to create reusable skills like the one above

SAP-Specific:

• SAP AI Core Documentation - Official SAP AI Core guides
• SAP AI SDK for Python - The SDK with the credential resolution logic discussed
• SAP Business Technology Platform (BTP) - SAP's enterprise cloud platform
• Gardener - Kubernetes-as-a-Service for multi-cloud environments

A Broader Mission for a Changing Landscape​

Beyond the visual redesign, the SAP Architecture Center is evolving to reflect a fundamental shift in both our industry and SAP's strategic direction. The pace of technological change, particularly with AI, cloud transformation, and evolving enterprise needs, requires a more dynamic and transparent approach to architectural guidance.

Our mandate has expanded. The Architecture Center is no longer simply a repository of reference architectures. It has become a communication channel between SAP's architectural vision and the global community of practitioners implementing these solutions. We are committed to bringing greater transparency to our work, sharing not just finished architectures but also insights into what we are currently developing, the challenges we are addressing, new research initiatives, and the strategic directions we are pursuing.

This shift recognises that architecture is a continuous conversation, not a set of static documents. As the industry evolves and SAP's strategy adapts to new market realities, the Architecture Center will serve as a living platform where these changes are communicated clearly, openly, and in a way that helps you make informed decisions about your own architectural choices.

Comprehensive Reference Architectures​

The platform now hosts 30 reference architectures across 104 unique documents, and the external version of the AI Golden Path. Each architecture provides detailed guidance on integrating SAP solutions with cloud providers and technology partners.

Recent additions include practical implementations for:

• Agentic AI & AI Agents covering how to build, integrate and orchestrate AI agents on SAP BTP using low-code approaches with Joule Studio, pro-code development with SAP Cloud SDK for AI, and Agent2Agent (A2A) interoperability.
• Integrating and Extending Joule exploring enterprise integration with SAP S/4HANA and SAP SuccessFactors, building custom skills and agents with Joule Studio, and extending Joule's capabilities across your landscape.

Community-Driven Content​

One of our core principles remains unchanged: the SAP Architecture Center thrives because of community contributions. The new Quick Start (coming soon) will make it easier than ever to contribute your expertise through an enhanced GitHub-based workflow. We have refined the contributor experience with better documentation, clearer guidelines, and streamlined processes for submitting new architectures or enhancing existing ones.

Our community section now provides comprehensive guides for getting started, including Visual Studio Code integration, architecture modelling guidelines, and best practices for creating diagrams and documentation. Whether you are proposing your first reference architecture or refining an existing one, the path forward is clearer.

What This Means for You​

Whether you are designing a new SAP integration, planning a cloud migration, or exploring how to implement AI capabilities in your enterprise applications, the new SAP Architecture Center provides:

• Clear, actionable guidance based on real-world implementations
• Detailed architectural patterns with diagrams and code samples
• Integration strategies for SAP products with hyperscaler services
• Best practices from SAP experts and community contributors
• Regular updates reflecting the latest SAP innovations

Looking Forward​

This release represents a significant milestone, but it is just the beginning. As part of our expanded mandate, we are committed to bringing greater transparency to our architectural work. You will see more frequent updates about emerging patterns, work-in-progress architectures, and strategic initiatives we are exploring. The Architecture Center will serve as your window into how SAP is thinking about and addressing the architectural challenges facing modern enterprises.

We are committed to continuously improving the platform based on your feedback and contributions. The SAP Architecture Center will continue to evolve as a living resource that grows with the SAP ecosystem, reflecting both the rapid pace of technological change and our evolving strategy.

We encourage you to explore the new platform, discover reference architectures relevant to your work, and consider joining our Community of Practice. Your expertise and real-world experience make this resource valuable for the entire SAP community. Through this enhanced transparency, we aim to create a stronger connection between SAP's architectural direction and the practical needs of the professionals implementing these solutions.

Get Involved​

The SAP Architecture Center is open source and welcomes contributions from architects, developers, and SAP professionals worldwide. Visit our Community of Practice page to learn how you can:

• Contribute new reference architectures
• Enhance existing documentation
• Share implementation experiences
• Participate in discussions (via SAP Community)
• Help shape the future of SAP architecture guidance

Thank you to all the contributors who have made this release possible. Your dedication to sharing knowledge and best practices benefits the entire SAP community and helps organisations worldwide build better solutions.

Celebrating Community Contributions​

We would like to highlight the contributions from our community partners who have enriched the Architecture Center with their real-world expertise. These contributions demonstrate the power of collaborative knowledge-sharing and bring valuable practitioner insights to our growing library of reference architectures.

We extend our sincere thanks to Fortinet for contributing Log-Driven Security Operations with SAP Enterprise Threat Detection and SIEM/SOAR Platforms, and to @randomstr1ng for authoring this comprehensive security architecture that bridges SAP-native threat detection with enterprise security operations.

Our appreciation goes to SD Worx for sharing SAP SuccessFactors Suite, and to @arjenvanhooydonk for creating this detailed overview of the SuccessFactors ecosystem that helps organisations understand the full employee lifecycle platform.

We are grateful to Glencore for contributing Transitioning Architectures from SAP NetWeaver, and to @abklgithub for providing this essential guidance on navigating the transition from NetWeaver-based products as they approach end-of-maintenance in 2027.

These contributions exemplify the collaborative spirit that makes the SAP Architecture Center a truly community-driven resource. We invite more partners and practitioners to share their architectural insights and help shape the future of enterprise architecture guidance.

We look forward to building the future of SAP architecture together.

The entire platform is available as open source at github.com/SAP/architecture-center.

ANYbotics, a Swiss robotics company, has stepped into this space with a vision to shape a safer future for industrial inspection, one where robots operate as autonomous members of the inspection team, running inspection operations integrated into plant maintenance workflows.

This vision is embodied in the company’s “ANYmal”: a four-legged inspection robot designed specifically for heavy industry.

Unlike general-purpose robotics platforms, ANYmal is engineered to operate in “big, dirty, dusty, and dangerous” environments, says Nicole Zingg, director of Technology Partnerships at ANYbotics. Places where stairs, corrosion, heat, and unreliable connectivity are the norm, not the exception.

But hardware, Zingg says, is only one part of the puzzle that makes ANYmal indispensable to customers.

Inspection robotics is about data​

“We build a hardware platform,” Zingg explains, “but inspection robotics is really about data that is consistent and trustworthy.”

ANYmal autonomously navigates industrial sites to collect data that goes beyond what a human can collect alone. Beyond just visual inspection, its sensors also collect multi-modal data, including thermal imaging, ultrasonic leak detection, gas concentration detection, acoustic anomaly detection, and more. The observations are fed into what ANYbotics calls “inspection intelligence,” which transforms the collected data into actionable operational insights. The result is higher uptime, longer asset lifecycles, and, most importantly, safer working conditions for humans.

ANYmal can make a huge impact on operations. One offshore wind customer, Zingg says, has used ANYmal to manage all inspections and has eliminated the need to send personnel to a remote platform for months. When human intervention was eventually required, ANYmal’s data from prior inspections made all the difference. The customer already knew exactly what was wrong, which expert to send, and what equipment to bring—avoiding costly and risky trial-and-error site visits.

Yet for ANYbotics, delivering insights is not enough if those insights are not integrated in the software systems customers use.

“SAP is where ANYbotics needs to be native”​

Through extensive user research, ANYbotics discovered that many plant operators, maintenance managers, and field service teams already run their daily operations in SAP. Work orders, asset histories, performance trends, and decisions all flow through SAP systems. “If customers are using SAP, SAP is where ANYbotics needs to be native,” Zingg says.

Meanwhile, SAP’s Project Embodied AI was looking for robotics companies to partner with. The project focuses on extending the impact of SAP Business AI into physical operations by enabling robots to autonomously perform complex tasks with an understanding of the broader business context.

It was clearly a perfect fit and has delivered advantages for both companies.

On the system side, a continuous, unbroken digital thread connects ANYbotics insights from industrial inspections to data in SAP systems, helping inform key business and operational decisions across the organization.

For end users, embedding ANYmal directly into familiar SAP workflows can also help ease adoption, since introducing robotics into already stretched industrial workforces can trigger anxiety. Concerns about job security, workflow disruption, and complexity are common, but embedding ANYmal directly into familiar SAP workflows can help reduce that friction, Zingg explains.

Treating robots as part of the workforce​

The first major integration point was SAP Field Service Management. Rather than sending only human technicians, customers can now dispatch work orders directly to ANYmal as they would to any other field team member. The robot then autonomously executes inspection tasks, gathers data, and reports the results directly back into a company’s SAP system.

From there, the integration expanded into asset-related scenarios and is now moving toward broader enablement via SAP Business Technology Platform (SAP BTP), with the goal of allowing robot-generated data to land wherever customers need it in their SAP landscape.

The ambition is not to force humans to adapt to robots, but for robots to adapt to human workflows. “ANYmal has to put data in the SAP system, just like human team members,” Zingg notes. ANYmal becomes another worker in the same operational system of record.

Project Embodied AI in practice​

This combination of ANYbotics robotic technology with SAP bridges the gap between physical operations and enterprise applications and tangibly reflects the goal of Project Embodied AI.

On the SAP side, AI agents operate on ANYmal’s robotic systems to execute physical tasks, such as safety inspections.

On the ANYbotics side, ANYmal is a physical object that moves through space, perceives its environment, and acts within real-world constraints. ANYmal uses SAP historic and time-series data to inform decisions while at the same time remaining fully autonomous even in environments with no connectivity.

It’s important to note, Zingg stresses, that ANYbotics has control over ANYmal’s behavior and inspection execution, while SAP has control over the business context such as work orders, asset data, or operational priorities. It is the SAP business context that informs how ANYmal’s insights are consumed and acted upon while ANYbotics controls ANYmal’s physical interactions.

Scaling safely and responsibly​

Today, more than 200 ANYmal robots are already in productive use worldwide, with inspection deployments in heavy-industry environments that would otherwise require constant human exposure.

Safety remains central to ANYbotics. Each deployment includes extensive testing and an on-site field engineer who helps ANYmal learn and validate its environment and trains customer teams on safe operational procedures. While ANYmal is built to work independently, humans remain firmly in the loop.

A glimpse into the future​

As industries face labor shortages and aging workforces, undocumented expertise can all too often be lost. With autonomous inspection robots such as ANYmal, this knowledge is captured and turned into programs that can run day in and day out across multiple sites. The captured data flows into SAP to become organizational intelligence that survives any workforce turnover.

ANYbotics’ partnership with SAP shows that this combination of robotics and enterprise software is moving swiftly from the experimental stage to real-world implementation.

In the future, industrial inspection will be powered by AI, not as disembodied dashboards or isolated machines, but as an integrated intelligent system where physical robots and digital workflows in SAP systems operate as one.

In that future, robots like ANYmal are no longer novelties. They are coworkers, albeit mechanical four-legged ones, quietly extending human capability into places humans were never meant to go. These robots, together with SAP, are shaping for a future where dirty, dangerous, and dusty industrial inspections are being transformed into business insights.

Alexa MacDonald

Top image courtesy of ANYbotics

Welcome to our Q4-2025 quarterly update for the SAP Architecture Center! This quarter was all about AI—from a brand new Embodied AI Agents architecture to expanded Joule guidance covering everything from S/4HANA integration to building custom AI agents. We also added practical content on event-driven patterns and data integration.

We hope you find this list useful and join us in thanking our contributors for their efforts in building the SAP Architecture Center together.

Featured Reference Architecture​

This quarter brings a new top-level reference architecture that bridges AI and robotics—showing how intelligent agents can operate in the physical world:

• Embodied AI Agents - Discover how to build and deploy Embodied AI Agents that interact with physical environments. This architecture explores the integration of AI capabilities with robotics and IoT systems for innovative enterprise applications.

Reference Architectures with New Content​

We've expanded existing reference architectures with significant new content, providing deeper insights across data management, AI, and integration topics:

• Integrating and Extending Joule

  • Joule in SAP S/4HANA Cloud - Understand how to integrate and leverage Joule AI capabilities within SAP S/4HANA Cloud Private Edition and Public Edition environments.
  • Identity and Access Management for SAP Joule - Implement secure authentication and authorization patterns for SAP Joule across your enterprise landscape.
  • Extend Joule with Joule Studio - Create custom Joule Skills and AI Agents using Joule Studio for seamless integration across SAP and non-SAP systems.

• Designing Event-Driven Applications

  • EDA Sample Use Cases - Explore real-world sample use cases demonstrating event-driven architecture patterns with SAP technologies.
  • SAP CAP Framework for Events to Business Actions Integration - Learn how to use the SAP CAP Framework to build robust events-to-business-actions integrations.

• Explore your Hyperscaler data with SAP Business Data Cloud

  • Integration with Snowflake - Connect and integrate Snowflake data sources with SAP Datasphere for comprehensive data analysis.

• Transforming Enterprise Data Strategy with SAP Business Data Cloud

  • Unifying Access Across SAP BDC with SAP Cloud Identity Services - Learn how to establish unified identity and access management across SAP Business Data Cloud components using SAP Cloud Identity Services.

Welcoming New Contributors​

We are thrilled to welcome new contributors who have joined our efforts to expand and enrich the SAP Architecture Center. Their expertise and dedication are invaluable to our community. A big thank you to:

• adelyafatykhova
• niklasweidenfeller
• guilherme-segantini
• nagesh-caparthy1
• seeobjectively

We hope you enjoyed reading these details. Please join us in shaping the future of SAP architecture and start contributing today!

We're excited to share the latest updates and additions to the SAP Architecture Center since our last major release in Q2-2025! Our community has been hard at work expanding the collection of reference architectures and welcoming new contributors along the way. This will be a quarterly recurring post going forward, where we spotlight newly released, updated, or retired content, along with members of the SAP ecosystem who have made their first contribution to our repository. It's also our chance to share some insights about how people are finding our site and repository.

We hope you find this list useful and join us in thanking our contributors for their efforts in building the SAP Architecture Center together.

New Reference Architectures​

We've added several new top-level reference architectures to provide even more guidance and best practices for building robust solutions with SAP technologies. Here are the latest additions, from newest to oldest:

• Extend Joule with Joule Studio - Utilize AI capabilities with Joule Studio in SAP Build. Create custom Joule Skills and AI Agents for seamless integration across SAP and non-SAP systems, driving automation and innovation.

• DevOps with SAP BTP - Adopt agile DevOps principles on SAP BTP with cloud services and tools for streamlined application lifecycle management.

• API Managed Integration - Enable secure, omni-channel API access to business apps with SAP Integration Suite, simplifying governance, security, and API consumption.

• Application to Application Integration - Enable seamless App2App integration with SAP Integration Suite for near real-time transactional data exchange across internal processes.

• Business to Business Integration - Optimize B2B integration with SAP Integration Suite for secure, scalable electronic document exchange with trading partners.

• SAP IAM integration with SAP Cloud Identity Services - Design authentication and role management flows for SAP SaaS with SAP Cloud Identity Services.

• Integrate and Extend with SAP Build Process Automation - Automate processes with SAP Build Process Automation, integrating workflows across SAP and non-SAP systems.

• Connect Business Applications with SAP Master Data Integration - Synchronize and manage business-critical data across SAP and third-party systems using SAP Master Data Integration.

• Secure Service Consumption Across Hyperscalers - This architecture outlines a cloud-agnostic approach for securely consuming services offered by hyperscalers from applications running outside their environments.

• Business to Government Integration - Streamline compliance with SAP's Business-to-Government Integration for secure electronic document exchange.

• Understanding Network Performance in a Multi Regional Solution - Optimize multi-regional cloud solutions with insights into network design, provider usage, and service placement for superior performance.

Reference Architectures with New Content​

We've also expanded existing reference architectures with new content, providing deeper insights and broader coverage on key topics:

• Generative AI on SAP BTP
  • Vibe Coding with Cline and SAP AI Core - Learn how to set up and use Cline, an autonomous coding agent, with SAP AI Core to accelerate your development workflows.
  • Agent2Agent Interoperability - Enable interoperability between AI agents with Agent2Agent protocol, fostering collaboration across enterprise landscapes.
  • Partner Models - Benefit from partner models like the IBM Granite foundation model for the increasing demand of generative AI features in business scenarios with emphasis on data security, IP Protection and enterprise-grade governance and compliance.

Welcoming New Contributors​

We are thrilled to welcome new contributors who have joined our efforts to expand and enrich the SAP Architecture Center. Their expertise and dedication are invaluable to our community. A big thank you to:

• uklasing
• kshanth
• AjitKP91
• avikSap
• alperdedeoglu
• sapgunnar
• bzarske
• maria-kondratyeva
• miguelmezamartinez

We hope you enjoyed reading these details. Please join us in shaping the future of SAP architecture and start contributing today!

I'm pleased to announce that my team at the Office of the CTO, SAP, has officially launched the SAP Architecture Center on the SAP Learning Center.

Why did we create it?​

In the past, we've relied on various tools, ranging from PowerPoint presentations to static websites, for documenting and sharing technical architectures. These methods, however, lacked collaborative authoring capabilities, robust version control, and ease of iterative refinement. To address these limitations, we've transitioned to a modern, collaborative solution using GitHub, a widely recognized platform among developers and architects.

What is the SAP Architecture Center?​

The SAP Architecture Center is a GitHub-based repository designed to enhance how we build, publish, and govern Reference Solution Architectures. Each architecture is managed through Markdown files on GitHub, supporting transparent collaboration, robust version control, and structured governance. Solution diagrams utilize draw.io, an open-source tool, and integrate seamlessly into our official Solution Diagrams repository, managed by Fabian Lehmann.

How does it work?​

• Efficient collaboration across teams.
• Robust version control for architectures.
• Collective enhancement and evolution of architectures.
• Structured governance with clear review and approval workflows.

Architecture Center Vision​

What's next?​

SAPPHIRE 2025 was our initial launch milestone, marking the start of this journey. Moving forward, we have several strategic enhancements planned:

1. Automated Architecture Validator with Joule Interface: Solution diagrams will include embedded service metadata, enabling AI-powered automated validation and testing through Joule.
2. Integration with Learning Journeys: Enhanced integration with SAP Learning Center Learning Journeys for certifications and accreditations, along with closer alignment with SAP Discovery Center’s service catalog and missions.
3. Expanded Architectures: New architectures in data and agentic AI—including open-source collaborations such as A2A interoperability—and additional architectures addressing non-functional requirements like HA/DR, security, and observability.

Special acknowledgment to Philipp Herzig and Andre Bechtold for sponsorship, the core team: James Rapp, Pierre-Olivier Basseville, Navya Khurana, Fabian Lehmann, Michael Still, Marina Noble, Adi Pleyer, PVN PavanKumar, Julian Schambeck, Johanna Gonzalez, Vedant Gupta, Gabriel Kevorkian, Kay Schmitteckert, Robin Purschwitz, Max Lienhardt, Jonas Mohr, Praveen Padegal, and all contributors.

Join us in shaping the future of SAP architecture.

Start contributing today!

Anirban Office of the CTO