Bezos memo: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
{{a|design|}}Legend has it that in 2002, an aspiring technology entrepreneur issued a prime directive to the burgeoning different business units in his organisation. The organisation was Amazon, the entrepreneur Jeff Bezos and the mandate would serve to form the backbone of Amazon’s “flywheel” in the modern web space, centralising the common [[application programming interface]] ('''[[API]]''') as the organisation’ pulmonary system:
{{a|design|}}Legend has it that in 2002, an aspiring technology entrepreneur issued a prime directive to the burgeoning different business units in his organisation. The organisation was Amazon, the entrepreneur Jeff Bezos and the mandate would serve to form the backbone of Amazon’s “flywheel” in the modern web space, centralising the common [[application programming interface]] ('''[[API]]''') as the organisation’ pulmonary system:
#All teams will henceforth expose their data and functionality through service interfaces.
{{quote|{{L1}}
#Teams must communicate with each other through these interfaces.
All teams will henceforth expose their data and functionality through service interfaces.<li>
#There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
Teams must communicate with each other through these interfaces.<li>
#It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.<li>
#All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.<li>
#Anyone who doesn’t do this will be fired.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
#Thank you; have a nice day!
<li>Anyone who doesn’t do this will be fired.<li>
Thank you; have a nice day!</ol>}}


===Service interfaces — aka [[API]]s===
===Service interfaces — aka [[API]]s===

Latest revision as of 09:08, 24 July 2024

The design of organisations and products
Index: Click to expand:
Tell me more
Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

Legend has it that in 2002, an aspiring technology entrepreneur issued a prime directive to the burgeoning different business units in his organisation. The organisation was Amazon, the entrepreneur Jeff Bezos and the mandate would serve to form the backbone of Amazon’s “flywheel” in the modern web space, centralising the common application programming interface (API) as the organisation’ pulmonary system:

  1. All teams will henceforth expose their data and functionality through service interfaces.
  2. Teams must communicate with each other through these interfaces.
  3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
  5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
  6. Anyone who doesn’t do this will be fired.
  7. Thank you; have a nice day!

Service interfaces — aka APIs

Creating a common interface for communication of information across the organisation allows maximum plug-and-play: allows the modularisation of business units, and — provided the unit managers conform with this basic criterion — gives them flexibility to organise their own units as they see fit. It is like a common, basic language: very much part of the end-to-end principle for design of distributed networks.

An API allow for for information to be non-destructively transformed, enhanced, sent backwards and forwards, providing a common basic protocol for other systems that interact with the system. Even though it is a foundational design principle of the internet, it was not rigorously imposed and, in legacy organisations that didn’t have Amazon’s ability to start, more or less completely, from scratch.

Banning other forms of inter-process communication enforces the standard, and incentivices everyone to get it right, keeping it as simple and robust as possible. This prevents people from building fiefdoms, constructing critical dependencies on their bespoke systems, and makes anyone and anything swap-out-able.

This is how you do top-down management: by mandating only what is necessary to permit maximum autonomy and interconnectedness of bottom-up procees. Bezos is saying “as long as everyone can see what you are doing, and you make what you are doing maximally shareable, you are free to extemporise. But if you break this one rule, get your coat.”

See also