This API ownership 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.
The first post in this API ownership blog series detailed a conceptual model to facilitate grounded decisions on business versus technical API ownership. To provide further guidance on ownership for specific types of APIs, I’m diving into System APIs as a start.
What are System APIs?
System APIs provide a means for insulating the data consumers from the complexity or changes to the underlying systems. Once built, many consumers can access data without any need to know the details of the underlying systems. System APIs are typically fine-grained, business process-independent, and highly reusable.
System APIs, and the systems they integrate with, typically support more than one value stream and/or enterprise capability. Defining business ownership in these shared usage contexts can be complex. If clear business capability ownership of shared infrastructure is not present, enterprises can fall back on several other methods to derive business ownership – for instance, data ownership, hybrid technical/business owners, shared services organizations, etc.
Business versus technical System API owners
Business ownership of a System API should attempt to follow capability and/or value-stream ownership if possible (with secondary methods to derive ownership in regard to data ownership or shared systems and services). Technical ownership of a System API should follow system/platform ownership.
The perceived quality of an API is tightly coupled with the quality of the data it interacts with and upon. A well-designed API for a backend system simultaneously elevates both the level of system control and the ease of system accessibility. In most cases, the data access rules are defined based on data classification overlaid with the role designation of the requestor, e.g., some data is public, some data is confidential, and some data is privileged based upon the requestor’s role and area of responsibility. These rules are driven by enterprise security and data governance policies in the enterprise and vary widely across
The best person to define the API access policies is the one who understands not only the data being requested and/or acted upon but also how the data will be used across the enterprise. In many cases, data supporting multiple business functions is managed in a single system (e.g., SAP, Salesforce) that supports shared business processes and capabilities.
Defining the business ownership of an API based on the ownership of the system where the data is can be problematic given that many system owners are typically only responsible (and qualified) for the technical aspects of the system along with the system functions at the core (e.g., system availability, system performance, core use cases, etc.) rather than the enterprise use cases for leveraging that system at the edge (e.g., customized processes for unique line-of-business (LOB) requirements, workarounds and integrations for unique customer requirements, etc.). Many organizations also do not have playbooks for managing shared systems with multiple LOB stakeholders.
In contrast, defining business ownership of a shared API has similar concerns given that many business owners are typically only responsible and qualified for the management of new feature delivery rather than the operational discipline required for enterprise platforms with broad concerns on resiliency, security, scalability, future flexibility, and other highly technical aspects. And again, many organizations do not have playbooks for managing shared systems with multiple LOB stakeholders.
Implications of assigning System API owners
Assigning business and technical ownership of shared resources deep within an enterprise application infrastructure has many pitfalls and tradeoffs, regardless of the decision.
In assigning ownership of System APIs, one should consider the near and long term goals for the shared System API, which makes the decision simpler – for example, a shared system that has little need for enhancement but must be available at all times can minimize the risks associated with a business owner role being staffed by assigning a technical staff member that is capable of achieving a balanced perspective under pressure and has a reasonable set of experience that aligns with the system’s capabilities. Conversely, a shared system that is used for launching new products and ventures can optimize for near-term objectives with a formal business owner that has reasonable grounding in technical concerns.
Another top consideration is that shared resources require shared leadership. Developing steering committees for shared infrastructure can achieve superior results to single ownership through collaboration and diversity in experience. If the organizational culture requires “a single throat to choke/hand to shake,” a steering committee that reports to an executive sponsor can act as a bridge from the abstract contextual business need to the organizational culture on the ground.
For companies with mature data governance disciplines, EA discipline have typically 2 roles of “Data Definitions Owner,” and “Data Owner.” The Data Definitions Owner – typically a domain architect with data governance skills – has authority when it comes to how the business entities are defined and what their attributes and relations are to other entities. The Data Owner – usually a data steward (in the MDM terms) – is responsible for the actual data quality, e.g., all mandatory attributes are present, no duplicate records, etc.
Typically, an organization has a single Data Definitions Owner per business data entity and multiple Data Owners (e.g., for multiple regions). For System APIs that expose business-process independent data, consider having a Data Definitions Owner or a Data Owner also as business API owner.
The next blog post will detail ownership and governance model for Process APIs. If you’d like to learn more, take a look at our API resources.
