大型商業(yè)銀行的業(yè)架構轉型實踐

1、 Page * MERGEFORMAT 15大型商業(yè)銀行的業(yè)架構轉型實踐目 錄 TOC o 1-3 h z u HYPERLINK l _Toc45008779 1.業(yè)務與 IT 之間的橋梁 PAGEREF _Toc45008779 h 3 HYPERLINK l _Toc45008780 2.銀行業(yè)務架構的演變 PAGEREF _Toc45008780 h 4 HYPERLINK l _Toc45008781 3.銀行業(yè)務架構設計和實踐 PAGEREF _Toc45008781 h 6 HYPERLINK l _Toc45008782 4.業(yè)務架構設計的難點 PAGEREF _Toc4500

2、8782 h 9 HYPERLINK l _Toc45008783 5.業(yè)務架構設計中的 trade-off PAGEREF _Toc45008783 h 11隨著云計算、大數據、區(qū)塊鏈和 AI 以及移動互聯(lián)等新一代信息技術的發(fā)展，企業(yè)數字化轉型加速。市場在變，需求也在變，面對高度創(chuàng)新和充滿不確定性的敏態(tài)業(yè)務，為快速交付高質量的軟件產品或服務，企業(yè)需要有更好的業(yè)務架構設計，去適應不同階段的業(yè)務特性。何為業(yè)務架構設計？企業(yè)的業(yè)務架構設計需要考慮哪些因素？業(yè)務架構設計的難點和挑戰(zhàn)是什么？企業(yè)應該如何權衡？面對這些問題，InfoQ 記者采訪了 QCon 全球軟件開發(fā)大會 2020（北京站）的講師、企

3、業(yè)級業(yè)務架構設計：方法論與實踐一書作者建信金融科技有限責任公司付曉巖老師，請他從企業(yè)級業(yè)務架構設計實踐者的視角聊聊這些問題。2000 年大學畢業(yè)后，付曉巖就加入建設銀行。從業(yè) 20 年，12 年在業(yè)務領域，8 年在 IT 領域，他的腳步遍及支行、分行、總行、子公司等建行內部各層級機構。進入 IT 領域后，付曉巖近乎全程經歷了建設銀行規(guī)模宏大的企業(yè)級轉型項目，并在項目中得到歷練，從而成長為一名資深的企業(yè)級業(yè)務架構師。業(yè)務與 IT 之間的橋梁IT 設計的真正目標是實現(xiàn)企業(yè)的價值。業(yè)務和技術應該是統(tǒng)一的、一體的，它們都是企業(yè)的有機組成部分。在付曉巖看來，業(yè)務架構是業(yè)務與 IT 之間的橋梁。不管規(guī)模大

4、小，企業(yè)都是一個整體，其生存、發(fā)展都依賴于企業(yè)形成內外部合力的能力，而這一能力的形成有賴于構建適宜其戰(zhàn)略執(zhí)行的企業(yè)架構（EA，Enterprise Architecture）。他認為，一個好的架構有利于企業(yè)戰(zhàn)略的執(zhí)行，尤其是數字化轉型。數字化轉型是業(yè)務與技術的深度融合，而融合需要機制，需要二者建立有效連接，業(yè)務架構正是這種連接方式?！皯?zhàn)略通過業(yè)務架構分解到業(yè)務流程，并將業(yè)務能力體系化、結構化地分解到企業(yè)的各個業(yè)務部分，再轉化為 IT 需求，通過與業(yè)務目標匹配的 IT 架構完成技術實現(xiàn)，將企業(yè)的戰(zhàn)略和能力、業(yè)務和技術有機串聯(lián)起來，構成一個協(xié)同整體。這就是業(yè)務架構乃至企業(yè)架構的使命?！案稌詭r表示。

5、銀行業(yè)務架構的演變 從自己的經歷出發(fā)，付曉巖闡述了銀行業(yè)務架構的演進。相比其他行業(yè)，銀行是信息化起步較早的。并且，大型銀行組織結構復雜、技術開發(fā)投入高、應用范圍大，因此，大型銀行在架構發(fā)展歷程上很有代表性。以國內銀行為例，其在架構方面的發(fā)展歷程如下：80 年代：分散架構 20 世紀 80 年代后半期，銀行開始引入主機系統(tǒng)，這時構建的業(yè)務系統(tǒng)“高度”分散。每個地級市都有自己的業(yè)務系統(tǒng)，不同城市間的業(yè)務無法聯(lián)通。以一筆匯款業(yè)務為例，現(xiàn)在是實時轉賬、零級清算、秒級到賬，而過去是多級清算?？绲貐^(qū)匯款，從一個城市的網點到自己的市分行，市分行到省分行，省分行到總行，總行到目標地的省分行，省分行到市分行，市

6、分行到網點?？上攵?，這種方式效率極低。90 年代：大集中架構 90 年代末，隨著計算機性能的提升和網絡的發(fā)展，銀行對數據集中的需求越來越強烈，因為先有數據集中才能實現(xiàn)業(yè)務集中。因此，銀行的大集中架構拉開帷幕。付曉巖表示，“大集中可以構建全行統(tǒng)一的業(yè)務系統(tǒng)，這對業(yè)務效率的提升是不言而喻的，但與此同時帶來的問題逐漸顯露，即豎井式開發(fā)、煙囪林立的問題?！?011 年左右：企業(yè)級架構 據付曉巖介紹，建行在 2011 年開始進行企業(yè)級轉型，設計全行統(tǒng)一的企業(yè)級架構，包括企業(yè)級業(yè)務架構和 7 層 12P 的企業(yè)級系統(tǒng)架構。2017 年，整個工程結束，建行內部一體化初步完成。數字化時代：開放式架構 不過，

7、架構的演進不會就此“打住”，內部統(tǒng)一后，銀行更重要的是適應面向數字化時代的開放與融合要求，深度參與到生態(tài)建設中。這一階段是開放式架構，真正從社會分工、生態(tài)分工的角度，結合生態(tài)伙伴、客戶情況，綜合分析架構解決方案。其設想如下圖所示：付曉巖指出：數字社會必定是一個與今日大不相同的“新時代”，無論是企業(yè)，還是個人，所有參與者都將迎來一個轉型過程。對企業(yè)而言，架構”新時代“的到來是注定的，這個”新時代“一定是業(yè)務架構與技術架構、業(yè)務與技術深度融合的時代。銀行業(yè)務架構設計和實踐 考慮因素 第一，目標的匹配性 企業(yè)需要清晰了解目標是什么？要解決的問題是什么？架構設計不是為了概念而設計，企業(yè)不是為了做業(yè)務架

8、構而做業(yè)務架構，也不是為了上“中臺”而上“中臺”，都是為了解決問題。付曉巖表示，“目的與手段要相匹配，目標的大小決定了業(yè)務架構設計的力度?！钡诙Y源的適配性 企業(yè)級業(yè)務架構設計不僅需要投入業(yè)務和技術人員，而且還需要有經驗的業(yè)務架構師進行指導以逐步培養(yǎng)公司自身的業(yè)務架構師?！坝捎跇I(yè)務架構領域還比較小眾，有經驗的企業(yè)級業(yè)務架構師很少，更多的是技術架構師。像一些失敗的中臺項目一樣，沒有與目標匹配的資源也是項目成敗的關鍵?！彼硎尽．斎?，即使有了業(yè)務架構師，如果沒有足夠數量的企業(yè)業(yè)務和技術人員配合，業(yè)務架構師也不能編出“架構”來。第三，時間的適配性 企業(yè)級業(yè)務架構設計不能也不該很快，這是對企業(yè)自身的

9、深入解讀和對未來的嚴肅規(guī)劃。它需要一定的時間投入，如果抱著“吃快餐”的心態(tài)，那項目質量很難保證。雖然架構設計不是一次搞定，需要演化，但是要為“打地基”投入合理時間。第四，耐力的匹配性 這里的”耐力“指的是堅持以企業(yè)級業(yè)務架構為核心，長期驅動企業(yè)業(yè)務管理、IT 管理的耐力。付曉巖認為，企業(yè)級業(yè)務架構是一種“秩序”，而“秩序”的維護需要耐力，如果沒有堅持的定力，那一次性的成功，很可能換不回企業(yè)的投入。企業(yè)需要的是維持持久的競爭力，也自然需要耐力上的付出。業(yè)務架構設計的三個階段 以銀行為例，其在進行業(yè)務架構設計中一般有幾個階段。首先，建立明確的企業(yè)級業(yè)務架構設計工程項目，并任命強有力的行級領導進行統(tǒng)

10、一管控，將相關業(yè)務部門、技術部門全部拉入工程項目，以確保決策能力和執(zhí)行能力。無論國內還是國外，企業(yè)級項目都是“管理者工程”。其次，進入項目過程，這時要明確戰(zhàn)略目標，即銀行針對多少年的戰(zhàn)略目標進行架構設計，確定戰(zhàn)略目標是什么，戰(zhàn)略目標對應的戰(zhàn)略能力有多少，目標越大，需要分解的能力自然越多。然后，形成現(xiàn)狀模型。將銀行現(xiàn)有的業(yè)務流程模型化、結構化，通過統(tǒng)一的企業(yè)價值鏈進行分類、整合、標準化，并將戰(zhàn)略能力分解到現(xiàn)狀模型中，將模型與戰(zhàn)略對齊，識別需要改變的業(yè)務流程，這就產生目標模型。付曉巖指出，盡可能在架構設計過程中，將全行統(tǒng)一的數據模型一并設計出來，然后結合數據模型和流程模型，提升標準化程度，設計出業(yè)

11、務組件。最終形成包括戰(zhàn)略、戰(zhàn)略能力、流程模型、數據模型、組件模型的企業(yè)級業(yè)務架構。業(yè)務架構設計雖然不求快，但也要注意合理控制時間，“一到兩年是比較合適的首次建模周期”。建行業(yè)務架構設計實踐：六年磨一劍 2011 年到 2017 年，建行進行的“新一代核心業(yè)務系統(tǒng)”建設項目，正是通過企業(yè)級業(yè)務架構設計驅動的，也被稱為“六年磨一劍”。整個實踐，先從戰(zhàn)略定位開始，分析建行的十二五、十三五規(guī)劃，確定全行的整體戰(zhàn)略目標。并且，還將戰(zhàn)略目標分解為更細的戰(zhàn)略能力舉措和更細粒度的戰(zhàn)略能力需求，“其目的是為了讓戰(zhàn)略落地具有更清晰、操作性更強的要求”。其次，進入現(xiàn)狀建模和目標建模階段。這是將建行實際的業(yè)務和改進舉

12、措與戰(zhàn)略對齊的過程。經過這樣的模型設計過程，包括價值鏈、流程模型、數據模型、產品模型、用戶體驗模型和業(yè)務組件在內的整體業(yè)務架構設計和架構資產即形成。據悉，總體架構設計大約花費 2 年時間，這與建行龐大的體量和業(yè)務復雜度有直接關系。同步完成的還有適配整體業(yè)務要求的技術架構，即 7 層 12P 的方案。然后，開始根據企業(yè)級業(yè)務架構和技術架構進行具體項目落地。整個企業(yè)級轉型總體分為三期，每期也有不同的小周期，由轉型項目的 PMO 統(tǒng)一管控進度。期間，還進行了海外建模，即實現(xiàn)全球架構一體化的海外模型設計及海外實施。2017 年，建行公開宣布工程結束。據公開信息介紹，實際落地 114 個業(yè)務組件、整合設

13、計 900 余個業(yè)務活動、標準化 4500 余個任務、3000 余個數據實體、150 余個基礎產品和 1 萬余個可售產品，“在世界銀行領域，這是首次完成如此大范圍和深度的企業(yè)級業(yè)務架構設計與實施”。業(yè)務架構設計的難點技術難點：標準化 從技術層面講，業(yè)務架構設計最大的難點是標準化。標準化是判斷服務異同和顆粒度的重要依據，這是各類架構設計中的難題。建模離不開標準化過程，做企業(yè)級模型要橫向對比企業(yè)所有業(yè)務領域，以期望在設計上實現(xiàn)“以更少支持更多”，并實現(xiàn)快速的靈活響應和減少重復開發(fā)這兩個目標。業(yè)務架構模型的標準化包括數據標準化、任務標準化兩部分，這兩者相輔相成，通過數據間的比較可以更好地進行任務標準

14、化，而通過與任務的結合也能更好地判斷數據定義是否準確、數據標準化是否到位。除了技術挑戰(zhàn)，還有諸多工程難點。工程難點 1：捷徑難尋 了解 DDD（領域驅動設計）的人可能知道，DDD 對企業(yè)級不抱太大希望，認為企業(yè)級的建設路徑只能是一個領域一個領域的不斷嘗試融合，無法通過自上向下的規(guī)劃產生。在付曉巖看來，金融領域恰恰是一個很不“專業(yè)”的專業(yè)，里面的東西五花八門，看似都在一個領域，實則“千差萬別”，各類業(yè)務的共性在于客戶（同一群客戶），圍繞客戶共建一個賬戶體系。換句話說，如果自上向下看，客戶和賬務應該是企業(yè)級的，而其他部分，需要一個領域一個領域的研究，這也是建模和標準化的難點。因此，企業(yè)架構建設的難

15、度跟企業(yè)所在行業(yè)的特點有直接關系。沒有一個通用的企業(yè)級業(yè)務模型可以隨便套，“阿里的業(yè)務架構套不到銀行頭上，銀行的業(yè)務架構也套不到阿里頭上”，甚至一個行業(yè)內，企業(yè)跟企業(yè)間內部特點的差別，也會決定企業(yè)架構建設路徑和結果的不同。沒有簡單復制的模式能幫你快速切換到企業(yè)級，“自己的路只能自己走”。但是，需要所有從業(yè)人員共同探索的，也恰恰是如何構建成熟的行業(yè)級模型，這是未來實現(xiàn)大規(guī)模軟件生產的關鍵。工程難點 2：文化難建 多數情況下，企業(yè)級不是一個單純的技術問題，這讓技術人員非常為難，因為這根本不在其能力范圍內。如果是一個業(yè)務種類繁多、部門龐雜、等級森嚴的傳統(tǒng)企業(yè)，建企業(yè)級相當于對部門邊界、協(xié)同關系的重新

16、界定，它對企業(yè)文化的依賴和改變都很強。工程難點 3：權責難定 在組織中，一件事情能做好，前提是做事的人權責匹配。但是，架構定位的困難在于，權力太小，不足以維護企業(yè)級；權力過大，又會發(fā)展成新的部門化組織，可能會導致架構決策行為方式出現(xiàn)“僵化”。建立合適的集體決策機制很重要。工程難點 4：長志難立 企業(yè)級（項目）的長期堅持是件難事，它的放棄和崩壞不一定是是架構組織撤銷、機制停掉這么激烈的動作，而是各種“畏難情緒”、“客觀原因”導致的緩慢的無序，它是一個個需求的分配、落地的偏離堆積產生的。并且，“破窗效應”對它的影響也很明顯?？傊?，一定不要搞“一次性”的企業(yè)級工程。業(yè)務架構設計中的 trade-of

17、f 在業(yè)務架構設計中，企業(yè)除了“直面”挑戰(zhàn)，還要權衡諸多事宜。付曉巖認為，業(yè)務架構設計是個迭代的過程，要允許反復和調整，不能武斷，沒有耐心。首先，不能允許簡單的“拍”結構。架構師必須具有開放性，保持謙虛。架構師是“中心”，但不要總把“權威”看得太重，架構是企業(yè)整體資產。從某種角度說，企業(yè)做架構正是為擺脫對特定架構師的“單點依賴”，讓架構工作能保持“業(yè)務連續(xù)性”。因此，架構設計要保持這種謙遜，這樣才能讓更好的設計思路進入設計師的視野，進入設計方案。其次，允許什么樣的架構調整。1.查漏補缺。項目有周期，每個環(huán)節(jié)都有一定時限。除首次做企業(yè)級轉型外，業(yè)務架構設計是很重要卻又不能被分配太多時間的環(huán)節(jié)。因

18、此，業(yè)務架構師必須在盡可能短的時間給出覆蓋度盡可能完整的架構方案。但是，時間越短、信息越少，就越可能出現(xiàn)疏漏。在細化階段發(fā)現(xiàn)問題很正常，自然調整就好。2.發(fā)現(xiàn)更好在實施階段，由于輸入的細節(jié)通常比業(yè)務架構設計階段更多，并且不排除在實施階段發(fā)現(xiàn)更好的做法，這樣的改良可以重寫到業(yè)務架構中，由此帶來的業(yè)務架構調整是有益的。3.現(xiàn)實妥協(xié)架構設計經常不僅僅只有一個可行方案。架構師手里永遠準備著兩套方案，隨時可以拋棄其中一套。比如，原本設計時有兩個方案可以選擇，在為 C 領域做業(yè)務架構設計時，A 領域和 B 領域都有可以采用的實現(xiàn)能力。A 領域的業(yè)務性質與 C 領域更為接近，于是架構設計時選擇 A 領域，但

19、實際推進項目時，負責 A 領域的項目組由于客觀條件限制，無法按時實現(xiàn)，只好再轉到 B 領域，這兩個方案基本等價，但是架構和模型上必須要做一定的調整，這是受現(xiàn)實條件制約的。4.錯誤修正對于架構設計錯誤，架構師要深入了解錯誤原因，總結原因，反省和提升自我，“好的架構師都是時間和項目鑄就的”。如果一名架構師經常出現(xiàn)此類問題，就必須考慮對其進行調整，或到項目組重新鍛煉，或是不再讓其擔任架構職責；如果是整個架構師團隊經常出現(xiàn)此類問題，很可能是工作機制的原因?？傊?，集體問題與個體問題不同，需要區(qū)別對待。再次，不允許明顯違反既有規(guī)則的調整。以客戶統(tǒng)一視圖需求為例，這是典型的跨領域需求，但又具有一定的領域特性

20、。因為金融行業(yè)客戶可能同時在多個領域發(fā)生業(yè)務，但每個業(yè)務線從自己的領域出發(fā)，應用客戶視圖時不一定要看所有內容。這就相當于在一個統(tǒng)一的數據基礎上分領域定制，這樣的需求既可以由客戶管理組件實現(xiàn)，又能由負責數據倉庫、數據主題的項目組實現(xiàn)，無論哪種實現(xiàn)，本質上都是通過數據倉庫加工。但是，分工一旦形成，就不要隨意調整。如果既定是由客戶組件做，特別是客戶管理組件已經實現(xiàn)部分功能時，就不應該允許客戶管理組件再以各種理由拒絕后續(xù)需求，把其他需求交給數據加工的項目組去做，這樣會導致架構混亂和決策原則的不一致。不要輕易推翻已經成為事實的判斷原則，要通過事實建立共識，建立規(guī)則。6關于企業(yè)開展業(yè)務架構設計的 6 點思

21、考 關于企業(yè)開展業(yè)務架構設計工作的思考，付曉巖表示，不想泛泛而談，先設定前提條件。如今正在進入時代轉型的“陣痛期”，我們將成為直面轉型的一代人，終將在一個不那么長的時間里，面對真正的“數字化時代”。以此為出發(fā)點，我們應做好幾點：1. 培養(yǎng)業(yè)務架構師 業(yè)務架構目前是人設計的，而非 AI 自動設計，因此業(yè)務架構師的培養(yǎng)是第一位的。業(yè)務架構設計需要長期的實踐，具備良好的結構化思維，需要對方法的深入了解和工程上下游的充分了解，而非靈機一動突然悟道，需要“慢功夫”。2. 建立架構之橋 業(yè)務架構位于業(yè)務和技術的中央，沒有經過企業(yè)級設計的“地形地貌”，會逐漸演變成“迷宮”，充斥著各種鮮為人知、容易迷路的“捷徑”。如果建設了能支持從業(yè)務模式到技術實現(xiàn)完整關聯(lián)、逐層展示的業(yè)務架構，企業(yè)就會有一張清晰的地圖來進行“導航