CBM由業務組件描述和構成，本文主要介紹業務組件的定義、作用、設計和驗證方法。
一、業務組件的定義
業務組件（Business Component，BC）定義為：一個可以獨立運行的構建企業的系統或功能模塊。通俗來說，業務組件就是對達成特定目標，需要完成的一組緊密關聯的工作事項的合集。
二、業務組件的作用
業務組件的作用，就是通過把企業功能組件化，從專業分工的角度構建企業業務能力網絡，從而實現企業的專業化和柔性化。此部分內容已經在《組件化業務模型（component business model, CBM）》（連結）中闡述，本文不再贅述。
業務組件還可以提供後續的基於SOA服務目錄清單，雖然在業務組件定義這一時期還沒有細化到服務，但是業務組件化後，我們可以通過流程對業務組件之間的關係和交互進一步分析，確定為了完成一個完整的端到端流程業務組件之間必須存在的接口和數據的交互，而這些交互正是識別服務的關鍵點。業務組件不是孤立的而共同組裝完成了流程的整合，而為了達到這個目的業務組件必須暴露相應的服務能力，即我們說的組件本身的服務能力化。
三、業務組件的五要素
業務組件是組件化業務模型（CBM）的核心。二者關係見圖1。
業務組件包含五個要素（見圖2）：
1. 目標/用途：為什麼存在，創造什麼價值，如何衡量；
2. 活動：定期執行的是哪些簡單的、具有凝聚性的活動；
3. 資源：需要哪些知識、資產和人力資源；
4. 治理：活動和資源是如何管理的；
5. 服務：從其他組件獲得哪些內容，以及向其他組件提供了哪些內容。
四、業務組件的特點
業務組件具有如下特點：
1. 業務組件有自己的輸入/輸出，在企業中承擔特定的職責，對外提供服務；
2. 業務組件是唯一的、不會重複的構造塊，由一系列緊密關聯的活動組成，可以單獨運行；
3. 企業所有的業務活動只能歸屬於某一個組件，組件間通過調用服務的方式進行協同與交互；
4. 業務組件具有高內聚，低耦合的特點。所謂耦合，就是兩個組件，其中一個變化將影響另一個也相應變化。所謂內聚，就是獨立、單一且具有明確邊界，業務組件之間相互隔離，改變其一，接口不變，系統不受影響。業務組件的高內聚，低耦合就是指業務組件之間通過低耦合方式進行連結，具備靈活、響應快、使用能力強的特點；其次，業務組件內各活動的具有高凝聚力，可對外提供效率高、質量好的服務。所以企業管理的目標就是降低業務耦合度（解耦），提升企業的內聚度（專業化）。耦合程度的分級可見圖3。
五、業務組件的劃分原則
業務組件是一系列不可分割的業務活動，那麼如何劃分業務組件呢？還是需要從業務組件的定義和特徵著手，從業務組件是企業專業化的功能模塊這個本質出發，從業務組件高內聚低耦合的特點出發，再綜合考慮以下因素：
1. 相似的業務活動；
2. 使用類似的數據；
3. 具有通用的處理流程；
4. 通用的業務目標；
5. 密切聯繫的組織單元通過組件共享，企業可以顯著地改善運營效率並提高差異化競爭優勢。
業務組件的劃分需要深入了解業務之間的關係，並根據企業的戰略、管理和執行各層面要求來進行歸類劃分。這需要有很好的業務分級分類能力，並考慮到業務間的數據流向和共享。
六、業務組件的顆粒度
業務組件的顆粒度用於表示業務所包含的業務組件的大小，是一個組織的管理顆粒度的反映，是一種達成共識的方式。顆粒度過大，功能複雜，靈活性小，升級困難（可以獨立升級往往會作為確定一個業務組件範圍的重要因素），很難實現重用；顆粒度過小，業務組件數較多，造成業務組件之間交互增多，管理成本提升，性能低下。因此找到一個合適的業務組件粒度是很重要的事情。
首先要說明的是，業務組件的顆粒度沒有硬性指導的原則，因為這不是一個硬性或可以測量的事物。一般來說，業務組件的顆粒度更多應從業務直接實現的業務目標層面去考慮，業務組件的精簡代表管理能力的聚焦、靈活度的提高、複雜度的降低。我們可以從以下幾個角度確定業務組件的顆粒度：
1. 業務特點：不同的業務特點導致業務顆粒度不同，如行政管理，各業務事項相對獨立，業務事項間鬆耦合特點明顯，可能會業務組件較多；
2. 抽象級別：不同的抽象層級導致業務顆粒度不同，如總部級的與部門級的；
3. 避免陷入根據日常業務出現的頻率、耗時、工作量等去評價顆粒度的大小。不能單純地把現頻率高，耗時多的業務定義為一級組件。應從該類業務實現的目的、價值去評估組件的大小；
4. 對於總是固定配合的幾個業務，且任何一個業務都不被此幾項業務以外的其他業務調用，則建議將此幾項業務合併為一個組件。一個業務組件的輸出必須為多個業務組件使用，如果一對一使用，代表該組件可合併。
七、業務組件的驗證方法
1. 業務場景十字分析法
業務場景十字分析法（見圖4）類比於軟體測試的白盒測試，即通過「測試用例」（流程場景）來驗證組件外部的流程和內部業務活動，驗證組件的正確性。
對於業務組件的CBM圖，首先相同業務域下的業務組件應能夠串接，其次不同業務域下的組件間的交互關係，應體現在同一層次，即戰略層面的不同業務域交互應都體現在戰略層，管理層面的不同業務域的交互應都體現在管理層，執行層面不同業務域的交互應都體現在執行層，在交互過程中不應有斜線關係。
2. 業務組件依賴性分析法
業務組件依賴性分析，類比於軟體測試的黑盒測試，即不關心組件內部，而通過驗證外部接口關係分析（組件的輸入、輸出、支持三方面）、驗證組件正確性。
通過連接業務組件的輸入輸出，可以分析業務組件在職能層級上是否準確。一般來講，戰略、管理和執行層的業務組件在連接上具有圖6的特點。
往期精彩回顧：
企業建模理論與方法
架構建模的十三項基本原則
數位化轉型的六個關鍵成功因素
如何從「0」到「1」的設計業務架構
讓大象變得敏捷
系統設計的一些原則
用企業架構戰略關係模型把組織的戰略目標從「口號」變成「乾貨」
TOGAF9.2升級要點簡介
架構應用實踐之——數位化組織（企業）建模思路
企業架構的建模過程
業務-應用-數據-技術架構的正向設計方法