Building APIs at scale in an organisation means you will have an API Ownership Model, whether you’ve set it consciously or not. An API Ownership Model is the framework you use to determine where in the organisation APIs are invented, defined, built, delivered and maintained.
Your API Ownership Model is about how you organise across teams and functions within the business to ship APIs. It’s also how your APIs themselves — the software — fits with the organisation. It’s about how those APIs run.
API Ownership Models are either Centralised, Distributed or Hybrid.
You may have the ability to choose your model based on how their strengths and weaknesses fit with your organisation, and the primary goals you are looking to achieve. In some cases, your organisation’s existing structures and delivery methodologies might dictate your API Ownership Model. You might be somewhere in the middle.
Either way your API Ownership Model will determine the delivery methodologies you will use, how you manage your API Lifecycle and your platform team design.
The next sections will go into further detail on each API Ownership Model, including explaining their strengths and weaknesses.
In a Centralised API Ownership Model your API Delivery (the build and run of APIs) and API Platform Governance is all handled in one place within your organisation.
In practice, this means one team that defines, builds and maintains APIs. This central team requires a platform budget and then charges other business units or programs for the building of APIs.
With a central team you can gain greater consistency and reuse because information sharing is easier and control is more straightforward.
Pros
- Easy to enforce governance
- Easy to police security and CI/CD
- Consistent API development practices
- Close adherence to standards
- Fast setup of central delivery team
- Enterprise view of API development
- Centralised API support
Cons
- Lack of agility
- Needs requirement coordination
- Hard to prioritise centralised delivery
- Capability limited to centralised team
- Limited scalability
In a Distributed API Ownership Model your API Delivery is distributed throughout the organisation and your API Platform Governance is centralised.
This is where any team within the organisation can build an API and deploy it to your API Platform.
With any team being able to build and deploy you open up speed and innovation. You just might end up with people building the same thing and inconsistency in how APIs are built and designed.
Overtime you can get the reuse and consistency but this is more of an evolutionary process.
You still need a central team to manage the API Platform. Sometimes in a distributed model, the central teams can be left holding the responsibility for orphaned APIs.
Pros
- Speed and agility for API delivery
- APIs are prioritised closer to the business
- Easiest way to scale up with capacity to meet demands
- Product view of API development
Cons
- Guidance and support must be provided
- Must automate to police security, standards and CI/CD
- API support by distributed teams
- Bottlenecks in onboarding / training
- Effort needed to evangelise
In a Hybrid API Ownership Model your API Delivery takes places with a mix of centralised and distributed teams. Your API Platform is managed centrally.
This means some APIs are developed by the central team, often on behalf of others, while some APIs are developed by other teams throughout the business.
Pros
- ⇦ Centralised and ⇨ Distributed pros
- Central team provides good example of applying standards
- Can support both a product and enterprise view of API development
- Centralised team can support other APIs if necessary
Cons
- ⇦ Centralised and ⇨ Distributed cons
- Supporting a product view of API development takes discipline
- Supporting an enterprise view of API development requires cooperation
- Fosters dependency on centralised team
As you can see the key difference between each model is where API Delivery takes place. Regardless of your model you usually have centralised platform ownership.
When it comes to selecting the right model you must look at how your organisation delivers today. You also need to look at the goals you are trying to achieve.
You then need to look at how delivery needs to or can take place.
