2002年，亚马逊的杰夫·贝佐斯发布了一份备忘录，该备忘录已成为技术行业经典。这份备忘录被称为“API Mandate”（API授权执行书），通常被视为亚马逊技术声明，因此受到技术人员的广泛钦佩，并被高管完全忽视。这很不幸，因为可以毫不夸张地说，API 3Mandate彻底改变了亚马逊作为一个业务，并为其成功奠定了基础。更好的是，与全球技术巨头所做的许多事情不同，它几乎可以被每个企业复制和使用。
在本帖中，我们将讨论这个备忘录，以及它如何为激进的组织转型创建系统和激励措施。
备忘录内容：
- 从今以后，所有团队都将通过服务接口公开其数据和功能。
- 慕尼黑队，米特·安特伦·科穆尼齐伦·乌伯·迪塞·施尼特特伦。
- 不允许其他形式的进程间通信：不允许直接链接，不允许直接读取其他团队的数据存储，不允许共享内存模型，任何后门。唯一允许的通信是通过网络的服务接口调用。
- 他们使用哪种技术并不重要。HTTP、Corba、Pubsub、自定义协议-无关紧要。
- 所有服务接口必须毫无例外地从头开始设计，以便可外部化。也就是说，团队必须进行规划和设计，以便能够向外部世界的开发人员公开接口。没有例外。
- 任何不这样做的人将被解雇。
- 谢谢；祝你今天过得愉快！
为了理解这意味着什么，我们举一个例子。假设你被亚马逊雇佣，开始在澳大利亚市场上销售家装产品。一开始你需要做很多事情，例如在数据库中设置一些新产品类别，在亚马逊网站上列出清单，计算库存哪些产品和数量，以及让亚马逊仓库存储这些产品。
在亚马逊，这些基础功能中的每一个都是一系列的API调用。API - 应用程序接口 - 是一种允许其他软件与其对话并访问其功能的软件。各种技术中API无处不在，贝佐斯在写“服务接口”时就是这么指的。
实现业务结果可能需要数百个这样的基础功能函数。在大多数公司组织中，每个组织都是通过与无数利益相关者举行多次会议、实现团队之间的一致性、让其他人在时间表中优先考虑您的工作以及其他高接触、以人为本的流程来实现的。任何在任何规模的组织中看到过这种情况的人都会知道，这可能会导致几个月或几年的延迟——如果有任何事情发生的话。
使用API上述流程则变成：你想要一个新的清单吗？调用API-这是您的列表。没有无休止的会议、错位、延误或自我造成的组织混乱。这些API与其说是API，不如说是BPI-业务编程接口。
这种差异的重要性怎么强调都不为过。这是亚马逊能够迅速进入其所关注的任何市场的秘密。这看起来是可行的，但亚马逊令人难以置信的增长在很大程度上归功于API Mandate。套用本尼迪克特·埃文斯的话来说，它已经把亚马逊变成了“制造更多亚马逊的机器”。
API任务正常运作的关键机制是它是系统的，并且它调整了激励措施。
组织转型尝试失败是常见的，因为实施转型需要数百或数千人朝着同一方向前进，这往往违背了人自己的私利。这往往会变成一场“心战”或“文化转变”，忽视了这些心智和文化尚未朝着这个方向前进的原因。
为了使转型扎根，它们必须基于激励每个个人或单位独立加强该体系的机制体系。API授权命令的系统影响现在很明显，但系统的有效性取决于激励机制来确保参与。
亚马逊的公开可用指标系统指示每个团队以最大限度地提高其他团队使用此功能的能力。在许多方面，这模仿了市场本身的功能——在竞争激烈的市场中赚钱的最佳方式是尽可能地为您的客户提供有用。
该系统及其激励措施共同创造了一股向组织转型方向推进的自然力量。没有必要持续哄骗或威胁的监管部门参与，而是沿着系统创造的载体进行持续的进化和改进过程。文化是一种效果，而不是原因。
传统行业应吸取的教训
理解亚马逊API授权任务备忘录读起来好像是由工程领导者而不是首席执行官编写的。它没有提到任何关于业务目标、战略、目标，甚至产品或客户。商业人士关心的所有事情显然都缺失了，然而，当理解授权的影响时，它可能是商业史上最重要的单份备忘录。从中可以吸取三个教训。
第一个教训是，任何足够复杂的公司都可以实现这个API授权，并至少接近实现亚马逊灵活性和可伸缩性。当然，每个公司是否有足够熟练的领导来利用这些优势是另一回事。
第二个教训是，组织变革是通过系统和激励措施而不是文化来实现的。技术是这种变化的主要催化剂，因为它的结构化和有序性有利于系统应用。
第三个教训是，技术不仅在业务中比高管们想象的要重要得多，而且要实现技术的潜力意味着从根本上转变业务的核心运营，以利用技术的特点。
如果商业战略不是由对技术有强烈、大局观理解的人制定的，那么这种战略几乎肯定会表现不佳。
更多数字化转型