台灣幾個主要銀行的核心系統現況CIO的想法

最近幾個平時就常碰面的友人問我最近在忙些什麼？怎麼很久沒有在論壇上出現？我說因為去年接受委託調查台灣幾個代表性銀行的系統現狀丶順便問問對於己經使用超過30年的帳務系統(一般皆稱其核心系統，我現在仍稱之為帳務處理系統是因為當年系統建構目標的確是帳務處理。而現在一般稱核心銀行系統，其系統目標規模早超過帳務處理，故仍稱之為帳務處理系統較為妥當)丶未來之路有什麼想法?

根據我接觸的幾位堪稱有代表性的CIO(當年曾身歴其境丶動腦又動手丶從無到有丶一手創建目前系統架構的黑手出身(非一般連程式都沒有寫過的光動囗不動手的所謂策略專家)丶幾乎一致的講法：現有系統的架構的確有些年紀丶但是應用系統還是維護的不錯丶業務上的需求還能滿足業務單位的要求。況且市場上即便有些銀行的確更換系統採用了套裝系統(package solution)丶但是綜合幾位CIO共同看法：一.那是原系統的維護上問題(原廠商後續支援無法期待丶客戶自身維護系統能力不足等等)己身並不存在這些問題。二.另外對於所謂的套裝軟體評估並不合用(功能過於跨大丶支援人力溝通障礙-語言丶対本地需求的了解不足丶原始程式碼不願意提供擔心將來的維護出問題－時效與成本⋯)。三.即便那些更換系統的銀行丶也看不出有何特殊效益丶充其量只是局部改善(分行早點下班)對於所謂新商品/與服務丶與自身相較也沒有特別之處。等等諸多看法丶大概對自身系統唯一的問題：僅剩IBM主機軟體經常調漲丶簡直吃定他們丶心生不滿而己。

過去我一直認為：核心系統系統如果計劃重建丶最好的方法就是完全，打掉重建丶才能徹底捨掉包袱全新打造心目中理想系統架構丶但是這樣的提案基本上是處於SI商的立塲：全新製作一件西裝總是比將一件中山裝改成西裝省得麻煩丶而且預算可以要求更多。但是這種想法丶就一年來的接觸丶根本無法説䏜大型行庫CIO。大抵CIO還是認為現在系統的帳戶/帳務處理丶對外支付/清算就交易(大量丶穩定丶效率)方面的功能，目前狀況還是對應得很好，而這㸃恰恰是大型行庫最重視的丶至於有關系統的擴展彈性(商品/通路/服務)丶那是次之丶能達到那是再好不過了。總而言之丶CIO要的就是一個新技術環境(web)－方便內/外部系統間的溝通以及一個彈性的平台(application framework-降低應用系統開發的成本及提高應用系統開發品質與效率。而且這個新系統架構還要能接納原系統上的資產－也就是下需要重新開發的應用系統(例如活期丶匯兌丶對外支付/清算⋯)。至於需要重新開發的系統則要能享受到新技術/平台的優點(例如應用系統開發工具與應用系統共同功能如On-Line 24x365丶On-Batch 平行處理機能⋯)。

回過頭來看看現在的系統技術/環境/架構，與目前這些行庫使用的大型系統相較丶容我簡化的說丶兩者的系統環境/架構丶前者是＂定義＂出來的功能而後者是＂開發＂出來的功能。兩者下的應用系統本質是差很大的(B@NCS 和UCP下的COBOL程式則本質相同)。但是所幸大型系統上在核心系統應用程式上都加上了一個控制程式(control programs)丶其目的就是讓應用程式的設計者不需要太(了解/碰觸)系統的環境丶單純的使用基本程式語言撰寫業務處理邏輯就好。在這樣情況下丶如果這些行庫的應用系統能夠秉持這樣的原則，那麼基本上這些程式還是語言單純(language native)程式丶而沒有夾系統軟體(OS/Middleware)丶如此那麼這樣CIO的理想或許是可以達成的。

我將這樣的想法告訴了委託者丶這位K先生所属的公司規模相當(員工數超過50000人)而且營業的重心(超過6成)擺在金融系統開發服務丶如果認真要作丶基本上是可以相當程度的達成這樣的想法。下個月，負責主要技術的負責人將要來台灣和我見面討論丶依我對於這家公司的了解，我認為是可以提出可以信賴的作法，但是關鍵還是在市場規模值不值得去做。對於這點丶依過去一年的往來觀感，我則持保守態度。

後記-很久沒有在論壇上出現是因為大部分的人都知道我主持論壇。聊得愈多難免把內心想法透露，因此最後都會加上一句，希望不要寫出來，造成有素材，但是不能任意使用，這也是是意料之外的後遺症。