Conway's Law, APIs, And People
Melvin Conway introduced Conway's Law in 1967. It states:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
In actionable terms, it means:
"If you design the org before you design the system, the system will look like the org."
This is not a good thing.
A few years back, at peak frustration with Apple (after being a complete fanboy for the previous decade), I tried update some credit card details stored in my Apple account. But there was no single, clear place to do it.
I logged into my iTunes account. Nothing. I logged in to my Apple Store account. Nothing there, either. I logged into the support website. No joy.
Somewhere along the way I realised I'd logged into what should have been the same system, three different ways. And yet, by the end, I wasn't logged into any of them.
Different systems, with similar capabilities, each acting a different ways.
Conway's Law in action. Today, as a Chrome OS fanboy, my life is much simpler. Ironically, it just works.
I'm hopeful - in an increasingly API first world - the simplicity of Chome OS will permeate every product and service I use. APIs can be the antidote to Conway's Law.
Zalando's "Purpose" statement in their excellent Restful API guidelines explains why:
"Great RESTful APIs look like they were designed by a single team."
APIs are often thought of as "features" with creation, maintenance, and documentation of them silo'd into separate teams. Screens are designed before systems, and APIs become a fast-follow (or slow-follow) consideration. Nothing "just works" as a result.
Thankfully, Platforms can help neutralize Conway's Law, with even larger Platforms like Microsoft highlighting the need to fight against it. But the war hasn't been won - yet.