事件起點:一個 1967 年的觀察,至今仍在每家公司上演
Melvin Conway 在 1967 年發表了一篇幾乎被退稿的論文,裡面有一句話後來被稱為「軟體業最被低估的定律」:
> *「系統設計者所產出的設計,必然 mirror 該組織的溝通結構。」*
他舉的例子極其具體:如果你把寫 compiler 的工作分給 4 個 team,最後你一定會得到一個 4-pass compiler,無論技術上有沒有必要這樣做。組織的切割方式,決定了產品的切割方式。
這不是比喻,是一個關於資訊流動的鐵律。
為什麼這會發生:溝通成本驅動架構決策
工程師做設計決策時,幾乎從不在真空中操作。他們面對的是:哪個 team 擁有哪個 codebase、誰跟誰開會很貴、API 邊界定在哪裡讓我的 team 不用等別人。
在這樣的現實下,介面(interface)往往不是根據最佳技術設計來劃分,而是根據最小化跨 team 協調成本來劃分。 這是完全理性的個人決策,但累積起來,就把組織結構直接烙印進了產品。
Microsoft 早期的 Office 就是教科書案例。Word 有自己的格式引擎、Excel 有自己的渲染邏輯、Outlook 有自己的資料模型——三者幾乎不共享底層基礎設施。對使用者而言,這三個產品在同一個公司出品,卻像三個陌生人。原因不是工程師不夠聰明,而是三個 team 彼此的溝通成本太高,高到各自關起門來做才是最理性的選擇。
Bezos 的反擊:用組織指令重寫架構
2002 年,Jeff Bezos 發出了一封現在被稱為「Bezos Mandate」的內部信,內容大致如下:
1. 所有 team 必須透過 service interface 暴露資料與功能 2. Teams 之間只能透過這些 interface 溝通 3. 不允許任何其他形式的 IPC(interprocess communication) 4. 違者開除
這封信的技術意圖,是強制 Amazon 建立 service-oriented architecture(SOA),也就是後來 AWS 的基礎。但更深層的邏輯是:Bezos 在用組織指令對抗康威定律——他知道如果不強制規定 team 的溝通方式,產品架構就會自然長成組織的形狀。
結果是 Amazon 的工程 team 在被迫設計對外 API 時,同時也在訓練自己建立真正模組化的系統。AWS 的誕生,某種程度上是這個組織實驗的副產品。
逆康威策略:先想清楚產品,再設計組織
康威定律原本是一個「這就是現實」的觀察,但被聰明的人反轉成一個設計工具:如果產品架構必然反映組織架構,那就先設計你想要的產品架構,再倒推出你應該有的組織結構。
這個策略有時被稱為「Inverse Conway Maneuver」(逆康威操作),在現代微服務架構的推廣中被廣泛引用。
實務上的含義: - 一家 startup 想做高度模組化、可插拔的平台?→ 從第一天就不要讓工程師橫跨所有模組,建立清晰的 team 邊界與 API 契約 - 想讓前後端高度解耦?→ 先確認前後端 team 之間有清晰的介面協議,而不只是「大家坐在一起溝通」 - 想做跨平台產品(Web/iOS/Android 行為一致)?→ 不要讓三個 platform team 各自為政,需要共享一個 product spec 流程
組織結構是最被低估的架構決策。 大多數公司花大量時間討論技術選型,卻在 hiring 和 team 劃分時隨機應變——而康威定律告訴你,後者其實比前者更決定性。
超越軟體:康威定律的普適版本
康威定律本質上在說的,是一個更古老的道理:任何複雜系統的輸出,都受限於產生它的溝通網絡的形狀。
這在軟體之外同樣成立: - 一部由多個導演聯合執導的電影,往往在敘事上有明顯的風格斷裂點 - 一份由多個部門聯合撰寫的政策報告,往往在邏輯上有縫隙——每個縫隙正好是一個部門的邊界 - 一個由多個國家聯合開發的武器系統(如早期歐洲航太合作),往往在零件介面上出現奇怪的妥協設計
溝通結構塑造輸出結構,這是一個跨領域的原則。
給建造者的問題
在你現在的組織裡,有沒有一個讓你覺得「這個介面設計得好奇怪」的地方?現在問自己:這個介面是技術決策,還是組織邊界的化石?