原文參見本人博客：如何落地復雜系統(tǒng)的架構治理?

之前的一篇架構治理相關文章《如何度量軟件架構》在Thoughtworks洞見發(fā)布后，收到路人甲的一個評論：

復雜系統(tǒng)且持續(xù)快速迭代的系統(tǒng)的架構治理有個很大的痛點，通過方法論和標準化的工具掃描和度量出來海量問題后，沒有合理的成本可控風險可控的解決方案，只管殺不管埋，就導致無疾而終，或者就是一通治理之后引來了更大的問題。

這個評論講到了復雜系統(tǒng)架構治理的痛點和難點，值得拿來聊一聊：

1. 對于多年復雜遺留系統(tǒng)，問題是非常多的，細究起來可能是“體無完膚”，哪哪都有問題，到處都需要改，無從下手。
2. 不知如何衡量成本與收益，一但開始，不是從價值大小入手，更多的是哪些故事更好聽，哪些優(yōu)先級更高。
3. 急功近利，兩三個月就要上線。技術架構優(yōu)化通常都是底層優(yōu)化，牽一發(fā)而動全身，測試不全面，急于上線引出更大的問題，被各方指責，直接回退，后續(xù)的優(yōu)化動作被迫停止，無疾而終。

這些問題都是經歷過復雜系統(tǒng)的架構治理才能提的出來。大部分底層架構的變動技術復雜度都非常高，也正因此，落地實施的難度更大，阻力也更大，但往往最大的阻力不在于技術層面，而在于管理實施過程中。

就像前幾年非?；鸨闹信_，很多公司紛紛效仿，卻很難獲得構建中臺的實際收益，大部分只是照貓畫虎，有形而無神。究其原因，中臺的實施是對企業(yè)組織的一次再造，對業(yè)務模式的一種變革，并不單純是技術問題，如果組織問題和業(yè)務問題無法解決，中臺便無法起到實質作用。

復雜系統(tǒng)的架構治理雖不如構建中臺般大張旗鼓，但在實施上的痛點有相似性。結合上面的問題，我們重點談談兩個大的方面：

• 如何在海量問題中，結合成本與收益，設定優(yōu)先級？
• 如何實施一個復雜系統(tǒng)的架構治理活動，保證不影響業(yè)務？

業(yè)務價值導向的優(yōu)先級定義

在之前的文章軟件架構治理 之 架構優(yōu)化方向
中介紹過如何識別軟件架構中的治理優(yōu)化點。當我們找到大量的優(yōu)化的方向，能投入的成本往往是有限的，如何從眾多的方向中挑選在當前的情況下最有必要去做的優(yōu)化呢？

這時候還是要回歸到架構治理的初衷上來看，架構治理之所以有必要，在于它可以幫助組織解決業(yè)務問題。如果單純從技術維度出發(fā)，確實有很多問題也很嚴重，比如有些服務的代碼和內部設計很差，但目前的功能相對穩(wěn)定，問題不多，而且從中長期來看，并沒有可見的需求，那這個優(yōu)化的優(yōu)先級就不高。

為了讓架構治理的收益最大化，可以利用上圖中的象限將找到的架構治理優(yōu)化項進行優(yōu)先級排序。成本高低很容易通過工作量的評估來判斷，但判斷一個架構治理優(yōu)化項的價值高低相對困難，這里我們可以參考幾個維度：

• 業(yè)務重要程度：架構治理優(yōu)化項涉及核心業(yè)務場景，能夠助力組織的戰(zhàn)略目標，現在不做優(yōu)化，未來的業(yè)務擴展會被影響，則優(yōu)先級較高。
• 緊急程度：架構治理優(yōu)化項涉及的內容可能導致重大影響，是迫切需要解決的問題，優(yōu)先級會較高。比如數據庫的存儲無法長久支撐業(yè)務發(fā)展，需要盡快考慮大數據方案或更換分布式存儲方案。
• 風險高低：架構治理優(yōu)化項不處理，會有潛在的風險，包括技術風險、安全風險和業(yè)務風險，涉及高風險的優(yōu)化項需要盡快處理，優(yōu)先級較高。
• 利益相關者意見：這點很少被提及，但實際操作很難忽略，是非常關鍵的維度。核心利益相關者對系統(tǒng)的定義或者訴求，直接影響著架構治理的大方向，也就影響著優(yōu)先級，比如整個團隊的核心方向就是構建業(yè)務中臺，那么架構治理也必須圍繞這個大的戰(zhàn)略目標來做，優(yōu)先級自然也很容易定義清楚。

除了上述關鍵的維度，把哪些內容納入到架構治理的計劃中，還有很多因素需要考慮，比如資源可用程度，包括人力資源和預算資源，如果資源有限，很多成本較高的優(yōu)化項的優(yōu)先級就會被降低。因此，在實際定義優(yōu)先級過程中，要參考以上關鍵維度，也要按照項目的實際情況做適度調整。

分階段落地復雜系統(tǒng)的架構治理

在定義好優(yōu)先級之后，許多項目負責人會像做業(yè)務功能開發(fā)一樣推進架構治理，按照工作量的評估直接排計劃，例如10個人干1個月能做完，那就安排開發(fā)1個月后上線。在大部分情況下，這種方法的效果會很差，甚至會引發(fā)非常嚴重的線上事故。

這其中有幾個比較關鍵的問題：

1. 架構治理項目中業(yè)務分析師的參與度會非常低，甚至沒有業(yè)務分析師，架構師和Tech Lead會更多從技術視角來做架構的分析和拆解，對業(yè)務的影響往往評估不足。
2. 解決方案的大方向設定之后，在任務細化過程中，開發(fā)角色很難像業(yè)務分析師拆解業(yè)務功能那樣細致，并且大部分的技術實現細節(jié)隱藏在代碼中，很難分析全面，在實際開發(fā)過程中會有很多隱藏的問題暴漏出來，導致項目無法繼續(xù)推進，或者項目延期。
3. 架構治理項目有些會涉及新技術棧替換就技術棧，而開發(fā)團隊對于新技術棧的開發(fā)經驗往往比較有限，或者只有個別人非常熟練，新技術棧的開發(fā)很難保證效率和質量。

因此，落地復雜系統(tǒng)的架構治理很難借助普通業(yè)務功能開發(fā)的經驗來推進。需要分階段進行逐步細化，迭代推進，如下圖：

從實際落地效果來看，方案驗證（POC）階段和試點推進階段非常關鍵，通過這兩個階段的進一步細化，可以進一步識別架構治理涉及的技術細節(jié)和實施風險，包括新技術棧帶來的挑戰(zhàn)和坑，針對性的給出解決方案。

值得強調的是，這里的方案驗證（POC）要做的更深入，產出更多，可以結合項目的情況和開發(fā)團隊的能力進行定義。因為后面緊跟著進一步的試點和全面推進，在POC的過程中，除了驗證方案的可行性，還要進一步的產出落地的規(guī)范和開發(fā)模板。架構治理所涉及的開發(fā)工作技術難度較大，比傳統(tǒng)的業(yè)務開發(fā)涉及的技術難點更多，為避免開發(fā)人員經驗不足導致的問題，需要通過POC產出架構專項治理的開發(fā)步驟，每個步驟的規(guī)范以及驗證方式。

另外在試點和全面推進階段，一定要設計回退方案，架構治理通常是底層技術架構的調整，涉及大量業(yè)務功能，一旦有問題，影響面非常大，很難確保萬無一失，所以要設計完善的回退方案或灰度驗證方案，把影響降到最低。