Failure Patterns
Use these symptoms to recognize when a SAP BTP extension or enterprise AI initiative has moved beyond local implementation correctness into architecture judgment.
What these patterns have in common
Local correctness survives; global validity does not. Each pattern reflects a boundary or jurisdiction failure where individual teams can be right, yet the system remains wrong.
Implementation symptoms - intermittent failures, tenant variance, security blocks, rollout friction, or agent responsibility drift - are downstream of an unsettled contract across identity, tenant, data, integration, lifecycle, or execution.
Recognize these as decision points. Treat them as triggers for an independent architectural verdict.
Postman works, Work Zone fails
Symptom: Direct requests succeed, but the governed path through AppRouter, Work Zone, destinations, or principal propagation fails.
Why local success is misleading: Postman proves connectivity. It does not prove the production entry path, identity chain, or runtime contract.
Decision that needs judgment: Decide whether the architecture is valid across the real entry surface or only on a protected test path.
One tenant works, next tenant fails
Symptom: The first tenant succeeds, but onboarding, routing, subscription, data isolation, or role mapping breaks in the next tenant.
Why local success is misleading: A single tenant can hide assumptions that are not valid as tenant-scoped architecture.
Decision that needs judgment: Decide whether the tenant model is structurally correct or only patched for the first context.
Dev works, prod fails
Symptom: The same logic works in development but fails after production trust, role collections, destinations, hardening, or rollout constraints apply.
Why local success is misleading: Development proves a local behavior. Production proves whether the boundary contract holds under real governance.
Decision that needs judgment: Decide whether the failure is environment configuration or an architecture that was never production-representative.
Technical user flow works, real user propagation fails
Symptom: A technical user or service credential path works, but named-user propagation returns wrong authorization, org context, or 403 behavior.
Why local success is misleading: Service-level success can bypass the user-context boundary that the business process actually depends on.
Decision that needs judgment: Decide which actor owns the action and whether the identity chain is legitimate end to end.
S/4 data copied into HDI becomes shadow truth
Symptom: Copied data works for reporting or UX, then gradually becomes a competing source of truth for decisions or writes.
Why local success is misleading: A successful copy does not transfer business authority, lifecycle ownership, or write jurisdiction.
Decision that needs judgment: Decide what must remain anchored in S/4HANA and what the extension is allowed to own.
Clean Core adopted, extension ownership unclear
Symptom: The program agrees to keep the core clean, but no one can say who owns extension truth, lifecycle, or cross-system responsibility.
Why local success is misleading: Clean Core constrains the core. It does not automatically decide the BTP extension architecture.
Decision that needs judgment: Decide where responsibility belongs before side-by-side architecture becomes shadow core.
Agent demo works, execution safety unclear
Symptom: The agent can answer, recommend, or execute, but the team cannot prove what it may see, infer, trigger, or write.
Why local success is misleading: A successful answer can still violate truth, context, authorization, workflow, or accountability boundaries.
Decision that needs judgment: Decide the permitted action class and who owns the final business action.
Migration or rollback requires manual repair
Symptom: Changes can be made only with manual fixes, expert intervention, or undocumented sequencing.
Why local success is misleading: Manual repair can keep production alive while proving the architecture is not reconstructible.
Decision that needs judgment: Decide whether the lifecycle boundary supports deterministic change from version N to N+1.
Integration works, but no one owns the contract
Symptom: Endpoints connect and payloads return, but teams disagree about meaning, ownership, failure handling, and change authority.
Why local success is misleading: Connectivity is not integration. Integration is governance of meaning across system boundaries.
Decision that needs judgment: Decide who owns the cross-system contract and which behavior is legitimate.
The system runs, but cannot move from N to N+1
Symptom: Operations continue, but the next version, tenant, policy, tool, prompt, workflow, or integration change cannot be applied cleanly.
Why local success is misleading: Running today is not proof of structural safety. Evolution is the stronger test.
Decision that needs judgment: Decide whether the system is stable by architecture or by continued expert intervention.
These are not implementation categories. They are verdict triggers. Stabilize the architecture; then continue implementation.
If several patterns coexist, the issue is likely no longer local.
AI-era failure patterns
When agents, workflows, extensions, automations, and core systems are combined, the same boundary problem appears as responsibility drift.
- Responsibility drift
- Truth drift
- Execution drift
- Identity drift
- Lifecycle drift
- Accountability drift
If this is already happening
If several of these patterns coexist, the question is usually no longer whether a capable team can make the system work. The question is whether the current architecture deserves to continue as designed.
Work With Me -> · SAP BTP Architecture Review -> · SAP BTP Extension Audit -> · SAP BTP Post-Go-Live Failure Assessment ->
Prefer recognizable project situations? See Representative Cases.