本節書摘來自華章出版社《系統架構：複雜系統的産品設計與開發》一書中的第3章，第3.3節系統的分解，作者[美]布魯斯·卡梅隆，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視
3.3系統的分解
3.3.1分解
分解（decomposition）就是把實體分成小的部件或組成部分。在應對複雜度的諸多工具中，它是較為強大的一種。“分而治之”（divide and conquer）是一項基本政策，它把大問題持續分解成小問題，直到每一個小問題都能夠解決為止。尤利烏斯•凱撒（julius caesar）在《高盧戰記》的開頭宣稱“所有的高盧人都可以分成三個部分”，這并不是巧合，而是說明在古羅馬時代，這種方略就已經得到深入研究和廣泛運用了。
正如2.4節所述，有些系統是很容易分解的，例如那種由彼此不同的元素所構成的系統，分解起來就比較簡單。如果系統是子產品式的，那麼分解起來就需要經過一番思考了。而對于整合式的系統來說，其分解方式則會顯得有些武斷。
把系統分解成部件的難點并不在于分解，而是展現在用分解出來的實體建構整個系統的這一過程上。這個過程通常稱為整合（integration）。對于形式領域來說，整合就是把各部件所具備的形式聚合起來，在這一過程中，我們會擔心這些元素在實體上或邏輯上是否能夠合适地拼接在一起。對于功能領域來說，我們會把大功能分解成一些小的功能，然後把每個實體所具備的功能重新組合起來，在這一過程中，我們會遇到湧現物，這是真正的挑戰所在。
我們現在開始分析team xt。剛才說過，分解系統所用的方式，取決于系統元素的構成情況。如果系統在形式上由彼此不同的元素所構成，那我們就可以認為把team xt團隊按照成員進行分解是一種恰當的分解方式。但如果系統在形式上不是由彼此截然不同的元素所構成的，或是元素的形式尚未确定，那我們就更有可能會考慮按照功能來進行分解。這可能會得到與功能相關的一些實體（例如，轉向機制、壓縮機，以及排序算法，都可以按照功能分解為這樣的一些實體）。具體到表3.1來說，其中有很多地方都表明，如果我們把注意力放在功能上，那就可能會得出一種與已有方式不同的分解方式。比如，我們發現jose和vladimir都具備“撰寫需求文檔”這一功能，于是我們就可以提出一種把jose和vladimir放在同一個實體内的分解方式。對我們了解系統湧現物來說，這種基于功能的分解方式，可能會更有幫助。
3.3.2體系
體系也是一種用來了解并思考系統複雜度的強大方法。體系（hierarchy）是一種其實體均處在某個層次或某個位階的系統，這些層次是按照上下順序排列起來的。社會系統中經常看到各種體系。比如，軍隊就是一種體系，其中有将軍、上校、少校、上尉等不同的軍階。大公司也是個體系，可以分為總裁、執行副總裁及資深副總裁等不同的層次。
為什麼有一些元素在體系中的位階會比另外一些元素高呢？一般來說，有下面這幾個原因：
這些元素所涉及的範圍更廣：例如州長比市長高，因為州長的行政範圍比市長大（州比市大）。
這些元素的重要性較高或性能較強：例如黑帶（black belt）選手比褐帶（brown belt，茶帶、棕帶）選手高，因為他們的晉級标準更加嚴格，武藝也更加高強。
這些元素在功能上要承擔更多的責任：例如總統比副總統高，因為總統的職責更大。
體系并非總是能夠明确地展示我們想要的資訊。即便仔細觀察圖3.1和表3.1，我們也依然不清楚team xt的實際層級。各小組的組長和整個團隊的經理，實際上都是為了傳遞有價值的設計方案而設立的，并不是單單為了評審其他人遞交上來的工作，是以，我們不能僅僅通過圖3.1和表3.1所展示的遞交和評審關系來推斷團隊的實際層級。于是，我們還需要觀察圖3.2，這張圖明确地展示了整個團隊的體系。我們可以看到：sue在amy、john和phil之上，而這三位小組長又處在團隊的其他成員之上。這些内容是從表3.1最右側那一列中的結構資訊中提取出來的。圖3.1給人的感覺是那些團隊成員似乎都處在同一級别。而圖3.2則呈現了一種分層的視圖，使我們可以明确地看出：有一些團隊成員在某種程度上要比其他成員更加重要。請注意，圖3.2中的體系并不意味着某一層中的團隊成員一定會向上一層彙報工作。工作彙報情況隻有在做層級分解時，才能展現出來。
3.3.3層級分解
将分解與體系這兩種手段結合起來，通常可以實作多層次的分解或層級化的分解，也就是可以實作像圖3.3這樣，大于兩層的分解方式。圖3.2中的中間那一層并沒有展現出這三位小組長之間的差別，而圖3.3則比較好，因為它使我們能夠更加清晰地意識到這三位組長有着不同的分工。而且它還把每個節點所統領的下層節點數量限制在7個以内，使其不超越我們的認知能力（該上限可以左右浮動兩個，位于5～9個）[1]。從圖3.3中可以看出，三位小組長都向sue彙報工作，而每位小組長所統領的四位組員都向該小組的組長彙報工作。
圖3.3 對team xt所做的層級分解
從表3.1和圖3.2來看，“組”（group）是一種有用的抽象單元，但它并不是分解該團隊的唯一方式。對于sue以下的那些團隊成員來說，我們可以用其他方式對其進行分解，包括按地理位置分解、按連接配接性分解或按功能關系分解等。實際上，圖3.2既沒有展現出這些團隊成員彼此之間是否離得很近或是否有連接配接管道（也就是說，沒有展示出形式關系），也沒有展現出某位成員是否會和另一位成員交換資訊（也就是說，沒有展示出功能關系）。
3.3.4簡單的系統、複雜度适中的系統以及複雜的系統
按照一套特定的分類标準，本書将系統分成簡單的系統、複雜度适中的系統，以及複雜度較大的系統（也就是複雜的系統）這三種類型。如果某系統像圖3.4這樣，隻需分解一次即可将其完整地描述出來，那麼它就是簡單的系統。第2章所講的那4個範例系統都是簡單的系統，即便是太陽系，也隻需要分解成由行星和更小的星體所組成的一層即可。對簡單的系統進行分解之後，在分解出來的這一層中（也就是系統之下的第1層），其元素一般都不超過7個（該上限可以左右浮動兩個）。而對這些元素進行研究時，我們則會發現：它們或多或少都是那種不便于繼續分解的原子部件（參見3.3.5節）。
圖3.4 對team xt進行第一次分解
如果某個系統不是簡單系統，但是經過兩次分解之後，可以表示成圖3.3這樣的形式，使得每個上級部件所統領的下級部件都不超過7個（該上限可以左右浮動兩個，這要求最底層的實體數量不能超過81個），那麼這種系統就是複雜度适中的系統。
複雜的系統與複雜度适中的系統一樣，也可以像圖3.3這樣進行分解，但是在系統下方的第2層中，仍然會有一些抽象的元素，這些元素還可以繼續分解。這種系統分析起來更為困難，而它也比前兩種系統更為常見。比如，假如natasha本身還上司着一個專門負責拟定備選概念的小組，那麼team xt就由複雜度适中的系統變成複雜的系統了。
我們很少會看到分解深度超過兩層的示意圖。不使用這種示意圖的原因有兩個。首先，如果繪制三層分解的示意圖，那麼最底層的元素數量上限大約是73。由于7可以左右浮動2，是以這個上限可以位于53～93，按照93來算，最多可以有729個元素，這個數量遠遠超過了人類所能了解的範圍。其次，我們在觀察某個組織或系統時，對系統之下的第1層元素（也就是向該組織“直接彙報”的那些元素），一般都會了解得非常清楚，而對系統之下的第2層元素（該層中的元素會直接向第1層中的元素進行彙報），也會有着一定程度的了解，但是再往下看，就多少顯得有些模糊了。
在分解系統時，筆者會把系統本身稱為第0層（level 0），把分解出來的那些層分别稱為系統之下的第1層（level 1（down））、系統之下的第2層（level 2（down））等。第2章說過，每件事物幾乎都可以當成系統來看待，是以，第0層究竟指代的是哪個系統還要由架構師的視點來确定。第0層系統之下的那些層，有很多種稱呼方式，它們可以叫做子產品（module）、配件（assembly）、子配件（sub-assembly）、函數或功能（function）、架（rack）、線上更換單元（online replacement unit，oru）、例程（routine）、委員會（committee）、工作組或任務組（task force）、單元（unit）、元件（component）、子元件（sub-component）、部件或部分（part）、區段（segment）、節（section）、章（chapter）等。稱呼方式雖然有很多，但每一種稱謂應該怎樣使用并沒有形成一緻的意見。在另一個人看來，某個人所說的配件可能應該叫做部件才對。至于系統之上的那些層，其稱呼方式則相對較少，有人将其稱為系統的系統（system of system）、複合體（complex）或集合（collection）。本書在提到系統之上的那些層時，會采用系統之上的第1層（level 1（up））、系統之上的第2層（level 2（up））等說法。
3.3.5原子部件
我們剛才說的那種歸類方式，某種程度上要依賴于“原子部件”（atomic part）這一概念，而該詞并沒有精确的定義。它的含義源自希臘語的（轉寫成拉丁字母是atomos）一詞，原意是不可分之物（indivisible）。在機械系統中，我們把那種不能輕易“拆解”的部件假定為原子部件。按照這種定義方式，人、螺絲及處理器晶片都是原子部件。處理器晶片當然也包含很多對架構起着重要作用的内部細節。比如，其中有哪些類型的半導體和邏輯門，這些類型的電子元器件分别有多少個，以及它們是如何連接配接起來的，等等。即便是一枚簡單的螺絲，也含有一些架構方面的重要細節。比如，它是一字頭（straight head）還是十字頭（也稱為菲利普頭，phillips head）等。由此看來，剛才所設想的那種定義方式似乎有些不夠清晰，但我們可以把握一條簡單的規則，那就是：不能拆解的東西都可以叫做原子部件。
在資訊系統中，“原子部件”這個定義就顯得更模糊了。有一種辦法可以判斷出某物應不應該稱為原子部件，那就是看該物是不是像單詞或指令那樣具備語義含義（semantic meaning），或者不是一種資料或資訊單元。這些單詞、指令或資料單元本身當然也包含各種細節。由于所有的資訊都是一種抽象（第4章将講述這一點），是以想在本身就比較抽象的資訊上再抽象出一個針對原子部件的有效定義，就必然會顯得非常模糊。不過與機械系統一樣，分析資訊系統時，也可以把握這樣一條簡單的規則：凡是一經拆解就失去意義的東西，都可以稱為原子部件。