This is part two of a series on how to apply governance in API Connect. Governance is sometimes considered a taboo topic because when people imagine governance, they see red tape that stifles progress. If governance is designed properly it can provide a single approach for all parts of the project with minimal impact on the development rate.

A question I often am asked is “How do we split out our API Connect estate in order to meet the need of our development teams?” The answer is always, “How does your development organization work today?”. This article will provide you with a strategy for splitting your development effort and API Connect estate when working with decentralised teams for the API Manager only.

Part one of this series can be found - https://chrisphillips-cminion.github.io/apiconnect/2020/07/31/apigov1.html

API Connect has four layers of segregation.

API Cloud

The API Cloud is top level of segregation. An API Cloud is an entire API Connect management appliance. If physical isolation is required between layers then multiple API Clouds will be designed and deployed. Each API Cloud requires their own Portal, Gateway and Analytics services, these cannot be shared. I would expect small organizations to have two API Clouds

  • Production
  • Non-Production.

For medium to large organizations I would expect them to have three to four API Clouds

  • Production
  • Non-Production – Where testing takes place
  • Development – Where development takes place
  • Infrastructure Sandbox - Where the infrastructure team can test patching and other changes to the infrastructure with minimum to zero impact on the developers, testers or customers.

Provider Organizations (pOrg)

Provider Organizations are the level of segregation below the API Cloud. Each API Cloud has one or more Provider Organizations, but a Provider Organization can only be on API Cloud. In a decentralised approach I recommend that a Provider Organization maps onto the development team, test environment and production environment.

The development team lead must be the owner of the Provider Organization for that team. They are responsible for on boarding and off boarding each of the developers. A developer can be in one or more Provider Organization as they would be in one or more development team. The drafts view is unique to each of the provider org, and so this helps to separate out the APIs to the team working on them and reduce the number of APIs that need to be managed. Each development team can decide how they are going to use catalogs.

The test Provider Organizations must be the owned by the test leader. There would be multiple Provider Organizations mapping on to each of the test environments, e.g. ST1, ST2, UAT27, KFC1. The test lead is then responsible for adding users and controlling the environment. Each development team would use the same test environments (see spaces below) to ensure that the APIs go through contamination testing as early as possible in the process. Contamination testing checks for conflicts in the APIs such as conflicting paths.

The production Provider Organization is owned by the operations team. They control access to the Provider Organization, and I would recommend that a break glass approach is taken. Break glass is where no one has access to the environment. However, if a user needs access they put in a request to get their account added to complete their work. When this work complete access is removed again.

Catalogs

Catalogs provide logically separation of the provider orgs. I recommend that they are treated like channels. Some examples of catalog names are

  • Internal
  • External Public
  • External Private
  • External Partner
  • Internal PSD2 A catalog has a one to one relationship on to a single developer portal site. (See Part 1)

The most important architectural principle is that no API consumer will need access to multiple catalogs for a single application and so all consuming applications should work with a single channel.

In the development team provider orgs, catalogs should be completely dictated by the need and process of the development team themselves. In Test and Production provider orgs the catalogs must be identical.

Spaces

When multiple teams are working with in the same catalog it is very easy for mistakes to happen. In order to provide better control of a catalog spaces can be used to segregate them. Spaces provide a RBAC for APIs. Each developer Provider Organization would be given a space in each catalog they are using in Test. The development team can then have full control over the APIs in the Test environment. If the development team is providing operational support for the APIs this same pattern must be used in Production as well.

In this article we have gone through the four level of separation in the API manager, these are the API clouds, Provider Organizations, Catalogs and Spaces. This system has been utilised successfully in many customers around the world.