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.
Following the posts on System API and Process API ownership, this last post in the API ownership series looks into ownership of Experience APIs.
What are Experience APIs?
Experience APIs are similar to Process APIs in that they composite the content, features, and functionality of several other APIs. However, unlike Process APIs, Experience APIs are more specifically tied to a unique business context, and they project data formats, interaction timings, or protocols (rather than process or create them) into a specific channel and context.
Additionally, Experience APIs inform and interact with a presentation layer specific to a unique business context; this provides a means to render pre-formatted data in a way that aligns to a specific audience and context so that the data can be easily consumed and acted upon to align with the intended business scenario.
Some examples of Experience APIs include:
- A mobile app that allows a mobile customer to see and manage open orders with integrated pricing and shipping information.
- A retail company with an API that allows a mobile customer to see and manage open orders with integrated pricing and shipping information.
- A financial services firm with an API that powers an employee-facing system, allowing a customer service representative to see and understand past interactions for a specific customer across several channels while attempting to serve a customer request.
- An insurance company having an API for each brokerage firm connected or each insurtech they use.
- A logistics company that needs different EDI formats to send to transport companies but all of those formats based on the same Process API capabilities.
Business versus technical Experience API owners
Business ownership of an Experience API should attempt to follow capability and/or value-stream ownership if possible. This designation should align with the business owner of the relationship with the consumer/partner.
Technical ownership of an Experience API should follow one of the following paradigms based on existing norms within the enterprise hosting the API:
- Presentation tier ownership – assigning technical ownership to staff members who are recognized experts in both presentation tier technologies and the existing touchpoints at the browser or native application that consumes the Experience API in question.
- System/platform ownership – assigning technical ownership to staff members who are recognized experts in a business facing platform that serves as a source for the majority of data/functionality manifested by the API.
- Process API ownership – The owner of a Process API could be the owner of the Experience API if the same business service/product team is also responsible for the relationship with the consumers of that business service/product.
Keep in mind Experience APIs are built to provide a way for interactive application developers to rapidly provision data into front-end applications that are used by customers, partners, and employees. As such, Experience APIs follow a “design-first” approach – that is, the API contract is specified before the actual implementation of the API and is driven by the consumers of the APIs in collaboration with User Experience professionals who specify how online interactions should be implemented from a design perspective.
Implications of assigning Experience API owners
The context of use and business implications from an Experience API are the driving factors for assigning business owners to Experience APIs. From a technical ownership perspective, organizations assigning ownership of Experience APIs should consider API context as well as communication skills.
Tech is easy; context is hard – technical owners of Experience APIs should be selected from a pool of leaders who are closest to the context of the API’s actual use. This context is key for driving roadmap alignment with the business owner. Without contextual knowledge, elevating conflicting perspectives into collaborative discussions will be difficult to achieve, and most dialogs will end up with people “talking past each other.”
Similarly, any tech owner of Experience APIs needs to be fluent in the aspects of API development beyond functional completeness (e.g., security, performance, compatibility, caching, etc.). As these sorts of concerns can get pushed to backlogs routinely, the technical owner needs a strong understanding and sophisticated communication skills to give these topics appropriate attention.
As previously stated, API ownership within the modern enterprise can be complex. This series was meant to serve as a guide for developing a model that makes sense in your enterprise, so let us know if you have other ownership principles in the comments section below!
