1、 銀行IT架構轉型中國銀行業的數字化轉型才剛剛拉開帷幕，作為轉型重點的銀行IT部門正在經歷從開發模式到組織定位的巨大變革。本文從時下銀行IT廣泛的敏捷轉型開始分析，揭示了中國銀行業面臨的數字化挑戰，分享了應對挑戰的一些共識，同時給出了中國銀行數字化轉型的大方向。數字化挑戰過去的3年時間里，我作為敏捷轉型顧問，合作頻次最多的，就是全國大大小小的銀行。銀行業IT這一波的敏捷轉型，很多人會歸因為互聯網金融的沖擊，認為銀行業IT被迫從原來的內部職能部門走上前臺，迎戰外部市場的挑戰。也有不少銀行從業人員，對此持有不同看法：類似P2P這樣的互聯網業務，對中國的銀行業還談不上任何的沖擊。在我看來，真正沖擊中

2、國銀行業的，是以下兩個方面：服務渠道的變遷渠道從過去實體的網點向數字化渠道轉移。注意，這并不是說所有的服務都變成了移動APP，而是所有的服務都會用某種數字化的形式呈現，比如現在到工行建行網點辦卡都是通過一臺綜合服務機；交行幾年前開始試點網點機器人，而招行已經在刷臉取款。由于銀行之前是沒有數字化部門的，所以這些要求自然跟IT掛上了鉤。FinTech的沖擊技術突破正在改變業務形態。最近火過了頭的加密貨幣（比特幣）正是這樣的技術案例，它可能對未來銀行業務產生顛覆性影響。在歐美很多利用智能技術做征信的平臺也快速崛起，替代了傳統費時費力的背景調查。對比之前的傳統銀行科技，FinTech擁有非常大的不確定

3、性，這給習慣于購買成熟軟件產品的銀行帶來了不小的挑戰。當然由于又是科技相關，所以這口鍋自然也得IT背了。以上兩點帶來的變化顯而易見，所以，無論提不提敏捷，銀行IT都得轉型。建立在支撐基礎業務、保證業務穩定運行之上的IT部門，不可能自然而然演進成為 HYPERLINK /s?_biz=MzI1MzcwMDg2MA=&mid=2247484260&idx=1&sn=de5b140fb1021d884abd0b6c566399a3&chksm=e9d13cf7dea6b5e106462dcf0d9942bd1cd336db1f54f52a60eb2b1feb878d5b8604e1eb66a0&sc

4、ene=21 l wechat_redirect t _blank “以用戶為中心，思考服務體驗，并保持對業界先進技術洞察”的新型數字化IT部門。下面就結合我過去3年中，近10家銀行的顧問經歷，談談這個轉型中的挑戰和可能的應對之策。穩與快我們輔導過一家外資銀行，一上來就要求全球范圍實施DevOps，“全面”敏捷。作為顧問，感覺很爽，改進起來氣貫長虹。半年之后，已經沒有不做敏捷改進的項目了，就連基于小型機AS/400的系統也都走上了DevOps的持續發布之路。中國的銀行業可就不是這樣一個情況了。我和業內熟悉的幾個人，經常開玩笑說“喝茶就是懸在中國銀行敏捷轉型頭上的達利摩斯之劍”高管們心里羨慕著互

5、聯網玩法的“小、快、靈”，腦子里卻時刻擔心著因生產事故被請去“喝茶”。轉型需要經歷煙斗曲線，當剛好處于曲線下挫點時，很可能因為一次事故而被全面叫停。一位銀行科技高管曾經在內部會議上對我直言：“不要以為我不支持敏捷，正是因為我支持，所以才拉著你們跑慢一點”。團隊里有顧問找到我說不想做中國的銀行了，太糾結，猶抱琵琶半遮面。于是我反問這位顧問，為什么中國的銀行不能像外行一樣一步到位呢？是因為太保守或者太官僚？一時問得對方語塞。其實，外行比起咱們可能更保守，生怕有一點負面消息，有的機構更龐大，更官僚。那么是什么原因，讓我們中國的銀行不敢“全面”敏捷呢？就我目前認知，中國銀行和外資銀行有兩點顯著不同：一

6、是中國銀行集中精力辦大事兒的構建方式；二是中國銀行IT的歷史定位。如果我們對比中外銀行的業務架構，會發現咱們的銀行在業務設計上非常集中。這樣的集中思路投射到IT系統建設上也是非常明顯的：一般會考慮一套系統支持多條業務線。經典的例子是咱們的銀行一般只有一套清算、核算平臺，而外行每條業務線可能有自己的獨立平臺。集中建設的好處自然已經體現出來了，短時間我們就構建起來了一個相對完善的金融電子平臺，但帶來的問題就是系統非常復雜。(圖：中外行典型組織結構區別)在敏捷轉型過程中，有兩個領域的復雜度是讓我頭疼的：電信和金融。大家可能想象不到，打通一次電話和完成一筆轉賬都要涉及近億行代碼！一條業務需求動輒要求修

7、改十幾個獨立應用！咱們集中建設的銀行系統顯然不是隨便就敢改的，早期即使在銀行大型機系統上引入迭代開發都是很困難的。而這些系統往往又是銀行的核心主干，任何小錯誤都可能造成致命的連鎖反應。在IT定位上，從國有五大行到各大股份制銀行，基本都將IT歸到了科技部下面統一管理。從組織結構上，可以看到IT的定位是一個共享的內部服務部門，或者說，是一個成本中心。最初的IT只是管理一些購買的商業軟件和平臺，并沒有作為一個強自研能力的組織存在。銀行IT的自有員工和外包人員比例，普遍都在1：6左右，一個主要的IT系統可能也就能投入兩三個長期自有員工。到了現代，這個以科技為核心（ HYPERLINK /s?_biz=

8、MzI1MzcwMDg2MA=&mid=2247484691&idx=1&sn=c93edfa833db81380d080a69825cc184&chksm=e9d13a80dea6b3961f1a164bd3a08dd5fb27f8ccbfb4e0f82e6142fc96d60cd3074fd55f690f&scene=21 l wechat_redirect t _blank TechCore）的時代，這樣的人員配置顯然已經捉襟見肘了。以上兩個因素，從技術架構和人員架構兩個方面制約了敏捷的大規模推廣。所以，銀行想要“快”起來，往往不那么容易。各家銀行的轉型，都會選擇相對新的技術領域，或和用

9、戶結合比較緊密的應用開始試點。而初期的轉型目標，也會設定為“探索在現有約束條件下，如何進行敏捷模式落地”。最終，大多數銀行都會走向“雙模”：明確哪些系統和應用更看重業務表現的穩定性（采用瀑布模式），哪些更看重市場變化的響應速度（采用敏捷迭代模式）。（圖：源于Gartner總結的雙模IT架構基本示意圖）理論上講，“雙模”只是一個過渡狀態，這種方式也受到了不少專家的批評。“雙模”可能會掩蓋掉一些更深層次的問題，比如系統快不起來，根本原因其實是架構質量問題。從科技的發展趨勢來看，確實止步于“雙模”是不明智的，微服務化和平臺化架構的逐步成熟會讓以前穩定第一的系統也快起來。但就目前的約束來看，“雙模”是

10、已有成型建制銀行IT的必經之路，其意義更多是在組織里植入管理不確定性的能力，從而構建對市場變化的快速響應能力。效率與響應力“唯快不破”是互聯網服務發展的必備條件，而這個“快”其實是被很多管理者誤解的。這個誤解也造成了銀行IT管理者們對“快”的提法有些許反感。這個誤解的根源，在于對效率和響應力的混淆。如果我們正確分析互聯網成功服務的特質，就會發現他們根據市場變化推出和改變服務的速度特別快，而這個快很明確是在響應力上。舉個日常生活中的例子，作為干洗店的客戶，我們其實并不關心干洗店內部的效率問題（例如單位時間處理多少件衣服、干洗機的利用率等），我們關心的是干洗店能多好多快地把我們衣服洗好。互聯網時代

11、給銀行業帶來的一個明顯轉變，就是從過去“以自身服務為中心”，到現在“以客戶為中心”。從前在以自身服務為中心的時候，我們的管理方法及技術實踐都是圍繞效率來做的；到了這個時候，顯然我們必須用客戶的視角來思考問題，所以就需要更加關注響應力。當我們在追求效率的道路上走到一定程度，就有可能傷害響應力。比如為了干洗機的利用率，我們批量分類客戶的同類型衣物放一個批次，顯然這樣的做法在訂單達到一定數量的時候，會減緩每個客戶的交貨時間，讓客戶等待更久，傷害了對客戶的響應力。同理，這也是為什么在敏捷組織里，我們提倡少分角色、跨職能協作。當我們的分工過于細化時，對外部的變化響應能力就下降了。在傳統銀行IT系統里這樣

12、的情況是很普遍的，一個業務需求需要分解到十幾個應用模塊完成，而每個模塊都只能由一個專人完成。理解響應力的重要性并不難，但實踐高響應力的管理卻是相當困難的。銀行業是一個重流程管理的行業，銀行IT顯然也繼承了這樣的基因。重流程標準化的管理方法，造成大家習慣性地進行自身局部效率的優化，實則增加了端到端的響應時間。我經常舉一個發生在我們每天日常工作中的例子讓大家意識到這個問題的嚴重性。你是一位IT管理者，小王是一位認真負責的開發人員。一天他告訴你，現在項目A上他的工作進入尾聲了，接下來只需要占用他一半的工作時間。這樣的情況下，小王希望請示接下來的工作安排。在實際工作過程中，大家會趕快告訴小王啟動項目B

13、的工作，或者分配給他項目C的部分工作。假設小王啟動了項目B的工作，很快他發現需要小李協助才能開展分析工作，而小李這個時候正在項目A上忙得不可開交。接下來有意思的事情就發生了，小王顯然會要求小李配合，而這事兒如果真正發生了，顯然就耽誤了項目A的工期，那么項目A的完成時間就要推后了。小王和小李有可能找到你來請示工作優先級，然而，可怕地是，在你的意識里，會覺得這顯然是“加加班”就能解決的問題！于是，整個IT產業陷入了做不完的需求和越來越嚴重的內耗！（圖：小王工作安排示意，由于項目B的引入工作越來越多，成效卻變少了）實際上，如果我們認識到項目A的關鍵要素是快速推向市場，那么我們給小王的安排應該是讓他繼

14、續專注于項目A，看看什么地方能夠協助團隊盡快完成項目。這個認知的轉變是困難的：作為管理者，要放棄過去對人員利用率的執著，理解利用率和響應力不是正比關系，在一定階段后甚至和效率也沒有正比關系。作為員工，要放棄一個蘿卜一個坑的工作模式，保持持續學習和跨職能工作的能力，把自己構建成一個T型人才。這個案例中，小王要能夠幫助項目A的其它工作，就要求他具有開發之外的其它能力，比如測試。在這樣一個時代背景下，銀行IT的敏捷轉型，實際是基于以用戶為中心的根本原則，加強整個組織的響應力。如果大家還在以“一個功能實現是不是更快了”來度量和牽引轉型方向，那么請盡快調整到“面向市場和用戶的端到端交付指標”上來。業務與

15、技術懂業務是銀行業人員晉升的關鍵因素。曾經在一次銀行IT中層管理干部的培訓上，我讓大家舉手表決是向業務方向發展，還是向技術方向發展，結果是全部都選擇的業務方向。不可否認，銀行業務的復雜度，要設計一套IT系統需要很強的業務理解。但數字化時代，技術成為了越來越重要的一個支柱，各銀行組織如果不能快速構建技術人員的職業通道，必然很難在數字化上取得真正的收益。我們從兩個方面來看看中國銀行業技術方面的挑戰。第一點是沒有足夠的技術封裝。經常看到一個有意思的現象是，銀行業務人員會看數據庫，每一張數據庫表就映射一張物理世界的報表。這樣的設計結果往往是一張銀行數據庫表可能有好幾百個字段。一段時間內，這樣的設計是很

16、流行的，因為溝通需求和最后驗收都會相當順暢，直接看數據庫表就完成了技術和業務的交流。隱患就是，數據庫根本就沒有模型可言，修改任何的數據項都需要波及整個系統，所以大家就傾向于一開始就把所有的數據項全部列好，如果不確定就先留下一些空字段以備后續不時之需。由于根本沒有數據模型封裝，看似業務上便于理解的設計，到后來也會因為冗余嚴重、耦合緊密而變得難于理解，或根本不可維護。只要是在基于如此架構上工作過的IT人員，就特別能理解，“為什么弄懂一個幾千行的存儲過程，需要花幾天時間”。沒有封裝的結果，就是每個維護修改者都需要理解已有系統的所有復雜細節。這也是為什么我們在銀行核心COBOL系統中，會看到大量的冗余

17、代碼與其修改已有的程序，還不如忘記已實現的業務，為新增業務重新開發。第二點是沒有開放的技術生態。銀行業經常把基于Java這樣現代語言的開發稱之為開放平臺，與之對比的是傳統基于大型機和小型機的封閉開發環境。最近還就開發效率問題和一個老牌銀行技術人員進行過討論。一個觀點是，基于成熟封閉環境的開發一旦上手其實效率可以很高，對金融行業來說更加模式化，并且硬件保證了高性能和穩定性。于是我也花了不少時間，來研究這樣環境下的開發模式，比如在綠色的傳統命令界面上完全采用鍵盤操作，從代碼管理到部署都是私有的平臺和工具。從我的角度來看，傳統封閉開發環境有以下幾個致命傷：技術設計的表現力不夠，造成可維護性差。長期下

18、來，系統修改十分困難，成本隨時間爬升很快。不能夠利用很多已有資源。從開源到云服務，實際上都是開放生態中的可用資源。開放技術的全球知識庫早已超越了任何一家企業可以提供的技術服務。使用這些共享資源的門檻，就是需要加入到這樣的開放生態中去，隨著環境的發展而持續演進。難以支撐快速的市場和用戶擴張，對基礎資源抽象隔離不夠。以云服務為例，某種意義上，云是對之前我們計算機硬件資源的封裝，讓其成為像日常生活中水電氣一樣的公用資源，它使得我們在數字世界擴張的時候可以不再受基礎資源的限制。然而，在銀行IT中，這樣的基礎資源和服務抽象很少。很多銀行已經意識到了上述的問題，在科技發展方向上，決定逐步將系統應用向開發技

19、術平臺遷移。但還存在很嚴重地照搬過去架構設計的傾向，如前述數據庫設計問題仍然存在于新系統中。在敏捷轉型過程中，會發現即使在開放平臺上也很難實現端到端的業務價值交付，其中核心癥結之一仍然在技術架構上。去年，我花了比較大的精力在領域驅動設計（DDD）的推廣上，也是希望通過這個方法讓銀行IT組織認識到正確的架構設計思想。未來的銀行數字化部門應該在應用設計上達成業務和技術的架構綁定，而在人員任職上形成業務和技術的雙通道。文檔與人曾經一句玩笑話“人走文檔留”，引起了我對銀行IT人才觀的深入思考。從較長一個時期看，IT人才觀的轉變可能是中國銀行業的最大挑戰。在前沿程序設計會議上，當我傾聽一家外行科技VP講

20、函數式編程，看到兩家美國銀行收購硅谷技術公司的業界新聞的時候，就深刻地意識到，把“文檔”當成IT資產的觀念，將會嚴重阻礙中國銀行的科技發展。也許，在國家鼓勵下的BATJ合作，可能給咱們的銀行IT業帶來深層次的沖擊。從去年開始，這個沖擊已經超越了我們經典意義上的敏捷轉型，而是銀行組織級的變革。在這個過程中，我認為我們要解決三個組織級的定位問題。IT合作伙伴的戰略定位從現在的人員外包模式，到面向價值共享的戰略合作模式。現行包人頭的方式，是敏捷轉型的障礙，在銀行數字化轉型過程中必須重視并解決。當IT和數字化成為銀行業未來業務的重要支柱，合作伙伴的定位及合作方式就必須相應改變。IT人員的能力定位從現行的流程執行模式，到面向業務和技術創新的持續學習模式。隨著智能技術在未來幾十年的持續滲透，追求效率的金融領域會逐步用機器替代掉重復性工作中的人。這對IT的影響是更深遠的，很快我們就會有機器來代替基礎的程序員和測試人員，也不再需要管理這些基礎人員的IT自有組織。但