中臺之上（二）：為什麼業務架構存在20多年，技術人員還覺得它有點虛？

業務架構這個詞大家時常聽到，但是能解釋得清楚的卻不多，撩撩度娘，你就會發現，不少人問及業務架構和應用架構的關係，聊天時，也常有人問起業務架構師和產品經理什麼區別？業務架構分析和需求分析什麼區別？為了思考這個問題，我把《軟體工程》、《軟體系統架構》、《系統分析與設計》都翻了，這些經典教材確實沒講過業務架構這件事；我把《聊聊架構》也翻了，發現其中的討論有解釋到業務、架構和技術的關係，但是也沒有特別強調業務架構，所以本文就先梳理下幾個較為有名的業務架構理論。

Zachman模型

其實，業務架構這個詞並不新，它隱藏在企業架構（EA）中。企業架構是上世紀80年代的產物，其標誌就是1987年Zachman提出的企業架構模型，該模型按照“5W1H”，即what（資料）、how（功能）、where（網路）、who（角色）、when（時間）、why（動機）六個維度，結合目標範圍、業務模型、資訊系統模型、技術模型、詳細展現、功能系統六個層次，將企業架構分成36個組成部分，描述了一個完整的企業架構要考慮的內容，詳圖如下：

​
資料來源：網路

Zachman模型雖然沒有明確提出業務架構這個概念，但是已經包含了業務架構關注的一些主要內容：如流程模型、資料、角色組織等，既然沒有提出業務架構概念，自然也就沒有包含構建方法，所以，Zachman模型應該算是業務架構的啟蒙，同時，它也表明了這一工具或者技術的最佳使用場景——面向複雜系統構建企業架構。

TOGAF

1995年，大名鼎鼎的TOGAF登場了，這個在企業架構市場中據說（2009年統計）佔了半壁江山的架構模型明確提出了業務架構的概念。TOGAF將企業定義為有著共同目標集合的組織的聚集。例如，企業可能是政府部門、一個完整的公司、公司部門、單個處/科室，或通過共同擁有權連線在一起的地理上疏遠的組織鏈。TOGAF進一步認為企業架構分為兩大部分：業務架構和IT架構，大部分企業架構方法都是從IT架構發展而來的。業務架構是把企業的業務戰略轉化為日常運作的渠道，業務戰略決定業務架構，它包括業務的運營模式、流程體系、組織結構、地域分佈等內容。TOGAF強調基於業務導向和驅動的架構來理解、分析、設計、構建、整合、擴充套件、執行和管理資訊系統，複雜系統整合的關鍵，是基於架構（或體系）的整合，而不是基於部件（或元件）的整合。TOGAF還提供了一個詳細的架構工件模型：

資料來源：百度

其中可以明確看到業務架構階段的交付物。相信很多對架構有興趣的朋友都認真學習過TOGAF模型，此處不再贅述。

FEA和DODAF

TOGAF之後，又先後誕生了FEA（聯邦企業架構）和DODAF（美國國防部體系架構框架）。前者的體系由五個參考模型組成：績效參考模型（PRM）、業務參考模型（BRM）、服務構件參考模型（FRM）、資料參考模型（DRM）、技術參考模型（TRM），該方法應用於美國電子政務領域，著眼於跨部門、跨機構提升業務效率，解決重複建設、資訊孤島等問題，很具有“企業級”理念，雖然沒有明確的業務架構定義，但是很好地應用了業務架構的思維。後者體系挺複雜的，8個視點52個模型，但是實用性不錯，美國國防部和一些企業在用，詳細內容如下：

資料來源：網路

其中能力視點和作戰視點就是我們做企業時關注的業務部分。這兩個模型網上有相關資料，感興趣的話可以自行查閱。

為何沉悶至今？

通過尋根溯源，可以發現，即便從TOGAF算起，業務架構這個詞也有20多年的歷史了，但是在開發人員中，業務架構顯然沒有需求分析的概念明確，業務架構師也遠不如產品經理常見。作者所在單位曾經實施了一個長達數年的企業級轉型專案，其中有明確的業務架構組織，但是，每每與技術人員討論，他們也常覺得業務架構有點兒“虛”。細究其原因，可能有如下幾點：

1. 用的少。原有的單體式或者豎井式開發依然是大家更經常採用的專案構建方法，而這種開發基本上沒有橫向視角，所以無需強調業務架構，通常的產品分析或者需求分析足以滿足開發需要；
2. 難設計。業務架構，特別是大型企業這種錯綜複雜的業務架構，說起來容易做起來難，業務架構對戰略的分解、業務架構自身的整合與標準化、到IT設計的過渡都有不少坑，業務越複雜越寬泛就越難駕馭，因此，即便做過業務架構設計的企業，也有不少將業務架構設計保持在高階狀態，有點兒“虛”；
3. 易跑偏。施工期間由於客觀因素可能導致實施對業務架構的偏離，這種偏離如果沒有及時糾正或者調整架構，累積久了會造成業務架構的失真，會變“虛”；
4. 難維護。少數扛過了業務架構落地困難期的企業，也會由於感受到維護架構的難度而心生放棄，從而降低了對業務架構的評價。

其實，業務架構從誕生之初就很清楚地定義了自己的使命：面向複雜系統構建。也就是說，業務架構同其他架構一樣，目的也是要降低複雜度，更好地規劃系統，因此TOGAF是將業務架構歸屬於IT戰略部分。但是從本人的實踐經驗看，業務架構不僅具有上述作用，其更突出的影響是對參加過業務架構設計工作的業務人員的影響，他們的邏輯思維能力、結構化能力、企業級觀念和意識都有明顯的改變，所以，應當將業務架構從IT戰略中獨立出來，更多面向業務人員，以充當業務與技術之間的橋樑。當然，業務架構真正要承擔起這一職責，還需要改進、簡化業務架構設計方法，對業務人員更友好，並且堅持使用業務架構方法做企業級需求管控，否則，熵增一定會將已經建好架構秩序迴歸混沌狀態。

中臺說到底也是一種業務架構設計結果，回顧軟體設計的發展歷程，中臺也不是石頭中蹦出來的齊天大聖，它並非一種超越了企業架構這個概念的存在，因此，想要深入理解中臺設計方式，多去學習下業務架構、軟體架構的發展歷程還是有幫助的。

架構伴侶：業務模型

業務架構是戰略、流程、組織等業務元素的結構化表達，因此，說起業務架構，自然離不開業務模型，所以，本章我們講講架構的伴侶——業務模型。

模型與業務模型

業務模型也是模型的一種，因此我們先從模型講起。模型的概念大家可以查到很多種，不過，度娘上有一種是我覺得比較容易理解的，這個解釋中說，模型是所研究的系統、過程、亊物或概念的一種表達形式，也可指根據實驗、圖樣放大或縮小而製作的樣品。很多人一說起模型都喜歡說模型是抽象的東西，模型最重要的是抽象，這個說法對軟體開發人員而言並無不妥，但是對於理解模型這個概念而言，還是有些狹窄了。模型可以是具象的，可以是實物，比如售樓處常見的樓盤模型，我們的老祖宗修故宮、給皇帝家造亭臺樓榭時，也會先做出精巧的木製模型；模型不僅可是真實事物，也可以是虛擬的，只要腦洞開的夠大，比如很流行的高達玩具模型、變形金剛等；模型當然也可以是抽象的，比如軟體開發中常用的實體模型、時序圖、狀態圖、用例圖等等。例子參見下圖：

​
模型就是一種表達形式，其實說出來的話也可以視為一種模型，它是你頭腦中的想法的表達，說的過程也就是個建模過程，還遵循了一定語法規則。所以模型不是個神祕的東西，對於業務人員而言，工作時候經常會畫的業務流程圖也是模型，與軟體開發中用的模型相比，無非是個建模視角和抽象程度的差別。

理解了模型，我們再來看看業務模型。套用上邊的概念，業務模型就是對業務的表達，至於這個業務的範圍就看你的需要了，如果只是針對一個產品，那業務模型可能就是對產品的生產、銷售、使用、售後管理過程的描述，其中還要包含所有參與方的目標、活動、角色、職責等等；如果針對的是一個大型企業，那業務模型的範圍就可能包含多條產品線，每條產品線都有不同的業務過程，而涉及到的參與方也會更多、更復雜。所以，業務模型最主要描述的就是組織及其運作過程。企業的業務模型有一個最高階抽象的三角形，如下：

這個三角形可以說是一切盈利性企業的基本行為，企業為生產而投入成本，產品或服務銷售後取得收入，而衡量企業業績的最基本方法就是通過收入減去成本形成的利潤。其實所有企業的行為都可以從這個三角形出發去分析，比如，一個企業基本流程就可以概括為：

企業準備向哪些人銷售自己的產品或服務，這就體現了企業自身的價值定位；企業準備組織那些人生產，組織哪些人銷售，在什麼樣的渠道上銷售，為此投入什麼樣的資源，這就是企業的生產和銷售流程；收入和成本都需要記賬，這就是財務會計的流程；對利潤實現情況的衡量、盈虧原因的分析等，體現在管理會計中；所有行為都會產生資料，這些資料是我們做系統設計時的必要輸入，是結合業務流程做架構分析的基礎。從這個最高階的核心模型出發，我們可以演化出整個企業的過程，可以模型化地創造一個企業，這就是“大道至簡，衍化致繁”吧。

建模原則與模型思維的應用

既然業務模型對業務架構、對系統設計如此重要，那麼建模是否有什麼訣竅呢？很遺憾，沒有。這不僅是我個人的理解，不少關於建模的書中也都會提到，建模看似有很多方法、標準可以遵守，但是模型質量卻十分依賴於建模者的經驗，是一個“熟練工種”，“老司機”很重要。雖然沒有捷徑，但還是有兩個原則可以時刻注意的：

1. 整體性原則。做模型切忌快速上手，不要快速被業務細節吸引，更不要被立馬解決問題的衝動左右，一定要將問題域或者說建模物件放在一個更大的環境中觀察，要先找到建模物件的邊界，也就是上下文環境。搞不清邊界，就搞不清範圍，即不知道起止，也不知道思慮是否周全，甚至無從檢驗建模成果，容易一葉障目，不見森林。
2. 合適性原則。大家可能都聽說過一個比方，把世界上最美的五官湊在一起，並不會成為世界上最美麗的臉，這就是合適性原則，美麗的臉通常是五官比例好、搭配好的臉，也就是說，模型中包含的各個部分、各類元素要有機結合在一起，不能在設計時為了圖新潮、趕時髦，甚至為了建模者個人的“執念”，生搬硬套，強買強賣，忽視了模型的平衡。

業務模型是為業務架構服務的，所以細心的讀者也一定注意到了，這兩條其實也是架構設計的重要原則。建模唯有不斷練習，不斷參與專案實踐，以獲得對建模成果的必要反饋，才能有所提高，設計上我們經常把不管實現的架構師比作“PPT架構師”，其實建模也一樣，不能在生產環境中得到反饋，建模者也會成“PPT模型師”，所以，“實踐是理論之源”啊。

經歷過的人都知道，認認真真建模是項枯燥繁瑣的事情，而且，我也提到，業務架構設計可以幫助業務人員提升邏輯思維能力，應該讓業務人員多參加，那麼廣大業務人員也會疑慮，投入這麼大精力參與這事兒，做完了專案，這技能還用得上嗎？肯定用得上啊，雖然不會到處去建模，但是重要模型思維可是非常有用的，我個人總結，有這麼三點是在各類工作中都值得借鑑的：

1. 把握整體。這條不再贅述，應用上，我建議，對於任何領導交辦給你的工作，儘可能不要第一時間就“Just do it”，而是要擠出點時間，考慮下來龍去脈，前因後果，這樣你才能控制好工作的度，過猶不及啊。
2. 穿透現象。浮在水面上的往往是冰山一角，透過現象看本質是我們對建模人員的基本要求，這種注意事物內在聯絡、本質差別的能力，有助於你撥開現象的迷霧，找到最佳的解決方案。
3. 保證落地。前一陣子曾經流行過一句話“一切不為業務目的服務的技術都是耍流氓”，套用一下，“一切不考慮落地的架構設計都是耍流氓”，架構不能飄在天上，印在紙上，所以，真正瞭解架構本質的人，無論做的是“矮窮挫”的搬磚方案，還是“高大上”的傳奇方案，都要以落地為前提，對應到日常工作中，就是我們無論何時何地提出的工作建議都不能是“空談”。

中臺的表達方式其實也是一種模型化表現方式，畢竟當前的軟體設計基本都是“模型驅動開發”，無非是模型工具的差別。關於模型的一些基礎性介紹先到此為止，本文所講的業務架構都是使用業務模型來構建的。
​\t
相關文章：中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”

作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、專案管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級專案業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公眾號：曉談巖說。