When an SAP BTP issue is no longer an implementation issue
Some SAP BTP extension problems keep being worked on long after they stop being decidable internally. Past this point, more implementation increases motion — not the legitimacy of the next architectural change.
What this usually looks like
- More implementation effort is not reducing ambiguity.
- Different teams are locally correct but cannot converge.
- The system runs, but no one can legitimately approve the next change.
- The path works in one surface or tenant but not in another.
- Security or rollout hardening exposes architectural assumptions too late.
Why the old path is not necessarily lower‑risk
Familiar motion, visible progress — and the wrong contract. When the failure is structural (boundary validity, trust, tenant model, lifecycle authority), risk sits in jurisdiction, not effort. Continuing the motion postpones the decision and entrenches the wrong contract.
What changes at this point
The center of gravity shifts from fixes to legitimacy: which boundaries are valid, which assumptions hold across tenants and entry paths, and who has authority to approve the change.
Implementation and troubleshooting
- Fixing incidents along the path
- Optimizing surface behavior
- Team‑local success criteria
Jurisdiction and decision legitimacy
- Boundary validity across identity, tenant, data, integration, lifecycle
- Which contracts must change vs remain
- Who holds final architectural jurisdiction
Next steps
Define the decision → stabilize the architecture → continue implementation. Fixed‑scope formats make this legible and fast.