IBM Integration User Group UK

One of the primary goals of API management software is to enable application teams to deploy APIs in a safe, decoupled way.

As discussed out our previous post “Is API management a centralized or decentralized approach?”, effective API management technology empowers application teams to define and administer their own APIs. However, the post notes that it is rarely necessary, or even desirable to have a separate API management infrastructure for each team.

A single infrastructure simplifies administration, improves consistency of implementation and reduces both hardware and operational cost. Enterprise class API management capabilities should be built with multi-tenancy in mind. This allows each application teams complete control over their own APIs and independence of creation (decentralized API ownership) even though they may all be hosted on the same platform (centralized infrastructure).  

This implies there will be (at least) two distinct roles in API management.

a) Centralized platform/infrastructure team

b) Decentralized application teams

However, do the responsibilities split neatly between those two roles, and if not, how do we bridge the gap? How do we ensure that the knowledge about the platform gets passed on to the application teams who are how administering their own APIs? Equally, how do we ensure that the platform team remain close to the day to day issues the teams are facing? This challenge is certainly as old as IT itself, and beyond. Indeed, it is present in any organisation.

We’ll look at this challenge specifically in the context of the roles and responsibilities of API management and consider two common approaches to solving the problem.

The first approach is to have people from the centralized team spend time working out in the provider teams in an advisory role. They effectively take short, time-limited secondments to go work full time to a limited scope on a provider team, becoming closer to the delivery pipeline, and directly seeing the pressures on a live project. The infrastructure members role will be that of a designer, reviewer, mentor and educator giving an infrastructure perspective to API Provider teams.

This has some key advantages, not least the fact that the central infrastructure team end up on the sharp end of project deadlines and get a better understanding of the day to day requirements and pressures. However, whilst this is quite likely a logical first step for many enterprises starting to adopt API management technologies, it is unlikely to scale over time.

The secondments take people away from the platform team, who in most organizations are already under constant pressure to reduce their headcount. Aside from putting in place rather cumbersome internal charging mechanisms, it is unlikely that the platform team can bear the cost of losing resources to project teams.  

The API Guild

The second option involves creating a third, virtual group of people drawn from both the platform and provider teams. This has many different flavors and has been given many names over the years. From “communities of practice” to “focus groups”, “task forces”, “swat teams” and many more. The current trend, with its own nuances, is to call this a guild.

It is not really accurate to describe these as a “third team” since they typically don’t have their own management chain or funding. They are better described as an “interest group”, created from people have a desire to do a particular thing within the company better. Guilds could form around anything from UI design, to performance testing, or security.

What we’re beginning to see in many enterprises, are guilds focused around API; their development, usage, security etc. At a high level their aim is to knowledge share API implementations to uncover the most effective ways of implementing and exposing APIs. We could discuss what that means on a theoretical level all day, but we’ll much more quickly understand the ways in which they add value if we consider some real examples of day to day responsibilities.

Let’s first articulate the typical responsibilities owned by the API platform team and API provider team’s respectively. Once we have a clear picture of that, we can then look at what further needs there are, and whether these could be best taken on by an API guild.

Team Roles

API Provider Team - Product Owner, API Developer(s), Project Manager, Access Manager, Solution Architect

Infrastructure Team - Platform Owner, System Administrator, Platform Operations and perhaps a Network Architect

Other Teams - Production Support, Testing teams, Dev Ops, Production Operations 

Some team roles could exist in one team, or multiple teams depending on how the API Management system is split. These might include Portal Developer, Testing Team, Release Manager. Different application separations at the organization, catalogue and space level will impact where these members sit in the various teams.

Team Responsibilities

First of all, we will delve into perhaps the most clear-cut set of responsibilities – the API platform/infrastructure team.

1. Central platform/infrastructure team

Responsible for the integrity of the underlying API management platform

• Creation/installation of new gateways

• Installation and upkeep of the API management, Portal and Analytics software

• Upgrades to the gateway runtimes and other API management software

• Deployment and management of gateway wide assets such as user defined policies(these are catalog/org wide), extensions

• Administration of the overall infrastructure via the Cloud Manager Console such as updating certificates and keys, adding users, analytics of servers, refreshing servers.

• Cross-cutting Portal changes such as registration techniques (e.g. Portal modules, new Active Directories)

• Onboarding/offboarding of new API Provider teams - setting up channels, planning tasks to be completed, determining configuration channels, setup spaces/catalogs etc, upload TLS Profiles. Close collaboration with the new API provider team to discuss new requirements on resources (e.g. new throughput on the gateways).

• Advising on API management infrastructure topology such as when to create new catalogues, deploy new gateway clusters, appropriate sharing of crypto artefacts, sharing/independence of channel extensions vs gateway scripting/user defined policies etc.

• Platform support – exploration of technical issues that have been escalated from the teams and require a platform wide approach. E.g. debugging of issues with User Defined Properties. Monitoring of existing capacity of the platform (e.g. gateway headroom). High level platform verification testing (e.g. testing overall throughput)

• Create Organizations, catalogues and roles as part of onboarding [need to discuss what the top-level namespace would be, org or catalogue]

• Provide support for catalogue and space owners

• Manage Crypto Security for encryption and decryption

• Manage wider platform level security concerns

• Gather details for support issues such as logs where only captured at the platform level.

• Administer Developer Portal. [note that this is dependent on whether catalogue is the top-level namespace. If so, there is a single overriding shared portal which the platform team should manage. If Org is the top-level, then teams might be able to look after their own portals.]

• Portal theming [for portals shared by many teams]

• Infrastructure Operational tasks

• Definitions of plans, rate limits, throttle limits and throughput control

• Certificate/Key creation and loading into platform

• Portal Authentication Architecture. E.g. which user registries can be used, what permissions the roles that can administer the portal have

2. Local “API Provider”/application teams

Act locally in the interests of the application, but with insight from the guild

Clearly many of the below in some organizations will be completed by the infrastructure team, the intention here is to raise what might be completed by provider teams to relieve infrastructure team pressures. As patterns of use mature and develop it will become easier to distribute and delegate these tasks.

• Space and catalogues creation - if relevant for the chosen application level separation of teams

• Team user onboarding, including access control based on roles. [roles: api dev, api admin, space owner, plus any custom roles defined at the org level] - if relevant for the chosen application level separation of teams

• Creation of designs

• Definitions of APIs and Products

• Request of rate limit/throughput increase and implementation of limiting at the Product level

• API Lifecycle - create, update, replace, delete, retires - following Production Operation procedures and oversight

• API documentation - Published into the Portal

• Manage TLS Profiles for a given API within the API definition

• Testing – API specific performance (with issues potentially escalated to the platform team), functional/unit testing etc. - testers might form a wider central testing team

3. Other Teams

• Production Support - Provide support for API consumers for functional issues. Non-functional may then be escalated to the platform team.

• Production Operations - overarching decision makers who manage allchange in production but not making the changes

• Dev Ops - Provide support for creation, issue resolution, change and best practice guidelines for developer pipelines

• Testing Teams
  
  
  • Central test team - hook into each API Provider teams for functional testing as well as non-functional testing i.e. load testing
  
  
  • Platform testing - validate infrastructure changes, disaster scenario and availability testing

• Release/Environment Management - Ensure changes are propagated through the lower environments ready for handover into Production

4. Guild

Achieves broad consensus across teams, but members of the guild work locally on an individual team

The guild is a collaborative approach instead of an authoritive approach which allows teams to be more agile. This may not suit some organizations or pockets of organizations that require more rigorous control.

• API style and consistency guidelines

• Developer Portal style and consistency

• Security: Work with the security team to assess how to combat vulnerabilities especially within API flows themselves

• Creation and rollout of training/education material for application teams, paired delivery, shadowing which might include; performance improvements, task completion steps, high level understanding of the platform etc.

• Assessing and raising of product enhancement requests

• API deployment guidelines

• Broader design and solution review and simplification

• Documentation such as onboarding planning – on how onboarding should occur.

• Platform roadmap – interaction with vendor to define strategy in relation to future product plans. Review of release notes on new product versions.