規則引擎並不靈：康威定律不適用於剛性設計 - verraes

理論本身就是系統
康威Conway博士描述了一種 "系統的線性圖與設計組織的線性圖之間的結構保持關係 "。他對 "系統 "的定義比 "軟體系統 "要寬泛得多。因此他的康威定理定義更符合系統理論，即（鬆散的定義）所有的東西都是一個系統，所有的東西都是一個系統的一部分。

例如，康威寫道："在同樣的意義上，一個理論是一個系統，這可能不那麼明顯"。他的例子涉及調查員形成了一個關於飛機如何墜毀的理論：調查員們根據他們的專業領域，對導致墜機的不同事件建立了子理論。該理論的結構將模仿調查員組織的通訊結構。

一個軟體系統並不是生活在真空中。它被嵌入到生產這個系統的組織中。它受我們關於軟體的理論支配：它是如何工作的，它做什麼，它為什麼這樣做，它是如何連線的。我們把這些理論稱為 "模型 "和 "架構"。

在一些組織中，這些理論只存在於人們的頭腦中。其他人則用圖表和檔案來表達這些。如果他們持續關注這些模型的協作和發展，那就更好了（例如，使用領域驅動設計）。但是，無論你是否有圖表，每個使用或設計系統的人都有一些關於該系統的理論。如果不對這些理論進行明確的建模，我們不僅有可能得到一個糟糕的系統設計，還有可能得到關於這個系統的錯誤信念。

規則引擎等反面案例
十多年前，我曾為一家SaaS公司提供諮詢。我發現，在CEO、銷售人員、客戶成功經理和培訓師、客戶和工程師之間，對系統如何運作的信念差異很大。如果你立即認為工程師有最好的理論：不。他們對設計（主要是由他們的前輩創造的）瞭解甚少，以至於他們每晚都要刪除和重建客戶儀表板資料庫。這是他們能在結果中獲得一些一致性的唯一方法。

另一個例子是Aardling的一個客戶，一個在具有複雜監管要求的領域運營的B2B公司。在建立公司時，執行長（一個領域專家）和技術長同意技術長不參與這個領域的複雜性。相反，技術將以一種允許技術保持與該領域無關的方式來構建。為了做到這一點，工程師們建立了一個表單生成器、一個規則引擎和一個模板語言。他們聘請了（非技術性的）領域專家，並教他們如何使用這些工具來建立面向客戶的功能。

快進到幾年後。從系統設計到產品再到組織控制結構，關於公司應該如何運作的理論已經滲透到了所有的東西中。

但你只能用表單和規則引擎做這麼多。

用這些工具可以很容易地建立起一些功能，有快速的週轉時間，但其他一切都必須由工程師來完成。這需要預算和優先順序，而且往往是通過捷徑完成的，這反過來又使後續的修改更加困難。整個設定使其無法實現某些增長目標。這些團隊沒有自主權，需要大量的協調來實現任何目標？重組能解決這個問題嗎？儘管系統設計模仿了公司成立初期的溝通結構，但現在的系統太僵化了，僅僅是團隊的洗牌是無法影響的。

僵化的系統
逆康威定理的倡導者告訴我們，我們所要做的就是重組團隊以獲得更好的系統設計。但是，如果軟體本身，創造它的人類（社會技術）環境，以及人們對系統的信念，都只是屬於他們自己的另外一套系統，而且他們都受到組織的溝通結構的影響，那麼應用這個定理就變得更加混亂。

為了有效地干預我上面的兩個例子，你必須解決組織、系統以及人們對組織和系統的理論。

軟體應該是柔軟的，也就是說，可塑性強，容易改變。
通常情況下，它其實不是容易改變的，因為這些系統通常是深度耦合和相互連線的。

改變一個元件會產生連鎖反應，不僅僅是在軟體元件中，而是在整個組織和客戶的生態系統中。如果我們的軟體的這種僵化性是我們的主要瓶頸之一，你會認為我們會急於解決這個問題。然而，令人失望的是，很少有軟體組織對其軟體的深層結構改進給予足夠的重視。

相反，他們轉向了重組。而這是一個誘人的承諾：改變你的組織，得到你想要的系統設計。它甚至帶有法律，所以它不會失敗! 然而，正如一位客戶的技術長曾經告訴我的，"我們重組了，但是系統沒有收到備忘錄"。(有一個挽回的因素：管理者只能間接地影響軟體系統，而他們唯一的工具是會議和重組)。

（banq：從程式碼重構 到程式碼重寫，再到換人：組織重組，經過這三個階段血流成河，損失巨大，人才流失嚴重，最後還是失敗，關鍵是沒有人知道軟體工程失敗的深層邏輯與原因）

擴充套件康威法則以說明剛性問題
康威法則是錯的嗎？不，我不這麼認為。當從頭開始設計一個系統時，它是正確的，這正是本文所描述的。當使用一個靈活的系統設計時，它是正確的，因為它足夠靈活，可以適應模仿新的團隊之間交流溝通結構。
但它不能很好地轉移到適用現有的具有剛性設計的系統中。

我建議這樣做：
系統設計將模仿組織的溝通結構，但只是在設計的靈活性允許的範圍內。

Conway博士評論說："我認為[溝通結構和系統設計之間]的關係是一種約束，僅此而已。你可以通過擾亂一方或另一方來改變什麼，取決於它們的具體特徵 "。

因此，"反康威演習 "也需要被擴充套件。

如果系統是新的或靈活的，改變組織結構以獲得你想要的系統設計；如果系統是僵化的，就先解決這個問題。

或者，更簡明的說法是：

人員重組並不能解決一個破碎的設計。

當涉及到新系統的設計時，康威定律被低估了，但當涉及到現有系統的重新設計時，卻被誇大了。

一個新的綠地專案有無限的靈活性。但隨著設計中更多的耦合和互連，它就失去了靈活性。我們需要儘早地、持續地考慮我們的組織結構，而不是在設計僵化後才去考慮。

防止我們的系統變得僵化需要持續的關注，從成千上萬的小的區域性設計決定到大規模的架構。為了支援和促成決策，我們需要關於系統、領域、產品和它所服務的生態系統的良好模型或理論。

當我們發現自己面對的是一個僵硬的系統時，反康威演習只是我們可以使用的工程裝置之一，而不是一個魔杖。

歸根結底，好的設計是導致良好設計的系統的原因。