Best Practices for AMPLIFY Organization Management

The following best practices provide guidelines on how to manage your AMPLIFY™ Platform organization(s). These best practices provide an excellent starting point to help you manage your AMPLIFY Organizations. Knowing that each customer is different, adjust how you manage organizations using these guidelines to match your specific situation.

What is an organization in the AMPLIFY Platform? The AMPLIFY Platform is a multi-tenant hybrid integration platform, and an organization is a single-tenant on this platform.

• An organization is uniquely defined by an organization’s identifier and is linked to a certain set of members and capabilities.
• Members are the users of the platform.
• Capabilities are the functionalities of the platform such as Integration Builder, AMPLIFY™
  Central and the AMPLIFY™ Unified Catalog.
• Integration Builder is the iPaaS solution of Axway.
• AMPLIFY Central is a governance platform that enables self-service centralized API and microservices management.

When we talk about a company or a customer below, then we refer to the company or customer that is using the AMPLIFY Platform. For example, ACME is the company or customer and ACME Production is the production organization of ACME on the AMPLIFY Platform.

What is the single most important best practice to remember?

Ensure that you keep production content and non-production content neatly separated from the beginning. This approach will help avoid content created during testing or when trying out some functionalities of the platform ending up in the same place as where the production assets are kept. This distinction can be made either by having separate organizations or by using one organization with different teams and where users have different roles per team.

Two Examples

We will discuss the advantages and disadvantages and show how each setup can be implemented.

1. Large setup – represents a company that has multiple organizations in the AMPLIFY Platform
2. Small setup – represents a company with a single organization in the AMPLIFY Platform.

Here is a brief overview of the different roles that will be used in the two examples:

Platform roles (I always assign you are always 1 platform role):

• Administrator: If a user has this role, the user is able to utilize all the functionalities that are available to that organization
• Non-Administrator: There are multiple non-administrator roles, they will not be discussed here

Team roles (you can maximum have 1 team role per team, a team is a grouping of users and assets):

• Administrator: Can manage the users of the team, but cannot manage or consume the assets in that team
• Developer: Cannot manage the users of the team, but can manage and consume the assets in that team
• Consumer: Can only consume the assets in that team
• None: If you are not assigned a single role in a specific team, then you do not belong to that team

Large setup

A large setup is used when different departments (or projects) want to work independently and where each department has a separate administrator. A large setup consists of multiple organizations in the AMPLIFY Platform, the different organizations are used to make a distinction between the different environments and departments of the company. In this setup there could even be personal organizations, a personal organization can be seen as a departmental organization with one user.

For very large enterprises, we can even imagine having multiple organizations per environment or department. For example, a multinational company could have separate organizations for North American and European operations. One tip for these very large corporations would be to have one organization per IdP or one organization per legal area, so as to comply with local regulations, such as GDPR.

AMPLIFY Platform – Organization Structure – Large Setup

ACME has one production environment, one non-production environment and multiple departmental organizations. We will describe the purpose and the setup of each organization from the bottom-up.

Departmental organization(s)

There can be multiple departmental organizations. A department can be a functional unit, such as HR or accounting; it could be a region such as Europe or North America; or it can even be a project, such as New Gizmo API.

Each department has one or more administrators that are responsible for the organization and typically belong to that specific department. The non-admin users are the other members of that department and can have different roles such as developer or consumer.

A consumer can, for example, be a tester of the assets that the developer creates. Each departmental organization can have different teams that are used to make a distinction between different subgroups in the department’s original projects or could even be personal teams. For example, the project ACME GIZMO V2 puts all of its assets, such as its APIs, and the project team members in a team called ACME GIZMO V2. If the work is finished on specific assets, it can be migrated to the non-production environment by the ACME Department Admin.

Non-Production organization

There is one non-production organization, and this organization is managed by one or more administrators, the ACME Non-Prod Admin(s). For each departmental organization, there is one team in that department. The members of these departmental teams are the corresponding admin members of the departmental organizations.

They have the developer role in those teams, which means that they are able to manage assets in these teams. If an asset is finalized in the departmental organization, then the departmental admins move it to the departmental team. The ACME Admin can then share these assets with the Ready for the Production team. All the assets that are ready for the production team are the assets that will be migrated to production.

Production organization

There is one production organization. This organization is managed by one or more administrators, the ACME Prod Admin(s). All the employees of ACME also have access to this organization, but with a consumer profile, which means they are able to consume all the assets in this organization, but they are not able to make changes to this organization.

The ACME Prod Admin is responsible for the unique team of this organization, the production team. This team contains all the productized assets of ACME, such as all the APIs and these assets are migrated from the Ready For Production team in the non-production environment.

Advantage

The advantage of the large setup is that there is a clear separation between environments, users, and roles and a CI/CD process can be followed to migrate assets from development to production. An officially maintained production organization ensures no unintended content ends up in production. All users of the company can still try all the functionality of the platform because there are non-production environments for this.

Disadvantage

The disadvantage of this setup is that it involves more work to maintain multiple organizations. For example, to connect each organization to the IdP of the customer.

Small setup

A small setup is good for smaller companies, single departments, or customers that want to try the platform.

AMPLIFY Platform – Organization Structure – Small Setup

In this setup, there is only one organization. The organization has one or more platform administrators and the rest of the users are not administrators of the platform. There are multiple teams that are used to separate different environments, departments, and users. We will discuss them from the bottom to the top to indicate the CI/CD flow of an asset.

Personal

There can be multiple personal teams. The idea of a personal team is that one user can use it to create and use assets. Either give each member of the organization a personal team or only give certain profiles a personal team or create a personal team when someone asks for it.

This user has the role of the developer in this team. The user cannot add other users to this team. If the user wants other members in the organization, an administrator should complete the task. If the user wants to migrate an asset to production, then this asset first needs to be created in a departmental team before going to non-production.

Departmental

A departmental team is a team that holds all the assets of a department or a project. There are 3 types of users in this team. There are the department administrators who manage the other users, there are the developers who manage the assets, and the consumers who can only consume the different assets. When an asset has been validated in a departmental team, it can be migrated to non-production.

Non-production

This team contains the assets before migrating them to production. Just as for the production team, the assets are managed by an ACME Prod Admin who has the role of AMPLIFY Central Admin. All the other members of the organization are not a member of this team. This team is solely used by the AMPLIFY Central Admin to manage the assets before they go into production.

Production

This team contains the production assets. If there are multiple ACME Prod Admins, then at least one needs to have the role of AMPLIFY Central Admin so that this admin can manage the assets in this team. All the other members of the organization are a consumer of this team. They can consume the production assets, but not make changes to them.

Advantage

The advantage of this kind of setup is that it is fast and easy to get started. There is also only one organization to manage which makes sense for smaller setups.

Disadvantage

Limit the number of administrators which may be seen as a disadvantage. This approach implies that not everyone can try all the functionality, which is the case in a large setup where everyone can try all the functionality by either being an administrator of a departmental organization or being an administrator of a personal organization.

Conclusion

In the examples above, both setups have advantages and disadvantages. Based on your specific requirements, elements from both setups can be adjusted to accommodate your needs. For example, you could choose to have two organizations, one production instance that is managed by a limited set of administrators and one non-production instance, where everyone is an administrator and which can be seen as a sort of sandbox. This approach also comes with advantages and disadvantages.

It is important to check from the beginning what works best for you!

Changing the model afterward is possible, but might take time depending on how heavily you are already using the platform. One thing you should take away from these best practices is how important it is to have a clear separation from the beginning between production and non-production assets. This separation can be made in an organization or on a team level.

Hopefully, this blog gave you some useful insights on how to manage your organization in the AMPLIFY Platform.