研究與報告

105銀行（總行：三重縣津市、總經理：前田 肇）、日本Unisys（本社：東京都江東区、社長：籾井 勝人）雙方共同開發的新核心系統『BankVision®1）』、昨日(2007年5月6日)開始正式上線。『BankVision』係建構世界首次建構在Microsoft（本社：東京都渋谷区、代表執行役 社長：格蘭 休士頓）Windows Server、 SQL Server架構上的大規模「次世代OPEN核心系統」。

105銀行、這回因新系統的開始啟用、由於附加價値提高、及客戶最適服務的即時提供、居中部地区地銀行同業龍頭地位更加穩固。

前回有提到EAI/ESB，我說過那都是根源於系統間整合的目的所創造出的名詞。如果EAI這個名詞最合適代表「系統整合」，那麼本文不妨也可以說是在談EAI.。談到EAI，首先就要談到Business，到底多大的Service想要整合起來?接這就要問Architecture，到底要採用什麼Techenology ?緊接著就是要如何Implement?這部份包括Network、Programming Model、User環境以及打算採用什麼Standard?這些都檢討過後，我們才可以決定採用什麼Pattern，到底採用DB整合的Pattern或者Message.Process整合的Pattern?兩者當然各有利弊，但是沒有所謂優劣而是看你的用途。首先，先談DB整合的Pattern，這種Pattern又分DB replication與DB Federation。前者-DB Replication，舉例說明，系統A(AP+DB構成)的DB即時(Real Time)但非同期(Asyn)透過網路(Network)複製到系統B(AP+DB構成)的DB，這種應用方式的好處是(1)使用者多有許多範例可供參考(2)系統A的運轉時間不受系統B運轉時間的影響(3)AP不需大幅修改。限制是(a)Real Time的Application應用不易達成(b)業務邏輯侷限於應用程式。

Unix 與 Linux 在建置分行Consolidated Server上兩者適用性的比較.

Browser 與 Java Client在建置分行Thin Client兩者適用性的比較

在認可(Authorization)方面、設計重心在階層(Hierarchy)的歸納與功能(Function)的分配。前者是由使用者(內部與外部)、通路(有人與無人)、產品(自有或同業)所構成(當然可以再做更精細的分類、視需求與執行可能)....在認可(Authorization)方面、設計重心在階層(Hierarchy)的歸納與功能(Function)的分配。前者是由使用者(內部與外部)、通路(有人與無人)、產品(自有或同業)所構成(當然可以再做更精細的分類、視需求與執行可能)、後者則是分類型(Classification)與規則(Rule)。

瑞穗企業銀行(Mizuho Coporate Bank-以下簡稱MCB)的次期系統、特徵是建構一個核心HUB系統、新種商品與新型服務皆依賴其整合、另一方面逐步將現行核心作業與機能縮減、解決系統長年修補所遺下的肥大化問題。將来的計劃則以邁向、SOA架構為目標....2004年12月三家銀行(註)系統整合完成後、瑞穗企業銀行開始次期系統的檢討。瑞穗企業銀行(Mizuho Coporate Bank-以下簡稱MCB)的次期系統、特徵是建構一個核心HUB系統、新種商品與新型服務皆依賴其整合、另一方面亦逐步將現行核心作業與機能縮減、解決系統長年修補所遺下的肥大化問題。將来的計劃則以邁向、SOA架構為目標。做為現階段系統核心的HUB-「業務間整合基盤」系統、競爭廠商有IBM(NEFSS)、日立製作所(NEXTCAP)、富士通都表現勢在必得的決心.、但最終確定由日立取得該合約。MCB的HUB主要角色是負責帳務系與對外系等系統間、控制交易(Transaction)的合作。系統構成則是由日立的伺服器「EP8000」搭載IBM的AIX構成。

註 第一勸業銀行(Fujitsu)、富士銀行(IBM)、興業銀行(Hitachi)合併分割成瑞穗銀行與瑞穗企業銀行。

核心系統在日本又稱基幹系統、不論叫核心系統或稱基幹系統、從名稱都可看出其在一個IT應用環境的重要角色地位。如果把核心系統視之為一個應用系統、我認為那是不完全的描述、迄今我仍經常聽到許多銀行同業說Core Banking System就等於Retail Banking System、逢此我都選擇表面沉默實則內心不表完全認同、我認為既稱之為核心(基幹)系統、表示必然支援許多應用系統、以銀行為例、不論消金、企金、外匯、情報都屬應用系統、且應建構在所謂銀行核心系統之上、因此核心(基幹)系統不僅是一IT架構(Architecture)提供許多個別應用系統的系統面與應用面功能、而且核心(基幹)系統應該規範了各應用系統的範本(Template)、例如365x24On-Line是核心系統共同功能(也是系統架構)個別應用系統都依此標準範本(Template)、設計應用系統的24x365On-Line、這是我認為之所以稱核心(基幹)系統、應該以這種角度看比較貼切。

台灣的銀行在1990年代時、當大部份的亞州國家的銀行陷於金融風暴漩渦時、幸運的並未受波及、仍然得以平穩發展。然而以今日眼光來看也並未因逃過一劫而蒙受好處、反而近15年因未如其他國家因金融風暴而趁機徹底解決沉荷後產生的爆發力相較之下反而不如。綜觀近年來全世界的銀行經歷過程都差不多、成立金控、進行合併、擴大經營規模、降低成本、組織再造、企業轉型..台灣的銀行在這股風潮下也進行同樣的策略、然而成效似乎不如其他國家、譬如與我國相近的韓國、主要原因可能如前述因為未經歷如其他國家金融風暴的打擊以致未能進行重大改革導致進行轉型時背負歷史包袱太多轉型不夠徹底、其他法令改革緩慢、銀行自有人才不足、合併速度緩慢、導致銀行規模無法短期內大型化等等、都讓台灣的銀行經營不振、這點可從近年來台灣股市金融股價反應上看出端倪....台灣的銀行在1990年代時、當大部份的亞州國家的銀行陷於金融風暴漩渦時、幸運的並未受波及、仍然得以平穩發展。然而以今日眼光來看也並未因逃過一劫而蒙受好處、反而近15年因未如其他國家因金融風暴而趁機徹底解決沉荷後產生的爆發力相較之下反而不如。

認証(Authentication)、認可(Authorization)、都是「共通應用系統」豐富內容中重要的一環。隨著顧客接點(Contact Point)需求多樣化、服務內容(Service Content)的複雜化、如果在前端(Front-End System)與及後端(Back-End System)上、建置此類系統安全管理、由於兩者目標任務志不在此....認証(Authentication)、認可(Authorization)、都是「共通應用系統」豐富內容中重要的一環。隨著顧客接點(Contact Point)需求多樣化、服務內容(Service Content)的複雜化、如果在前端(Front-End System)與及後端(Back-End System)上、建置此類系統安全管理、由於兩者目標任務志不在此、以及追求追加此「共通應用系統」對前端後端系統影響的極小化、建置一中端(Middle-End System)來收容諸如「認可」這類「共通應用系統」自是十分恰當。