In our previous blog, we covered the overview of governance posture for organizations. In this blog, we will take a deep dive into identifying the family of assets in the API ecosystem and their approval process. The aspects covered in this blog are highlighted in orange in the image below. As with any initiative an approval process spreads across different pillars and stages of the governance process as shown in the following matrix.
Governance starts with the establishment of policies that project teams need to adhere, typically these policies are converted to best practices, standards, templates/patterns, examples, and checklists by a group of architects and SMEs belonging to that particular technology or domain. This is what TOGAF refers to as “Reference Library” in “Architecture Repository.” Anypoint Platform provides such capabilities through its Anypoint Exchange repository. These contents/assets published to Exchange need to be governed through an approval process.
Why do we need an asset approval process?
Custom assets have a high potential for reuse. A well-built asset can have a positive multiplier effect resulting in delivery acceleration. An incorrectly built asset can have a negative multiplier effect, which may result in corrective actions in multiple lines of business with potential downtime of systems and financial loss.
What assets need to be governed by the asset approval process?
MuleSoft’s Anypoint Exchange hosts two categories of assets:
1. MuleSoft-provided assets
Anypoint Platform is pre-bundled with industry-standard templates for various industries like healthcare, finance, retail, etc. in the form of examples and RAML fragments, which are reusable interface definitions.
2. Customer-created assets
Customers can publish their own assets using API Designer, Anypoint Studio, and Exchange. Assets created by customers are:
- API specifications using RAML or OAS
- Templates and examples
- Standards and best-practice documents
- Reusable RAML fragments.
- Custom connectors
This category of assets requires governance.
Custom asset approval governance process
MuleSoft has an out-of-the-box approval process for APIs. But the assets other than APIs need a custom-approval process. Here is how it’s done:
- The enforcement is not out-of-the-box for the above assets but can be done by using platform APIs and external systems like Salesforce, ServiceNow, or email.
- Create a separate business group for “Design” where architects and SMEs can create and publish the specifications, templates, examples, fragments, etc.
- Inject approval process when these assets are published to Exchange in “Design” business group. This can be achieved by developing an integration flow (let’s call it an Asset Approval Flow) that triggers whenever assets are published to Exchange. This flow will send an email to the governance team or create an approval request in Salesforce/ServiceNow/email (note that pre-defined approval flow needs to be created in Salesforce or ServiceNow).
- The governance team will review the API specifications in the “Design” business group and then provide approvals either through email or Salesforce or ServiceNow whichever method is used.
- The custom-built “Asset Approval Flow” gets triggered based on the email approval or Salesforce or ServiceNow. It will move the assets from the “Design” business group to the appropriate business group for the developers to use.
The same approach is followed for publishing templates, custom connectors, and custom policies. Templates, custom connectors, and custom policies all allow the governance team to enforce standards and best practices to be followed by the team during the API development phase.
What’s next?
Stay tuned for more blogs uncovering governance details of the different stages. To learn more, download the API lifecycle management eBook to discover how to set up your developers for success from API design to deprecation.
