One API Team or Many??

[anonymous]

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!

[abeatty]

An interesting question, Kristopher. When I worked at Pearson for their API program that indeed was an approach considered and debated. We ended up going down the ownership path, especially because we very much wanted to support a DevOps model, at the time. Creating a team that owns any slice of the pie, whether its operations, database, UI or APIs has a number of drawbacks. At Pearson, they wanted teams to very much own, and be responsible for, the full stack. When I worked to setup Apigee for API management I took the same approach, set it up as tool for teams to utilize themselves. Training at scale became a challenge for sure, one of the drawbacks to distributed management. I personally believe APIs need to be at the heart of a team, very much part-n-parcel for making a system really functionally successful.

[anonymous]

Thanks for sharing. This is for sure an important thing to consider. If you want APIs to be part of the DevOps culture you need to enable target system to own their own products.

I’m interested in knowing if in this distributed model is there still any concept of a central team at all? We’re definitely working in an environment we’re trying to adopt a DevOps pipeline but still have plenty of legacy systems that needed to be dealt with.

[abeatty]

For the internal API program for Pearson we did setup a small team to help manage a number of aspects of APIs. Best practices was a nice thing to centralize, and we even had a few people who helped to manage the Apigee implementation. We tried to make it both a self-service model, and about advise and guidance. Not about dictating and commanding (so anti-DevOps). There is also an external API program still running at Pearson, led by @Allen.Rodgers. He did have a group that provided APIs for external third-parties to interface with the product, so it was more of that centralized model. Definitely know what you mean for supporting legacy systems. A DevOps model seems harder to get going there, doesn’t it? Especially if the system isn’t getting a ton of new work or functionality. A centralized model might make more sense in that scenario.

One drawback to the centralized model, that I’m sure Allen will tell you a few war stories about, is often when the internal system changes, the API managed by the centralized team is affected, often without warning. You can mitigate this with some solid automated testing, but its human nature to forget something which you are not managing directly or on a day-to-day basis. Another drawback is troubleshooting issues for the development team, if they don’t know or understand their proxies. It’s all the classic DevOps arguments about why access and control to their entire system is so critical. Legacy systems seem to wreak havoc with that model though, at least in my experience. I did find it very easy to get teams trained and knowledge about both Apigee and their own proxies. Most of the time they spent was more on the how, what, why and when for the actual API itself. That was the true secret sauce.

[anonymous]

I must say this is such an interesting question @Kristopher Kleva and we come across this topic with almost every engagement. To answer you in short there is no real right or wrong answer to this, having a single API team or many is so much dependent on the factors like size of an org,processes,culture,product,dependencies and engagement across functions etc..

But in general I really like the way you put it up - “centralize the management of the platform but allow teams to roll their own”. This makes so much sense and we have seen this across small,mid and big orgs. We are now hearing terms like “API hubs” which exactly leads to central management and development by functions.

Trying to put some pros and cons of not doing it in the above way.

One central API team

Pros -

1. Design consistency - Think of all API’s coming out from the same team which would follow consistent design principles, coding standards etc..

2. Not reinventing the wheels - One API team developing and designing would mostly remove redundant functionality and often go by the principles of reusability

Cons -

1. A bottleneck of resources, technology, processes hindering timelines.

2. Could restrict innovation - One might be amazed how much innovation could API’s/digitalization foster. If the same guys do it the same way without having looked at it from various different perspectives, there might be some hinderance to innovation.

Many many API teams (one per function)

Pros -

1. Not a lot of dependency, can pretty much exist and evolve as individual API programs

2. Easy to isolate issues,bugs - Since the API team has control over management etc..it could be a quicker turnaround while dealing with a functional or a performance issues.

Cons -

1. Chaos, confusion - If the infrastructure is shared then this could lead to situations like stepping on some one else’s work by mistake etc..

2. Inconsistencies in design and the overall developer experience through an entire API program

[anonymous]

At all costs we should avoid Con #1 Chaos, confusion!

I think one additional consideration here is how we can foster micro-services adoption without posing friction. The DevOps two-pizza team that would prefer to roll their own proxies from using a collection of their own APIs along with others that do not technically ‘belong’ to which are made available in the platform.

[anonymous]

From the comment so far I’ve captured the recommendation as:

If you can support adoption horizontally (and vertically) in your organization, you should do anything you can to promote it. Many Micro-Services two-pizza sized teams should have full control to build their own tools.

Naturally, governance will be an issue and you should prioritize good communications between all those micro-services teams. Executives, management and security also need to be comfortable they are feeling of the pulse of the platform.

The centralized API Team should then focus more heavily on the extension of core services and operations of now bulging in size API Platform. This will likely now grow from 50 or so facades to 200-300 in a span of a year. In addition, they will continue to evangelize API Design, Facade Development, Testing selling it as “API Management as a Service” to all corners of the Enterprise. This will include but will not be limited to internal, external and third-party app developers; business analysts, managers and executives.

[anonymous]

If you are going to go with the “many many API teams” approach, my biggest advice is to not create an architecture committee, but mandate frameworks instead. The biggest slow-down in any enterprise is the dreaded “architecture review”, but if you have certain technology frameworks that are mandated and supported by a central team - there is a much higher probability that you will have some consistency in how the APIs are implemented.

[anonymous]

Very good observation. It seems like the tenancy to formalize the API design by creating a governance structure is often part of these conversations. I agree that providing a framework that pushes teams in the right direction naturally would be preferred over the dreaded review meeting.

From a API design perspective, one tool that’s helped us “Codify” our API style guide is Apiary.io. https://enterprise.apiary.io/ This helps everyone to adhere to basic API design patterns and conventions.

However, I’m still confused on how we attempt to maintain some notion of consistency in the API Proxy construction is going to require code / proxy quality tools. For example, how can we provide a framework to mandate API security best practices without requiring a manual review?

[anonymous]

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

[anonymous]

Totally agree on getting tooling for “Codifying” API style guide.

With regards to API Proxy construction, having templates pre-populated is probably the best way go to. Even if there was a proxy called “official-XYZ-proxy-template” that is pre-provisioned, there is an 90% chance that people will clone it, and a 90% chance they won’t screw it up so badly that the best practices are lost More importantly, if you do find an API service that is not meeting a particular best practice, you need to make sure your framework has the tooling to “correct” the mistake without the need to do a totally new code push.

[anonymous]

I would only add here to recognize that as you become more digital your needs, your opportunities, and your capabilities will change. The model that works on day one must not be seen as set in stone. Rather, instill within the organization the expectation that the organization at the center of the API journey will change over time in response to new opportunities, expanding capabilities, and the maturation of platforms and processes.