3.1業務架構元模型綜述
業務架構 (Business Architecture) 定義了企業各類業務的運作模式及業務之間的關系結構。它以承接企業戰略為出發點，以支撐實作企業戰略為目标， 通過對于業務能力的識别與建構，并将業務能力以業務服務的方式透出，實作對于業務流程的支撐， 并最終通過組織給予保障。
業務架構是企業架構的核心内容，直接決定了企業戰略的實作能力，是其他架構領域工作的前提條件和架構設計的主要依據。
業務架構整體上包括“業務”、“流程”、“組織”、 “服務”、“領域”和“模式”六大部分，如下圖 3.1-1 所示：
其中“模式”部分是我們為“平台型”企業架構設計的核心解決方案，包括：
3.2 業務架構元模型應用
3.2.1 現代業務架構典型問題
在幫助企業建構業務架構的過程中，我們發現大部分企業正面臨共同的問題：如何抽離多業務線共享的能力，集中管控和演進，以避免重複投資？新業務如何基于企業能力快速組裝上線，以支撐業務快速疊代創新？
問題的背景和起因在于，當大型企業的業務發展到達一定規模，多條業務線并存、或多個業務單元并行發展，IT 建設會随着業務邊界、組織邊界，不可避免的進一步分化，也加劇了 IT 部門進行統一管控的困難。
一方面，在很多場景中，這樣的分化帶來了雙重投資甚至多重投資的浪費，另一方面也在加劇本就存在的使用者或者客戶體驗的割裂、資料孤島、IT 翻新周期長等固有問題。
同時，當業務線不斷嘗試新的業務模式，或對于已有模式進行更快的試驗、調整與擴充。對于 IT 支撐的響應力也提出了更高的要求。固有的系統搭建或者産品部署模式，越來越不足以提供及時的響應， 且在“快速試錯”、“小步快跑”的創新場景應對下， 成本高昂。
為了解決上述問題，我們對問題進行了進一步拆解：
- Q1：什麼是可共享複用的能力？
- Q2：如何識别和建構能力？
- Q3：如何使用能力，實作新業務快速上線？
在對問題進行上述拆解後，我們将基于業務架構元模型逐一解決。
3.2.2 什麼是可共享複用的能力？
在現代企業架構中，面向能力的規劃超越面向功能與服務的規劃成為企業級業務架構規劃的關注要點，如何基于能力的識别與規劃，最大化的沉澱企業級可複用的能力，并通過擴充、編排群組合等形式應用到更多的場景，是平台型企業架構需要解決的關鍵問題。
企業為了應對業務的快速疊代、多場景和不确定性， 需要在平台上建構可複用的“能力”以及為能力提供必要的擴充與可變機制，以此為不同前台提供靈活多變的業務服務，滿足不同前台差異化個性化的的需求。
而“能力”根據粒度的不同，可再度細分為“基礎能力”、“能力元件”和“解決方案”三個層級。
不同業務的差異性，則可通過能力的“擴充點”設計和不同“業務身份”在擴充點上的“擴充實作” 進行區分。
總體實作機制如下：
業務身份：“業務身份”的概念最早由阿裡巴巴提出，業務平台在對各業務同時提供服務時，需要能區分每一次業務服務請求的業務身份要素，以便提供差異化個性化的服務；是以需要對企業各業務的身份和特征進行模組化和區分，其産出即為“業務身份”。業務身份是業務在平台中的代名詞，是在業務營運中唯一區分某個具體業務的 ID。平台基于業務身份比對該特定業務的流程和業務規則，并基于業務身份實作服務路由、需求溯源、業務監控和業務隔離。
基礎能力：是對領域對象的原子操作，完成一個領域對象上單一且完整的職責。比如：建立售後單、修改商品庫存量等，是能力組合和複用的最小單元。
能力元件：能力元件是對基礎能力的進一步封裝， 目的是友善業務的使用。按封裝粒度不同分為兩類： 第一類能力元件是根據業務服務的需要編排封裝的一組關聯的基礎能力，進而提供完整的服務。比如： 訂單建立能力元件。第二類能力元件是平台針對一系列緊密關聯的業務活動，設計的能力模闆，可基于該模闆快速定制某個具體業務的特定流程和能力，進而達到複用全部關聯能力的目的。比如：“組合支付”、“快速建站”等能力元件。能力元件加 快了業務接入平台的速度，讓業務側專注業務本身， 不再需要耗費精力在了解平台大量的基礎能力上。
擴充點與擴充實作：“擴充點”是對基礎能力的可變性設計，在技術側展現為基礎能力實作中的某一個步驟的接口定義，而接口的一個實作即為一個“擴 展實作”。比如：訂單渲染基礎能力中有一個步驟 是訂單總價試算，而正常時期的總價試算規則與秒殺時期的總價試算規則是不同的，是以需要對訂單渲染基礎能力設計“訂單總價試算規則”的擴充點， 并分别定義在正常時期和秒殺時期的擴充實作。
解決方案：是平台針對一類共性業務的端到端過程設計的能力模闆；可基于該模闆快速定制某個具體業務的特定能力和流程，進而達到業務模式級别複用的目的。比如：虛拟物品交易解決方案。
3.2.3 如何識别和建構能力？
識别建構能力的過程分為“業務梳理”和“模式設計” 兩個階段。
在業務梳理階段：對企業業務、流程、組織、業務服務和業務規則進行細緻完整地梳理，作為後續模式設計的基礎和輸入。
而在模式設計階段：則會通過流程模組化、領域模組化、業務身份模組化和能力模組化 4 個步驟完成企業能力的識别建構。
具體過程如下：
模式設計階段中：
• 流程模組化：負責識别共性業務，并抽取通用流程， 設計可變點，作為可複用性分析的基礎。
• 領域模組化：負責基于流程模組化結果，識别領域事件和領域對象，并劃分子域的邊界；領域對象構成了提供可複用能力的基本單元，對領域對象的操作即是基礎能力。
• 業務身份模組化：負責定義業務身份識别的要素和業務身份解析規則，用于給可複用的能力區分不同的業務身份要素。
• 能力模組化：負責最終完成平台三類可複用能力的設計，即“基礎能力”設計、“能力元件” 設計和“解決方案”設計。
3.2.3.1 流程模組化
為了提取可複用的能力，首先需要識别共性業務， 然後将同一類共性的業務抽象提煉出通用流程，并 基于通用流程進行可變性分析。 具體方法是按業務架構中流程部分的元模型（階 段、活動、任務、步驟、業務規則），結合自上而 下以及自下而上的方式逐層提煉收斂通用模型和 可變點。
總體實作機制如下：
提煉通用流程後的可變性分析，旨在找出“什麼在變”、“為什麼變”和“怎麼變”，是以可變性模型主要由：“可變點”、“可變點實作”以及“可變點、可變點實作之間的關系”三部分組成。
綜上所述，流程模組化的主要步驟如下：
- 分析業務組合，提取共性業務。
- 分析所有共性業務的各流程步驟及其輸出對象， 抽象提煉通用步驟和業務實體；識别各業務的差異部分，提煉設計可變點，确定可變點實作和關系。
- 分析所有共性業務的各流程任務，抽象提煉通用任務；識别各業務在任務上的差異部分。
- 分析所有共性業務的各流程活動，抽象提煉通用活動；識别各業務在活動上的差異部分。
- 分析所有共性業務的各流程階段，抽象提煉通用階段；識别各業務在階段上的差異部分。
3.2.3.2 領域模組化
領域是指組織的業務範圍以及在其中所進行的活動，也就是平台能力需要支撐的業務範圍。是以， 為了建構出平台能力，需要對業務領域進行深入的了解和設計。
在業務架構部分，将進行領域戰略層級的模組化，主要包括：“子域”、“領域對象”、“領域事件” 部分的設計。
領域戰略層級模組化的過程如下：
3.2.3.2.1 領域事件識别
領域事件（Domain Event）：是領域專家關心的， 在業務上真實發生的事件，這些事件對系統會産生重要的影響，如果沒有這些事件的發生，整個業務邏輯和系統實作就不能成立。我們可以通過領域事件對過去發生的事情進行溯源，因為過去所發生的對業務有意義的資訊都會通過某種形式儲存下來。比如：“使用者位址已更新”、“訂單已發貨” 等領域事件。
領域事件對系統常見的影響有：
對内：
- 産生了某種資料
- 觸發了某種流程或事情
- 狀态發生了某種變化
對外：
- 發送了某些消息
目前比較常用的領域事件識别方法是“事件風暴（Event Storming）”，主要步驟如下：
- 邀請業務專家（或領域專家）和技術專家共同參與事件風暴工作坊，其它參與角色按需補充。
- 明确和選擇需要分析的業務場景。
- 确定起始事件和結束事件，事件以“XXX已 YYY”的形式進行命名（對于英文版過去完成時的中文表達方法）。
- 根據場景和業務複述的複雜度，決定以時間線的哪個方向開始梳理事件（正向或逆向）。
- 以先發散再收斂的方式，按照時間線的先後順序和并行關系，補充和完善領域事件。
- 使用“規則”抽象分支條件或複雜的規則細節， 通過抽象降低分支複雜度，規則以“XXX規則”的名詞形式進行命名。
- 完成一遍事件梳理之後，通過問問題的方式， 逆向檢查（ReverseCheck）事件流的邏輯合理性，例如：
- 該事件真的需要在系統實作的時候考慮嗎？
- 該事件如果存在，那它的前提條件是什麼？
- 該事件如果要産生，那它的前一個事件必須是？
- 重複以上步驟，疊代式的完成全部領域事件的識别。
領域事件識别的示例如下
3.2.3.2.2 領域對象識别
領域對象（DomainObject）：是對業務的高度抽象，作為業務和系統實作的核心聯系，領域對象封裝和承載了業務邏輯，是系統設計的基礎。
領域模組化中重要的部分之一就是對“領域對象”及領域對象之間關系的識别和設計。而領域對象識别将基于前面領域事件識别的結果開展。
領域對象，通常包含（但不限于）：
- 領域事件中出現了的名詞；
- 如果沒有資訊系統，在現實中會看得見摸得着的事物（例如訂單）；
- 雖然在目前業務中看不見摸不着，但是可以在未來抽象出來的業務概念。
在領域驅動設計（Domain-Driven Design）（參考文獻 7）中一般存在三類領域對象：
聚合根：是領域對象的根節點，具有全局辨別，對象其它的實體隻能通過聚合根來導航；如訂單可以分為訂單頭和訂單行，訂單頭是聚合根，它包含了訂單基本資訊；訂單行是實體，它包含訂單的明細資訊，聚合跟所代表的聚合實作了對于業務一緻性的保障，是業務一緻性的邊界。
實體：是領域對象的主幹，具有唯一辨別和生命周期，可以通過辨別判斷相等性，并且是可變的，如常見的使用者實體、訂單實體；
值對象：實體的附加業務概念，用來描述實體所包含的業務資訊，無唯一辨別，可枚舉且不可變，如收貨位址、合同種類等等。
業務架構隻負責初步和整體識别領域對象，而對領域對象的分類（聚合根、實體、值對象）和戰術層級的詳細設計将在應用架構設計部分完成。
領域對象識别的主要步驟如下：
- 對每一個領域事件，快速識别或抽象出與該領域事件最相關（或隐含的）的業務概念，并将其以名詞形式予以貼出。
- 檢查領域名詞和領域事件在概念和粒度（例如數量，單數還是集合）上的一緻性，通過重命名的方式統一語言，消除二義性。
- 如果在讨論過程中，有任何因為問題澄清和知識增長帶來的對于之前各種産出物的共識性調整，請不要猶豫，立刻予以調整和優化。
- 重複以上步驟，疊代式的完成全部領域對象的識别。
領域對象識别的示例如下：
3.2.3.2.3 子域劃分
子域（Subdomain）：是對問題域的澄清和劃分，同時也是對于資源投入優先級的重要參考。比如： “訂單子域”、“物流子域”等，子域的劃分仍屬于業務架構關注範疇。
子域的類型分為：
核心域（Core Domain）：是目前産品的核心差異化競争力，是整個業務的盈利來源和基石，如果核心域不存在那麼整個業務就不能運作。對于核心域，需要投入最優勢的資源（包括能力高的人）， 和做嚴謹良好的設計。
支撐域（SupportingSubdomain）：解決的是支撐核心域運作的問題，其重要程度不如核心域，但具備強烈的個性化需求，難以在業内找到現成的解決方案，需要專門的團隊定制開發。
通用域（GenericSubdomain）：該類問題在業内非常常見，是以很可能有現成的解決方案，通過購買或簡單修改的方式就可以使用。
子域劃分的主要步驟如下：
- 根據“每一個問題子域負責解決一個有獨立業務價值的業務問題”的視角出發，可以通過疑問句的方式來澄清和分析子域需要解決的業務問題，例如“如何進行庫存管理？（英文描述類似 Howto…？）”。
- 利用虛線，将解決同一個業務問題的限界上下文以切割圖像的方式劃在一起，并以“XXX子域”的形式對每個子域進行命名。
- 根據三種類型的子域定義，共同結合業務實際或者參考設計思維中的電梯演講），确定每個子域的子域類型。
子域劃分的示例如下:
3.2.3.3 業務身份模組化
業務身份由“業務身份 ID”、“業務身份名稱”、 “業務身份要素定義”、“業務身份識别解析規則” 四個部分組成。
其中，業務身份要素定義是最基礎、也是最難的部分。企業應根據自身業務特征對身份要素進行識别定義，常見的身份要素次元包括但不限于：客戶、産品和管道等。
業務身份要素除了對要素次元進行抽取識别，還需要定義每個要素次元所包含的領域對象（包括領域對象的屬性）；這些領域對象及其屬性用來定義業務身份的識别解析規則。實作機制如下:
業務身份模組化的主要步驟如下：
- 分析業務組合，提取業務身份要素次元。
- 确定各業務身份要素次元對應的領域對象（包括領域對象的屬性）。
- 确定領域對象各屬性的取值條件規則，定義業務身份識别解析規則。
- 指定業務身份名稱。
- 指定業務身份 ID。
3.2.3.4 能力模組化
能力模組化分為“基礎能力和擴充點設計”、“能力 元件設計”和“解決方案設計”三個部分，過程順序如下：
3.2.3.4.1 基礎能力與擴充點設計
基礎能力：是對領域對象的原子操作，完成一個領域上單一且完整的職責。比如：建立售後單、修改商品庫存量等。
擴充點與擴充實作：“擴充點”是對基礎能力的可變性設計，在技術側展現為基礎能力實作中的某一個步驟的接口定義，而接口的一個實作為一個“擴 展實作”。比如：訂單渲染基礎能力中有一個步驟 是訂單總價試算，而正常時期的總價試算規則與秒殺時期的總價試算規則是不同的，是以需要對訂單渲染基礎能力設計“訂單總價試算規則”的擴充點， 并分别定義在正常時期和秒殺時期的擴充實作。
不同的業務通過使用同一個基礎能力來達成共享複用的目的，而不同業務在業務規則上的差異性，則通過定義該基礎能力在擴充點上的不同擴充實作來區分。
需要注意的是，通常這套機制需要技術上的開發架構支援。
基礎能力與擴充點設計的主要步驟如下：
- 對流程模組化步驟中輸出的各“任務”下的所有“步驟”，确定其對應的領域對象（注意，該領域對象應來自于前面的領域模組化步驟）。
- 根據步驟對領域對象的操作，設計對應的基礎能力；基礎能力的設計應遵循如下原則：
- 完成對一個領域對象單一且完整的操作職責
- 基礎能力操作的領域對象最大不能超出單個聚合，最小不能破壞業務的一緻性要求
- 基礎能力的輸入與輸出建議對象化，以規範使用
- 根據流程模組化步驟中識别出的與該基礎能力有關的可變點，以及各業務身份在該可變點上不同的業務規則，提煉設計出基礎能力的擴充點
- 确定擴充點的預設實作（即預設情況下基礎能力執行的業務規則）
3.2.3.4.2 能力元件設計
能力元件：是對基礎能力的進一步封裝，目的是友善業務的使用。能力元件加快了業務接入平台的速度，讓業務側專注業務本身，不再需要耗費精力在了解平台大量的基礎能力上。
能力元件按封裝粒度不同分為兩類：
第一類能力元件是根據業務服務的需要編排封裝的一組關聯的基礎能力，進而提供完整的業務服務。
比如：訂單建立能力元件。
第二類能力元件是平台針對一系列緊密關聯的業務活動，設計的能力模闆，可基于該模闆快速定制某個具體業務的特定流程和能力，進而達到複用全部關聯能力的目的。比如：“購物車”、“結算”、“快速建站”等能力元件。
實作機制及示例如下：
基礎能力與能力元件的設計都基于流程模組化和領域模組化的結果，各設計産出要素的對應關系如下:
能力元件設計的主要步驟如下：
- 對流程模組化中輸出的每個任務，設計其所需的業務服務，可采用服務藍圖的方法進行業務服務設計。
- 對每個業務服務，封裝編排滿足其需求的一組基礎能力成為第一類能力元件。
- 對流程模組化中輸出的階段和業務活動進行逐項分析，從價值傳遞和階段性價值傳遞的角度， 識别對應的一系列緊密關聯的業務活動；将這些業務活動包含涉及的所有能力元件和基礎能力封裝定義為第二類能力元件。
3.2.3.4.3 解決方案設計
解決方案：是平台針對一類共性業務的端到端過程設計的能力模闆；可基于該模闆快速定制某個具體業務的特定能力，進而達到業務模式複用的目的。比如：虛拟物品交易解決方案。
從以上定義可以看出，解決方案的核心是對共性業務進行識别提取和對業務全部能力進行模闆化封裝。
解決方案設計的主要步驟如下：
- 識别和提取共性業務。
- 對共性業務進行流程模組化和領域模組化，具體方法參見前面所述。
- 進行基礎能力和擴充點設計。
- 進行能力元件設計。
- 基于通用流程，将共性業務中包含的所有基礎能力、擴充點和能力元件封裝定義為解決方案。
3.2.4 如何複用能力，實作新業務快速上線？
3.2.4.1 多層級複用
在平台化架構中，能力的複用可分為三個層級：
其中“業務能力複用”和“業務模式複用”層級都 對可複用能力的識别和設計提出了要求。是以，基于前面論述的可複用能力建構方法，我們就能實作這兩層的複用效果。
多層級複用為什麼能實作呢？首先在于底層領域模型的設計，有了模組化後的領域對象提供共享的基礎能力，再加上擴充機制，就能實作基礎能力在不同業務上的複用；而經過通用流程的模組化，這些基礎能力又能進一步組裝成更大粒度的可複用能力元件，進而實作局部業務流程的複用；如果業務流程的複用能夠延伸到業務的全流程，即對于同一類共性業務其全流程都能基于一個解決方案模闆定制， 而這個解決方案模闆是其下所有能力元件和基礎能力的封裝，那麼新的業務隻需定制該解決方案模闆即可實作業務模式的複用，快速上線新業務。其關系如下:
3.2.4.2 複用基礎能力和能力元件
在識别和建構了平台的基礎能力和能力元件之後，不同業務就能針對特定的業務需求複用它們并快速定制。方法是對基礎能力下的擴充點進行擴充實作的配置和開發，示例如下：
複用基礎能力和能力元件的主要步驟如下：
- 配置新業務對應的業務身份在各基礎能力擴充點上的擴充實作，如果無需定制可直接采用預設擴充實作。
- 開發基礎能力的擴充實作。
- 根據業務流程，編排基礎能力和能力元件，實作業務需求。
- 對于現有能力不能滿足業務需求的情況，需要平台側新增開發任務，修改或者新增基礎能力和能力元件；然後應用側按上述過程完成定制使用。
3.2.4.3 複用解決方案
對于新業務，如果已建構了其所屬共性業務的解決方案，則可通過複用該解決方案進行業務的快速定制。方法是：基于解決方案的通用流程定制新業務流程，并對基礎能力下的擴充點進行擴充實作的配置和開發。
複用解決方案的主要步驟如下：
- 基于標明的解決方案，配置新業務的業務全流程。
- 配置新業務對應的業務身份在各基礎能力擴充點上的擴充實作，如果無需定制可直接采用預設擴充實作。
- 開發基礎能力的擴充實作。
- 根據業務全流程，編排基礎能力和能力元件， 實作業務需求。
- 對于現有能力不能滿足業務需求的情況，需要平台側新增開發任務，修改或者新增基礎能力、能力元件和解決方案；然後應用側按上述過程完成定制使用。
3.3 業務架構元模型補充說明
在 3.2章節中，我們對業務架構元模型的“Pattern（模式）”部分進行了詳細說明，下面對業務架構元模型的其餘部分進行補充說明；這些部分都可參照傳統業務架構的方法進行設計，此處不再贅述。
3.3.1 業務次元
此次元主要對企業的業務組合管理進行模組化，分析企業各主營業務和輔助業務的關系結構及運作模式。要素如下：
業務群：是企業基于業務戰略拆解，确定開展的特定經營活動。比如：開展 ToC 的電商平台經營活動， 其下又進一步細分為快消品業務群和消費電子業務群等。
業務：是業務群下具有業務價值的業務單元。比如： 實體商品業務、生活服務業務等；内部支撐類的業務比如人力資源管理等。
場景：是面向使用者提供價值的端到端業務場景。通 常 從 4W1H（What、Who、Where、When、How）的次元識别和定義業務場景要素，然後從業務場景要素的排列組合中篩選出有實際意義的業務場景。
3.3.2 流程次元
此次元主要對企業的業務流程進行分層模組化，分析企業如何通過一系列業務活動，按照相關的業務規則将輸入轉換成為有價值的輸出，進而實作使用者價值。要素如下：
階段：即業務流程階段，包含一組使用者的及與使用者互動的業務活動，用以實作階段性價值傳遞的目的。比如：售前、售中和售後等。
活動：即業務活動，是某個業務角色辦理的業務事項，包含一個或一組任務，有明确的業務成果和業務輸出。比如：商品釋出、活動釋出等。
任務：是完成活動的工作程式，是流程的基本組成單元。比如：查詢商品詳情、更新商品庫存、建立訂單等。
步驟：是完成任務的具體步驟，是流程的最原子操作。比如：校驗使用者狀态、校驗商戶狀态、訂單總價試算等。
業務規則：是定義或限制業務某些方面的陳述，旨在維護業務結構或控制或影響業務行為，它描述業務過程與決策過程。比如：if 訂單. 提貨方式=“郵寄” 且 訂單 . 支付狀态 =“已支付”then“建立物流單”。
3.3.3 組織次元
此次元主要對企業的組織體系進行分析。公司組織體系指為了保障戰略和業務規劃落地，以及有效實施業務流程體系，公司采取的組織架構和管控模式。要素如下：
組織單元：是公司組織體系的組成單元。
崗位：是随組織結構設定的，要求個體完成的一項或多項責任以及為此賦予個體的權力的總和。
角色：是業務流程中活動參與者的原型，參與者在流程中的位置通過擔任合适的角色确定。組織為完成某一目标，往往會把此目标分解，以便能交給不同能力和責任的角色合作完成。
3.3.4 服務次元
此次元主要對企業對内和對外提供的業務服務進行模組化分析。要素如下：
業務服務：是企業和企業的每個業務單元為其客戶提供的内部和外部服務。服務是能力對外呈現價值的方式，是具備明确的業務特征，獨立完整、由一個或多個關聯緊密的功能組合的集合。比如：開戶、送出訂單等。
原文： ThoughtWorks釋出《現代企業架構白皮書》 (qq.com)
關注我的公衆号
唯有不斷學習方能改變！
--
Ryan Miao