很多人喜歡將建構核心銀行系統比喻成建構一建築物、如是則Platform如鋼骨結構、隔間裝璜如Application。

鋼骨結構與隔間裝璜孰輕孰重?其實都重要、問題在過程各階段中誰應擔任主角、當藍圖完成後、開始鋼骨結構、鋼骨結構完成後、進行細部工程、最後才能進行隔間裝璜。其實IT人何嘗不知這種簡單的道理?問題是出在IT人員原本責任是「鋼骨結構」(Platform)、要他們「隔間裝璜」(Application)、絕非其所長、勉強越俎代庖、根本不能令Business人員滿意、而現今的軟體技術堪稱「難用」、也很難要求Business人員使用這種「難用的工具」去裝璜(Build)自己滿意的房間(Application)。所以對開發Business、「難用」的IT工具才是遲遲無法讓Business人員去履行自己應盡的責任主因。至於何時Business人員才能才能有簡單好用的工具?前端介面(Presentation Logic)系統應該已經快要實現了、至於後端核心(Business Logic)系統?應該還要一段時間。

「Package是指修改率低於30%」-是一般的普遍共識的話、如今DIY仍遠高於Package的核心銀行系統、而且無人能證明何日可以達到這個水準、任何人又何需再賣力去吹噓自己的產品是Package?如果說Package是指修改率低於30%的話、那麼核心銀行系統-迄今我所聽到的案例是沒有一個是合乎這個門檻的。我問過中國信託(FNS/BANCS)內部開發者、他們告訴我-「幾乎是重寫的」、這樣說也許過於貶低FNS的一無是處、所以稱 之-「架構參考」也許較適當。我也問過台新銀行(FNS/BANCS)同樣問題、B副總也說-「改了90%」、比中國信託略低一些、姑且稱之-「範本延用」。緊著接的板信(信合社改制)、也花了超過16個月(當初宣稱12個月內完成)才上線、比起台新時間是少了一半、換算修改率-「改了45%」、似乎接近-「Package是指修改率低於30%」的水準?其實不然、回頭看國泰世華銀行的例子(FNS/BANCS)簽約迄今早過1年、2年上線可能?沒人敢打包票。曾有內部負責開發者告訴我、廠商(FNS/IBM)拿板信的DB企圖說服他們接受、被他們拒絕、原因是兩個銀行無論就「規模與業務」、差距實在太大根本不可行、據他們估計-「修改個80%」、似乎是合理的推測。

討論核心銀行系統究竟是Business或System只是方便與業務人員(Business)與IT人員(System)溝通上的便利而已....因任何IT應用系統都由H/W,S/W,APPLICATION構成、核心銀行系統也不例外。只不過被稱為核心系統就自然而然被視為一種架構(Architecture Framewaor)、典範(Template)、共同服務(Common Service)、共同應用(Common Application)、最終就是具有整合銀行所有應用系統的能力。因此討論核心銀行系統究竟是Business或System只是方便與業務人員(Business)與IT人員(System)溝通上的便利而已、因為你很難讓一個業務人員理解甚麼是R&A(Reliability&Availability)?甚麼是QoS(Qualoty of Service)?反之你也很難讓一個IT人員理解甚麼是支付、清算與結帳(核心銀行系統最重要的應用功能)?以及三者與銀行、通路、顧客(核心銀行系統最重要的使用對象)的錯綜複雜關係與運用精細之處。核心系統的主導者(開發或維護者)必需要具有把核心系統從Business面向或從System面向解釋的能力、否則就不夠資格談論核心系統。這種能力並非與生俱來也非考試認證所得、而是做多、看多、想多漫長累積才能有所領悟。