現代企業架構框架 — 業務架構

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 服務維度

此維度主要對企業對內和對外提供的業務服務進行建模分析。要素如下：

業務服務：是企業和企業的每個業務單元為其客戶提供的內部和外部服務。服務是能力對外呈現價值的方式，是具備明確的業務特徵，獨立完整、由一個或多個關聯緊密的功能組合的集合。比如：開戶、提交訂單等。