Redgate是如何做出架構決策的？

架構決策“最簡單”的解決方案是讓擁有巨大大腦的人做出所有決定。這種“Megamind”方法當然有一些優勢——一個人可以快速做出決定，並且有一個人負責；缺點使這些優點相形見絀。把責任推給一個人是有風險的——人並不完美（對不起！）。

讓我們嘗試改進一下：我們可以任命一個變革顧問委員會 (CAB)。CAB 是一個具有相關領域經驗的小組，負責審查決策並提出改進建議。CAB 聽起來像是一種改進；不同的群體做出更好的決策，相關領域的專業知識必然會讓事情變得更好。不幸的是，研究表明擁有變更審批流程並不是一個好主意。

“……發現外部批准與提前期、部署頻率和恢復時間呈負相關，與變更失敗率無關。簡而言之，外部機構（例如經理或 CAB）的批准根本無法提高生產系統的穩定性，以恢復服務的時間和更改失敗率來衡量。但是，它肯定會減慢速度。事實上，這比根本沒有變更審批流程更糟糕。” （加速：妮可福斯格倫）

我們在 Redgate 的核心信念是“我們相信製作軟體的最佳方式是讓擁有明確目標、行動自由和學習動力的團隊參與進來。”。提交設計以供批准與行動自由的原則背道而馳。但是，我們也認識到，有時單個團隊可能不具備整個環境，並且區域性決策可能是區域性最優。

我們如何解決這個問題？

聖達菲潛艇的船長大衛·馬奎特已經給了我們答案。在被置於一個陌生的環境後，他形成了一種強調地方決策而不放棄控制的領導風格。基於意圖的領導賦予團隊決策權，但使用“意圖檢查”讓其他人提供洞察力。

我們已經將這種方法體現在我們如何做出架構決策中。在開始工作之前，我們要求工程師記錄他們的決定決策。把事情寫下來改進了設計（畢竟，如果你不能把它寫下來，你到底要如何實現它），但它也為那些有不同觀點的人提供了一個意圖檢查。

我們的方法借鑑了兩個既定流程，為 Redgate 構建了一些東西。

• RFC（徵求意見）檔案起源於 1969 年網際網路的早期。這是一個正式的流程，公開工作以向每個人提供意見。RFC 過程今天仍然用於定義網際網路的關鍵部分。例如，您可以檢視有關 IPv6的完整討論記錄（引入是因為現在有數十億臺裝置連線在一起）。
• ADR（架構決策記錄）是另一端工程決策的輕量級記錄。ADR 日誌與原始碼一起儲存，讓工程師可以很好地概覽決策背後的歷史背景。

我們將兩者結合起來——並提出了一種我們稱之為“架構意圖檢查”（AIC）的東西。在開始架構更改工作之前，AIC 充當非阻塞檢查。我們要求團隊尋求相關利益相關者的反饋，如果發現可能改變決策的新資訊，我們將改變決策！我們假設我們的大多數工程決策都是好的，因為我們一直在努力確保工程團隊擁有更廣泛的業務背景。