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.
Part three of this API ownership blog series is all about Process APIs – let’s get into it!
What are Process APIs?
Process APIs provide a means of combining data and orchestrating multiple System APIs for a specific business purpose (e.g., 360-degree view on customer, order fulfillment, etc.). They are often used to construct a business entity which attributes are managed in multiple systems of records (e.g., SAP, Salesforce, etc.) by different business functions (CRM, Customer Support, etc.).
Process APIs manifest a set of business services and often support a portfolio of enterprise offerings (i.e., products and services). The ownership of Process APIs typically resides with the owner of the value stream that encompasses the supported products and services. When this is not possible, increased levels of cooperation are needed between multiple stakeholders. This cooperation can be achieved by a cross-organizational standing committee that owns the Process API and governs its roadmap, release cycle, and operational management strategy.
Business versus technical Process API owners
Business ownership of a Process API should attempt to follow capability and/or value-stream ownership if possible, with secondary methods to derive ownership in regard to shared systems, products, and services. Technical ownership of a Process API should follow system/platform ownership. If the Process API in question spans multiple platforms, ownership can be derived from several methods (e.g., which system or platform has the highest likelihood of impact from changes, designate an owner from an integration services organizational unit, etc.)
Process API ownership concerns can be more complex than System APIs given that the number of system interfaces is greater than that of a typical System API, which only integrates with a singular system of record. Additionally, composite services have more dependencies and therefore can result in greater difficulty managing quality of service issues inclusive of, but not limited to, performance, error management, error tracing and isolation, etc.
Since Process APIs are closer to concrete business transactions, assigning technology staff members to play the role of business owner becomes less feasible and more problematic. Conversely, given the technical complexity of composite services that are still abstracted away from actual experiences, defining a singular owner also has its own issues and tradeoffs.
Implications of assigning Process API owners
Noting the difficulties of composite business services that are abstracted away from singular experiences, organizations should consider shared infrastructure and leadership based on potential when assigning ownership of Process APIs.
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.
Additionally, evaluate your organization’s ability to manufacture the leaders you need – leaders capable of showing sound judgment with complex landscapes and incomplete data are needed now more than ever in the new world of composite enterprises. Assigning leaders based on potential (rather than specific experience and qualifications) and surrounding them with competent position players can help fill organizational leadership gaps both today and in the long term.
The final post in this API ownership blog series will explore Experience API governance models. In the meantime, learn how APIs and API-led connectivity can help transform your customers’ experiences by reading our whitepaper.
