在很多開發者看來，提升敏捷性是解決技術難題的不二法則。但本文的作者作爲一家有着一百多年曆史的大公司的技術援助顧問卻認爲，由於歷史遺留、文化隔閡等原因決定：在大公司，所謂的敏捷性開發其實並不是人們以爲的管用。
爲什麼他會這麼說呢？一起來看看。
以下爲譯文：
在硅谷流傳着很多油嘴滑舌、譁衆取寵的膚淺言論，這些言論都是關於開發過程中保持敏捷的重要性的。關於引入敏捷技術的容易性，以及哪些問題可以通過敏捷技術解決，有太多的假設。在這篇文章中，我試圖糾正其中的一些錯誤看法。
在過去的20年裏，我曾經是三家初創公司的技術合夥創始人，其中兩家公司發展到中等規模後被賣掉了，後來我給一些中型到大型規模的公司做一些諮詢工作。這些公司通常有幾個辦公室，最多可能有3000人。特別是我在2009年搬到紐約後，我成了一名技術救援人員，試圖幫助拯救那些技術落後於時代的老媒體公司，讓他們迎頭趕上新技術。
現在我正在爲我曾經合作過的最大的集團公司工作。它擁有11000名員工，旗下有180家公司在運營。這是一家你們大多數人可能都認識的著名公司，你們中的許多人可能還是它的客戶。在本文中，我將它稱爲“SuperRentalCorp”。
關於“初創企業很敏捷，而大公司就像轉個身都困難的恐龍一樣難以成事”這一主題的文章，已經比比皆是。許多商業作家甚至寫了一些有趣的書，來介紹大公司如何重組以使其更加敏捷。例如，埃裏克·里斯在他的書《創業之路》中提出過一些有趣的想法。
但拯救一家大公司的技術是如此困難，原因何在呢？
在SuperRentalCorp發生的一些問題就是一個很好的例子。
當我最初被告知這家公司需要幫助時，是這樣的情形。我的一個給這家公司做諮詢工作的朋友這樣對我說：“嘿，這家公司需要幫助構建一個API。你知道如何構建API嗎？你能幫他們嗎？”他告訴我，這家公司嘗試構建這個API已經兩年了，但到目前爲止他們還在失敗。
我心裏想，“用兩年的時間來構建一個API，並且還失敗了！看在上帝的份上，現在都已經是2019年了，有幾百萬個工具可以用來輕鬆構建API。他們怎麼可能認爲這很困難呢？一個好的工程師可以在一天內把這件事解決掉。他們爲什麼苦苦掙扎這麼久？”
但是我最初的想法是基於這樣的一種場景假設：你只有一個數據庫，而你想要做的只是將API置於你的數據庫和外部世界之間。這是我在早期初創公司工作時的常見場景。如果使用一個新建的Ruby on Rails項目，說正經的，你可以在一個小時內構建出這種API。
然而，對大公司來講，有兩個大問題困擾着大公司的技術救援：歷史和信任。
——我先談談歷史。
當我提到“歷史”這個詞時，我指的不是簡單地解決歷史遺留應用程序的問題，而是處理過去30或40年間不同CEO所做決定的遺留後果，因爲公司對過去每個十年時代的變化趨勢都得適應。
SuperRentalCorp成立於100多年前，當時世界大部分地區由幾個歐洲帝國統治，而大多數公司都是依託他們在西方國家內的公司來經營全球業務。但在1948年至1980年的那個時代，所有的舊帝國都解體了，取而代之的是一百多個新的國家，而這些新國家都保護着自己的獨立性。因此，SuperRentalCorp決定採用分散結構。它在大多數國家中設立了子公司，並且子公司作爲獨立公司運營。有時子公司的部分所有權被出售給他人。這意味着，當上世紀70年代末第一批大型數據庫來到時，這家公司沒有中央數據庫、中央IT部門、也沒有首席技術官或首席信息官。
不久之後，由於政治形勢似乎變得安全了一些，合併一些服務的好處變得顯而易見，因此一些子公司被合併，組建了區域性公司。例如，中東和北非有一家，歐洲有一家，北美有一家，亞洲有一家，南美有一家。通過這種結構，這家公司進入了90年代，這時它開始認真考慮通過網絡數據庫來管理它所提供的所有服務。
20世紀90年代，面對激烈的全球競爭，這家公司決定通過收購最成功的競爭對手們來實現增長。如果我告訴這些被收購的所有的品牌名字，你會認出其中的大多數，但你可能會驚訝地發現他們現在都爲一家公司所擁有。我也很驚訝，因爲我也認爲這些公司是競爭對手。但事實上他們不再是了。
然後，大約在2005年Web2.0時代的到來，導致競爭對手大量涌現，這些競爭對手提供類似於SuperRentalCorp的服務，但是他們通過使用互聯網技術，以新的方式來提供這些服務。同樣地，SuperRentalCorp收購了其中的幾家初創公司，通過吸收競爭對手來贏得競爭的勝利。許多被收購的初創公司只在單一國家，或單一的市場（如歐盟）內運營。
就在最近，這家公司的新首席執行官決定最好把公司統一起來。一些國際子公司已被全資收購，目前正在進行重組，因此它們將作爲公司內部的部門而非獨立公司運營。
作爲對公司統一的新的重點工作的一部分，SuperRentalCorp希望構建一個統一的API，以便外界認爲該公司具有內部統一的技術架構。也就是說，SuperRentalCorp希望給外界一個這樣的假象：即該公司只有一個統一的數據庫，並且與該數據庫的交互很容易。
然而，真實的情況是怎樣呢？真實的情況是：SuperRentalCorp擁有20個主要數據庫，由20個不同的團隊在至少10個不同的國家/地區運行，其中許多擁有獨立公司的運營歷史，每個團隊都保護自己的數據，部分出於安全擔憂，部分出於對有關用戶隱私的本地法律和對國際用戶數據傳輸的監管的擔憂，還有部分原因是純粹的頑固。
和任何數據庫的操作一樣，這裏有兩個需要關注的問題：讀取和寫入。數據庫讀取並不難。我們可以從20個不同的數據庫中提取（必要的）數據，將數據存儲在一個作爲緩存的集中數據庫中，並在該數據庫和外部世界之間放置一個API。數據的時效會出現一些小問題，我們必須進行實驗，以確定哪些數據是高優先級的，需要在幾秒鐘內複製過來。不太重要的數據可以每5分鐘複製一次，或者在更新時觸發一次複製操作。
所以，數據庫讀取不是那麼困難，雖然不簡單，但總是有辦法做到。
數據庫寫入操作則是另一回事了。如果倫敦的一個客戶想從我們在倫敦的子公司租用一個資源，租用請求（數據庫寫入）需要轉到中央API，這是否意味着中心API必須知道特定的寫入操作應該轉到哪個內部數據庫？同樣，寫入請求也發生在尼日利亞、德國和巴西，每個國家的寫入請求都將進入各自的數據庫。這就變成了一場噩夢——二十年前，這種思路導致了企業服務總線（ESB）體系結構的創建，但是ESB現在已經不受歡迎了，因爲它過於複雜、僵硬和笨拙。
兩年前，SuperRentalCorp決定成爲MuleSoft公司的客戶，以便MuleSoft公司幫助他們構建新的API。到目前爲止，他們已經投資了大約2500萬美元在MuleSoft公司所做的相關工作上。MuleSoft公司有一些很好的工具來構建API，但是這些工具似乎對數據讀取比對數據寫入更有幫助。也就是說，MuleSoft公司的工具對簡單的問題有幫助，但對困難的問題卻沒有效果。（既然說了這句話，我還想再補充一句，SuperRentalCorp裏有一些，他們超愛MuleSoft。）
從最佳集成架構的角度而言，我認爲唯一可以作爲長期解決方案的是類似於Jay Kreps在2013年前後寫的統一日誌架構。這個架構中，所有的寫入操作都需要進入一個集中的日誌，例如Kafka，然後各個數據庫就可以從那裏提取他們需要的內容，每個團隊都要自己決定從集中的日誌提取的內容。
但是，SuperRentalCorp有一些零售店，配有直接與特定的數據庫進行通信的POS系統，對這些零售店而言，數據寫入的路徑（直接從POS到數據庫）是以難以更改的方式硬編碼的，因此想要擁有一個單一的寫入點，SuperRentalCorp還需要花費幾年的時間。
目前，SuperRentalCorp的每個數據庫團隊都必須接受來自多個源的寫入操作。但從長遠來看，統一的日誌是一條可行之路。這意味着這20個團隊中的每一個團隊都必須對他們的流程做出重大的改變。這就解釋了爲什麼該公司花費了2年時間，投資了2500萬美元試圖構建一個API，最終卻失敗了的這一事實。
這個問題的發生部分是技術性的，部分是心理性的。每個團隊必須放棄一些權力，然後信任一個超出他們控制的流程。當公司有一個新的首席執行官時會發生什麼？如果他決定再次拆分公司呢？團隊對當前公司戰略的持久性有多信任？他們是不是應該給自己留點空間，回到過去做事的方式？…
到目前爲止，我只討論了由內部數據庫和內部流程引起的問題。從某種意義上說，與依賴那些外部供應商提供的超出了SuperRentalCorp的控制的服務相比，內部機制導致的問題都是容易解決的。
從20世紀90年代開始，出現了一種管理理念，認爲公司應該專注於其“核心競爭力”，並將其它一切外包出去。比如說，如果你是一家報紙，你不需要僱傭清潔工來保持辦公室的清潔，而是應該把清潔工作外包給一家專門從事清潔公司辦公室的公司。把精力集中在你擅長的事情上，把其它的一切交給別人去做。如果你試圖自己做每件事，那麼你就犯了“非自主發明綜合症”。儘管我已經看到了不利的一面，但在這場爭論中，有很多是我同意的。外包限制了你的靈活性，因爲你最終與外部公司建立了長期關係，但這些公司可能並不會隨着你的需求的變化而發展。雖然解僱一家清潔服務公司並僱傭另一家似乎很容易，但有些服務公司卻很難更換。
早在20世紀90年代，SuperRentalCorp就決定將其客戶忠誠度計劃的管理外包，因爲它被視爲一項財務職能，而SuperRentalCorp不是一家財務公司。他們挑選的外包公司也非常原始落後，甚至不爲其服務提供公共的API。因此，現在當SuperRentalCorp希望將其忠誠度管理系統集成到各種CRM（客戶關係管理）系統和POS系統中時，它無法做到這一點，因爲SuperRentalCorp對管理其忠誠度計劃的外包公司的技術決策沒有決定權。是的，SuperRentalCorp可以終止與這家外包公司的業務關係，開發自己的系統來管理忠誠度計劃，但他們已經正在處理大量其它的技術難題。而目前，終止與管理其忠誠度計劃的外包公司的業務關係還不能作爲一種選項。
所有這些都有助於解釋爲什麼一家大而老的公司的技術救援是如此困難，因爲它不得不持續地和它的歷史作鬥爭。
困擾着大公司技術救援的還有另外一個問題，那就是信任。擁有龐大資產的公司每天都要與內部和外部的不誠實的行爲者打交道，這不是危言聳聽，而是日常的現實。關於公司應該如何變得更敏捷的華而不實的膚淺言辭並不是很有幫助，因爲公司需要面對的是公司結構、所有權和戰略等真正的問題。儘管我很喜歡初創者社區，但是我覺得來自硅谷的太多文章描述的大公司和老公司所面臨的問題只是簡單的假設。特別是，大部分文章都認爲信任問題是庸人自擾，而並認爲是重要的和真實存在的。一些膚淺的建議傾向於“假定善意”，就好像數十億美元的公司就像維基百科一樣。
事實上，大公司一直面臨着被公司內外的貪婪所摧毀的風險。而初創企業在處理信任問題上比較容易，因爲當整個團隊只有5個人時，你們都可以直視對方的眼睛，當他們表現異常時，你可以再次檢查你的同事。而當你在180個國家擁有11000名員工時，這是不可能做到的。
在很大程度上，“敏捷”幾乎等同於“互相信任”。如果你想知道爲什麼大公司在敏捷方面有困難，部分原因是11000人不可能像5個人那樣互相信任。現實就是這樣，除非有人能想出一個神奇的法術，讓不同國家、不同文化、講不同語言的大批人彼此信任，就像他們是好朋友一樣，如果真能這樣的話，那麼初創社區的人們需要注意了，可以看出這些建議是多麼地不走心。
