Solved: One API Team or Many?? - Page 2

kkleva · 03-04-2016 11:00 AM

I think most API Platforms tend to start with consumer facing Apps. Building a mobile app was typically the biggest reason folks start this journey. However, as the Good News about APIs starts to spread across the Enterprise the notion of a centralized API Team is often brought into question.

Is having a single team going to cause bottlenecks?

Should we really put all or eggs in one basket?

Does it make sense to centralize the management of the platform but allow Micro-Services teams to roll their own proxies?

I'm interested in the communities perspective if the notion of a single API Team is really a best practice for small to medium sized Enterprises?

For example, I'd agree that it's probably impractical for the entire US Government to have a single API Team.... but what about a Omni-Channel retailer?

What are some benefits and drawbacks one could experience by having a single team handle the API Proxy specification, design and deployment for all consumer facing and back office systems?

Your thoughts are appreciated!

dcouldwell

My general feeling and experience is that, for organisations above a certain size, as they grow will inevitably have to support multiple API teams if they don't want one centralised team to start becoming a bottleneck.

So if we assume that you have to scale then you have to address the issue of multiple teams. One way of looking at this is to consider what are your 'Must Win Battles' vs where do you want to allow teams to innovate / feel free to follow their own preference.

This lead to the following 3 ideas for overall API Program management

1) Policeman

Which areas do you need to mandate standards that should be followed by all API Teams?

Such areas would include anything that's needed to drive a consistent API Consumer experience e.g. API Versioning, Security, General RESTful API design principles

They might also include areas behind the scenes that need to leverage internal assets consistently or provide a consistent experience for the API Maintainer team e.g. Logging, Audit, Traffic Management

These constitute the Must Win Battles that you must get a consensus on. Be realistic on how many of these you can have

2) Teacher

Having a central centre of excellence to help new API team get started can provide a significant accelerator to new initiatives. Also having some core Principles that all teams adhere to that give a consistent direction to the program without dictating the exact approach promotes consistency.

This core team can also be the provider for Training and Expertise if required e.g. Training for new API Proxy developers, design reviews if requested (agree with @alan@apigee.com that you need to be careful here and this not become a 'Policeman' activity, needs to stay in Teacher mode) or even seconding someone into a new team to get them kick started.

The Principles outlined could include advice on suggested tooling to be used by teams or Best Practice in terms of process e.g. all proxies should be under CI control without dictating which CI tool is used but offering advice on what tools are available.

3) Referee

Inevitably there will be more contentious issues and especially with multiple teams using a common platform. An independent team that can help resolve these issues can smooth the way. The key is that that team remains independent and has representation across the organisation.

The balance between the above 3 roles will differ in different organisations but the key is pragmatic approach to Standards v.s. Principles is required to maintain API Program momentum and not get mired in committee / review / gatekeeper mode

View solution in original post