基於模型的設計與協調
前面講過了模型轉化爲方案和基於模型的溝通，自然就到了基於模型和業務架構進行的企業級IT系統開發，相信到這一講很多人都會有所期待，畢竟從業務到模型只是一個複雜的“預備過程”，開發纔是大家關注的重頭戲，然而，我不得不以自己六年的企業級項目經驗告訴大家，這裏既沒有什麼神祕，也不該有什麼神祕。可能讓你失望了，但這是事實。爲什麼很多企業，甚至包括科技企業在內，業務轉型或企業級方面做得不理想，其實是因爲一個很簡單的問題——脫節。一開始把企業級或業務轉型搞得“高大上”，請諮詢顧問、搞戰略項目，但是往往停留在企業高層，缺少向執行層面的貫穿，當然也就更談不到傳導到開發，甚至搞戰略時技術人員都很少參與。
搞企業級或者業務轉型，實際上是個“全民工程”，不能只做頂層設計，必須逐級分解；不能只是業務自己想轉型，而是必須拉上技術人員一起研究。轉型不是搞一套新需求，而是要實實在在落地的。而基於模型的企業級業務架構設計方法正是關注戰略到落地的“一氣呵成”。
基於模型的設計
模型驅動開發（MDD）並不是新鮮事物，搞開發的人，尤其是科班出身的開發人員，上學時可能就知道MDD了，特別是UML這類耳熟能詳的需求分析方法；企業架構也有30多年曆史了，就算只以TOGAF爲起點，業務架構也有20多年曆史。雖然業務架構這幾年提的人越來越多，並且大家着手的落地實踐也日益增多，不再覺得業務架構，特別是企業級業務架構只是“畫大餅”，但是，它只是在以往的工程方法之上累積發展起來的，所以，它更多的是對使用者決心和意志有較高要求，而非有什麼點石成金的神奇方法。所有的企業級業務架構都是在痛苦的摸索、懷疑甚至反覆中，靠着“革命樂觀主義”精神和持之以恆的努力，迭代演化出來的，無論最初的設計看起來多出色、多驚豔，終歸也要隨着時代發展更迭，何況大部分的企業級業務架構設計最多隻能算是給出了一個可以被多數人接受的演化起點而已。
基於業務模型進行項目設計在具體方法上可以根據自身企業的特點和習慣去決定實施工藝，但是其過程本質上是對業務模型的細化。業務模型爲了設計企業級業務架構，必然對活動、任務進行適當的抽象，甚至減少一些工作細節，這樣的模型可以讓項目實施團隊瞭解其標準化的核心，以及功能複用方面的設計思路，但是在具體開發中，實施團隊是要瞭解到細節需求的，這與建模過程有一些矛盾之處。對建模而言，需要了解一定的細節，細節有助於判斷抽象的正確性和合理性，但是，建好的模型中卻不能表達太多的細節，過多的細節會讓抽象的表達變得混亂，而且，以後我們還會講到，過多的細節也會讓模型的應用過程笨拙，使維護變得不可能。所以，到了設計階段就必須對模型表達的工作流再細化，這也是爲什麼說業務架構的建模不能替代需求分析的原因。設計階段的細化允許對原有的工作流進行拆分重構，但是有一個前提，就是新產生的元素必須基於舊元素，並且標明繼承關係，這樣才能保證設計的連續性。比如，之前虛擬案例中“獲取新客戶”、“維護老客戶”、“存款”這三個活動，在實際設計中，如果存款部分和客戶管理部分按照組件邊界劃分了項目組，存款項目組負責合約管理組件和賬戶管理組件，客戶項目組負責客戶管理組件，這種情況下，需求分析或者開發人員可能更願意用一個較長流程來表示應用視角，這樣可以更好地描述兩個項目組提供的功能如何在具體的存款業務場景中銜接，而重構後的流程很可能如下圖：
現實場景中，對公客戶經理錄入客戶信息時很可能對方還只是潛在客戶或者客戶並沒有馬上進行開戶操作，而是隔了一段時間之後纔開戶，這時客戶信息可能需要更新。如果是客戶經理首先瞭解到需要變更客戶信息，則會走上邊泳道中流程；如果客戶直接去了櫃檯，櫃員則會首先檢查客戶信息，這時發現需要更新，則可以走下邊泳道這個過程，更新之後再開立賬戶。圖中也可以發現，原本沒有“檢查客戶信息”這個任務，在最初的建模過程中，它是可以寫在開立賬戶這個任務中的，但是在細化流程階段，則可以考慮是不是將其獨立出來。這個取決於整體的架構判斷，如果其他流程中也涉及這種拆分，確實可以調整企業級業務架構模型，如果不涉及或者很少領域涉及，也可以將其標記爲“開立賬戶”任務的衍生。這種細化可能產生新的數據需求，設計新的數據實體，或者在原有的數據實體下產生根據某種維度細分的子實體。
之後就是根據細化了的、已經達到需求分析標準的業務模型，進行大家已經比較習慣的項目開發，設計用例、設計功能或者服務、分組開發、測試上線。但是企業級項目很重要的一點是要建立各階段工作之間明確的銜接關係，尤其是設計元素之間的聯繫，最好能建立“戰略-戰略能力-需求-活動與任務-細化活動與任務-用例-交易或服務”這樣明確的關聯關係，形成一個完整的、分層級的企業能力地圖，當然，這需要工具的支持。其參考邏輯關係如下：
企業能力視圖不能僅侷限於業務側或者到組件層級，而是應該延伸到最終的實現，業務與技術的深度融合是今後企業發展的大趨勢，業務就是技術，技術也是業務，企業未來的作戰地圖必須是基於業務技術一體化的視圖，而非分裂的視角。
基於業務架構的協調
“檢查客戶信息”這個任務的增加，還引出了企業級項目中很常見的另一項工作——跨項目協調。業務模型最初設計時將任務歸類給了各個組件，每個組件都包含了一定數量的任務和數據，從而構成了自己的邊界，這個邊界可以演化成各個子項目的邊界。假定根據業務模型，企業內部已經完成了第一次“爭吵”，所有項目的邊界在下達項目計劃給項目組時，已經暫時接受了，那麼，在進行需求分析產生的這個“檢查客戶信息”任務應該歸誰呢？從流程圖中，似乎挺明顯，它讀取客戶信息數據做判斷，生成判斷結果，按照數據聚類的話，應該歸負責客戶管理組件的項目組實施，尤其是在多個領域都涉及這種拆分時，它的“企業級”屬性看起來比較明顯。但如果涉及的領域很少呢？比如只有存款領域用它，雖然圖中做了簡化，數據實體沒有增加，但在實際需求中，如果要求它不但生成屏顯的判斷結果，還記錄判斷結果並生成推送信息給客戶經理呢？如果這個推送信息又被視爲運營和銷售兩個部門間的溝通呢？數據會增加，而這些數據的歸屬似乎也是模棱兩可的。不但任務的“企業級”屬性模糊了，連數據歸屬都有點兒模糊。如果我們再引入一些常見的影響因素，比如，項目組的預算管理比較嚴格、項目組都面臨工期問題、新加任務識別的較晚等等，在這些因素的作用下，項目組對於這些調整是很不願意接受的，畢竟，企業級項目的一大特點就是，功能誰都能做，誰做了也都可以實現企業級複用，爲什麼就非得拍給我？這就是對基於模型的企業級架構協調工作的考驗，一方面考驗模型本身的質量，而更重要的是考驗人和制度。人指的當然是業務架構師自身的設計和協調能力，架構師提出的調整方案是否具有足夠的說服力；制度指的就是整個企業給企業級項目或者企業級轉型提供的配套管理措施是否到位，項目組對企業級管控的執行是否給力。文中的案例是虛擬的，但在實際工作中，大家難免會遇到類似情況，如果這類問題解決的不好，組件間的不規則“邊緣”會越來越多，而企業級項目協調難度之大，甚至會令一些項目組望而卻步，爲了趕工，寧願多幹活兒、少開會，產生一些連架構層都不清楚的“違章建築”，最終形成一個到處都有“兔子洞”的企業級。
基於模型的企業級業務架構對解決上述問題有多大幫助呢？個人的經驗認爲，最大的幫助在於大家可以用同一種“語言”進行“吵架”，在進行項目協調的過程中，業務模型會很自然地吸引“火力”，它是項目設計的源頭，向上追溯一定會追溯到模型這裏，使大家不再只是“公說公有理，婆說婆有理”，爲最終達成一致結論提供了有益的標靶。而模型也是一種很好的、結構化的結論記錄形式，比起“一紙文書”的會議紀要或者發個內部電郵更容易讓項目組理解和執行。
可能也有人會覺得，形成一個至高無上的強力架構不是更簡單嗎？但是，從實際工作角度來看，一是模型很難一開始就做到十分完善，很難達到可以照做不問的程度；二是，做企業級不是爲了造就新的技術官僚，是爲了打破部門邊界、提升企業能力，所以讓架構自己過於中心化了，反倒不是一個很好的選擇。從這裏引申開去，做企業級項目的成功標誌，我個人認爲不是項目上線，而是業務能力被全面地固定在機構中並且能夠可視化，讓大家都能在一個框架下朝着一個目標努力，不再過分依賴個人，無論是業務還是技術人員，這纔是企業級的真諦。
從設計的角度再說說中臺，中臺其實也不過是個規劃和迭代的結果，如果拋開規模導致的技術複雜度來看，只要堅持企業級的方向或者合理的領域規劃，經過業務設計和沉降過程，產生中臺規劃只是個必然結果，每個企業都能找到屬於自己特點的中臺，而這個“尋找”的過程對企業而言勝過“中臺”這個結果本身。從企業級的視角出發，你也許能夠找到比中臺模式更適合你的組件化結構，而不必沉迷於中臺這個概念。
實施中產生的架構調整
前面已經多次提到了業務架構設計是個迭代的過程，會有不斷的反覆和調整，站在旁觀者或者事後回頭看的角度，這是挺容易理解的，但是在執行過程中，卻是一個需要慎重考慮且非常“煩人”的事情。如果把你擺在業務架構師的位置上，花了好大精力，動用了不少的人力、物力，幾經周折彙報，過五關斬六將地完成了業務架構設計，任務發到了項目組，然後沒過多久，以各類合理不合理的理由被提出種種調整，這當然是件很讓人掉頭髮的事情，作爲企業級項目，這些調整往往涉及的不是一個項目組，而是一條繩上拴着好幾只“螞蚱”，企業級架構管控經常在做些“按下葫蘆浮起瓢”的操作。每每出現這種情況，上上下下都會想爲什麼架構不能直接把事情拍了（當然很多時候還是站在自己立場上想，爲什麼不按我說的拍）？業務架構師自己也會覺得，我說的很在理，我是最站在企業級立場的，爲什麼不乾脆讓我直接說了算？其實業務架構師，如果具有較大權力確實有助於貫徹整體架構，中心化畢竟是一種高效的執行結構，但是中心化的決策方式其實不符合建設企業級項目的目標，上一講最後我提到，理想的企業級項目，實現之後應該達到不對個人的依賴，而過於強勢的架構師自然會導致這種依賴的產生，所以，無論是從職業的角度還是企業級項目目標的角度，架構師都必須接受、鼓勵、坦然應對這種調整要求，當然，這不是要求架構師允許無限制的浪費精力和項目時間，而是首先堅持“以理服人”，再要求對架構設計的貫徹，討論是讓所有項目人員深入理解企業級的過程，這個過程必須，也只能允許反覆和挑戰。基於實施情況進行調整，對業務架構和模型都是有益的，沒有此類反饋的模型，十之八九是沒有被真正使用的模型。
應該做的調整
既然允許調整，又不能無限浪費時間，那我們就來梳理下應當調整的情況：
- 原有架構設計中的疏漏。這一點是架構師們不願意看到，出現疏漏證明了原有工作的缺失，不過， “知漏就改還是好同志”，別給自己找什麼藉口，坦然承認，補充設計，調整架構方案，越是虛懷若谷，越是贏得尊重。項目都是有周期的，每個環節都必須有一定的時限，除了首次做企業級轉型之外，業務架構設計是非常重要卻又不能被分配太多時間的環節，想想對項目的“敏捷”要求，如果讓業務架構師自己慢條斯理地搞起細緻的業務架構設計，相信所有人都會瘋掉。那麼，業務架構師就必須在儘可能短的時間內給出覆蓋度儘可能完整的架構方案，這是對業務架構師的考驗。但是，平心而論，時間越短、信息越少，就越可能出現疏漏，在細化階段發現問題就很正常，自然調整就好，各方都不必苛求。
- 出現了更好的設計。上一講的虛擬案例中就提供了改良的可能性，“檢查客戶信息”這個任務獨立出來，可能會給整個企業級設計帶來一定的改善，方便其他業務領域實現同類需求，這樣的改良就可以回補到模型中，由此帶來的架構調整是有益的。
- 對現實妥協的等價方案。架構設計經常不是隻有一個可行方案，人們常說，架構師就是在手裏永遠準備兩套方案，並隨時準備拋棄其中一套。我個人也經歷過這樣的事情，原本設計時有兩個方案可以選擇，在爲C領域做業務架構設計時，A領域和B領域都有可以採用的會計引擎實現能力，A領域的業務性質與C領域更爲接近，於是做架構設計時選擇了A領域，但是實際推進項目時，負責A領域的項目組由於客觀條件限制，無法按時實現，只好再轉到B領域，兩個方案基本等價，但是架構和模型上必須要做一定的調整，這是現實條件制約的。對了，不要問我爲什麼兩個領域都會有類似的會計引擎實現能力，這是另一種現實。
- 架構設計錯誤。與第一點不同，這是實實在在的錯誤，是架構師們一直竭力避免的情況，這對架構設計和架構師自身能力的可靠性都是直接的挑戰，對此，架構師應當做的就不僅是調整了，更重要的是深入瞭解錯誤原因，總結經驗，反省和提升自我，由此，也看出經驗在架構師綜合素質中的重要性，好的架構師都是時間和項目鑄就的。但是，如果一個架構師經常出現此類問題，就必須考慮對其進行調整了，或是到項目組重新鍛鍊，或是不再讓其擔任架構職責。如果是整個架構師團隊經常出現此類問題，那就很可能是工作機制的原因，是不是架構師沒有機會深入參與到項目過程中去了解項目實際情況？是不是上一講提到的“違章建築”太多，導致架構已經失靈？總之，集體問題與個體問題不同，需要區別對待。
不應該做的調整
以上是幾種應當做的調整，還有些情況則不應當調整，大致如下：
- 明顯違反既有規則的調整。比如客戶統一視圖這類需求，這是典型的跨領域需求，但是又具有一定的領域特性，因爲金融行業中客戶可能同時在多個領域發生業務，但是每個業務條線從自己領域出發，應用客戶視圖時不一定要看所有內容，這就相當於在一個統一的數據基礎上分領域定製，這樣的需求其實由客戶管理組件實現，或者由專門負責數據倉庫、數據主題的項目組實現都可以，因爲客戶管理組件掌握客戶基本信息但未必掌握業務數據，大型企業中，通常會考慮以數據倉庫的方式歸集各組件形成的數據，因此，無論是哪個項目組實現，本質上都是通過數據倉庫加工。但是，分工一旦形成，就不要再隨意調整，如果既定是由客戶管理組件做，特別是客戶管理組件已經實現一部分時，就不能允許客戶管理組件再以各種理由推脫後續需求，把其他需求交給做數據加工的項目組去做，這樣會導致架構的混亂，導致決策原則的不一致，不要輕易推翻已經成爲事實的判斷原則，要通過事實建立共識。
- 不必要的重複造輪子。這樣例子相信在大家都常見到，一般的重複造輪子我們不談了，反對的理由大家也都清楚。還有一類重複造輪子則可能是“企業級”給“逼”出來的，這麼說有點奇怪，有點給企業級“潑髒水”的嫌疑，但是實際工作中確實會遇到，特別是在企業級轉型過程中。企業級項目最大的難度其實是實施過程中的跨項目協調，這時各種利益衝突都會在某種誘導條件下爆發出來，背後的原因即可能是錯綜複雜的，涉及到遺留系統難以拆解、缺乏關鍵業務人員、第三方不配合、技術不過關等非常客觀甚至是由來已久的因素；也可能是簡單到令人無奈的，就是給不想幹找一堆理由，這些令人心力交瘁的協調工作，也可能會“逼”得大家寧可重複造輪子，也不願通過協調解決問題。這種情況，架構管控上也要堅決制止，因爲轉型之路雖艱難，但是開倒車會導致更大的艱難，會讓之前的努力都付之流水。
經過多年的企業級實踐，有時我也會問自己，企業級這麼費勁兒的事情，真的物有所值嗎？坦白地告訴你，無法計算。所謂降低開發成本，這個是常掛在嘴邊，但不一定是企業級要去解決的核心問題，技術五到八年差不多就換代了，節省的成本就算能算出來可以挺幾年？你還得扣除轉型成本。所謂系統互聯互通、數據共享，其實這個是通過對關鍵問題的企業級處理，也就是點上的企業級就可以解決，比如數據標準化加數據倉庫。所謂靈活響應、快速上線，這個更多是開發方式、Devops等關注的內容，畢竟領域之所以爲領域，還是因爲領域之間有差別，可以因共享而提升的反應速度可能是有限的。所以，企業級價值在哪裏？我個人認爲，花費這麼大力氣搞企業級最重要的是轉變企業文化，打破部門邊界，讓企業融爲一體，讓業務與技術融爲一體，這種一體化帶來的企業內部的變化，帶來的高效協作纔是最有價值的，是企業未來長期競爭力的基礎。衡量企業級項目成功的標誌並非單指一個系統的實現，文化沒有轉變、思維沒有轉變，是不會真的誕生這樣一個系統的，即便交給企業一個這樣的系統，也可能會被改回去。做企業級，難點不在技術，企業級真正解決的是業務問題、組織問題、思想問題，是超越技術之上的建立一個什麼樣的企業的問題。企業級業務系統是給具備此類文化的企業使用的配套工具，也是給不具備此類文化的企業提供的一個轉型過程，至於結果，要由時間、感受和市場去檢驗，而非標準。
不同的系統也會反映不同的企業文化，這點如同之前對阿里中臺背後的分析，希望朋友們能夠多去思考和觀察你所能接觸到的系統和使用這些系統的企業。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對複雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型
中臺之上（六）：如何爲一個商業銀行設計業務架構？
中臺之上（七）：不神祕但很麻煩的業務架構落地過程
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。