Work

I provide contract-bound architecture judgment — not implementation.

Teams bring me in when they need an external verdict to stop endless investigations, restore clear ownership, and make a decision that survives post go-live reality.

What I do (and what I don’t)

I do

• Diagnose boundary failures in SAP BTP extension landscapes.
• Produce a written verdict that clarifies what must change vs what must not change.
• Define jurisdiction rules (who owns what, where the platform ends, where the extension begins).
• Help leadership converge when “everyone has a piece of the truth”.

I don’t

• Provide delivery/implementation services.
• Join as staff augmentation, ticket execution, or “extra hands”.
• Replace your architects — I align them around a stable decision.

The boundary map I use

My work is grounded in six boundaries (in the same order used in the “Why BTP Projects Fail” framework):

1. Runtime / Execution Boundary — what runs where, and what runtime rules actually govern behavior
2. Identity Boundary — identity propagation, trust, and authorization context across layers
3. Tenant Boundary — tenant routing, isolation expectations, and multitenancy truth vs assumptions
4. Data Boundary — ownership, integrity rules, replication, and cross-domain data contracts
5. Integration Boundary — cross-system jurisdiction (“Postman works, Work Zone fails”)
6. Lifecycle Boundary — upgrades, rollout rules, evolution authority, and long-term stability window

This applies to CAP and beyond (e.g., RAP-based scenarios, Kyma/CF workloads, Work Zone surfaces) — the failure pattern is architectural, not framework-specific.

When architectural judgment is required

You are likely facing a boundary failure if:

• It works in one tenant but fails in another.
• It works in Postman but breaks behind AppRouter / Work Zone.
• It “passed go-live” but degrades months later during rollout, scale, or organizational change.
• Fixes require changing subdomains, destinations, trust, roles, or tenant routing (not just code).
• Multiple teams are involved, yet no one clearly owns the failure.

Engagement formats (fixed-fee, scope-based)

I keep engagements fixed-fee and timeboxed. Pricing is shared in a short SOW after an intake message.

Option A — Boundary Verdict Sprint

For high-signal situations where the program is already in “it’s complicated” mode.

Outputs

• Boundary map (all six boundaries)
• Top decision points: what must change vs what must not change
• Written verdict memo (shareable inside leadership)

Option B — Boundary Audit

For deeper diagnosis + stakeholder alignment when ownership is fragmented across teams/vendors.

Outputs

• Everything in Option A, plus:
• Interview-based ownership map (who controls what in reality)
• Remediation plan framed as jurisdiction rules, not a ticket list
• Convergence notes: the minimum set of decisions required to end the investigation loop

Option C — Annual Coverage

For organizations running multiple extensions and needing repeated verdicts across the year.

Outputs

• Multiple verdict cycles with consistent boundary language
• Ongoing boundary governance support (especially during rollout/upgrade windows)
• Priority access when incidents trigger a “responsibility gap”

How to engage

Send one message with:

1) Your landscape (S/4 + BTP runtime(s) + identity)
2) Symptoms (what works where, what breaks where)
3) Timeline (go-live / rollout / recent change)
4) Stakeholders (who owns what today)
5) The decision you cannot converge on

Contact: pei_jiandong@hotmail.com
Or reach out via LinkedIn.