Today’s API governance is not like the kind of governance familiar to those that went through the service-oriented architecture (SOA) days. Many organizations have learned from past mistakes, opting instead for a lighter-weight governance model. No longer does API governance focus on internal optimization. Rather, today’s API governance is focused on the external developer experience. It is meant to advocate for the current and future API consumers, while delivering value for the business.
Choosing an API governance model can be challenging, however. There are a variety of options available. How are you supposed to know which one is best for your organization?
Let’s look at what a healthy API governance program includes, then examine the different models of API governance to see which one may be the right fit for your organization.
What does healthy API governance look like?
Healthy API governance should encourage consistency across the organization, mixed with the flexibility to support changing market needs. In the early stages of an enterprise API program, a small group of API architects will often fulfill this role. They will establish standards, practices, and patterns that are encouraged across all lines of business.
Over time, standards are formalized and API design reviews are required before APIs can be deployed onto a production API gateway. While they may not operate under the title of an API Center of Excellence (API C4E), they are often performing the duties of a governance team.
This early stage of an API C4E can either make-or-break your API program. Strict API design reviews with caustic feedback can discourage development teams, resulting in circumvented processes. Bottlenecks can also emerge, resulting in days of waiting for an API design review, only to find out that the team has to go back and make significant changes to their design and code.
An effective governance model seeks to empower teams to be self-governing as much as possible. They drive consistency and seek to cross-communicate the experiences of other teams through shared resources and automation.
API design reviews are conducted in the spirit of listening, understanding, and encouraging improvements rather than strict pass/fail feedback.
Common design patterns are demonstrated through examples and from existing production APIs. Less time is spent trying to re-invent solutions and more time is invested in delivering value consistently.
Selecting an API governance model
We have found that there are a set of common API governance models. They vary based on the level of centralization and the degree of control exerted over API design and implementation. These governance models include:
Centralized Governance: A single central team or authority is responsible for all aspects of API governance, often as part of an API C4E. This central team defines the standards, approve API designs, and enforces compliance. This model provides a high level of consistency and control, but it can also slow down development and limit flexibility for larger organizations.
Federated Governance: The responsibilities for API governance are distributed among multiple teams or individuals across the organization. Each team has autonomy over their portfolio of APIs. However, they must still adhere to a set of basic standards defined centrally. This model offers a balance between control and flexibility for larger organizations that wish to encourage consistency across the entire organization while still offering automony.
Distributed Governance: A model where each team has full control over their APIs with no central authority. This model offers maximum flexibility and speed. It is often seen in organizations that have product-centric organization structures, where each team has its own executives, product managers, development teams, and budgets. However, it can lead to inconsistencies and make it difficult to enforce a unified security model and set of quality standards. This is especially the case as product lines try to cross-sell to existing customers but find that their authorization mechanisms vary significantly, resulting in frustrating integrations by customers.
Summary: These three models are seen the most often when we consult with organizations on establishing a growing API program. Unless your organization is an early-stage startups or a smaller organization with a handful of APIs, a federated governance model will fit your needs.
Customizing your API governance model
While the three governance models outlined above are most common, there are some techniques used to further customize the model to fit your specific organization needs. These include:
Hybrid Governance: Combines elements of centralized and decentralized governance. For instance, a central team might define broad standards and guidelines, but individual teams have discretion over how to implement these in their specific context. This model attempts to balance consistency and control with flexibility and autonomy. Applying this model is helpful when organizations must support business units created from acquisitions that are still operating somewhat independently. A hybrid model provides time for groups to realign themselves to a centralized set of guidelines while managing their existing APIs.
Automated Governance: This model leverages automation tools to enforce governance policies. For example, API linters and automated tests are used as part of an automated CI/CD process to check whether APIs comply with design standards. This can increase efficiency and consistency while shifting left your compliance checks to an earlier stage of the design and development process. This model is useful when combined with any of the above models to enhance their effectiveness.
Summary: Automate when possible to reduce the burden and wait time for your API design reviews. If you have multiple APIs across the organization that each have their own style guide as a result of independent development or acquisitions, start with a hybrid governance model. You can target a federated governance model as you are able to unify teams into a single set of standards and practices.
Scaling your API governance model
Once your API governance model is established, it is time to start thinking about how to scale it across the organization. If your organization are like some that we have partnered with to grow their API program, you may have thousands of developers spread across different lines of business and domain areas. In this case, scaling your API governance model is essential. We recommend implementing a federated API coaching model alongside governance automation.
Federated API coaches support their business units or domain areas, reducing the burden and wait time often associated with a centralized governance model. These coaches are trained and deployed across the organization to distribute the review process. API coaches also benefit from their knowledge of their domain area, providing deeper insight than a centralized group that is less familiar with the domain.
You can learn more about federated API coaching from our recent article, “Scaling Your API Program with Federated API Coaching”. In this article, we take a deeper dive into the challenges of scaling an API program and how API coaches can help alleviate many of the day-to-day pressures experienced by an API C4E.
Getting started with your API governance model
As organizations grow their API landscapes, governance can become a challenging task. Selecting the appropriate API governance model is an important step for your API program. By examining each of the models and selecting the appropriate one, organizations can be prepared to scale their API program effectively. Combining the API governance model with a federated API coach program enables teams to gain the support they need quickly and with the deeper understanding of those in their same area of business.
Did you know that LaunchAny has partnered with organizations of all sizes to establish their API governance model? We can perform an assessment of your API program to identify the best API governance model for you, as well as recommend areas of improvement to effectively scale your API program. Contact us to find out more.