Categories
程式開發

從業務架構視角聊聊大型商業銀行的轉型實踐


從業務架構視角聊聊大型商業銀行的轉型實踐 1

隨著雲計算、大數據、區塊鍊和AI以及移動互聯等新一代信息技術的發展,企業數字化轉型加速。市場在變,需求也在變,面對高度創新和充滿不確定性的敏態業務,為快速交付高質量的軟件產品或服務,企業需要有更好的業務架構設計,去適應不同階段的業務特性。

何為業務架構設計?企業的業務架構設計需要考慮哪些因素?業務架構設計的難點和挑戰是什麼?企業應該如何權衡? …

面對這些問題,InfoQ記者採訪了 QCon 全球軟件開發大會 2020(北京站)的講師、《企業級業務架構設計:方法論與實踐》一書作者——建信金融科技有限責任公司付曉岩老師,請他從企業級業務架構設計實踐者的視角聊聊這些問題。

2000年大學畢業後,付曉岩就加入建設銀行。從業20年,12年在業務領域,8年在IT領域,他的腳步遍及支行、分行、總行、子公司等建行內部各層級機構。進入IT領域後,付曉岩近乎全程經歷了建設銀行規模宏大的企業級轉型項目,並在項目中得到歷練,從而成長為一名資深的企業級業務架構師。

業務與IT之間的橋樑

IT設計的真正目標是實現企業的價值。業務和技術應該是統一的、一體的,它們都是企業的有機組成部分。

在付曉岩看來,業務架構是業務與IT之間的橋樑。不管規模大小,企業都是一個整體,其生存、發展都依賴於企業形成內外部合力的能力,而這一能力的形成有賴於構建適宜其戰略執行的企業架構(EA,Enterprise Architecture)。

他認為,一個好的架構有利於企業戰略的執行,尤其是數字化轉型。數字化轉型是業務與技術的深度融合,而融合需要機制,需要二者建立有效連接,業務架構正是這種連接方式。

“戰略通過業務架構分解到業務流程,並將業務能力體系化、結構化地分解到企業的各個業務部分,再轉化為IT需求,通過與業務目標匹配的IT架構完成技術實現,將企業的戰略和能力、業務和技術有機串聯起來,構成一個協同整體。這就是業務架構乃至企業架構的使命。“付曉岩表示。

銀行業務架構的演變

從自己的經歷出發,付曉岩闡述了銀行業務架構的演進。

相比其他行業,銀行是信息化起步較早的。並且,大型銀行組織結構複雜、技術開發投入高、應用範圍大,因此,大型銀行在架構發展歷程上很有代表性。

以國內銀行為例,其在架構方面的發展歷程如下:

從業務架構視角聊聊大型商業銀行的轉型實踐 2

國內銀行的架構演進趨勢

80年代:分散架構

20世紀80年代後半期,銀行開始引入主機系統,這時構建的業務系統“高度”分散。每個地級市都有自己的業務系統,不同城市間的業務無法聯通。

以一筆匯款業務為例,現在是實時轉賬、零級清算、秒級到賬,而過去是多級清算。跨地區匯款,從一個城市的網點到自己的市分行,市分行到省分行,省分行到總行,總行到目標地的省分行,省分行到市分行,市分行到網點。可想而知,這種方式效率極低。

90年代:大集中架構

90年代末,隨著計算機性能的提升和網絡的發展,銀行對數據集中的需求越來越強烈,因為先有數據集中才能實現業務集中。因此,銀行的大集中架構拉開帷幕。

付曉岩表示,“大集中可以構建全行統一的業務系統,這對業務效率的提升是不言而喻的,但與此同時帶來的問題逐漸顯露,即’豎井式’開發、煙囪林立的問題。”

2011年左右:企業級架構

據付曉岩介紹,建行在2011年開始進行企業級轉型,設計全行統一的企業級架構,包括企業級業務架構和7層12P的企業級系統架構。

2017年,整個工程結束,建行內部一體化初步完成。

數字化時代:開放式架構

不過,架構的演進不會就此“打住”,內部統一後,銀行更重要的是適應面向數字化時代的開放與融合要求,深度參與到生態建設中。這一階段是開放式架構,真正從社會分工、生態分工的角度,結合生態夥伴、客戶情況,綜合分析架構解決方案。其設想如下圖所示:

從業務架構視角聊聊大型商業銀行的轉型實踐 3

開放式架構理念演示圖

付曉岩指出:數字社會必定是一個與今日大不相同的“新時代”,無論是企業,還是個人,所有參與者都將迎來一個轉型過程。對企業而言,架構”新時代“的到來是注定的,這個”新時代“一定是業務架構與技術架構、業務與技術深度融合的時代。

銀行業務架構設計和實踐

考慮因素

第一,目標的匹配性

企業需要清晰了解目標是什麼?要解決的問題是什麼?架構設計不是為了概念而設計,企業不是為了做業務架構而做業務架構,也不是為了上“中台”而上“中台”,都是為了解決問題。

付曉岩表示,“目的與手段要相匹配,目標的大小決定了業務架構設計的力度。”

第二,資源的適配性

企業級業務架構設計不僅需要投入業務和技術人員,而且還需要有經驗的業務架構師進行指導以逐步培養公司自身的業務架構師。 “由於業務架構領域還比較’小眾’,有經驗的企業級業務架構師很少,更多的是技術架構師。像一些’失敗’的中台項目一樣,沒有與目標匹配的資源也是項目成敗的關鍵。”他表示。

當然,即使有了業務架構師,如果沒有足夠數量的企業業務和技術人員配合,業務架構師也不能編出“架構”來。

第三,時間的適配性

企業級業務架構設計不能也不該很快,這是對企業自身的深入解讀和對未來的嚴肅規劃。它需要一定的時間投入,如果抱著“吃快餐”的心態,那項目質量很難保證。

雖然架構設計不是一次搞定,需要演化,但是要為“打地基”投入合理時間。

第四,耐力的匹配性

這裡的”耐力“指的是堅持以企業級業務架構為核心,長期驅動企業業務管理、IT管理的耐力。

付曉岩認為,企業級業務架構是一種“秩序”,而“秩序”的維護需要耐力,如果沒有堅持的定力,那一次性的成功,很可能換不回企業的投入。企業需要的是維持持久的競爭力,也自然需要耐力上的付出。

業務架構設計的三個階段

以銀行為例,其在進行業務架構設計中一般有幾個階段。

首先,建立明確的企業級業務架構設計工程項目,並任命強有力的行級領導進行統一管控,將相關業務部門、技術部門全部拉入工程項目,以確保決策能力和執行能力。無論國內還是國外,企業級項目都是“管理者工程”。

其次,進入項目過程,這時要明確戰略目標,即銀行針對多少年的戰略目標進行架構設計,確定戰略目標是什麼,戰略目標對應的戰略能力有多少,目標越大,需要分解的能力自然越多。

然後,形成現狀模型。將銀行現有的業務流程模型化、結構化,通過統一的企業價值鏈進行分類、整合、標準化,並將戰略能力分解到現狀模型中,將模型與戰略對齊,識別需要改變的業務流程,這就產生目標模型。

付曉岩指出,盡可能在架構設計過程中,將全行統一的數據模型一併設計出來,然後結合數據模型和流程模型,提升標準化程度,設計出業務組件。最終形成包括戰略、戰略能力、流程模型、數據模型、組件模型的企業級業務架構。

業務架構設計雖然不求快,但也要注意合理控制時間,“一到兩年是比較合適的首次建模週期”。

建行業務架構設計實踐:六年磨一劍

2011年到2017年,建行進行的“新一代核心業務系統”建設項目,正是通過企業級業務架構設計驅動的,也被稱為“六年磨一劍”。

整個實踐,先從戰略定位開始,分析建行的十二五、十三五規劃,確定全行的整體戰略目標。並且,還將戰略目標分解為更細的戰略能力舉措和更細粒度的戰略能力需求,“其目的是為了讓戰略落地具有更清晰、操作性更強的要求”。

其次,進入現狀建模和目標建模階段。這是將建行實際的業務和改進舉措與戰略對齊的過程。經過這樣的模型設計過程,包括價值鏈、流程模型、數據模型、產品模型、用戶體驗模型和業務組件在內的整體業務架構設計和架構資產即形成。

據悉,總體架構設計大約花費2年時間,這與建行龐大的體量和業務複雜度有直接關係。同步完成的還有適配整體業務要求的技術架構,即7層12P的方案。

然後,開始根據企業級業務架構和技術架構進行具體項目落地。整個企業級轉型總體分為三期,每期也有不同的小周期,由轉型項目的PMO統一管控進度。期間,還進行了海外建模,即實現全球架構一體化的海外模型設計及海外實施。

2017年,建行公開宣布工程結束。據公開信息介紹,實際落地114個業務組件、整合設計900餘個業務活動、標準化4500餘個任務、3000餘個數據實體、150餘個基礎產品和1萬餘個可售產品,“在世界銀行領域,這是首次完成如此大範圍和深度的企業級業務架構設計與實施”。

業務架構設計的難點

技術難點:標準化

從技術層面講,業務架構設計最大的難點是標準化。標準化是判斷服務異同和顆粒度的重要依據,這是各類架構設計中的難題。建模離不開標準化過程,做企業級模型要橫向對比企業所有業務領域,以期望在設計上實現“以更少支持更多”,並實現快速的靈活響應和減少重複開發這兩個目標。

業務架構模型的標準化包括數據標準化、任務標準化兩部分,這兩者相輔相成,通過數據間的比較可以更好地進行任務標準化,而通過與任務的結合也能更好地判斷數據定義是否準確、數據標準化是否到位。

除了技術挑戰,還有諸多工程難點。

工程難點1:捷徑難尋

了解DDD(領域驅動設計)的人可能知道,DDD對企業級不抱太大希望,認為企業級的建設路徑只能是一個領域一個領域的不斷嘗試融合,無法通過自上向下的規劃產生。

在付曉岩看來,金融領域恰恰是一個很不“專業”的專業,裡面的東西五花八門,看似都在一個領域,實則“千差萬別”,各類業務的共性在於客戶(同一群客戶),圍繞客戶共建一個賬戶體系。換句話說,如果自上向下看,客戶和賬務應該是企業級的,而其他部分,需要一個領域一個領域的研究,這也是建模和標準化的難點。

因此,企業架構建設的難度跟企業所在行業的特點有直接關係。沒有一個通用的企業級業務模型可以隨便套,“阿里的業務架構套不到銀行頭上,銀行的業務架構也套不到阿里頭上”,甚至一個行業內,企業跟企業間內部特點的差別,也會決定企業架構建設路徑和結果的不同。沒有簡單複制的模式能幫你快速切換到企業級,“自己的路只能自己走”。

但是,需要所有從業人員共同探索的,也恰恰是如何構建成熟的行業級模型,這是未來實現大規模軟件生產的關鍵。

工程難點2:文化難建

多數情況下,企業級不是一個單純的技術問題,這讓技術人員非常為難,因為這根本不在其能力範圍內。如果是一個業務種類繁多、部門龐雜、等級森嚴的傳統企業,建企業級相當於對部門邊界、協同關係的重新界定,它對企業文化的依賴和改變都很強。

工程難點3:權責難定

在組織中,一件事情能做好,前提是做事的人權責匹配。但是,架構定位的困難在於,權力太小,不足以維護企業級;權力過大,又會發展成新的部門化組織,可能會導致架構決策行為方式出現“僵化”。建立合適的集體決策機制很重要。

工程難點4:長志難立

企業級(項目)的長期堅持是件難事,它的放棄和崩壞不一定是是架構組織撤銷、機制停掉這麼激烈的動作,而是各種“畏難情緒”、“客觀原因”導致的緩慢的無序,它是一個個需求的分配、落地的偏離堆積產生的。並且,“破窗效應”對它的影響也很明顯。總之,一定不要搞“一次性”的企業級工程。

業務架構設計中的trade-off

在業務架構設計中,企業除了“直面”挑戰,還要權衡諸多事宜。付曉岩認為,業務架構設計是個迭代的過程,要允許反復和調整,不能武斷,沒有耐心。

首先,不能允許簡單的“拍”結構。架構師必須具有開放性,保持謙虛。架構師是“中心”,但不要總把“權威”看得太重,架構是企業整體資產。從某種角度說,企業做架構正是為擺脫對特定架構師的“單點依賴”,讓架構工作能保持“業務連續性”。因此,架構設計要保持這種謙遜,這樣才能讓更好的設計思路進入設計師的視野,進入設計方案。

其次,允許什麼樣的架構調整。

1.查漏補缺。

項目有周期,每個環節都有一定時限。除首次做企業級轉型外,業務架構設計是很重要卻又不能被分配太多時間的環節。因此,業務架構師必須在盡可能短的時間給出覆蓋度盡可能完整的架構方案。但是,時間越短、信息越少,就越可能出現疏漏。在細化階段發現問題很正常,自然調整就好。

2.發現更好

在實施階段,由於輸入的細節通常比業務架構設計階段更多,並且不排除在實施階段發現更好的做法,這樣的改良可以重寫到業務架構中,由此帶來的業務架構調整是有益的。

3.現實妥協

架構設計經常不僅僅只有一個可行方案。架構師手里永遠準備著兩套方案,隨時可以拋棄其中一套。比如,原本設計時有兩個方案可以選擇,在為C領域做業務架構設計時,A領域和B領域都有可以採用的實現能力。 A領域的業務性質與C領域更為接近,於是架構設計時選擇A領域,但實際推進項目時,負責A領域的項目組由於客觀條件限制,無法按時實現,只好再轉到B領域,這兩個方案基本等價,但是架構和模型上必須要做一定的調整,這是受現實條件製約的。

4.錯誤修正

對於架構設計錯誤,架構師要深入了解錯誤原因,總結原因,反省和提升自我,“好的架構師都是時間和項目鑄就的”。如果一名架構師經常出現此類問題,就必須考慮對其進行調整,或到項目組重新鍛煉,或是不再讓其擔任架構職責;如果是整個架構師團隊經常出現此類問題,很可能是工作機制的原因。總之,集體問題與個體問題不同,需要區別對待。

再次,不允許明顯違反既有規則的調整。

以客戶統一視圖需求為例,這是典型的跨領域需求,但又具有一定的領域特性。因為金融行業客戶可能同時在多個領域發生業務,但每個業務線從自己的領域出發,應用客戶視圖時不一定要看所有內容。這就相當於在一個統一的數據基礎上分領域定制,這樣的需求既可以由客戶管理組件實現,又能由負責數據倉庫、數據主題的項目組實現,無論哪種實現,本質上都是通過數據倉庫加工。

但是,分工一旦形成,就不要隨意調整。如果既定是由客戶組件做,特別是客戶管理組件已經實現部分功能時,就不應該允許客戶管理組件再以各種理由拒絕後續需求,把其他需求交給數據加工的項目組去做,這樣會導致架構混亂和決策原則的不一致。不要輕易推翻已經成為事實的判斷原則,要通過​​事實建立共識,建立規則。

關於企業開展業務架構設計的6點思考

關於企業開展業務架構設計工作的思考,付曉岩表示,不想泛泛而談,先設定前提條件。如今正在進入時代轉型的“陣痛期”,我們將成為直面轉型的一代人,終將在一個不那麼長的時間裡,面對真正的“數字化時代”。以此為出發點,我們應做好幾點:

1.培養業務架構師

業務架構目前是人設計的,而非AI自動設計,因此業務架構師的培養是第一位的。業務架構設計需要長期的實踐,具備良好的結構化思維,需要對方法的深入了解和工程上下游的充分了解,而非靈機一動突然悟道,需要“慢功夫”。

2.建立架構之橋

業務架構位於業務和技術的中央,沒有經過企業級設計的“地形地貌”,會逐漸演變成“迷宮”,充斥著各種鮮為人知、容易迷路的“捷徑”。如果建設了能支持從業務模式到技術實現完整關聯、逐層展示的業務架構,企業就會有一張清晰的地圖來進行“導航”,從而實現對業務問題的快速解決、對技術的合理應用,這是非常重要的價值,並且是有效連接二者、實現深度融合的方式。

3.轉變業務思維模式

數字化時代,軟件是最核心的生產力,各種業務需求都將主要依靠軟件的改良實現,企業的核心競爭力來自於業務與技術的融合能力,這意味著從業者的底層思維邏輯需要“刷新” ,與這種生產環境最為匹配的顯然是結構化思維能力,應當考慮通過業務架構設計方法和任務持續提升業務人員的結構化思維能力。

4.轉變軟件生產方式

技術人員要能結構化地看待業務構成與技術實現的關係,從而更好地將業務分解成合適的“零件”,這是在技術人員原有結構化思維方式上的一種深化。對技術人員而言,還意味著主動去接受標準化的“約束”,從個體化的改進軟件向公用化的改進“標準”發展,逐步實踐以標準化組件支持企業商業模式的構建。

5.加強架構思維鍛煉

在付曉岩看來,架構設計的四大思維支柱包括整體思維、洞察能力、演進思維和開放思維。架構設計應堅持從整體看問題,而非執著於局部細節;要堅持通過深入交流來獲得對業務的洞察,而非僅停留在需求文檔或者少數人員的轉述,最好有來自親身參與獲得的洞察;不要“唯快不破”,要堅持循序漸進,雖然要以數字化轉型為持久方向,但也不能“拔苗助長”;要堅持方法間的優勢互補,堅持設計理念和方案的開放性,要面向開放的生態設計架構。這些原則既適用於架構師個人,也適用於企業管理。

6.構建環境

無論是方法論,還是架構師,作用的發揮都離不開企業環境。如果企業沒有配套環境,沒有合適的體制機制保障方法論的落地,那就沒有一種方法論能給企業帶來改變和優勢。架構師和企業是互相成就的,二者的同時成功也促進了方法論的發展。

更多架構演進相關實例請持續關注QCon北京2020。一線技術大咖助你一臂之力,輕鬆應對高度創新和充滿不確定性的敏態業務,快速交付高質量的軟件產品和服務。