A key determinant of your enterprise’s API and Service strategy success is not only how many APIs and Services you’ve developed, how much business and technical capability coverage you’ve built out (and how many people can contribute to it). A vital factor of success is how high-quality your portfolio is. The best APIs and Services need to be discoverable, reliable, reusable, and compliant (with well-managed and visible exception pathways), and alignment to an API governance model ensures this.
An effective API governance model can also enable effective KPI tracking of API efforts; to demonstrate the business value of APIs and Services. Aligning your enterprise’s governance model to both a catalog of existing assets and the API and Service lifecycle is critical to enable this level of reporting.
What’s an API governance model and what does it involve?
We’re using API governance model as a catch-all term; it’s in fact more than APIs and more than just governance – it’s a whole maturity model for your enterprise to use in determining how reliable, reusable, and compliant APIs and Services are. It typically includes (we’ll use the term API in this list as an umbrella term for all APIs and Services):
- API design patterns and standards, that are ideally baked into the process, for easy identification of what is in and out of compliance
- With guidance on methods, parameters, platform and region requirements supporting top-down and bottom-up API development
- Information models for consistent resources (in request/response payloads) and APIs that are designed in the language of the business
- Automated API governance and validation flows against approved style guides, providing real-time guides on acceptable artifacts
- With governance summaries including API name and description, version and lifecycle state, owner, Specification type (REST, SOAP etc.), classifications, method/operation consistency, NFRs, policies
- Common utility services like security, and policies that can be configured based on usage
- Non-Functional Requirements (NFRs) and Service Level Agreements (SLAs)
- ID access control for production modification
- The ability to generate consumable runtime-ready artifacts (leveraging template-driven output to ensure consistency and save API development time)
- Standard and best practice policies as well as fault tolerant flows for ensuring consistent error responses
- Best practice policies for greenfield and brownfield APIs
- Validation against code rules in the CI pipeline
- Unit test examples for policies/code and script runners for acceptance testing of the proxy
- Software Development Kits (SDKs)
- Documentation
Recommended approach to implementing an API governance model – align to a holistic catalog and extended API and Service lifecycle
We see three main pain points in current approaches to API governance model alignment:
- API Standardization. Most large enterprises rely heavily on contracted developers working in their own IDEs/basic editors to code their APIs, with API governance model standards held in documents or spreadsheets – therefore it’s hard to enforce enterprise standards and scale beyond a handful of talented developers
- API Governance Reporting. Not only is it hard to enforce the actual standards, but near impossible to report on, as there’s no single source of truth into an API or Service’s level of maturity and governance compliance – and enterprises desperately need this view into their portfolio – for both internal executive and external regulatory reporting
- User Experience for Applying Governance. We see most enterprises are still treating APIs as mere technology assets created as project by-products. As more of the upfront design and build work moves from IT focused and manual to one with clear business direction and self-service for providers, APIs need to be developed and deployed in an optimal way allowing your organization to successfully industrialize and commercialize them. API governance and standards that are transparent, easy to align to, and baked into the process through an easy to follow UI/UX become a key contributor to enabling proper catalog expansion, increasing developer production, and expanding the lifecycle and audience able to participate.
The key to overcoming these pain points is to align an API governance model to both a discoverable holistic catalog of what APIs and Services are already available, and the API and Service lifecycle upstream of CI/CD and run.
To do this, we recommend using the ignite platform, which provides a holistic API and Service catalog and extended lifecycle, aligned to enterprise API governance models via:
- Managing the API governance model components themselves (see list above) directly in the platform
- Abstraction – existing assets are imported and abstracted (i.e. made code- and implementation-agnostic) into a set of Designs and associated versioned Specifications – this enables:
- APIs and Services to be organized and normalized into reusable bundle-ready building blocks
- With API versioning best practices built in – multiple versions organized under a Design with major, minor, and patch versioning
- Future-flexibility: API governance models can evolve over time; APIs and Services need to be adaptable to respond to this
- APIs and Services to be organized and normalized into reusable bundle-ready building blocks
- Baked-into process – removes manual errors and ensures maturity upfront with automated flows (e.g. self-service API and Service governance, code validation, NFRs defined upfront)
- Aligning the API governance model to all assets both in the holistic catalog and API lifecycle – and aligned to bottom-up and top-down API development efforts – import, organize and normalize, or build new
- Clear exception approvals/processes and audit/reporting capabilities for those APIs and Services out of compliance – whether they need to be normalized, or are simply being registered to the catalog
- Service discovery to promote reuse, reduce duplication, and provide an ecosystem for business and IT to collaborate over core APIs and Services
- Bi-directional integration with upstream and downstream systems (e.g. CI/CD, distributed runtime)
For more information on ignite, check out our platform page.
