To many people, governance is a four-letter word. As vital as governance is to any organization’s strategy, the mere mention of the word can take the oxygen out of the room. One reason for this is that people often view governance as a burden that slows things down. However, when done effectively, governance can provide clear direction, remove obstacles, and allow different parts of the organization to function independently. The best way to implement this empowering style of governance is to keep strategic goals top of mind, to align with the dynamics of the organization that needs to be governed and to use incentives as much or more than any punitive measures.
Mike Amundsen’s recent blog post on the role of decision making in API governance is a step in this direction. Focusing on the scalability of a complex organization, he outlines how the decision process can be unbundled and distributed. When dealing with complex systems, the most effective solutions often come down to decomposing processes and parts. Mike’s line of thinking made me consider how API governance itself could be unpacked. Do people all mean the same thing when they talk about API governance? Are enforcing API consumer rate limits at runtime and measuring the business benefit of specific API products really part of the same concept? Well, yes and no. In general, API governance is about ensuring that the APIs offered by an organization deliver their intended value. However, since there is such a wide variety of goals that API governance addresses, they may end up in conflict.
To deal with the contention between goals, I propose four categories of API governance: program, product, portfolio, and platform. In my experience, any conflict in an organization’s API governance happens between these areas, not within them. This classification scheme can help your organization define a comprehensive API governance model with clear ownership and objectives that will minimize and mitigate possible friction.
API program governance
At the highest level of the scheme is API program governance. To support their digital transformation efforts, many organizations look for ways to utilize APIs for the betterment of their business. Step one is to define the API strategy that aligns with the organization’s business goals and organizational dynamics. The subsequent steps that implement the strategy are best guided by an enterprise API program. I believe it is the responsibility of the API program leadership — often an API “Center for Enablement” (C4E) within the organization — to define the overall API governance model, including governance of the program’s own objectives.
Fundamentally, an API program is a cross-organizational change initiative. The most effective API programs are holistic in nature, taking into account not just changes in technology, but also addressing business alignment, delivery methodologies, team structures, and even organizational culture. As such, API program goals vary. API program governance is about measuring the program’s progress against its goals, and addressing any gaps either by accelerating change or by adjusting course. Here are some of the questions you should ask and address through API program governance:
- How can we measure the program’s impact on its stated goals?
- How can we measure and increase our organization’s adoption of an API-led approach?
- On which attributes and areas of the organization do we want to focus our governance versus the ones we just want to monitor?
- How can we assess why some groups are not following the guidance, and how should we deal with them?
- How can we tell if our program goals are the right ones?
The C4E should maintain ownership of API program governance for the duration of the program. An explicit focus on program goals and governance will help the C4E keep the API program on track.
API product governance
Regardless of the overall enterprise API strategy, each API product should have a standalone product strategy and intended business model. A successful API product should be self-sustaining. From that perspective alone, it is obvious as to why the governance of an API product should be distinct from the supporting organization’s API program. API product governance should be the responsibility of the API product team, and more specifically be the accountability of the API product manager.
API product governance is about managing the lifecycle of individual APIs, ensuring they are meeting their business objectives, and measuring the API product against its defined business model. Here are some of the questions you should ask and address through API product governance:
- Who should own the product lifecycle overall?
- How well-aligned are the product vision, business model, market strategy, product design, roadmap, and operating model?
- How effectively is new feature delivery being balanced with the retirement of technical debt?
- What channels (automated and user-based) are in place to collect consumer feedback and measure API product performance?
- What API product risks need to be managed, and what regulatory compliance is required?
The C4E should be involved in answering the first question around ownership initially, and revisit that question on an ongoing basis. However, the responsibility for API product governance should move quickly to the API’s product manager and their associated product team.
API portfolio governance
As organizations mature their API-led approach, they will end up with more and more API products. As the number of API products increases, so does the need for governance of some cross-cutting concerns. While API program governance covers the enterprise-wide concerns that are change-oriented, a new category of governance — API portfolio governance — is needed to handle those that are long-lasting. Without portfolio governance, an organization runs the risk of duplicating efforts within product teams, providing inconsistent developer experiences, and opening up vulnerabilities.
API portfolio governance is about overseeing the superset of API products in an organization. This type of governance can help merge similar API products, deprecate unused APIs, driving consistency around design, applying consistent policies, and aggregate external perspectives. Here are some of the questions you should ask and address through API portfolio governance:
- What is the consumption profile for the products in our API portfolio? What are our highest value API products? How do we manage those that are redundant or unused?
- What security and operational policies must be enforced across our API product portfolio? How are we protecting our customers’ data? How are we protecting our own data?
- What design conventions and standards should be followed across the portfolio?
- How much synergy is there between the various developer communities utilizing our APIs, and how can they best be served?
- Are there economies of scale that can be leveraged with the collaborating partners for our various API products?
- What cross-cutting concerns should we address in the portfolio of third party APIs that our organization consumes?
API program and portfolio governance will likely be a C4E responsibility in the early stages of an API program. As the program progresses, it will be important for the C4E to transfer responsibility for portfolio governance to other long-living entities within the organization. For the portfolio of external APIs, this will likely be a centralized group within the business organization, such as the office of the Chief Digital Officer. For internal APIs, it could be with a shared services unit on the business side, or a centralized group in IT. Regardless of placement, portfolio governance needs to remain focused on the business aspects of the API portfolio.
API platform governance
Lastly, we need to consider API governance that happens automatically within the organization’s runtime API interactions. This platform governance is needed to provide the level of efficiency and scale needed in a digital organization. Without it, organizational leaders would have limited ability to observe and measure the impact of their governance measures, nor would they be able to enforce governance policies in real time.
API platform governance has a dual nature. In one respect, it is about providing metrics to and enforcing policies for the other three categories of API governance. In the other respect, it is about exploiting automation and digital native capabilities to ensure stability, security, and resilience within the operational environment in which the API products are implemented. Here are some questions you should ask and address through API platform governance:
- What runtime capabilities are needed to enforce API product governance policies? (e.g. rate limits, usage data collection broken down by version/consumer)
- What runtime capabilities are needed to enforce API portfolio governance policies? (e.g. authentication and authorization, data attribution, message correlation, traffic control, third-party API consumption metrics).
- What do normal operations look like and how can operational anomalies be managed?
- What is the API platform business model and how can its efficiency and effectiveness be continually measured?
Like portfolio governance, API platform governance is likely to start out under the ownership of the API C4E. Over time, it should be transitioned to a cross-organizational group within IT. Many organizations are moving to product-based rather than a project-based structure. In these organizations, there are often specific platform teams who play the role of serving cross-functional product teams while providing technology stewardship for shared concerns.
The fifth “P”: principles
Perhaps the most important part of the API governance model is managing the contention between the different categories. Early in an API program, there is likely to be contention between the program’s objectives and the organization’s status quo. As a result, strong program governance is needed from the outset. The C4E will need to keep the program goals top-of-mind, find allies throughout the organization, and choose its battles carefully. As the program matures, and the number of API products grow, the friction between product and program governance may increase. On one hand, API product managers will not want their feature delivery slowed down by organizational red tape. On the other, those governing the API product portfolio will not want a collection of APIs that lack consistency and cohesion.
Delineating the different categories of governance should clarify roles and mitigate potential contention in the overall API governance model. Keeping the focus on consumer needs will provide additional guidance to resolve conflicts. A proactive measure that an organization’s C4E can take to optimize the governance model is to establish a set of principles that articulate the API program’s ethos. Although not explicitly API-related, Amazon and Netflix have used widely-proliferated principles to define their respective cultures and scale their organizations. Broadly-communicated principles give an opportunity to state whether the emphasis should be on product empowerment or portfolio consistency, on user flexibility or user experience. Whereas other aspects of governance should be revisited and evolve over time, you should try to define principles that are at a high-enough level that they stand the test of time.
API governance is a big topic. Hopefully, breaking it down into these four categories will help your organization structure an effective API program that can transition to steady-state in due time. For more help with API governance and other aspects of API strategy, check out MuleSoft’s API Program Workshops.
