|第3章|
架構伴侶：業務模型
業務架構是戰略、流程、組織等業務元素的結構化表達，是以，說起業務架構，自然離不開結構化表達的基本方式—業務模型，是以本章将重點介紹業務模型。
3.1 模型與業務模型
業務模型也是模型的一種，是以我們需要先從模型講起。關于模型的概念，各位讀者可以查到很多種定義，不過，筆者覺得百度上有一種定義比較容易了解：模型是所研究的系統、過程、事物或概念的一種表達形式，也可指根據實驗、圖樣放大或縮小而制作的樣品。
很多人一談起模型就認為模型是抽象的，模型最重要的就是抽象，這種說法對軟體開發人員而言并無不妥，但是對于了解模型的概念而言，還是有些狹隘了。模型也可以是具象的，可以是實物，比如售樓處常見的樓盤模型，古時的工匠為皇家修建故宮、亭台樓榭時，也會先做出精巧的木制模型，而且是與實物構造一模一樣的“高精度”模型。模型不僅可以是真實的事物，也可以是虛拟的，隻要想象力足夠強大，即可建立虛拟模型，比如時下很流行的高達玩具模型、變形金剛等。模型當然也可以是抽象的，比如軟體開發中常用的實體模型、時序圖、狀态圖、用例圖等。圖3-1是幾種不同類型的常見模型。
模型就是一種表達形式，其實我們所說的話也可以視為一種模型，它是我們頭腦中某種想法的表達，表述的過程即可看作是模組化的過程，同時我們的表述還遵循了一定的文法規則。是以，模型其實并不神秘，對于業務人員而言，工作時經常會畫的業務流程圖也是一種模型，與軟體開發中所用的模型相比，無非是存在模組化視角和抽象程度的差别。
了解了模型，我們再來看一下業務模型。套用上文所述的概念，業務模型就是對業務的表達，至于這個業務的範圍就要看實際需要了。如果隻是針對一個産品，那麼業務模型可能就是對産品的設計、生産、銷售、使用、售後管理過程的描述，其中還要包含所有參與方的目标、活動、角色、職責等。如果針對的是一個大型企業，那麼業務模型的範圍就可能包含多條産品線，每條産品線都有不同的業務過程，而所涉及的參與方也會更多、更複雜。
是以，業務模型最主要描述的就是組織及其運作過程。企業的業務模型有一個最高階抽象的三角形，如圖3-2所示。
圖3-2所示的這個三角形可以說是一切盈利性企業的基本行為，企業為生産而投入成本，産品或服務銷售後獲得收入，而衡量企業業績的最基本方法就是計算收入減去成本所得的利潤。
所有企業的行為都可以從這個三角形出發進行分析，比如，一個企業的基本流程可以概括如下。
企業确定向哪些人銷售自己的産品或服務，這就展現了企業自身的價值定位。
- 企業準備組織哪些人進行生産、銷售，在什麼樣的管道上銷售，為此投入什麼樣的資源，這就是企業的生産和銷售流程。
- 收入和成本都需要記賬，這就是财務會計的流程。
- 對利潤實作情況的衡量、盈虧原因的分析等，都展現在管理會計中。
所有的行為都會産生資料，這些資料是我們做系統設計時的必要輸入，是結合業務流程做架構分析的基礎。從這個最高階的核心模型出發，我們可以演化出整個企業的業務過程，可以模型化地創造一個企業，這就是所謂的“大道至簡，衍化緻繁”。
3.2 常見的模組化方法
1. ISO 9000模型
業務人員在業務學習過程中很容易接觸到流程模型，比如ISO 9000品質體系中會使用的流程模型。ISO 9000品質管理體系是國際标準化組織（ISO）制定的國際标準之一，是指由ISO/TC 176（國際标準化組織品質管理和品質保證技術委員會）制定的所有國際标準。該标準可以幫助組織實施并有效運作品質管理體系，是品質管理體系通用的要求和指南。
1992年，我國等同采用ISO 9000系列标準，形成GB/T 19000系列标準，随後，各行業也将ISO 9000系列标準轉化為行業标準。申請ISO 9000品質認證的企業，通常要繪制企業的業務流程圖，流程圖的樣式為垂直職能帶型，通常使用Visio工具進行繪制，參見圖3-3所示的樣例。
ISO 9000模型對業務人員非常友好，但是，将其應用到軟體設計領域，則會出現表達能力比較單一，對技術分析而言有所不足的問題。
2. BPMN模型
BPMN（Business Process Model and Notation）即業務流程模組化與标注，是由BPMI（The Business Process Management Initiative）開發的一套模組化标準語言。2004年5月，BPMI正式釋出了BPMN 1.0 規範，其後，BPMI并入到OMG組織，OMG于2011年推出BPMN 2.0标準，該标準對BPMN進行了重新定義。
BPMN的主要目标是為所有業務使用者提供一些易于了解的符号，支援流程的建立、分析和實作，直到最終使用者的管理和監控。開發BPMN的核心目标就是要建構從面向業務流程模組化到面向IT執行語言的一座橋梁，是以BPMN的出現填補了從業務流程設計到流程開發的空白。
BPMN的工具較多，圖元比較豐富，網上可以很容易地找到一些範例和工具介紹，如圖3-4所示。
作為模組化語言而言，BPMN的表達能力很強，其元素的核心集包括含事件、活動和網關在内的流對象（Flow Objects），含順序流、消息流以及關聯在内的連接配接對象（Connecting Objects），含資料對象、文字注釋群組在内的人工資訊（Artifacts），以及作為圖形化容器的泳道。
BPMN對于業務人員而言需要一定的學習過程，業務人員通過學習不難掌握BPMN，并且還可以将其應用到業務工作中；BPMN對技術端而言，除了可以正常輔助業務分析之外，還可以用于工作流引擎設計。
3. UML（統一模組化語言）
技術人員非常熟悉UML（Unified Modeling Language，統一模組化語言），UML是非專利的第三代模組化和規約語言。UML可應用于一系列最佳工程實踐，這些最佳實踐在對大規模、複雜系統進行模組化方面，特别是在軟體架構層次中已經被驗證有效。
UML體系中包含了3個主要的模型，具體說明如下。
1）功能模型：從使用者的角度展示系統的功能，包括用例圖。
2）對象模型：采用對象、屬性、操作、關聯等概念展示系統的結構和基礎，包括類圖、對象圖。
3）動态模型：展現系統的内部行為，包括序列圖、活動圖、狀态圖。
由于UML在開發中已經廣為使用，是以本書不再贅述其示例。UML對技術人員比較友好，但是其缺點也十分鮮明，就是對業務人員非常不友好。
業務架構的任務是搭建業務與技術之間的橋梁，是以作為業務架構在結構化表達方面不可或缺的工具，業務模型必須同時照顧業務與技術雙方的感受，也即表達能力豐富、兼具業務和技術友好性的模組化方法對業務架構而言更為合适。如果企業在以往的技術實作中已經習慣于采用某種模組化方法，而猶豫是否要進行模型方法層面的大調整，則要考慮如下因素以判斷是否進行該調整。
1）是否可以對原有方法進行改造以彌補缺陷。如果原來的方法太過面向技術端，那麼能否增加面向業務端的合适的展現方式？如果對改造效果的評估或者試驗不樂觀，那麼建議還是切換模組化方法吧。
2）原有的模型成果是否還有複用的價值。如果企業決心進行大規模轉型，那麼原有的模型成果除了提供初期分析的資訊輸入之外，基本上再不會有多大的複用可能性，切換模組化方法也就沒什麼不可以的了。
3.3 模組化原則與模型思維的應用
既然業務模型對業務架構、系統設計如此重要，那麼模組化是否存在什麼“秘籍”呢？很遺憾，沒有。這不僅是筆者個人的了解，不少關于模組化的書中也都提到過，模組化看似有很多種方法、标準可以遵循，但是模型品質尤其依賴模組化者的經驗，是一個“熟練工種”，經驗豐富很重要。
雖然沒有捷徑，但還是有兩個原則需要讀者時刻注意。
第一，整體性原則。做模型切忌快速上手，不要輕易被業務細節吸引，更不要被立馬解決問題的沖動所左右，一定要将問題域（或者說模組化對象）通盤考慮清楚，先有整體輪廓再考慮局部設計。管理課上講溝通時經常會列舉一個“做飛機”的例子，先将聽課的學員分成若幹組，每個組設計飛機的不同部分，比如機首、機身、機翼、機尾，而不給出整體要求，組間也不允許溝通，然後将各組的設計拼接起來，最終很可能就會看到如圖3-5所示的這種結果。
沒有整體性原則做指導，就真的可能會做出不僅飛不起來，而且還極其“醜陋”的飛機。企業中常見到的“豎井式”開發，也會出現這樣的情況，每個子系統獨立工作時都很正常，協作起來就不行，因為原本就沒有按照整體進行過設計。
第二，合适性原則。讀者可能聽過這樣一個比方，将世界上最美的五官湊在一起，并不會成為世界上最美麗的臉，這就是合适性原則。美麗的臉通常是五官比例好、搭配好的臉（如圖3-6所示），也就是說，模型中所包含的各個部分、各類元素要有機地結合在一起，而不能在設計時為了圖新潮、趕時髦，甚至為了模組化者個人的“執念”，放大需求、胡思亂想、生搬硬套，隻想進行“理想”的實作，而不進行“合适”的實作，漠視客觀現實和循序漸進而導緻設計結果的“無用”。
業務模型是為業務架構服務的，是以細心的讀者也一定注意到了，上文所述的這兩條原則其實也是架構設計的重要原則。模組化唯有不斷練習，不斷參與項目實踐，以獲得對模組化成果的重要回報，才能有所提高。設計上經常将不管實作結果的架構師稱作“PPT架構師”，其實模組化也是一樣，若不能在生産環境中得到回報，那麼模組化者也會成為“PPT模型師”，是以說，實踐是理論之源。
做過模組化的人都能了解，認真模組化是一件枯燥又繁瑣的事情，前文中也曾提到過，業務架構設計可以幫助業務人員提升邏輯思維能力，應該讓業務人員多參加。那麼對于廣大業務人員而言，投入這麼大的精力參與這麼枯燥的工作，完結了項目之後，這技能還能用得上嗎？答案是肯定的，雖然業務人員不會在項目結束之後還繼續模組化，但是重要的模型思維卻是終身受用的。
筆者個人總結出的如下3點模型思維是在各類工作中都值得借鑒的。
（1）把握整體
關于把握整體的重要性這裡不再贅述，關于其應用場景，舉例來說就是，對于上司交辦的任何工作，盡可能不要第一時間就“Just do it”，而是要先抽出點時間，考慮下事情的來龍去脈、前因後果，這樣才能控制好工作的度，以免過猶不及。時間和人力是企業最寶貴的資源，不是任何事情都值得投入最大的精力去追求滿分效果，要從整體着眼來評價工作事項，盡量杜絕過度“敬業”對時間和人力的浪費。
（2）穿透現象
露出水面的往往是冰山一角，能夠透過現象看本質是對模組化人員工作能力的基本要求。這種注意事物内在聯系、本質差别的能力，有助于讀者撥開籠罩在現象表面的“迷霧”，找到解決問題的最佳方案。這種思維方式在任何工作中都是可以用得上的。
（3）保證落地
曾經有句流行語：“一切不為業務目的服務的技術都是耍流氓”，這裡套用一下，“一切不考慮落地的架構設計都是耍流氓”。架構不能隻是停留在口頭上，紙面，真正了解架構本質的人，無論做出什麼樣的設計方案，都會以落地實施為前提。對應到日常工作中，就是無論何時何地，各位提出的工作建議都不能隻是“空談”，都要為其實作而負責。落地靠的是經驗、方法、能力，而不完全是信心，是以，工作要慎重，膽大的同時更要心細。
關于模型的一些基礎性介紹先到此為止，本書所講的業務架構都是使用業務模型來建構的。雖然業務架構與模型之間關系緊密，但是必須明白的是，架構不等同于模型，模型也不等同于架構，不要将二者混為一談，架構相當于思想，模型隻是表達。實踐中如果遇到問題，一定要先想清楚原因，不要因為模型表達方式不理想而認為架構無用，也不要因為架構設計不理想而埋怨模型。
目前主流的軟體設計方法其實都是MDD（Model Driven Develo-pment，模型驅動開發）形态的，無非是模組化工具、模組化方法的差異，即使是火熱的中台模式，其設計過程也離不開模型方法。