Problem description
During recent API Backlog discussions, we have repeatedly seen new proposals reaching the backlog with unclear or weak alignment to CAMARA scope.
This is creating recurring discussions on topics that should ideally be clarified earlier in the proposal process, such as whether the proposal is really a customer-facing northbound API, whether it fits the definition of a Service API or Service Management API, whether it overlaps with existing CAMARA APIs, or whether parts of it are actually closer to Operate APIs or other out-of-scope areas.
The Project Charter already defines CAMARA scope and the API onboarding process already states that proposals must be validated against CAMARA governance and the Project Charter during backlog review. However, the current API Proposal Template and API Scope Enhancement Template do not explicitly require proposal owners to explain why their proposal fits CAMARA scope. As a result, scope-fit analysis is happening too late and too often during backlog sessions instead of being made explicit at submission time.
Expected action
Update the API Backlog proposal documentation so that scope alignment is made explicit and mandatory at submission time.
In particular, the API Proposal Template and the API Scope Enhancement Template should include a dedicated section where proposal owners must explain:
- why the proposal is in scope for CAMARA,
- which CAMARA northbound API type it belongs to,
- why it is not an Operate API or other out-of-scope interface,
- whether it overlaps with existing CAMARA APIs and, if not, why a new proposal is needed,
- and which parts are explicitly considered out of scope.
Optionally, the same scope-fit check could also be reflected in the backlog issue template and/or in a short backlog review checklist for codeowners.
Additional context
Relevant reference documents:
Governance/ProjectCharter.mdGovernance/documentation/API-Onboarding-and-Lifecycle.mdAPIBacklog/documentation/API-proposal-template.mdAPIBacklog/documentation/API-Scope-Enhancement-Template.md
The intention is not to redefine CAMARA scope in another place, but to make the existing scope rules operational and visible earlier in the backlog intake process.
Problem description
During recent API Backlog discussions, we have repeatedly seen new proposals reaching the backlog with unclear or weak alignment to CAMARA scope.
This is creating recurring discussions on topics that should ideally be clarified earlier in the proposal process, such as whether the proposal is really a customer-facing northbound API, whether it fits the definition of a Service API or Service Management API, whether it overlaps with existing CAMARA APIs, or whether parts of it are actually closer to Operate APIs or other out-of-scope areas.
The Project Charter already defines CAMARA scope and the API onboarding process already states that proposals must be validated against CAMARA governance and the Project Charter during backlog review. However, the current API Proposal Template and API Scope Enhancement Template do not explicitly require proposal owners to explain why their proposal fits CAMARA scope. As a result, scope-fit analysis is happening too late and too often during backlog sessions instead of being made explicit at submission time.
Expected action
Update the API Backlog proposal documentation so that scope alignment is made explicit and mandatory at submission time.
In particular, the API Proposal Template and the API Scope Enhancement Template should include a dedicated section where proposal owners must explain:
Optionally, the same scope-fit check could also be reflected in the backlog issue template and/or in a short backlog review checklist for codeowners.
Additional context
Relevant reference documents:
Governance/ProjectCharter.mdGovernance/documentation/API-Onboarding-and-Lifecycle.mdAPIBacklog/documentation/API-proposal-template.mdAPIBacklog/documentation/API-Scope-Enhancement-Template.mdThe intention is not to redefine CAMARA scope in another place, but to make the existing scope rules operational and visible earlier in the backlog intake process.