When there is more than one team in an organization, things need to be coordinated. This is especially true when it comes to organizations seeking consistent API design despite have those designs having different authors. Developers, designers, architects, and product managers intuit that consistent design helps them achieve greater speed and scale. Further, a common approach makes integration more intuitive and can reduce ongoing support costs. But getting teams aligned is a whole separate, more significant challenge when compared to just creating the API.
The social scientist couple, Fred and Merrelyn Emery, identified two basic patterns for coordinating activities across multiple teams. They named them “first design principle” and “second design principle”, or DP1 and DP2, respectively. Later, they added the concept of the laissez-faire organization.
Laissez-fair Governance
Laissez-faire is defined as the absence of design principles. Nearly all API ecosystems start as laissez-faire. API design is not a coordinated activity in the beginning but rather a technical means-to-an-end. Laissez-faire is understandable, even desirable at this point in an organization’s journey. An organization’s culture and context define a significant amount of the unique pain points that emerge from inconsistent approaches; these can be difficult to predict. Further, if the API ecosystem does not require further scaling or evolution beyond fragmented, random one-off efforts, a laissez-faire approach to consistency may be appropriate.
DP1 Governance
However, given the necessity of APIs to value delivery in digital transformation efforts, most businesses can’t stop with just laissez-faire design approaches. In these cases, leadership will establish a DP1 organizational structure; they’ll introduce a manager or supervisor whose explicit job is to coordinate parts to achieve an outcome. In API design, the role of this “API reviewer” or “Center of Excellence” group is to achieve greater consistency for the interfaces produced.
On the one hand, responsibility for achieving a quality outcome is straightforward. A single, highly-trained individual (or group) could apply to an entire domain. Ownership of the improvement activities is clear; activities like problem assessment, activity creation, oversite, progress reporting, and feedback gathering.
On the other, DP1 implementations of governance also have notable downsides. For one thing, it can be difficult for any person from a single discipline (architecture, engineering, etc.) to also excel in the myriad of additional skills this type of oversite requires. These skills include diplomacy, consensus-building, project management, and influencing with minimal formal authority, in addition to having a rich and deep understanding of API nuance. Career progression for these diamonds-in-the-rough people is also unclear.
For development teams, especially for those used to a laissez-faire design approach, the introduction of this new supervisor or group can be met with hesitation, even suspicion. They may feel a loss of autonomy or lowered morale over what they perceive as a condemnation of their past work. When the relationship is strained and feedback loops poor, the introduction of this design leadership comes across as “ivory tower architecture”.
It is these DP1 organizational environments that spring to mind when we hear the word “governance”: bureaucratic, dictatorial, and process-heavy hierarchies. These worst-case scenarios cause individuals to feel robbed of agency without the opportunity of recourse. Not everything is worse-case, of course. The most common case is ineffectual, flaccid governance: governance that is tolerated during the production of a token wins. However, the overall API program/platform cannot deliver on the grand transformation promised at the onset.
DP2 Governance
In a DP2 approach, regulation of design standards (and subsequent quality outcomes) is built into the teams themselves. Individuals are expected to manage the coordination across their boundaries. For example, when designing an error object, Ramesh would consult with his peer on another team, Tara. Tara would have experience creating something similar from her work with Maria and Jose who, likewise, are assigned to other teams. And so on and so forth.
Those familiar with Brooks’ Law might notice their Spider-sense tingling. Putting the onus to “carry water” on individuals creates significant communication overhead, particularly as the number of people required to coordinate increases.
Training is one approach to lessen the amount of communication required. “If everyone just knows what to do,” the thinking goes, “they’ll have more time to just do it”. With ongoing effort, this approach can work. However, “upskilling” every individual across all the organization’s development teams is also not trivial. A business pursuing this course of action is also likely to appoint someone or some group to oversee this upskilling, which puts us back into the DP1 design camp. The “information action fallacy” also looms large.
Changing the environment to make desired outcomes more likely is also an approach. I’ll talk more about this in a future post.
Wrapping Up
As the number and complexity of API ecosystems increase, we also need to increase the sophistication of our scaling approaches. Thankfully, a tremendous body of sociotechnical and systems theory over the decades addresses exactly that. As stewards of those ecosystems, our challenge is to step outside of our previous professional callings and engage with this new (to us) wisdom. The sooner we can do that, the sooner we can deliver on the promise of distributed systems.
