2002 年的時候，Amazon的傑夫·貝佐斯（Jeff Bezos） 發布了一份備忘錄，這份備忘錄後來成為了科技行業的教規。這份備忘錄叫做「API 授權」（API Mandate），一般被認為是Amazon對技術方面做出的聲明，所以只是受到技術人員的廣泛讚賞，但卻被高級主管們完全忽視了。這是很不幸的。因為，可以毫不誇張地說，API授權徹底變革了Amazon的業務，並為它的成功奠定了基礎。而且更好的一點是，跟這家全球性的科技巨頭所做的很多事情不同，任何企業幾乎都可以複制和使用這個。

在這篇文章當中，我們將討論這份備忘錄，以及它是如何為激進的組織轉型建立系統以及激勵措施的。

備忘錄

據報導[注1] ，這份備忘錄是這樣的，

從今天起，所有的團隊都要以服務介面連接埠的方式，提供資料和各種功能。
團隊之間必須通過連接埠來通信。
不允許任何其他形式的互操作：不允許直接連結，不允許直接讀取其他團隊的資料，不允許共享儲存空間，不允許任何形式的後門。唯一許可的通訊方式，就是透過網路呼叫服務。
具體的實際技術不做規定，HTTP、Corba、PubSub、自定義協議皆可。
所有的服務連接埠，必須從一開始就以可以公開作為設計導向，沒有例外。這就是說，在設計連接埠的時候，就預設這個連接埠可以對外部人員開放，沒有討價還價的餘地。
不遵守上面規定者，一律開除。
謝謝；祝你過得愉快！

在Amazon這裡，這些子功能每一個都是一系列的API 的系統呼叫。API，應用程式介面（Application Programming Interface），是一種可以讓其他的軟體跟自己對話並存取自身功能的軟體。API 在各種技術當中都隨處可見，而這就是貝佐斯所謂的「服務連接埠」。

業務程式編輯連接埠

實現一項業務成果可能需要數百個這樣的功能。在大多數的組織當中，大家都是透過跟無數的利益相關者舉行多次的會議、進行團隊之間的協調、讓其他人在自己的日程安排當中優先考慮你的工作，以及靠其他需要大量接觸、以人為中心的流程來完成的。任何人在任何規模的組織當中看到過這種情況的都會知道，這可能會導致長達數月或數年的延誤——如果說最終能辦成的話。

API 授權要求負責把商品上架的團隊要把自己團隊要做的事情作為API 公開出來，而不是靠人際溝通來解決。你有新的商品要上架？那就呼叫API——然後你的商品就可以上架了。沒有沒完沒了的會議、溝通不到位、延誤或自己造成的組織混亂^[注3]。這些API 與其說是API，不如說是BPI——業務程式介面（Business Programming Interfaces）。

這種差異的重要性怎麼強調都不為過。這就是Amazon之所以能夠迅速進入它所關注的任何市場的秘訣。這看起來似乎不太可能，但Amazon令人難以置信的增長在很大程度上都要歸功於API授權^[注4]。套用Benedict Evans的話來說，它已經把Amazon變成了「製造出更多Amazon的機器」。

API 授權似乎是技術領導而不是CEO 寫出來的。裡面沒有提到任何跟業務目標、戰略、投放範圍，甚至產品或客戶有關的內容。業務人員關心的一切顯然都不存在，但是一旦你理解了這份指令影響時，就會知道這也許是商業史上最重要的一份備忘錄。我們從中可以學習到三條經驗。

第一條經驗是，任何公司只要足夠複雜都可以自己去實施API授權，而且至少可以很好地實現跟Amazon接近的靈活性和可擴展性。當然，每一家公司是不是都擁有領導技能足夠熟練的領導，知道如何去利用這些優勢，則是另一回事。

第二條經驗是，組織變革是透過系統和激勵機製而不是透過文化來實現的。技術是這種變革的主要催化劑，因為技術是結構化的，有序的，本身就適合系統性的應用。

第三條經驗是，技術對業務的重要性不僅遠超高階主管們的想像，而且實現技術潛能意味著企業的核心運營會發生根本性的轉變，這樣才能利用技術的特性。如果商業戰略不是由對技術有著深刻理解的人來製定的話，那麼幾乎可以肯定，這項戰略注定會不如預期。

像Amazon這樣的公司都在哪裡？

既然API授權這麼好，那為什麼像Amazon這樣的企業少之又少？其中一個重要的原因也許是，很少有高階主管了解甚至喜歡技術，進而能夠有效地利用技術來獲得競爭優勢。即便是經驗豐富的公司也往往會忽視建構自身業務的激勵措施，並無視技術所推動的業務轉型的系統方法。

好消息是，像Amazon這樣的公司已經為我們其他人點亮了一條前進的道路。在明確了解來API 授權的真正含義後，任何組織都可以掌握這種真正的變革。