This blog series is the result of a collaboration between Stephen Fishman, Stanislav Pokraev, and Adam Davis. Each author represents a different area of the MuleSoft organization – Customer Success, Office of the CTO, and Professional Services, respectively
API ownership can be contentious given complexities regarding business context, accountability, shared systems, dependencies, and more.
As a guide for developing an ownership model that makes sense for your enterprise, it’s helpful to consider how the API will be used in a business context. This includes the degree to which the API is shared by multiple stakeholders across the organization, the proximity of the API to customer transactions and experiences, and the level of organizational support of DevOps cultural norms and processes inclusive of “You build it, you run it.”
Likewise, organizational incentives and processes should be in place to drive good stewardship and balanced interdisciplinary decision making. The state of organizational maturity on modernization topics ranging across business architecture, API productization, debt management, monitoring and alerting, etc. should also be considered.
Business versus technical API owners
Business API owner
The main responsibility of the business API owner is to justify the existence and continuous operation of the API. Typical activities performed by business API owners are:
- Understanding the needs of potential API consumers.
- Owning the business scope of the API as
well as the API’s SLA. - Communicating the business value of the API.
- Owning and directing the API implementation, release, and evolution strategy.
- Ensuring that the business capabilities of the API are fully documented, published, discoverable, and consumable.
- Ensuring API-consumer facing standards are articulated and complied with.
- Defining, monitoring, acting upon, and communicating business KPIs for the API as needed.
- Identifying, managing, and communicating business-related issues and enhancement requests.
- Integrating business-related issues/enhancement requests into a holistic API roadmap and versioning strategy.
Technical API owner
The main responsibility of the technical API owner is to ensure that the API is implemented, operated, and evolved in accordance with the company’s best practices and standards. Typical activities performed by technical API owners are:
- Developing the API and its operations as well as implementing change requests.
- Owning the operational-level agreements (OLA) of the API and ensuring that the API meets its objectives in terms of availability, performance, security, and more.
- Defining, instrumenting, monitoring, acting upon, and communicating technical KPIs for the API as needed, and connecting KPI performance with potential OLA and SLA issues.
- Ensuring that the technical capabilities of the API are fully documented, published, discoverable, and consumable.
- Ensuring API-developer and API-operator facing standards are articulated and complied with.
- Identifying, managing, and communicating the dependencies of the API on the underlying APIs/systems.
- Identifying, managing, and communicating technical issues and enhancement requests.
- Integrating technical issues/enhancement requests into a holistic API roadmap and versioning strategy.
API ownership: additional considerations
The first candidate for business API owner is the person who effectively owns or has the best interest in owning the change and release cycle of the business service realized by the API. Outside of experimentation and innovation contexts, building APIs without a roadmap or any real demand for consumption does not add value and is not good practice.
Preferably, business and IT leaders should act in partnership regarding API ownership – the business should drive the API strategy and roadmap in a marketplace context, and IT should drive the technical aspects, such as architectural and operational standards, implementation of releases and changes, incident management, etc. The business representatives owning the APIs should have the appropriate experience, discipline, skills, and functional expertise to decide on the API release cycles and changes. Not having the above should not lead to “central” (technology) ownership, and functional ownership should not sit with a core technology group.
It’s important to note that some APIs do not support a business function directly. For example, an API that is used to authenticate users is very important, but not directly related to a business function. Such APIs might not have a business API owner, but they need a technical API owner to ensure that the required functionality is available to other APIs/applications.
Depending on the API’s importance, what scenarios and populations the API supports, or available talent and organizational people strategies, some API owners can function in both business and technical ownership. Shared ownership that is mapped to value streams and/or capability models can be problematic in certain organizational cultures – while collaborative ownership models generally have the highest potential for smooth delivery and operation, aligning to existing cultural norms is the higher order principle in most circumstances.
Assuming that the enterprise has adopted DevOps norms to some degree, the team that builds the API should stay with the API (i.e., “You build it, you run it”). Ideally, the technical owner of an API should be from the team that has built the API. If there is no DevOps culture (an API is built by one team and operated by another team), a technical API owner should be assigned when the API needs to change (e.g., technical API owner for each version of the API).
Ownership of an API should not be considered indefinite, as it can and likely will change over time based on the changing needs of the enterprise along with career growth or changes for the assigned owner. However, implicit in the authority granted to either a technical or business owner of an API is the responsibility for stewardship.
Stewardship scope extends beyond the business requirements for the API into keeping the API assets healthy, fresh, operable, and flexible. Stewardship efforts in the modern, agile enterprise can be problematic given the lack of linear connection to near-term business ROI. Noting this issue, establishing stewardship guidelines along with financing and incentives (for individuals, leaders, and teams) to attain reasonable levels of stewardship is necessary to keep the time and cost of future remediation efforts from ballooning to the level that discourages future investments, which causes enterprise capabilities to decay, inviting corporate disruption from competitors.
In part two of this blog series on API ownership, I will break down the API-led ownership and governance model for System APIs. To learn more about APIs and how to design a great API, download the eBook Undisturbed REST: A Guide to Designing the Perfect API.
