By Matthew Reinbold in Newsletter — Sep 21, 2020

Net API Notes for 2020/09/22 - Mailbag II! - Issue 142

It has been a couple of weeks, and the videos from the API Specifications Conference (ASC 2020) have been posted. I'll probably highlight some notable presentations next week. This week, however, it is time for another mailbag!

MAILBAG, PART DEUX: CONWAY'S LAW AND MICROSERVICES

Questions trickle in from time to time. Earlier this year, I grouped a number and answered them at once. Lauren, a graduate student, recently reached out with her own set of questions regarding Conway's Law and microservices.

I found Lauren's questions insightful and thought others might be wondering the same thing. With her permission, here's our exchange.

HOW DOES CONWAY'S LAW RELATE TO MICROSERVICES IMPLEMENTATION?

Like Metcalfe's or Moore's Laws, Conway's Law attempts to describe a naturally occurring phenomenon. It says that designed systems will mirror the communication structure of the participants. In most situations, the way communication flows between groups is due to their organizational arrangement. (Said another way, "Organizations ship their org charts".)

Microservices are an architectural style that attempts to minimize communication overhead between participants. With lowered coordination costs, microservices decrease time to production. However, this benefit comes with the additional deployment pipeline, security, monitoring, and test complexity.

Attempting to reap the benefits of microservices (lowered communication overhead) while maintaining existing communication patterns (i.e., the same org) is likely to fail. What Conway's Law predicts is that solution arrived at will look much like the existing team structure. As author and architectural consultant Ruth Malan says:

"If the architecture of the system and the architecture of the org are at odds, the architecture of the org wins."

HOW DID YOU GO ABOUT IMPLEMENTING CONWAY'S LAW IN AN ENTERPRISE?

Conway's Law exists in organizations whether or not anyone is implementing it. I think what is being asked is how one aligns communication patterns to produce the desired architectural outcomes.

After individuals, the next organizational communication structure is the development team. Understanding the different types of groups, and the communication between them, should be part of the design process. The book Team Topologies, by Matthew Skelton and Manuel Pais, defines several optimal team arrangements to achieve specific outcomes.

I've written more about this in my recent talk, "APIs Are Arrangements of Power" (specifically, see the section under 'The Inverse Conway Maneuver').

HOW DO YOU START?

As software expert Grady Booch says:

"A good architecture is characterized by crisp abstractions, a good separation of concerns, a clear distribution of responsibilities, and simplicity.

Start with crisp abstractions, good separation of concerns, and a clear distribution of responsibilities. Drawing the lines between these, the bounded contexts, can be tricky. UK author and software consultant Nick Tune defines bounded contexts as:

"a bet on those things that will change together"

Teams (or individuals) should be aligned so that communication can most easily happen within each one of those bets. Distance - whether geographical, org hierarchical, or even mentality - can make that communication more difficult.

WAS THERE PUSH BACK?

What is often seen as resistance is more often a difference of perspective. Even though service boundaries are made with the best information available, they are still guesses. If that wasn't enough, things change.

Thankfully, change is what the microservice style excels at. By shrinking and isolating what needs to be changed behind stable, predictable contracts, the rest of the software experience is buffered from that churn of modern development.

Demonstrating this value to the business (and, subsequently, people's careers) is important to overcoming resistance. There is more available on this subject in my previous work (search the page for "Blue Ocean Strategy").

HOW LONG DID IT TAKE TO IMPLEMENT IT?

Architecture, microservice or otherwise, is always ongoing. Software that is "done" is software that is dead.

Again, from Grady:

"Meaningful architecture is a living, vibrant process of deliberation, design, and decision."

Each organization is different. Each may declare their metrics by which they claim success (i.e., "we've 'completed' our microservice journey"). Ultimately, if an architectural initiative can demonstrate that it contributes to an organization meeting its objectives, it is successful.

WHERE IS THE MOST IMPORTANT PLACE TO START WHEN IMPLEMENTING MICROSERVICES?

There are several good books on the subject. The two that immediately come to mind are Sam Newman's From Monolith to Microservice and Chris Richardson's Microservices Patterns.

Whatever the specific approach, I strongly encourage developers to start with solving a stakeholder need rather than a particular architectural pattern. I've seen too many enthusiastic, bright teams proudly announce that they're "doing microservices" without entirely understanding the problem they're trying to solve.

WHAT ARE YOUR OPINIONS ON DESIGN FIRST ARCHITECTURE FOR MICROSERVICES?

I am a strong advocate for design-first architecture. As Frank Lloyd Wright said:

"You can use an eraser on the drafting table or a sledgehammer on the construction site."

Having to rewrite code because the problem wasn't properly understood is an expensive and demoralizing process. We are fortunate to have an array of tools that allow us to play with a design, mock sample requests, and present them to stakeholders.

Some mistakenly assume that any planning upfront is antithetical to agile development. It is unfortunate. Changing a few YAML lines in an API description enables fast feedback loops that agile practitioners should aspire to.

WHAT ARE YOUR OPINIONS ON CODE FIRST FOR MICROSERVICES?

I don't encourage it. There may be situations where a team hopes to annotate the heck out of their methods in a legacy codebase. The annotations then help a language or framework to expose that code as individually addressable services. However these services are usually anemic because they solved a developer need, not a stakeholder one.

Regular API speaker and author, Mike Amundsen, made a powerful observation several years ago:

"Your data model is not your object model is not your resource model is not your message model."

Each one of those layers required to deliver working software has a different set of objectives they need to meet. That is why when you take something, like the arrangement of your implementation (your object model) and use it for something else (the resource model), the result is a compromised design.

WHAT ARE SOME TOOLS TO HELP SUCCESSFULLY IMPLEMENT DESIGN FIRST IN AN ENTERPRISE?

There are many tools available. My biggest suggestion is to find a tool that best aligns with the communication expectations in an organization. If your organization is a heavy power-point driven culture, ensure that the tooling enables the relevant exports and renders smoothly in decks. If it is a memo driven culture, how might APIs be best portrayed? If regular post-mortems and demos are the coins of the realm, find something that accommodates that storytelling.

I want to express a big thank you to Lauren for the opportunity to answer some great questions.

MILESTONES

WRAPPING UP

I also wanted to express a thank you to folks who have been sending me feedback on Netapi.events; there's some URL configuration and forwarding issues that I just need to sit down and sort out. Despite that, however, you can still view the list of upcoming API events. If you see something missing, let me know, and I would be glad to add it.

Finally, thank you to the Patreons who chip in to cover the caffeine that powers this newsletter.

Till next time,

Matthew @libel_vox and matthewreinbold.com