In 2017, Ronnie Mitra presented a talk at Nordic APIs entitled “Programming the People Platform: Beyond Conway’s Law.” In that talk, Mitra outlined a model for distributed decision making and how it can be used to improve API governance. The material from that talk made it into the book “Continuous API Management.” Here, Mitra explained in greater detail how to apply this model to match, and eventually evolve, the way teams make decisions about what types of APIs to build, how to design and implement them, and how they should be managed over time.
What’s at the heart of Mitra’s observations? How can his observations be applied to IT organizations looking to modernize and manage their ecosystems? Mitra distributed decision-making model focused on three key things:
- Governance is about decisions.
- Understanding the elements of a decision.
- The advantages and challenges of centralized vs. distributed decisions.
#1 Governance is all about decisions
When setting out to govern any aspect of the organization, it’s really all about making decisions. In the case of governing an API program, you’ll need to make a variety of decisions, such as:
- Which API should we build next?
- What are the design parameters for these APIs?
- What are the technical implementation details of each API?
- Once deployed into the IT ecosystem, when and how should the API be maintained?
- How long should you maintain this API before deprecating it?
These decisions are never-ending — new decisions will always need to be made as APIs pass through each lifecycle phase. New APIs will need to be built, existing APIs need to be maintained, and old ones will deprecate.
Some of these decisions can be made across a group of APIs (e.g. general design and implementation principles). But others will require a case-by-case approach (e.g. APIs for external use vs. APIs for internal use). Occasionally, your decisions need to be informed by “information in the field,” based on the knowledge and experience from front-line users, designers, and developers.
Currently, there’s conflicting advice on the subject. Centrally-managed shared principles and local distributed experience is at odds with the guidance to reduce the role of central governance to empower teams to make their own decisions. In reality, decision making is a multi-step process, that enables a custom-fit governance model for a company’s needs and culture.
But to do that, we need to understand what making a “decision” entails.
#2 Understanding the elements of a decision
We all make decisions every day. Typically, we don’t dwell too much on the process of decision-making; we just decide and move on. However, Mitra points out that each decision is actually a set of actions. This set of actions has five key components:
- Inception
- Choice generation
- Selection
- Authorization
- Implementation
- Challenge
Knowing each of the steps gives us the ability to focus, optimize, and improve the quality and the speed at which we make our decisions.
Inception
The first of the decision elements is inception. An idea is created that will require a decision. Examples of inception in the API space are: “We need a customer-onboarding API,” “We should redesign and rebuild our internal data-access layer APIs,” “We should deprecate the old reports API,” and so on.
Sometimes decisions can be created and resolved quickly without much time spent contemplating impact or consequence. Other times, decisions go through a long process, resulting in a missed business opportunity (e.g. “We should eventually create a public API to beat our competitors in the marketplace.”).
Either way, decisions start as questions or suggestions.
Choice generation
It can be difficult to make a decision when the range of options is unknown. To avoid missing important details, the second step in the decision-making process is choice generation. For example, it may be time to redesign your public-facing APIs, which can be done through a variety of methods. To get the best outcome, your team would conduct research and generate a series of options before making a decision.
It becomes more important to explore and generate options as the number of unknown variables in your decision increases. If you have experience working with document databases, making design decisions for your data storage may be straightforward. However, if you’re looking into streaming data storage for the first time, it’s beneficial to learn the domain and discover common challenges others have faced.
In the end, choice generation is about creating a list of options. There’s an art to creating a set of choices that reflect your organization’s concerns, in that it is limited but not too restrictive. The process of choice generation sets the boundaries going forward.
Selection
Selection is the act of picking one of the possibilities from the set of options generated in the previous step. Most often, selecting an option is context-driven. For example, the API-design parameters would differ between a team using NodeJS and JSON format and the team responsible for supporting the nightly batch-file-transfer API.
One advantage of choice generation is the ability to set clear boundaries for the selection process. The possibilities are limited, but allow individual teams to make their own decisions based on the context of their roles and duties.
Authorization
Making a selection is not the end of the decision-making process. Often, someone still needs to review and approve the selection. Authorization establishes the validity of the selection. In many organizations, teams make a selection from an approved set of tools or technologies but still require approval from stakeholders before making a purchase, installing, or implementing that selection.
Authorization can act as a safety check, preventing teams or individuals from making costly mistakes. At the same time, if all choices need to be authorized from a single, central source, it’s likely that authority will become a bottleneck in the decision-making process. While authorization provides a safety check, it can come at the cost of speed or agility.
Implementation
Selection and authorization lead to implementation — the execution of the decision. It is important that the execution begins soon after authorization. Slow implementation can lead to a delivery that is too late or poorly executed.
Implementation is often executed by people who were not in the previous decision-making steps. A good example of this is construction work. The decisions are made, the plans are written up in detail, and turned over to the master contractor to make those plans into a reality.
The implementation element of a decision is the culmination of all the previous steps — inception, choice generation, selection, and authorization. Even when we make a decision by and for ourselves, we still go through some version of these steps.
Challenge
Decisions are not forever. Circumstances change, organizations evolve, and markets mature. That means it is important to keep an open mind about your decisions even after they have been executed.
This review of previous decision elements is a way to challenge the decision and is an important step in keeping a vital and healthy ecosystem. For example, a year ago, in the process of choice generation, you may have only found two viable options to consider. But now, there are a few more major contenders for your “menu of options.”
It is important to account for and encourage challenging past decisions, especially ones made some time ago. “We’ve always done it this way” is often evidence that it is time to challenge previously-made decisions.
The challenge step brings the decision-making process full circle as it will often lead to a new set of decisions to be made in order to keep your system healthy and moving forward.
#3 Advantages and challenges of centralized vs. distributed decisions
After the decision-making process and organization operations are clear, it’s then possible to nudge the organization toward a new goal. This is where the notions of centralized and decentralized come into play. Like so many things, the difference between positive and negative is not always simple and lies in a gray zone. The same is true for value judgments about centralized and distributed decision-making.
In a classic centralized model, all the elements of the decision (inception, choice generation, selection, authorization, implementation, and challenge) originate and live within a central source (e.g. a person or an enterprise-level committee). In a fully-decentralized model, all the elements are decided by an individual or team. The optimal solution is rarely found at either end of the extreme. Instead, we need a way to fine-tune our decision model.
Consider the possibility that inception, choice generation, and authorization reside within a central, company-wide committee while the selection, implementation, and challenge elements are farmed out to teams. In this model, teams can exercise a level of autonomy based on their own circumstances, while company-wide elements of the decision can offer reasonable guidelines based on research and exploration.
It’s common for decision elements to vary from team to team. For example, new teams might start with nearly no responsibility for decision elements and, as the team gains experience, the centralized decision-making body can shift elements of the decision to the team themselves. This process of gradually shifting decision elements can be tracked and managed like many other aspects of your company’s culture and process.
The challenge isn’t whether to commit to a centralized or distributed decision-making model. The challenge is how to mix decision elements within a team or set of teams to optimize effectiveness without slowing down production.
For more on building an API strategy that aligns your organization and culture, check out our “Way of the API” workshop.
