A city mobility app exposes an API that a regional transit partner will consume. The partner sits outside the city org chart. How should the BA classify that partner?
Select an answer to reveal the explanation.
Short Explanation
If another agency rides your API, they care about your project—even if HR doesn’t list them. External partners still go on the stakeholder map for a municipal mobility build.
Full Explanation
A regional transit partner that will consume a city mobility API sits outside the city’s org chart yet clearly holds interest and influence over interface design, availability, and change timing. The BA should classify that partner as an external stakeholder whose needs still belong in stakeholder analysis. Civic platforms routinely depend on cross-agency consumers; excluding them because they are not employees creates integration failures and political friction at go-live.
Treating the partner as a non-stakeholder because they are outside the org chart fails conceptually because organizational employment is not the definition of a stakeholder; interest and influence are. Treating them as an internal employee stakeholder once the API goes live fails because go-live does not convert an external agency into city staff, and engagement and contract norms remain external. Limiting them to temporary vendor status only if they pay a license fee fails because payment is not the gate for stakeholder recognition when they consume a public API that the city exposes for regional service.
Exam caveat: Associates must include external partners and consumers in stakeholder maps even when HR charts omit them. Operational check: add the transit partner to the mobility-app stakeholder register with external classification, capture API needs and change-notification expectations, and include them in interface review communications before the next API milestone.