中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

為了更有效地完成銀行業務的數智化轉型和創新，我們不可避免地要了解銀行業務的IT架構情況，只是很多時候，我們缺乏了架構層的認知，而這篇文章里，作者就梳理了銀行IT應用架構的變遷及發展，我們不妨來看看。

在科技金融、數字金融的大背景、新趨勢下，我們若想更合理、更有效的完成銀行業務數智化轉型和創新，一個基礎能力便是要了解整體的IT應用架構情況。

這樣才能知道自己的業務處于哪個層面，哪個位置，有什么關聯業務、關聯系統，當下的設計方案會對現有架構產生什么影響，是否符合全行數智化戰略等等。

另外，為什么我們在架構評審時總是不通過，好像架構師在刻意為難一樣。其實并不是架構師有意為之，而是信息差和視野差的原因，因為我們總是以單一視角（微觀）來看待這件事，忽視了從中觀角度對業務架構、應用架構的認識。

所以，本文將以我近些年在不同銀行的架構實踐，概括性介紹銀行IT架構的演變過程。因為篇幅有限，筆者也非架構專家，文中若有不足之處，煩請同行專家批評指正。

關于銀行從傳統線下記賬，到后面的系統化（線上化），再隨著移動時代的發展，逐漸變成數字化的進程，很多書中都有比較全面的描述，比如《王劍講銀行業》、《大眾金融》，微信讀書上都有，在此不再贅述。下面我來從“實用性”的視角開始介紹。

一、最簡單的架構關系

銀行系統中，什么最重要？——錢最重要。

但錢是一個物品（拋開數字貨幣），反映到系統中，其實就是一個個客戶下的一條條數據。這些數據是系統的重中之重，是業務開展的核心，所以承載記錄“錢”的系統，被我們稱為核心系統。

這里的“核心”二字，是個名詞，它就叫核心系統。和我們理解的形容詞“核心”不一樣，這個概念我剛入行的時候理解了很久，才慢慢從形容詞核心過渡到名詞“核心系統”。

我們舉一個最簡單的例子，也是上世紀數字化剛剛起步時，很多小銀行的實際情況。

張三來到銀行網點，在柜臺存了一萬塊錢，這個過程從應用層面分析，最少涉及到兩個系統：柜面系統、核心系統。

交易從柜面系統錄入要素，之后上送到核心系統進行驗證、處理、反饋，這就是一個最簡單的交易關系。

類似的，還有李四去ATM機存取錢，同樣是從ATM系統錄入要素，并進行基本信息驗證，之后上送到核心系統進行處理、反饋。

然而，剛才只是存取錢，銀行還有很多其他業務。比如我們以光大云繳費平臺中的代收業務為例，在線上繳費推出之前，類似的代收業務需要去柜臺辦理。當時銀行就是在發揮自己線下網點覆蓋度廣的優勢，讓用戶能夠就近繳費。

但是代收業務中，還需要對接各個第三方機構（如水廠、燃氣公司、物業公司等系統），即真正的收費方。因此，業務架構變成了三層。

隨著業務的發展，核心系統需要處理的業務越來越多，不僅有代收、代付，還有很多支付結算、理財、保險、司法查控等業務，都會在核心系統加一層、再加一層。

每種業務都有自己的特色機制，久而久之，核心系統變得越來越“臃腫”，這也是第一個階段顯著的特點：“重”（zhong）核心。

核心系統里面的數據非常重要，隨著里面包含的業務變多，維護成本越來越高，運行的安全性、穩定性、效率都面臨著嚴峻的考驗。

二、天下大勢，合久必分

為了緩解核心系統的壓力，從“業務解耦”的角度來看，便需要將核心系統中的業務應用部分逐漸剝離出來，讓核心專注于處理賬務和賬戶相關的任務，因此，在業務架構層面將進入“瘦核心”階段。

于是，像代收、代付類的業務系統被拆出來了，像存款、理財、貴金屬、基金代銷等業務也被拆出來了。

每個業務的第三方都由業務系統自行對接，一個業務發起后，大致邏輯是：渠道->業務系統->第三方->核心系統->各種結果返回。當然，里面的順序不同業務會有差異，在此大家能夠理解主體意思即可。

這時，業務架構圖大致變成了這種效果。里面會有很多很多業務系統，也會有很多外部合作機構。

同時，隨著互聯網渠道的興起，像手機銀行、網上銀行、移動展業等互聯網渠道應運而生。而銀行的系統都是部署在絕對安全的“內網”，與互聯網之間的傳輸交互，與傳統的渠道直接通過內網連接的方式也有很多不同。

而且當銀行的業務開始豐富、延展時，還會有很多第三方渠道、合作方，通過互聯網模式將業務要素傳入行內，因此，為了完成內外網的安全互通，銀行增加了“接入網關”這個模塊。

在資金交易方面，不僅有本行的資金處理，還有很多跨行交易的訴求。而核心系統主要進行本行交易處理，關于跨行交易，也有不同的系統承載。

于是，上面這張圖又可以調整成這樣。

緊接著，“瘦核心”階段下的問題也逐漸體現出來，那就是業務系統太多了，像代收代付類的業務，一家銀行有幾十上百個都很常見。

每個系統都需要維護，而且很多系統之間存在不少共性，因此在系統建設層面存在很多冗余和資源浪費。

三、天下大勢，分久必合

因此，“瘦核心”之后，銀行的架構演變來到了第三個階段：平臺化。

將同類業務組合提煉，對外形成一個統一的產品，對內進行合并，并通過技術升級、標準流程制定等理念，提升開發、維護的效率。

所以，我覺得像光大云繳費這樣的平臺級產品，也屬于這個階段的產物。

• 同類型的還有“統一支付平臺”，將本行、跨行的支付交易做了提煉、整合；
• “綜合財富平臺”，將理財、基金、保險、存款等理財類產品做了抽象、歸納；
• “中間業務平臺”，將代收類、代付類多種交易做了匯總、統一；
• “營銷平臺”，將各類客戶、各種渠道下的營銷場景進行歸類、配置；
• “外聯網關”，將行內與行外系統交互的規范進行管理、統籌。

各個業務系統都會產生很多業務數據，對于數據的處理，又拆分成了數據倉庫、報表平臺、客戶統一視圖（ECIF）等不同維度的數據類產品。

通過整合，將某類目標聚焦，既在架構上更清晰，又能通過技術和業務上的拓展性支撐未來多年的業務發展。

當然，上述介紹中提及的系統，僅是銀行IT業務系統中的一小部分，還有很多監管類、管理類、風控類、場景金融類、銀企合作類、資金類、資管類、同業類等等業務應用。

但從整個架構演變過程來看，具體業務差異不大，更多是基于科技發展、系統穩定、業務趨勢等多個方面形成的“合理化迭代”。

本文也沒有提到ESB（企業服務總線）的價值和接入模式，不過ESB作為非業務系統，在產品設計層面也不會有什么影響。

文章至此，介紹了銀行IT架構變遷過程中的三個階段：重核心、瘦核心、平臺化，最終形成類似于下圖這種架構模式。

不同的銀行具體的架構，以及系統的名稱都會有差異，但本質的結構和關聯情況大同小異。

四、數字化與數智化時代的業務挑戰

介紹完應用架構的變遷，最后聊一聊我對于理解整體架構這件事的意義。

我們若想在當下的架構里增加一個新系統，要考慮的要素還是蠻多的，因為任何系統都不是一個獨立的個體，所以要考慮這個系統在業務場景中，和其他系統的聯動性，還要考慮功能的復用性，以及功能的“載體”（即放到哪里）。

當下銀行在新建系統中的考量和審核都比較嚴格，一是為了避免重復性建設，能夠復用、能夠整合的，依然本著復用和整合的目標。

二是很多系統上線之后，實際應用效果并不好，因此需要更加明確，更加具備可行性和業務價值。

三是近年來銀行的經營效益也在經受很大的挑戰，新系統建設的花費是一筆不小的數目，因此也不會像前些年那樣順利。

基于上述原因，很多情況下業務部門提出的新需求，可能就需要在現有應用中開發，或者將一個業務拆分成不同的模塊，放到不同的應用中。

因此將對產品設計者提出新的考驗，不僅要進行產品方案設計，還要跨部門溝通，多部門協作，做系統權衡。

另外，即便是同意了新建系統，這個新系統在設計過程中也要勢必要遵循本行的開發規范、架構規范。

比如用戶登錄是否要對接行內的統一認證模塊？密碼加密是否要對接行里的安全密鑰模塊？線上的合同或者回執，是否要對接行內的電子簽章模塊？營銷短信或通知短信，是否要對接行內的短信平臺？

比如，和其他系統對接是系統直連，還是通過ESB，或者其他與ESB類似作用的服務總線？（因為很多銀行不只有一個ESB，還有很多前置系統、網關系統，同樣承載了系統間統一對接的作用）

再比如，系統是自建渠道，還是掛載到現有渠道？如果是掛載現有渠道，又要遵循渠道側的設計規范、接入規范、安全規范。系統是否涉及資金交易，若涉及，資金交易通過哪個支付系統處理？系統產生的數據如何入倉？

還比如，我們需要某些數據，這些數據是從哪里獲?。繑祩}？核心系統？卡系統？還是哪里？不知道，你得挨個問。

以上種種，還有未羅列的很多問題，都是在實際數字化推進過程中將要遇到的問題。

因此，銀行業務的數字化，并不單純是產品設計的問題，更多的精力是如何在當下的環境中，形成一個多方認可的執行方案。

我覺得，這些問題是未來影響銀行快速實現數字化、數智化的最大“攔路虎”，更可怕的事，這些問題沒有標準答案，沒有可遵循的流程或制度，只能靠我們一次次的溝通、討論、權衡，甚至妥協。

五、寫在最后

我從2015年8月參加工作開始，便莫名其妙的踏入了銀行數字化轉型的浪潮之中，八年間在全國幾十家銀行做過項目、售前，從測試的執行，到項目的把控，到需求的分析，再到產品的設計、方案的制定，越來越覺得大多數從業者缺少對整體應用架構的認識和理解，因此在執行中經常遇到“不可控”的阻礙。

隨著工作的深入，我反而覺得所謂的“不可控”，其實是認知差和信息差的結果，當我們試著站在全局的角度，或者對方的角度考慮這些問題時，似乎也能理解了。

其實銀行非常需要專業的產品經理來推動數字化戰略轉型。

而傳統的銀行從業者缺少互聯網思維和產品思維，市場上的產品經理又缺少對銀行業的理解，很多乙方的需求分析師也是半路轉行，或者僅限于執行而缺少頂層設計能力。

因此，當下的銀行，尤其是城商行、農信社、農商行，亟需補充專業的數字化人才。

最近一年，我翻閱了很多銀行相關的書籍、文章，沒有找到一篇真正適合銀行IT從業人員、業務人員、產品設計者、新入行人員了解銀行IT應用架構的介紹，因此將自己的理解匯總成這篇文章。

希望能夠幫助更多的銀行從業者，了解應用架構，進而更有效的推進金融領域數字化創新，寫好未來“普惠金融”、“綠色金融”、“養老金融”、“科技金融”、“數字金融”五大篇章。

本文均為個人觀點，與供職機構、合作伙伴無關。

為我投票

我在參加人人都是產品經理2023年度評選，希望喜歡我的文章的朋友都能來支持我一下~

點擊下方鏈接進入我的個人參選頁面，點擊紅心即可為我投票。

每人每天最多可投30票，投票即可獲得抽獎機會，抽取書籍、人人都是產品經理紀念周邊&起點課堂會員等好禮哦！

投票傳送門：https://996.pm/7l9po