2002年貝佐斯頒布的那道「API 授權」備忘錄，奠定了亞馬遜成為當今的電子商務的巨頭

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

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

備忘錄

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

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

為了便於理解這意味著什麼，我們不妨舉個例子。假設Amazon把你招募了進來，要你針對澳大利亞市場銷售家居裝飾產品。你需要做很多事情才能開始賣，比方說要為資料庫設置一些新的產品類別、要到Amazon的網站上把商品列上架、確定要備貨的類型和數量，以及讓Amazon的倉庫存放那些產品^[注2]。

在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 授權執行得當的關鍵機制是它是系統性的，而且跟激勵措施保持一致。

組織轉型嘗試的失敗很常見，因為實施轉型需要成百上千的人朝著同一個方向去努力，而這往往會跟他們自身的利益背道而馳。這通常會演變成爭奪「理智與感情之戰」，要嘛需要一場「文化轉變」，但卻忽視了那些思想和文化為什麼沒有能夠朝著那個方向發展的原因。

變革要想札根下來，需要有一套基於機制的系統，用這套系統來激勵每一個個體或單位獨立地強化這套系統。API 授權的系統性影響我們現在已經看得很清楚了，但係統的效力卻要依賴於確保參與的激勵機制。

Amazon的指標體係都是公開可見的，這就會刺激著每一支團隊在提供功能的時候，都要盡量讓其他團隊利用自己功能，讓自己的能力最大化。從很多方面來說，這模仿了市場本身的功能——要想在競爭激烈的市場當中賺錢，最好的辦法是盡可能對你的客戶有用。

這套系統，以及相應的激勵措施，它們共同創造出一股能夠推動組織轉型的自然力量。不需要不斷地威逼利誘那些頑固分子去參與，相反，這是一個沿著系統創造出來的方向持續演進和改進的過程。文化是結果，而不是原因。

三條經驗

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

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

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

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

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

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

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

你所需要的，只是一份措辭強硬的備忘錄而已。

• [注1]就像亞瑟王的傳說一樣，這份備忘錄已經進入到神話的領域。不管它是不是用這種確切的形式存在，無論是過去還是現在，API 授權在Amazon都是真實存在的。
• [注2]這些細節完全是推測，但論點是站得住腳的。
• [注3]至少在理論上。我相信其中的一些在實踐當中仍然會時有發生。
• [注4]至少是作為Amazon擴展自身組織的系統性制度方法的象徵。
• 資料來源：The Memo
• 本文授權轉載自36kr