業務架構——跨領域的統一語言

拾昧館 2019-12-06

展開全文

領域驅動設計的起點一般是企業啟動了一個軟件項目，該項目對應的整個業務范圍就是領域（Domain）。在戰略設計階段，設計人員需要識別核心域/子域，并進一步識別限界上下文以及上下文之間的關系，然后進行領域建模。

業務架構設計的起點一般是企業戰略。例如：某個以直銷為主的企業提出“渠道優先”戰略，目標是用3年時間將渠道銷售收入的占比從當前的20%提升到80%。業務架構人員需要對這一戰略目標進行影響評估，即評估新戰略對企業究竟意味著什么。在這一過程中，業務架構人員需要評估哪些價值流會受到影響，支撐這些價值流的業務能力中有哪些存在差距。通過分析找到對戰略實現最重要且差距最大的價值流和業務能力，并在此基礎上規劃項目或項目組合。

不難發現，業務架構的重點恰好是DDD戰略設計的起點，二者之間必然存在某種聯系。然而，探討業務架構與領域驅動設計的關系有何意義呢？在眾多的DDD實踐中，由于領域專家參與不足等原因，設計人員在戰略設計上投入的精力要遠遠小于他們在戰術設計上投入的精力，這可能導致辛辛苦苦開發出來的軟件無法支撐企業戰略，很快被棄用。而在為數不多的業務架構實踐中，由于缺乏與IT有效銜接的方法和機制，業務架構的輸出只能停留在PPT上，無法落地。如果能夠把業務架構和領域驅動設計結合起來，一方面強化DDD實踐與戰略的銜接，另一方面為業務架構找到落地的方法和途徑，應該是一件很有價值的事情。

1. 業務架構有什么用？

首先，讓我們通過一個虛擬的案例來了解下業務架構有什么用。

Taste Coffee是一家傳統咖啡店（后簡稱TC），從創立至今已有接近50年歷史。這個月TC剛剛啟動了一個軟件項目，希望實現產品的線上銷售。該項目團隊采用領域驅動設計方法。為了更好地理解TC成立“實現線上銷售”軟件項目的背景，讓我們回到半年前，也就是TC的管理團隊剛剛啟動新一輪戰略規劃的時間點。

TC作為咖啡店中的“百年老店”，一直以有競爭力的選址和優雅的環境吸引消費者。但是，隨著人們消費習慣的改變，越來越多的年輕人不愿意在分秒必爭的早上抽出10分鐘去店里買咖啡，而是希望在地鐵上就能夠通過手機下單，到公司樓下時外賣員就已經把咖啡送到自己面前了。為了滿足消費者“在線下單外賣”的訴求，TC管理團隊決定拓展線上銷售業務。他們給自己設定了一個小目標，就是在一年內實現線上訂單金額占總訂單金額的比例達到50%。起初他們有2個選擇，一是開發自己的APP，二是跟互聯網平臺企業（如餓了嗎、美團等）合作。經過反復權衡，TC管理團隊決定選擇后一種方式，即跟互聯網平臺合作拓展線上銷售業務。

戰略一經確定，就輪到TC的業務架構師登場了，他的工作就是對這項新戰略進行影響評估，也就是要搞清楚跟互聯網平臺合作拓展線上銷售對整個TC來說意味著什么？哪些方面存在不足？哪些方面必須調整？等等。

如何理解“影響評估”呢？打個比方，有人想在自家樓頂修建一個游泳池，為了把這個想法變成現實，通常他需要找一名建筑設計師，基于最初的建筑圖紙進行全面、專業的評估，包括整個建筑的結構、承重、管線布局等等，并給出結論：能不能在頂樓修建游泳池，具體建在哪個位置，是否要對整個建筑進行加固，相應的管線布局是否需要調整，等等。如果沒有這樣的評估結論，恐怕沒有哪個施工隊敢接這個活兒。

同樣，任何戰略都是對企業這個運行中的復雜系統進行變更，如果認為線上銷售只對銷售業務有影響，就好像以為在樓頂修建游泳池只要做好防水就行了，這樣的想法是非常危險的！

現在我們了解了對戰略進行影響評估的重要性，那么業務架構師要如何進行影響評估呢？就好像建筑設計師做評估需要建筑圖紙，業務架構師也需要一套業務架構資產，或者叫業務架構藍圖。假設TC已經有一套基線版本的業務架構資產了（這些資產是如何設計出來的，將在“2. 什么是業務架構”中進行闡述），業務架構師將在此基礎上進行影響評估。他發現，與互聯網平臺合作拓展線上銷售主要影響3條價值流：

銷售產品：以前客戶在店里買咖啡，一手交錢一手交貨，不需要派送；現在仍有一部分客戶在店里下單，但另一部分客戶會通過互聯網平臺下單，后者代收貨款并負責派送。因此，需要進一步分析新戰略對渠道管理和派送管理兩個業務能力的影響。
生產產品：以前像是三明治、蛋糕這類產品都是裝在盤子里或紙袋里提供給客戶的，現在則需要在生產環節就進行包裝、保鮮等處理，待收到客戶訂單時才能直接派送。因此，需要進一步分析新戰略對產品包裝能力的影響。
財務結算：以前TC只需要付款給供應商，而現在TC還需要從互聯網平臺收款，同時給互聯網平臺支付服務費，財務結算業務變得更復雜了。

在進一步分析支撐財務結算價值流的業務能力時，TC的業務架構師遇到一些困難。一開始他把收款、付款作為兩個業務能力，正好對應應收（AR）和應付（AP）兩個業務部門，將來可以規劃為2個方案包，分別實現應收和應付的自動化。但有人對此提出了挑戰，認為收款和付款之間本來就有很多共性，如果規劃兩個方案報分別實現自動化，可能會導致重復建設。

經過討論，雙方都認可“收款”和“付款”是2個行為，行為一定能歸結到對象上，因此應該先找到收款和付款行為背后的對象，才能設計出與之匹配的業務能力。經過與相關領域專家反復討論，他們最終達成一致：財務交易（Financial Transaction）、款項（Payment）和財務科目（Financial Account）才是收款和付款背后的對象：

TC跟互聯網平臺收款，意味著一筆款項（如：20萬）被計入收入科目；
TC向互聯網平臺支付服務費，意味著另一筆款項（如：2萬）被計入費用科目；
對應上述2筆會計分錄，卻只發生了1筆財務交易，即互聯網平臺從20萬的貨款中扣住了2萬的服務費，將剩余的18萬轉賬給TC。

這樣，財務交易管理、款項管理和財務科目管理就是財務結算價值流下的3個業務能力了。他們不僅能夠支撐TC與互聯網公司之間的雙向結算，還可以用在銷售產品價值流中，支撐TC跟客戶之間的收款或退款業務。

通過上述分析，TC的業務架構師給出了“實現線上銷售”的項目規劃，其中包括3個子項目：實現客戶在線獲得產品、優化部分產品的生產流程，以及實現財務結算自動化。其中，實現財務結算自動化子項目又可以分為3個方案包，即財務交易方案包、款項方案包和財務科目方案包，分別實現3個業務能力的自動化。

可見，在將戰略轉化為項目的過程中，業務架構師站在整個企業層面進行設計，不局限于部門或項目的邊界，有助于合理地規劃項目，確保項目對準戰略，同時減少項目間可能存在的重復建設。

2. 什么是業務架構？

在上面的案例里，我們了解到業務架構師是如何將戰略轉化為項目的，但并沒有解釋什么是業務架構、如何開發業務架構資產。事實上，很多人對業務架構都有一種說不清、道不明的感覺。因此，在討論業務架構與領域驅動設計的關系之前，有必要澄清一下業務架構的一些基本概念。

簡單地說，業務架構就是對業務的結構化表達。至于什么樣才算“結構化表達”，BIZBOK給出了一個更加具象化的定義，即“業務架構呈現全面的、多維度的業務視角，包括：業務能力、端到端的價值交付、信息和組織結構，以及這些業務視角之間的關系，以及它們與戰略、產品、政策、項目和Stakeholder之間的關系。” 下圖是BIZBOK的業務架構模型，其中內環四個是核心元素，即Capability（業務能力）、Value Stream（價值流）、Information（業務概念）和Organization（組織）；外環是六個擴展元素，即Strategies（戰略）、Initiatives（項目）、Metrics（指標）、Products（產品）、Policies（政策）和Stakeholder（干系人）。本文重點介紹四個核心元素。

2.1 Information（業務概念）

業務概念是將現實世界中的人、事、物進行抽象，并映射到數字世界的一種載體，核心是“抽象”。這里的抽象不是過程抽象，而是本質抽象。例如：產品需求要評審，合同條款也要評審，但“評審”不是業務概念（而是一個操作），“產品”和“合同”才是業務概念。

業務概念的作用在于確保語義的一致性。例如，不同業務領域都存在“需求”這個術語。銷售人員所說的需求與開發人員所說的需求可能非常不一樣，前者一般是指客戶面臨的問題或挑戰（wants and needs），對象是客戶；而后者一般是指產品需求（requirement），對象是產品。在一個需求管理相關的軟件項目中，如果設計人員不能準確區分這兩個概念，可能導致大量無效需求進入開發環節。而這恰恰是業務概念要解決的問題。

2.2 Capability（業務能力）

把一個業務概念和與之相關的操作（或行為）封裝起來，就成了業務能力。這里的操作不是指增、刪、改、查之類的數據庫操作，而是真實業務中對業務概念的操作。例如：員工（Human Resource）是一個業務概念，與之相關的操作包括員工權限管理、員工績效管理、員工薪酬管理、員工風險管理、員工偏好管理，等等。

業務能力的作用在于模塊化。它描述業務“做什么”，同時屏蔽了業務要“怎么做、什么時候做、誰來做”等細節，從而大大提高了共性、穩定性、可復用性。正如前面案例中提到的，無論是TC給互聯網平臺付款，還是反過來互聯網平臺給TC付款，其本質都是對款項、財務科目和財務交易這3個業務概念的操作。

最常見到的對業務能力的誤解，就是把業務能力等同于“技能”。例如，可以說面試是招聘人員的技能，但不能說面試是一個業務能力，因為面試過程中涉及到很多業務概念，以及圍繞這些業務概念的很多操作（即業務能力）：

面試的候選人是一類員工，對應Human Resource Management能力；
候選人具備某種技能，對應CompetencyManagement能力；
候選人面試的是某個崗位，對應Job Management能力；
面試是以面對面或電話會議的方式進行的，對應Conference Management能力；
面試前需要發送信息給候選人，告知對方面試的時間、地點等，對應Message Management能力；
安排面試本身是一個任務，對應Work Management能力；
面試過程中需要遵從一些公司內外部的政策，對應Policy Management能力；
……

2.3 Value Stream（價值流）

價值流描述企業為誰（即Stakeholder）提供什么價值，相當于企業級的業務用例。價值流把企業當黑盒，屏蔽了如何提供價值、有哪些場景、內部如何分工協作等細節，聚焦為誰、提供什么價值。例如，當我們分析TC有哪些價值流時，就要把TC當作一個整體（黑盒），客戶希望從TC獲得產品，那么客戶就是Stakeholder，獲得產品（Acquire Product）就是一條價值流。相對來說，“線上下單”就不是一條價值流，因為無論是線上下單還是面對面下單，客戶的訴求是獲得產品，如果可以不下單就獲得產品，客戶也會很開心。除了“獲得產品”，開發產品（Develop Product）、獲取原材料（Acquire Materials and Assets）、生產產品（ManufactureProduct）、優化庫存（Optimize Inventory）、執行營銷活動（Execute Campaign）等等都是價值流。與執行層面的業務流程相比，業務流程會隨著時間的推移發生變化，但價值流非常穩定，無論是50年前還是今天，“獲得產品”作為一條價值流都不存在任何變化。

一條價值流可以細分為幾個價值流階段。以“獲得產品”價值流為例，可以細分為生成訂單、確認訂單、交付訂單、客戶接收產品這幾個階段，每個階段交付明確的價值項，這些價值項匯總起來，最終交付一個完整的價值，即“獲得產品”。無論客戶獲得產品的方式發生了多么大的變化，這條價值流以及每個價值流階段所交付的價值項是不會改變的。

價值流的作用在于分離關注點。企業是一個運行中的復雜系統，分析復雜系統的關鍵在于能不能將其“切片”，即把一個復雜系統切分成若干個簡單系統。價值流就是把不同Stakeholder的關注點（Concern）梳理出來，就好像把一堆雜亂無章的電線梳理成一條一條的電線，這樣就方便于找出問題到底出在哪條電線上。

2.4 價值流與業務能力的CrossMapping

看完業務能力和價值流，我們再來看看二者之間的關系。如果說價值流描述了“動態的”業務，那業務能力就是描述“靜態的”業務，二者體現了業務的不同維度，它們之間沒有因果關系，只有相關關系。例如，不能說“客戶管理”能力是由“獲得產品”價值流決定的，因為“財務結算”價值流以及其他很多價值流都會用到“客戶管理”能力。

價值流和業務能力之間的相關關系體現為，在每個價值流階段下匹配業務能力，業務能力使能價值流實現價值。以TC的“獲得產品”價值流為例，客戶提出需求階段，肯定需要客戶管理、產品管理能力。如果客戶是通過互聯網平臺提出需求，則還會涉及伙伴管理能力。為及時通知客戶訂單處理的進度，還需要消息管理的能力。通常，價值流階段需要匹配到L2甚至L3的業務能力，這里為了簡單起見，僅僅匹配了L1的業務能力。

2.5 價值流對應子域，業務能力對應限界上下文

看到這里，可能您已經發現，價值流與業務能力的關系與領域驅動設計中的子域與限界上下文的關系非常相似。如果從問題域和解決方案域的角度來審視，可以認為價值流體現的是問題域，即實現線上銷售涉及哪幾個方面的問題；而業務能力體現的是解決方案域，即哪些業務能力才能支撐價值流實現上述價值。同樣，在領域驅動設計中，子域體現的是問題域，限界上下文體現的是解決方案域，那么能否認為價值流就相當于子域、業務能力就相當于限界上下文呢？

我們嘗試用領域驅動設計的方式重新表述一下前面的業務架構分析結論：

獲得產品、生產產品、財務結算三條價值流分別對應三個子域，其中獲得產品子域是核心域，生產產品和財務結算是支撐域；
獲得產品子域包含客戶管理、產品管理、消息管理、伙伴管理等限界上下文；
生產產品子域包含訂單管理、產品管理、原材料管理等限界上下文；
財務結算子域包含訂單管理、財務管理等限界上下文。

可見，價值流對應子域，業務能力對應限界上下文，將業務架構的分析結論匹配到領域驅動設計的戰略設計階段中也是完全成立的。

2.6 Organization（組織）

組織作為業務架構四個核心元素之一，與通常意義上的組織結構類似，只是業務架構不局限于企業內部的組織結構，而是著眼于企業所處的生態，把企業內部組織和外部伙伴在一個模型上呈現出來。

組織在業務架構中的作用恰恰在于，時刻提醒我們，組織只是業務架構中的一個維度，不是全部！業務概念、價值流、業務能力等其他業務架構元素必須以獨立于組織的方式描述業務，跨越組織壁壘往往是業務架構人員面臨的最大挑戰。在過去三年筆者從事業務架構工作的過程中，不止一次地遇到這樣的場景：業務架構師向某業務部門領導匯報能力框架，領導發現某部門沒有體現在業務能力框架上，于是要求業務架構師修改，最終匯報通過的業務能力框架與組織結構一一對應。不僅如此，將來一旦組織結構發生調整，業務能力框架必然要跟著調整。整個過程完美印證了“康威定律”！這樣的業務能力看似每一個都有明確的業務Owner，實際上已經喪失了獨立性，完全違背了業務架構所強調的“全面的、多維度的業務視角”，也不可能在戰略到項目的轉換過程中發揮任何作用。因此，在開發業務架構資產時，應該盡可能地避免受到組織結構的影響。

2.7 小結

用一張圖總結業務架構核心元素之間的關系：

業務能力使用并修改業務概念
組織擁有業務能力
業務能力產出Outcome
業務能力使能價值流階段
價值流細化為價值流階段
價值流交付價值主張
價值流階段交付價值項
價值項匯聚為價值主張
Outcome實現價值項

醫生在診斷患者的病因時，腦子里一定有一套“人體結構圖”，包括血液循環系統、消化系統、神經系統等等。頭痛可能是因為呼吸系統感染引起的，也可能是因為神經系統出了問題。在制訂解決方案前，醫生必須要做出全面的評估，才能確認問題出在哪里，避免“頭痛醫頭，腳痛醫腳”。同樣，企業面臨各種內外部變化，要快速響應這些變化，這就必須有一套“企業結構圖”，從業務概念、業務能力、價值流、組織等不同維度描述企業的業務，以及各維度之間的關聯關系。相當于為物理世界中的企業在數字世界建立模型，從而幫助企業在此基礎上進行變化的影響評估。這就是業務架構。

3. 業務架構與DDD戰略設計的關系

當我們說業務架構時，其實隱含了兩個層面的意思：一是把業務架構當名詞，即業務架構資產，或者叫業務架構藍圖，它把企業當作一個運行中的復雜系統，從不同維度對企業進行建模；二是把業務架構當動詞，即基于業務架構資產進行戰略影響評估，正如前面TC案例中所描述的，任何戰略的調整都可能對企業產生整體的影響，業務架構有助于全面地評估戰略帶來的影響，從而合理地規劃項目，避免不必要的重復建設。

下圖描述了作為動詞的業務架構是如何在企業戰略制訂到實施的過程中發揮作用的，業務架構主要在What階段發揮作用：