在 Xapo 銀行分散實踐架構

引言

軟體架構在建構軟體系統實務中的角色長期以來一直備受爭議。在大多數組織中，你會發現某種形式的「架構」功能，通常以「企業架構」為名。這通常是一個集中式團隊，其有效且善意的目標是確保所有建構的軟體都符合產業和公司標準、使用適合問題的模式和技術、針對問題空間進行最佳化、依需要擴充，並避免任何不必要的重複。的確，在任何領域和任何有意義的規模中建構任何有價值的軟體時，都必須考量所有這些面向。

通常，此架構功能會承擔所有系統變更的架構設計工作，通常（但並非總是）與最終會實作解決方案的開發團隊隔離。這些設計一旦完成，就會交給開發人員實作。這是許多組織數十年來的運作方式。那麼問題在哪裡？讓我們列出一些

• 集中式控制將知識保留在組成架構功能的人員腦中，這會讓實作團隊免除相同的責任。這會扼殺創意思考和好奇心，以及回應正在執行的系統的傾向。對於實際建置團隊來說，架構從字面上來說是「別人的問題」；
• 因此，建立架構設計的團隊可能遠離實作前線，而且可能無法承認與特定網域相關的真正挑戰。他們也不會接觸到設計在包含生態系統中執行的無法預見（且無法預測）的後果；
• 這會導致開發人員和架構師之間出現長期的回饋迴路，導致遞送延遲，而且經常出現不充分或不適當的架構和設計；
• 最終，架構功能會變成瓶頸，因為他們必須管理架構變更，並從整個組織的無數結果中學習，因此會有很長的佇列時間。

當你將 2020 年全球疫情納入考量（以及系統現在越來越分散且持續且漸進地演進）時，這些挑戰會倍增。採用更遠距且更彈性的工作方式的組織數量大幅增加。傳統面對面的協作論壇（知識保留在少數個人手中）瓦解了。對決策背後理由的理解消失了，集體知識中出現了差距，而且結果通常是軟體設計不良，甚至延誤更久。

當然，這些挑戰在疫情之前就已經存在，然而，我們最近在人們工作方式上看到的全面性變革，已經清楚地突顯出舊式集中式軟體架構思考方式的缺陷。

Xapo 一直以分散且完全遠距的方式工作，但當疫情來襲時，他們加倍分散，但目標是不影響架構品質、對變更的回應能力或概念完整性。

一些歷史背景…

Xapo 成立於 2014 年，最初提供比特幣服務，包括託管錢包、交易、付款和冷儲存服務，對象為零售和機構客戶，成為全球最大、最受信賴的比特幣保管機構。2018 年，Xapo 秉持「保護您的畢生積蓄」的使命，著手成為一家完全取得執照和受監管的銀行和 VASP（虛擬資產服務提供商），並在直布羅陀金融服務委員會 (GFSC) 的監督下，善用其在直布羅陀的據點。這種策略轉變讓 Xapo 能夠在完全受監管的環境中提供傳統銀行服務，包括美元簽帳金融卡，以及比特幣服務。2020 年，Xapo 獲得銀行和 VASP 執照，並開始著手建立新的 Xapo 銀行。

Xapo 從電子貨幣轉型為完整的銀行和 VASP 商業模式時，現有的 Xapo 軟體資產大部分得以重新利用。不過，正如您所預期的，自 Xapo 成立以來的六年來，技術負債、緊密耦合和服務的低凝聚力對交付和變更速度產生了顯著的阻力。變更通常會影響多個團隊，並跨越多個功能和子網域界線。更具挑戰性的是，Xapo 人員分佈在 40 多個國家和 25 個以上時區！

團隊以職能部門（產品、設計、架構、工程、品質保證等）為組織架構，工作以相當瀑布式的方式在這些部門之間流動。排隊和漫長的等待時間很常見，尤其是因為小型集中式架構團隊需要參與、檢閱和核准所有設計，這種情況就更加明顯。

經驗豐富且才華洋溢的工程師正在創造新穎且高品質的軟體 - 很明顯，此處的挑戰與他們的技能或努力無關。流程和組織已發展為努力做正確的事並確保持續品質，然而，無意間該系統和相關控制現在正在減緩進度。Xapo 如何才能創建一個組織和系統，讓個別貢獻者發揮其全部潛力，改善流程並減少摩擦，同時維護甚至改進我們的軟體和架構？

最後，值得注意的是，以前曾有定期召集 Xapo 集體智慧以制定架構決策的努力。名為「雅典娜神廟」，它允許工程師提出、討論並決定架構和設計問題。雖然最初出席率很高，但它卻陷入困境。討論變得越來越冗長，無法達成結論，因此，很少做出進展所需的決策，或者如果做出了決策，則會在隨後的討論中被推翻。

奠定基礎

很明顯，需要採取措施來減少開發工作流程中的摩擦。此外，為了減少排隊和交接，團隊能夠獨立自主地行動（儘可能）的能力成為關鍵的成功因素。

Xapo 所做的第一件事就是開始從業務領域的角度思考我們的軟體，而不是透過技術功能的觀點。Noush 和她的團隊知道領域驅動設計最終是前進的方向，但她從事一項粗略的評估開始，評估軟體如何融入廣泛的業務子領域（支付、卡片、銀行業務、合規等），並且我們大量依賴 Matthew Skelton 和 Manuel Pais 的團隊拓撲工作來創建真正跨職能的團隊。在幾個月內與產品和營運部門的同事合作，Noush 和她的團隊將整個交付組織轉移到與業務相符的串流對齊團隊 (SAT)。

同時，Noush 旨在大幅改善我們的開發人員體驗；以前集中化的運作和嚴格的控制使得創建或變更服務、變更組態或在不需要申請單的情況下執行任何操作都令人沮喪且困難。為了快速行動，Xapo 工程需要優化我們的流程和工具，以實現團隊自主性和在整個生命週期中完全擁有服務。Xapo 更改了平台團隊的任務以與此保持一致，並開始認真地改進基礎架構和工具以支援它。

在這個階段，Noush 聘請了 Thoughtworks。聘請有經驗的專業人士，來協助整個組織進行這種轉型變革，其目的是為了加速變革，同時支援我們的工程和產品人員，並幫助他們以安全的方式瞭解這些新原則。

我們共同為工程奠定了基礎，定義了我們的核心工程原則 - 主要重點是建立針對團隊自主性和減少交接而最佳化的軟體，並將 DDD 社交化為一個主要的組織概念。在這個過程中，我們延續了從 SAT 轉移開始的工作，更詳細地思考我們的受限情境，並讓它們與團隊日益緊密地結合，為我們的路線圖提供資訊，並逐步改善我們的基礎架構。

這些基礎意味著我們知道要去哪裡，以及大致如何到達那裡，但作為一個完全遠程、快速成長、逐步變化的組織，如何做到這一點是下一個挑戰。

作為一個組織，Xapo 需要做得更好，才能以更加非同步的方式工作。全球化和完全遠程會帶來許多挑戰，而這些挑戰在位於幾個合併辦公室地點的組織中並不存在。我們如何確保所有團隊成員共享相同的整體目標和理解？我們如何管理時間，以便工程師能夠以最適合自己的方式最佳化他們的工作日？我們應如何支援新團隊成員的入職，並幫助他們瞭解我們所做的架構決策的背景、理由和限制？與 Thoughtworks 技術原則 Andrew Harmel-Law 合作，並大量依賴他的部落格文章，我們旨在對我們的架構實施一種分散、對話和諮詢的方法，讓團隊能夠獨立做出決策，同時確保尋求主要利益相關者和專家的建議。Xapo 的架構諮詢論壇 (AAF) 因此而誕生。一家以分散式金融存取原則為基礎的公司選擇以這種方式管理架構，完全分散且不需要中央核准權限，這多少有些恰當。

運作方式

我們遵循的方法由 Andrew 的部落格文章中說明：“以對話方式擴展架構實務”。與所有採用此方法的案例一樣，Xapo 組織、人員、軟體、業務目標和文化特質的具體事項，在事情的運作方式中都扮演了關鍵角色。

有三個關鍵因素值得注意：首先，Xapo 是一家已轉型的公司，而且處於重大全球擴展的早期階段。其次，Xapiens 的據點遍布各地。Xapo 是一家真正的全球性公司，因此，預設的通訊模式為非同步和書面形式。第三，這個全球人才庫表示 Xapiens 是擁有豐富經驗的聰明人，並能提供許多意見/建議。有些人曾指出，這在過去曾阻礙了決策的進度。

我們最初將推出的重點放在三個關鍵領域：架構建議流程、ADR（架構決策記錄）和 AAF。我們同時啟動了所有這些核心元素，並在一個介紹架構建議流程的會議中成立 AAF。我們事先準備了一些回顧性的 ADR。這些 ADR 非常豐富且充實，涵蓋了最近做出的重大決策，將某些關鍵服務移轉給第三方供應商。這是所有與會者至少會部分感興趣的事項。

我們精心策劃了 AAF 的受邀名單：所有團隊的意見都納入了考量，架構、資訊安全、基礎架構、產品、交付、法規、營運、財務甚至執行長也都在其中。說明重點的常設議程也很重要。除了 AAF 的標準活動，例如檢視尖峰後續的實際 ADR之外，我們還增加了以下時段

• 團隊耦合問題（產品和交付在此特別重要 - 如上所述，Xapo 已啟動由團隊拓撲驅動的重新組織，以配合 Thoughtworks 參與時的流程），
• 四個關鍵指標（如DORA DevOps 狀態報告和書籍“加速”中所述[1]，
• 雲端支出

在進行幾次 AAF 迭代後，我們增加了另一個時段，討論 ADR 的進度。我們不僅想了解決策的制定速度，還想了解這些決策進入程式碼並投入生產的速度。因此，我們在標準設定中增加了另一個 ADR 狀態：“已採用”，表示 ADR 已實施並在生產環境中執行。我們將在下面更詳細地討論這一點。

在此提供有關 Xapo AAF 一般面向的幾點說明。作為「非同步優先」公司，Noush 持續挑戰 Andrew，以最大化實作的非同步性。Andrew 最初反對這點，因為他看到對話對所有人都有價值，不只對直接參與對話的人。他大可不必擔心。面對面的元素（每週 AAF 會議）從原本的一小時縮減為一半，但維持相同的節奏。AAF 的參與人數總是很多，對話也專注且有價值。事前工作（分享正在進行的 Spike 和建議的 ADR，以便及早提供建議）和事後工作（加入 AAF 中深入面對面對話中提出的建議）都勤奮地完成，而 ADR 的書面記錄（包括極有價值的建議部分）也迅速成為一大資源。在 Andrew 離開後接手執行這個流程的 Xapo 架構師具備技術寫作背景、極佳的組織能力和極佳的注重細節能力，這一點也有幫助。

我們一開始為什麼不納入架構原則、技術雷達（甚至 CFR）？簡短的答案是「它們不緊急」。Xapo 工程部門已經有書面原則，但更重要的是，它們已經存在於 Xapien 開發團隊的腦海中。然而，這並不表示我們在建議過程中遇到挑戰和這些隱含原則的潛在強化時會置之不理。

雷達也是後來才加入的，因為自我管理開始越來越深入地嵌入到不斷成長且越來越分散的團隊中，而潛在有價值的差異和“受限購買”的實例也變得明顯。在那之前，技術領域一直非常專注（特別是對於一家前新創公司來說）：當意識到某樣東西有用時，Xapien 會採用它、評估它，然後開始使用它。

ADR 也經歷了有趣的演變。我們利用上述 Xapien 架構師強大的資訊管理技能，迅速從基於 wiki 的 ADR 儲存庫（Confluence）轉移到基於票證系統的儲存庫（Jira）。為什麼？我們已經提到強烈希望改善決策的處理量，一直到實作和部署。將 Jira 作為我們的 ADR 首頁，讓我們可以將「狀態」欄位及其各種值之間的轉換變成一個資料點。每當開啟新的 ADR 票證時，我們都會產生自動時間戳記，並將狀態設定為「草稿」。在 AAF 中，唯一的需求是設定「建議」狀態，並新增另一個時間戳記。（這樣也讓議程更容易制定，我們在頁面範本中有一個固定的「建議中的所有事項」查詢）。稍後轉移到「已接受」的狀態也有其時間戳記，而當我們新增上述「已採用」的狀態時，表示決策已經編碼並在 PROD 中執行。透過轉移到這個工具，我們並沒有從團隊中拿走任何東西，我們仍然有一個票證範本，讓關鍵的 ADR 部分不言而喻，同時不會遺失任何豐富的文字元素。我們也消除了在狀態變更時記得更新時間戳記的需求。最重要的是，我們仍然駐留在開發人員每天使用的工具中。最重要的是，我們讓自己具備執行各種查詢和繪製各種圖表的能耐，讓我們深入了解事情的進度。

我們在這額外資料中尋找什麼？建立的 ADR 數量是一個有趣的數據點，但關鍵在於從「草稿」到「採用」所花費的時間，無論是總計或個別步驟。與 DORA 四個關鍵指標一樣，「決策前置時間」證明是流程和系統健全性的可靠指標。所有這些數據點都與團隊分享，讓他們能夠逐步改善和自我修正，提出諸如「為什麼這份文件在草稿/提案/接受階段停留這麼久？」等問題。

轉移到 Jira 還有一個好處：它與 Slack 等通訊系統的簡單整合更豐富且更專注，符合 Xapo 的非同步文化。新的 ADR 可以由 Slackbot 自動公告。狀態變更也可以用相同方式處理。這些都不需要手動，而且我們可以免費獲得透明度。不僅如此，透過將實作故事與 ADR 票證關聯，我們可以開始查看與 ADR 及其狀態相關的工作。這對於跨團隊 ADR 來說特別方便，例如在許多核心系統中放入改進的追蹤路由。

已實現的效益

很明顯，AAF/ADR 方法從早期開始就在 Xapo 發揮了很好的作用，而且隨著各種元素被塑造成符合 Xapo 文化，效益不斷累積。我們已經提到了這種方法帶來的幾項好處，但還有哪些其他好處實現了？

雖然不屬於這種方法的一部分，但跨功能需求 (CFR) 和技術策略逐漸浮出檯面。前者自然而然地隨著 ADR 的提出而產生，並在發生時被明確捕捉。它們變得明確的事實讓關鍵的 AAF 代表可以在相關點提出他們的需求，因為這些需求逐漸浮現。例如，法規代表及其在產品組織中的代表能夠在技術論壇中明確說明合規觀點的確切需求。

技術策略的重點也出現了。Noush 作為大多數 AAF 的 CTO 出席，可以分享她對整體技術方向的想法，以及她所承受的限制。然後可以在特定決策的背景下討論這些內容，這表示它們不僅與整體策略保持一致，而且策略可以在團隊的日常現實中接受嚴格的壓力測試。不僅如此，透過接觸並鼓勵參與此類討論，一般策略也變得廣為人知。

團隊的經驗以及與原則的一致性也經過壓力測試。我們已經強調了團隊及其 ADR 與核心原則遭遇的最顯著範例，但這一次又一次以較小的方式發生。與策略一樣，團隊參與這些對話，不僅可以對原則在現實中的形成方式提供隱含的回饋，還可以提出變更建議。因此，與會者可以了解整個組織對這些原則的一致性，不僅是抽象的，還包括在軟體交付方面；這是一個有價值的數據點。

AAF 的這種一般「意義建構」能力在更一般的方式中也很強大。前面提到的擴展工作的關鍵方面是轉換為明確的領域驅動架構。隨著工作的進展，逐週進行，領域語言的流行度顯著增加。雖然最初並不總是不同的，也不符合有界限的背景，但它與特定 ADR 相關的事實意味著可以針對實際問題提供有關關鍵 DDD 方法的建議。這加速了對這些各種模式的理解，但也提升了工程團隊對領域驅動設計的深入理解，開啟了一個良性循環，即注意領域語言，注意它何時對耦合和其他關鍵設計問題提供見解（例如，當很明顯兩個團隊以微妙的不同方式談論相同的領域概念，或者他們似乎都傾向於實作服務，而其中只有一個團隊應該實作，而另一個團隊委派給），利用這一點在討論這些設計問題時達到目的，然後部署它們來解決這些問題，從而改善個別團隊和整體速度。

AAF 的導入並不表示組織中不再需要建築師。事實上，我們的小團隊仍然像以往一樣忙碌，提供建議、支援 AAF，並將時間專注於對 Xapo 產生重大影響的高影響力專案。賦予我們的團隊權力，並讓這些領域的專家在更接近程式碼庫的地方做出決策，對產生實際變更所需的時間產生了重大影響。過去需要數週（或數月！）的設計和決策，現在可以在幾天內完成，並記錄完善、為所有人所理解，並構成我們技術社群的集體智慧的一部分。架構現在是一項集體責任，任何人都可以在我們的指導原則下分享想法或挑戰方法。

經驗教訓

如果我們給人一種印象，認為採用這套相互連結的實務、工具、方法和心態很容易或沒有挑戰，那我們就是失職了。核心在於需要轉換到一個新的「常識」系統，而這是一種內部、個人和團體層級的變革。

最明顯的跡象在於，共識的舒適感是一件很難放下的事情。你會記得，架構建議流程只有一個規則：「任何人可以做出架構決策」，而且不需要達成協議，也不需要尋求更高權力的核准。儘管如此，即使是有意識的心靈屈服於這個想法，在一次又一次的 AAF 會議中，仍然會聽到「所以，我們都同意嗎？」這句話，當討論結束時，這句話就會脫口而出。雖然這是一個信號，表示轉換到新的心態尚未完成，但表達出這個無意識的需求，確實讓我們能夠提醒與會者，共識並非必要，可以在沒有共識的情況下做出決策並採取行動。

另一個信號以追求與原則相符的「完美」（不妥協）解決方案的形式出現。雖然這種情況發生的頻率低得多，但最初很明顯，那些在決策制定方面經驗較少的人認為，那些曾經擁有這些責任的人，也就是「建築師」，可能就像聖人一樣有智慧，並且能夠找到通往所有世界的最佳途徑。明確關注權衡取捨，以及建築師對此提供的建議，逐漸消除了這種心態，當這些建議開始在 ADR 中明確記錄下來時，就達到了真正的解決方案。將這一點公開意味著，所有相關人員都可以理解，這種妥協不僅是可以接受的，而且是不可避免的。例如，人們認識到，在優化 Xapos 服務以實現團隊自主性的過程中，工作會重複進行。這是一件壞事嗎？不一定。協調和同步經常會比消除重複所帶來的效益產生更大的開銷。討論帶到最前線的是，一般人了解到，在某些情況下，重複可能會導致不連貫的使用者體驗。在這種情況下，好處明顯大於調整工作的缺點。在最前面考慮到這一點，並作為一個集體，在做出妥協時，對於將重點放在何處有很大的幫助。

決策也受益於始終以業務決策為依據。許多時候，決定某個選項是否為「最佳」的關鍵因素取決於產品或業務策略。在 AAF 中納入產品代表，表示他們擁有所有可供參考的背景資訊，以便做出架構決策，並能據此分享建議。一個很好的例子是，無論行動應用程式在哪裡使用、由誰使用，最重要的是不論平台為何，都要有單一、通用的使用者體驗，這項基礎產品和設計決策就是一個很好的例子。為了確保 iOS 和 Android 體驗在各方面都保持一致，需要付出許多努力，而且如果沒有這項產品指導，這將會造成大量的努力浪費。然而，由於這項決策對於整個產品精神和體驗至關重要，因此是不可或缺的。有了這項認知，團隊可以非常快速地做出多項策略性決策，而且所有人都知道原因，這是一個有益的副作用。

同時也值得指出這種定期同步追蹤的更一般性好處。決策不僅能有效收集所需的建議意見，而且（更重要的是）所有與會人員，無論決策是否與他們相關，都能接觸到 Xapo 業務和集體推理過程的具體內容。在非同步地回到工作崗位時，這項好處非常明顯，而且團隊更能了解 Xapo 每週開拓的道路的細節和細微差別。這項好處至關重要，因為沒有指導和方向的團隊自主性會導致混亂。建議流程（包括責任）等限制有助於讓 Xapo 獲得自由，並減少我們的工程師需要思考的龐雜事務。花時間深入思考 Xapo 的技術支柱和原則也是一項關鍵的成功因素。透過這項普遍的調整和共同的理解，以及透過簡短的 AAF 每週加強和更新，所有團隊都能在他們的專注時間內提供價值，這項能力令人印象深刻。

這些高價值、高影響力的每週會議還有另一個好處：它們讓人們可以安全地改變想法，偶爾也可以出錯或失敗。從首席技術長以下的所有人都會以身作則。例如，隨著團隊共同深入了解領域驅動設計 (DDD) 的工具，並看到 Xapo 的軟體如何體現許多 DDD 模式，就有必要將服務重新分配給不同的團隊，或將它們重構以與更合適的團隊及其邊界脈絡保持一致。這並不是說在團隊拓撲轉型開始時進行的第一次團隊拆分距離理想狀態還很遙遠，但它可以逐步改善。[2]首席技術長是最初做出這些團隊決策，並將軟體分配給他們的決策者。透過重構這些責任界線，並根據 ADR 所產生的見解進行部分驅動，人們親眼看到設計，包括組織設計，不需要第一次就正確無誤。

為了讓這一切順利運作，顯然一致且定期管理 ADR 積壓事項和定義明確的 ADR 所有權非常重要。此外，在技術內外行銷完整方法的好處，讓大家可以將其放在心上並看到好處。由於 Xapo 的非同步和全球性質，因此決定專門指派一位全職人員負責推動跨工程及其他領域的協作，以確保這件事發生。

當重新檢視各種 ADR 時，發生了這個有益的例子。所有決策都是在某個時間點做出的，並且應該盡可能捕捉該脈絡的具體資訊。當很明顯這個決策脈絡將在未來的某個時間點發生可預測的變化時，可以安排重新評估。當非策略性託管決策被做出時，這件事發生在 Xapo，因為這是當時唯一可行的選項。一段固定時間後，重新檢視了這個決策，並進行了後續的 ADR，以將事情恢復正常並遷移到策略性雲端供應商。

在結束本節之前，我們必須強調一個關鍵事實：AAF 和架構建議流程從未孤立存在。在 Xapo，事先奠定的基礎具有顯著的正面影響，現有的 Xapien 文化的優勢也是如此。團隊明顯受益於轉移到團隊拓撲樣式的組織結構、同時專注於產品思維、持續交付基礎設施和 DORA 四個關鍵指標提供的資料。從功能性團隊轉移到串流對齊團隊 (SAT) 模型在紙面上看起來很簡單。實際上，這對任何組織來說都是一個重大的改變，重要的是 Noush 和他的團隊花時間和空間讓它穩定下來並開始順利運作。

在 Thoughtworks 離開後，Noush 和 Kamil 在 Xapo 採用 AAF 時學到的關鍵教訓是，它需要持續的照護和關注。單獨建立一個論壇或結構不足以確保其持續成功。相反，它需要定期評估和支援，以維持其動能和影響力。這表示我們必須鼓勵參與、提供資源和指導、解決產生的任何問題，並適應不斷變化的環境。只有持續培養和改善我們的做法和成果，我們才能確保它對 Xapo 在長期內保持有效和有價值。

下一步是什麼？

AAF 和建議流程無疑為 Xapo 帶來了許多好處。然而，我們工程團隊不能讓自己自滿，我們正在尋找可以持續改進的方法。這是持續改善軟體開發實務和文化的機會，在出版時有幾個機會正在考慮中。

Kamil 正在尋求形式化一個內部開源模型，讓團隊可以在有界限的背景下做出貢獻。這將使開發人員能夠跨團隊分享程式碼和最佳實務，減少重複的工作，並提供絕佳的知識分享機會。透過利用開發人員的集體知識和專業知識，我們可以加速創新，進一步提升程式碼品質，並減少排隊和摩擦。

Kamil 和團隊也認知到持續改善和反覆運算開發人員體驗 (DevX) 和工具的重要性。透過投資於簡化開發和減少摩擦的工具和流程，Xapo 可以讓我們的開發人員工作得更有效率且更有效。

整個 Xapo 工程團隊將持續開發和改善我們的技術原則，以確保它們與不斷變化的業務目標和優先事項保持一致。透過定期檢視和更新我們的原則，我們可以確保它們保持相關性，並為我們的開發工作提供指導。

每個人都將 AAF 的實作視為我們持續改善軟體開發實務和文化的旅程的開端。透過追求這些計畫，開發人員可以更具協作性地工作、嘗試新想法、更有效率地工作，並做出更明智的決策。這最終將有助於更快速地交付更好的軟體，並支援我們更廣泛的業務目標。