大約在我十六、十七歲的時候，第一次得到香港腳。最初也搞不懂是什麼病，該怎麼處理。總之，有一回去了學校的保健室，保健室的護士給了我塗了某種抗霉菌的藥，就改善了。很不幸的，後來我又得到了，抗霉菌的藥卻愈來愈不管用。不久之後，我發現原來用水楊酸來處理這個問題就行了，而且水楊酸不會有抗藥性，因為水楊酸作用的原理並不是殺死霉菌而是溶解掉皮膚的角質層。更有趣的事是，水楊酸（以柳樹皮的形式） 被人類使用已經有上千年的歷史，顯然，古人未必了解它的作用原理，反正有用就是了，而且還非常地管用。
從年輕到老，身上總是有一些大大小小的病：有的看一次醫生就好了，有的則是換了四、五個醫生，換了四、五種療法才改善。每種療法都有自己的理論體系，而人體是複雜 (complex) 系統，當某個療法在某些時刻超管用，某些時刻卻收效甚微時，這充分地體現了一句話：「所有的模型都是錯的，但是有些是有用的。」
相較於醫學的複雜，軟體開發的難則是繁瑣 (complicated)。由於軟體是繁瑣系統，任何的軟體錯誤，只要找到因果關系，就是可以修正，並不會有模型錯誤卻管用的奇妙現象。對我來說，每一種程式語言的開發效率，是可以分析、辯証、有正確的答案的；什麼樣子的軟體架構設計合理、什麼樣子的不合理也有答案。換言之，我們可以追求有用的解法，也可以去追求正確的理論，畢竟面對的是繁瑣而非複雜，真理是可以在有生之年抵達的。
面對複雜系統，因果關系相對非常難以駕御，可行的應對策略是採取：試誤學習或是基於反脆弱理論選擇經過時間考驗的解決方案。與之相對的，面對繁瑣系統，因果關系的分析是可行的，這時候試誤學習很容易將自己困在區域最佳解，而全域最佳解往往是在理解了因果關系之後就會出現。在繁瑣的前提之下，往往是專家可以做出絕佳的成果。
當複雜與繁瑣同時出現
那問題來了，真實的世界很多時候，並不是 100% 的複雜或是 100% 的繁瑣，而是 80% 複雜搭配 20% 繁瑣，或是反過來，又或是恰好為 50%, 50% 的複雜與繁瑣。那在這種又複雜又繁瑣的環境之下，有什麼比較好的應對策略可以應用呢？
階層化複雜性這個應對策略特別適用於這種既複雜又繁瑣的情況，而且此一策略也廣泛地出現在各個領域，但是又因為領域依賴的緣故，在不同的領域往往就有不同的名字。
階層化複雜性
階層化複雜性最早由司馬賀 (Herbert Alexander Simon) 提出，這個概念提出之後，據說對許多領域都造成了影響。我個人對這個概念的理解一開始也覺得頗為模糊，後來在多個領域看到之後，卻覺得清晰無比。
比方說，在軟體設計領域，階層化複雜性稱之為 Policy vs Mechanism ；在團隊拓撲 (team topology) 的領域，稱之為 stream-aligned team vs platform team ；在管理顧問的領域，稱之為 content knowledge vs process knowlege 。在軍事上，古代也有說法：「將在外，君命有所不受。」
階層化複雜性帶來的顯著好處在於降低了認知複雜度 (cognitive load)，當面對的情況是既複雜又繁瑣時，如果將系統設計成至少兩層，上層處理 what ，下層處理 how ，上下兩層都會簡單得多。。
仔細想想，當上層可以專注於處理 what ，即那些繁瑣的成分可以交給下層去處理，上層就可以用更快的速度變動，而快速改變本身就是適應複雜環境的關鍵。而下層若可以專注於處理 how ，即需要擔心的都是繁瑣、都是因果可以分析清楚的，即使在尋找答案的過程需要投資，一旦找出了答案，就得到了長期可用的解決方案。
我在不同的領域體會到了數次階層化複雜性之後，得到了三個重要的啟發：
what/how 拆分可以迭代運行。一件事做了 what/how 拆分之後，任選拆分完的其中一部分，有時候又可以再拆成兩層。舉個例子，以 IT 來講，軟體可以視為是 what，而硬體可以視為是 how ，然而，軟體至少又可以拆成 frontend 與 backend ，這又是下一個迭代的 what 與 how 的拆分法。
what/how 拆分並不容易。通常不是憑感覺或是少數的經驗就可以做好拆分，因為 what 與 how 必須巧妙地各自捕捉到 complex 和 complicated 的成分。
一種新的 what/how 拆分往往意謂著一種創新。正確的 what/how 拆分之後，how 的部分可視為是一種基礎設施 (infra) 的新作法，而這種基礎設施的新作法有時也適合做為顧問諮詢的題目，因為生產力的改進往往也有市場需求。
總結
複雜與繁瑣是兩種截然不同的系統屬性，各自對應不同的應對策略。面對複雜系統，試誤學習與時間驗證的解法較為有效，而在繁瑣系統中，因果關係可以被清楚分析，專家知識能夠帶來最佳解。然而，在真實世界中，複雜與繁瑣往往共存，此時「階層化複雜性」提供了一種有效的方法來降低認知負擔並提升系統適應性。
透過將系統拆分為處理 what（目標）與 how（執行）的層級，上層能夠更靈活應對變化，而下層則能專注於建立可長期運行的穩定基礎。這種策略在軟體架構、團隊組織、管理顧問乃至軍事領域都有廣泛應用。關鍵在於找到合適的 what 和 how 拆分方式，使複雜與繁瑣的部分各自歸位，進而優化整體系統的效能與發展潛力。
一個成功的 what/how 拆分不僅能降低認知複雜度，還可能成為創造新基礎設施的契機，甚至有創造新的市場的可能性。