以對話方式擴展架構實務

當「傳統」架構方法失效時

坦白說，「傳統」軟體架構方法（即非編碼、決策制定、繪製圖表）對我來說很難在最佳時機發揮作用。但在我使用它們在持續交付自主團隊的世界中時，我發現自己一再面臨一項不可能的任務：無所不在，容忍顯著的脈絡差異，且不阻擋任何人。

這讓我想。是否有替代方案？

有：我停止做出架構決策。完全停止。

在本文中，我將介紹這種替代思維模式和相關的工具和實務，這些工具和實務使我能夠顛覆「軟體架構師」的傳統角色，同時將軟體架構的實務帶到開發團隊中。更重要的是，我將解釋在這種替代方法中，每個人都可以安全有效地執行他們需要的架構，而不會陷入混亂。 [1]

我們需要更多「執行」架構的方法，而不是更少。

在我看來，軟體交付朝向團隊自主權不斷提升的趨勢，增加了對更多架構思考的需求，並結合了架構決策制定中的替代方法。

確保我們的軟體團隊體驗真正的自主權會引發一個關鍵問題：一小群架構師如何才能滿足大量飢餓、與價值流一致的團隊？為什麼？因為在這種環境中，架構師[2]現在需要同時在更多地方執行所有傳統「架構」。

我們需要一種可行的方法來應對團隊自主權的人性化規模挑戰，以及由此產生的架構。

在本文的其餘部分，我將介紹一種執行和管理架構的替代方法。我將詳細說明它是什麼、如何運作，以及您如何自行採用它。最重要的是，我將重點說明如何失敗，以便您取得成功。

最基本的元素：透過「建議程序」進行決策

讓我們以一個我們旨在使其最大程度獨立的團隊作為起點。顯然，這個團隊需要以某種方式參與架構思考和決策制定，但如何做呢？

這些「許多決策中心」正是我們所需要的，但很明顯，傳統的由一群擁有所有權力的架構師做出所有決策的自上而下架構與這種分散式模型相悖。「然而」，挑戰被提出，「決策仍然需要做出，這就是架構」，這些懷疑論者是對的。

這些架構決策仍然必須經過深思熟慮地做出，否則我們將回到原點，甚至更糟。因此，這種替代方法的第一個方面，實際上是它的核心要素，必須描述它如何做出決策。它被稱為「建議流程」。

建議流程是這種無政府主義、分散式架構方法的核心要素。它最大的優點是它的極度簡潔。它包含一個規則和一個限定詞

就這樣。這就是建議流程的全部內容。

然而，這種明顯的直截了當隱藏了一個值得明確表達的概念；雖然決策者絕不義務同意這兩組諮詢小組給予他們的建議，但他們必須尋求建議，並且必須聽取和記錄建議。我們在此不尋求共識，但我們正在尋求廣泛的意見和聲音。

針對此議題，經常提出的挑戰在於必須諮詢多少人。這是一個有效的疑慮，但可以緩解。在部署此技術時，我們會建立一份檢查清單，協助決策者找出需要諮詢的人員，以及諮詢的範圍。會影響資訊安全嗎？與 CISO 討論。接近個人身分資訊嗎？請資料團隊的 Mary 和法律團隊的 Vanessa 參與。使用者註冊流程可能會變更嗎？與 UX 主管討論。即將採用新的雲端服務嗎？與雲端架構師 Kris 討論。考慮變更 API 嗎？與所有使用者團隊的主管討論。

有時，此諮詢名單可能會很長。這沒關係。有些決策規模較大，而建議範圍清楚顯示規模和重要性。有時可以縮小決策範圍，因此許多決策會這麼做。其他時候，受影響的人數眾多，會讓決策者三思。這件事可能讓他們的作業稍微輕鬆一點，但真的值得諮詢所有那些人嗎？或者，他們可以將這個大型決策拆分成多個較小的決策嗎？當決策進行時，通常會純粹基於權宜考量而調整規模。[3]

我們可以進一步推動建議程序嗎？是的，我們可以，而且我們應該這麼做。我總是鼓勵遵循建議程序的人特別找尋會反對他們的人。在無需同意所聽到的意見的壓力下，他們必然會更認真地參與。因此，所收到的建議深度和廣度會更大。決策也不會因此而受損。他們的學習也不會受損。

這讓我們進一步探討建議程序的優點。在部署建議程序時，我總是看到更好、更快速、更負責任的決策，最重要的是，這些決策是由執行者理解和擁有的，原因在於決策者既有需求，也負有責任。

作為副作用，可用決策者的池子也會成長，每個人很快就會開始尋找需要做出的決策，而且，由於諮詢流程給予他們權力安全感，因此會標記它們並推動它們達成結論。團隊對決策的需求可以由他們自己滿足的事實，也會導致適當程度的行動偏見，而問責制在需要時會作為煞車。

透過這種方式工作，我們消除了對固定且永久的階層結構和遵守大師決策者的需求。由於這兩個原因，諮詢流程是這種架構方法中最基本的元素，因為分散式決策制定是任何自稱為「無政府主義」事物的核心元素。

但是等等，我們是否一下子就消除了對我們「傳統」架構師的所有需求？完全沒有，但很明顯我們的角色已經改變了。在本文的以下各節中，將介紹這種方法的支援元素，我們將看到一組重新調整的實務和工具，讓我們能夠讓團隊和他們支持的業務達到他們需要的地方。

在我們繼續討論這些支援元素之前，先花點時間來強調並討論這分散式方法中所有其他元素共有的唯一事項，以及與核心元素共通之處：它們專注於對話，以及它在有效達成並傳播共識中所扮演的角色。

四個支援元素

這通常在實務中如何運作

考量到這一切，您如何看待實際運作的狀況？讓我們來看看…

當架構決策的需求首次出現時，它很可能很模糊，而且可能理解不佳。因此，最好立即開啟新的 ADR 範本，並開始嘗試填寫。

首先要處理的是「脈絡」區段。要嘗試處理這個區段，我們需要了解我們決策的「原因」，以及我們需要平衡的周遭力量。我們可能會很快意識到，我們需要做一些研究才能完成這個簡短的區段。

本研究的早期停靠港口應為架構原則和雷達。您會記得，這些原則讓我們了解理想解決方案理想上將展現的旅行方向。並非所有原則都相關，但有些原則應有助於我們的決策。請記得，架構原則的主要目標是協助評估多種技術可能性，並強調最合適的可能性。

有時，經驗會有些不同。其中一種替代方案是，相關原則無法協助您在兩個選項之間做出選擇，表示兩者之間幾乎沒有差異，或者您的原則可能不夠 S.M.A.R.T。這是重新檢視原則並重新定義原則的充分理由。

另一種替代方案也可能以重新評估的一組原則告終，或許稍晚一些。當您為了做出決定而傾向於違反一個或多個原則時，就會出現這些原則。這沒關係；良好的決定可以違背原則，但為此您需要清楚說明為何採取此行動方針是正確的步驟。推翻原則是一個重要的步驟，因為這表示我們實際上偏離了旅行的一般方向。因此，必須清楚論證並有力地證明決策和產生的 ADR。這也可能表示根據此發展重新檢視原則的時候到了。

相較之下，雷達的性質更具諮詢性。它將提供一個概念，說明在我們的問題空間中，什麼（如果有）是現行的實際標準、過去已完成的事項，以及其他團隊可能正在嘗試的事項。採取不同的方式不太可能引起關注，但這再次是說明 ADR 中偏差的明確理由。

考慮到所有這些，我們可以開始提出關鍵標準，以評估選項，以及替代方案清單。或許我們已了解到我們真的需要做一些功課，在這種情況下，我們可能會衍生一個時間限制的 Spike，以進一步了解某事。我們的 ADR 思考將有助於在此撰寫超清楚的驗收標準。如果我們不需要執行 Spike，我們將考慮尋求建議。

從脈絡中獲得這些輸入（例如，技術策略、適用原則、雷達脈衝和主要標準/替代方案）將反過來幫助我們思考向誰尋求建議。根據我的經驗，當你對問題空間/需求有相當的信心時，參與其中是有幫助的，但在你過於依附於特定解決方案之前。當你尋求建議時，花費大部分時間和精力與那些與你意見相左的人交談；那些你知道想法不同的人，你知道你會有盲點。不僅如此，還要挑戰自己。考慮“這個替代方案有什麼不好？它的缺點是什麼？”花費大部分時間思考最直接和最根本挑戰你決策的替代方案。

在進行討論之前，準備好粗略形式的 ADR，並提前與他們分享，這會有幫助。這將給他們思考時間。然後，當你見面時，仔細查看 ADR 範本的每個元素。你是否錯過了脈絡中的某些內容？來自原則/脈衝？來自評估標準？徵求並收集他們對所有這些事情的建議。更重要的是，詢問他們為什麼提出這些建議。這些問題的答案是學習做出更好架構決策的關鍵。你的顧問將幫助你了解他們如何看待問題，他們過去遇到過哪些類似問題，甚至是你根本沒有想到的整個方面。 [7]

AAF 呢？那不是收集建議的地方嗎？是的，我在上面分享的所有內容都應該指導你在任何地方進行對話，但對於團隊或個人做出的前幾個決定，真的很有幫助，讓這些決定以更具針對性的方式與關鍵顧問一起做出。你在 AAF 之前提出的 ADR 將非常紮實且專注，然後再廣泛分享，這意味著產生的 AAF 對話將會更豐富、更專注。有時，在 AAF 中進行快速對話將導致後續更深入的 1 對 1 對話。

請記住，一旦你有了建議，無論來自何處，你都必須將其納入你的 ADR。你不需要採納給出的建議，但你必須記錄下來。這裡一個很好的做法是優先處理你寫作中人們會覺得不直觀或驚訝的事情。如果你不同意關鍵建議，請說明原因和理由。如果你正在做一些新的事情，請清楚說明當前的方式為何對你不起作用。請記住使用原則。有時它們會支持你的決定。清楚說明如何。有時你必須違反它們。清楚說明原因。你的目標是讓讀者了解你為何做出你所做的決定。如果你達到了這個目標，那麼你將不僅有一個穩固的決定，而且你很可能在這個過程中學到了很多東西。 [8]

在我結束本節之前，請記住，所有決定都是時間點，而且沒有人可以預見每種可能性，但你希望能夠在稍後回顧並對一個決定感到滿意，因為你當時知道/理解了什麼。在其中，你捕捉到的背景和標準是關鍵。這種重新審視決定的過程是另一個很好的學習工具。有了事後的好處，你現在可以提出諸如：「我們是否充分了解背景？」和「我們對自己所知道和不知道的事情是否足夠誠實？」等問題。

如何失敗

因此，這就是我們對架構的替代、分散、無政府主義方法的全部內容，以及它們通常如何組合在一起的一個想法。但在我們得出結論之前，我們應該解決一個最後的方面——你可以失敗的主要方式。讓我們一一列舉出來。

你將看到的大多數失敗實際上都是好的失敗——當經驗較少的人做出決定時的小失敗。這些很好，因為這個過程促进了那些需要它們的人快速做出決定，更重要的是，它促进了透明度和快速识别失败（因為做出决定的人将在编码时意识到这些问题）以及重新审视和分享经验教训的安全方法。接受這些，在 AAF 中特別指出並慶祝它們。這是建立學習文化的一個關鍵方面。

要最有效地學習，你需要感到安全，當集體學習時，每個人都可以從最廣泛、最多樣化的投入中受益，這些投入有助於討論。請記住，在這種方法中，我們明確不尋求共識，但我們正在尋求廣泛的投入和聲音。正是在這裡，下一個故障模式出現了，它比第一個故障模式更陰險、更具破壞性。當你作為對話發起人和空間持有者，未能納入所有應該做出貢獻、做出決定和學習的人時，就會出現這種第二種故障模式。對於這種架構風格的早期採用階段來說，很大一部分感覺就像巨大的成功。「它有效！越來越多的人做出決定，在 ADR 中寫下它們，提供建議並在 AAF 中討論它們！我從未見過如此符合原則的參與！」只有在稍後反思時，你才會意識到收益本可以更大。正是當這種滿足感第一次襲來時，你必須最小心。你真的在觀察大眾參與和學習，還是只是一群核心嫌疑人？你積極緩解這個問題。注意誰做出了貢獻。放大聲音，確保其他人聆聽那些較安靜的貢獻者。確保影響力是平衡的，而不是基於聲譽、任期或在層級中的位置。積極鼓勵多種觀點並強調其帶來的價值，以便它能夠自我維持。

第三種失敗模式是對您遭遇前述失敗模式的早期警告，然而，這一個更存在於理想與不受歡迎之間的灰色地帶。隨著您繼續這趟旅程，您將發現偏離常軌的決策。這些決策從未在 AAF 中出現，也從未進入 ADR。有兩種方法可以處理它們。第一種正確的方法是將發現視為您所希望的 - 一個誠實的錯誤，以及一個學習和教導他人的機會。也許決策者甚至沒有意識到他們正在做一個關鍵決策。也許他們來自其他地方的壓力。也許他們認為這沒有想像中那麼重要。也許他們覺得自己會在 AAF 中被大聲斥責。無論原因為何，都將其視為他們和您學習的方式。改善流程。對待這些問題的另一種錯誤方法是退回舊方法，並重新控制。這將我們很好地帶到了完全破壞這種方法及其所有承諾的失敗模式。

很容易陷入這種第四種也是最危險的失敗模式，因此您需要持續保持警覺。觸發此模式發生的唯一事情是像您這樣的「大寫 A」架構師不信任他人；不實踐您所宣揚的；沒有為剛才提到的微小失敗和後續的學習機會騰出足夠的空間；繼續在幕後執行「影子架構」，以確保事情仍然按照您認為應該進行的方式進行，儘管來自其他地方的所有信號。這種失敗模式的唯一好處是，由於我上面列出的所有好處都無法實現，因此它會非常迅速地顯現出來。

如果您想知道是否這種關鍵失敗模式讓這種架構方法難以實現，您的想法是正確的。我過去很幸運。當我為他人做決定時，同事會叫我出來，而我發現自己對人們不知道我知道的事情感到沮喪。但後來我意識到，我作為一名建築實務者未能完成我的真正任務 - 我未能讓正確的對話在正確的時間與正確的人發生。請記住這一點（甚至可以委派其他人當您未能堅持這個流程時叫您出來），您會驚訝於成功是多麼容易（且令人滿意）。

再次說明五個元素，以及可能的進一步步驟

由於我們現在有了好處和（潛在的）壞處，以及需要留意的失敗模式集合，讓我們做個結論。我們回顧一下，我們有架構的替代方法的五個要素

一個核心要素：建議流程

四個支持要素

• 架構諮詢論壇
• 輕量級 ADR
• 團隊來源原則
• 您自己的技術雷達

希望我已經清楚地說明，儘管這些要素對您來說可能都不是新的（除了建議流程之外），但它們之間存在著非常不同的相互作用/相互強化，背景是對話、學習和安全。至少根據我的經驗，令人興奮的事實是，這更有可能提供成功部署的架構，現在和未來。這是我的擴展首選，並確保我合作的團隊兌現我們對使用者的承諾，畢竟，這是目標。

後記：下一步是什麼？

當然，雖然我試著讓這篇文章保持重點，但還是有深入探討的可能。我見過以這種方式工作的團隊自然而然地開始鋪設自己的道路，在（交付）平台團隊出現之前，就自建了自己的交付平台。（請參閱我同事 Evan Bottcher 的優秀文章 “我在談論平台時所談論的”，以及 Skelton 和 Pais 的 團隊拓撲，以取得更多詳細資訊。）

我也見過團隊實施自己的 架構適用性功能（不只是圍繞 執行成本），以便他們知道集體架構何時超出預期範圍。

我學到最大的教訓是，一旦你賦予人們權力，給他們一個成功並認可他們成功的環境，他們將會迅速而集體地開始思考你甚至沒有想到的事情。這就是這種方法的真正好處：取用多數人的集體智慧，而不是過度依賴少數人的智慧，後者受到更多限制。