Independent SAP BTP Architect
Builder‑side authority for post‑go‑live SAP BTP extensions. I provide independent SAP BTP architecture reviews, extension audits, and boundary verdicts when work continues but the decision no longer converges — what must change, what must remain, and who owns it.
Former platform engineer at SAP; worked across multitenancy, identity propagation, integration boundaries, and lifecycle orchestration on SAP BTP.
The Boundary Model emerged from repeated post–go-live failures observed from inside the platform layer.
Who this is for
For architects, technical leads, and decision‑makers facing post–go‑live instability in SAP BTP extensions.
Typical pattern:
Docs look aligned.
Runtime behavior varies by path, tenant, or identity.
Ownership fragments across teams.
The system runs; the architecture can’t be governed.
Different symptoms. Same architecture question.
Teams rarely begin with a methodology. They begin with symptoms: architecture review, extension audit, post‑go‑live failure, identity propagation problems, AppRouter / Work Zone failures, tenant onboarding drift, or vendor disagreement.
These are often different words for the same underlying question: is the current SAP BTP extension architecture still structurally safe to evolve?
SAP BTP Architecture Review → · SAP BTP Extension Audit → · SAP BTP Post-Go-Live Failure Assessment →
What I actually do
- Diagnose boundary failures across runtime, identity, tenant, data, integration, and lifecycle.
- Issue a written verdict — what must change, what must remain.
- Re‑establish jurisdiction — who owns what, and where.
What these engagements are not
- Not implementation takeover.
- Not staff augmentation or ticket execution.
- Not generic advisory or “best‑practice” consulting.
You may need an independent verdict when…
- The system runs, but no team can legitimately approve the next change.
- Teams are locally correct; the decision still does not converge.
- Rollout, onboarding, or hardening exposes an ungovernable architecture.
- Works in Postman; fails behind App Router or Work Zone.
- Local fixes increase motion; ambiguity does not decrease.
When this is no longer an implementation problem
Troubleshooting improves a step; it does not grant legitimacy. When teams are locally correct and the system remains globally unstable, the failure is jurisdiction — not effort.
Define the decision across boundaries — identity, tenant, data ownership, integration contracts, lifecycle gates — then continue implementation on stable ground.
Implementation vs verdict → · When internal alignment has failed →
Choose your path
Four direct entry points to make the situation legible and bounded.
Boundary Model
Canonical definition of six boundaries and why traditional reviews miss these failures.
Read the model →Failure Patterns
Recurring symptoms of boundary and jurisdiction failure in SAP BTP extensions.
See patterns →What an independent verdict does
Inputs, assessment, outputs, and boundaries — without implementation takeover.
Make it legible →Need a review?
Direct entry point for SAP BTP architecture review when internal teams can no longer approve the architecture end‑to‑end.
Request a review path →Verdict services
Fixed‑scope architectural judgment — clear inputs in, a written decision out. Not a funnel.
Verdict servicesWhen to request a review
If the decision no longer converges internally, move to a fixed‑scope review. The next move is small and tangible.
Start with one structured page: landscape, divergence, ownership, decision. Short version → What This Is Not