Wed, 2006-05-31 08:53 — F I N
說實在的台灣迄今核心銀行系統並無所謂PACKAGE.即使目前市場活力十足的FNS,P銀行C銀行買的還是一個核心銀行系統的LICENSE而非一個PACKAGE.FNS迄今僅僅證明了是一個WORKABLE(FUNCTIONALITY&NON-FUNCTIONALITY)的架構,而未證明它是一個PACKAGE.C銀行花了將近3年重寫台灣版FNS的核心銀行系統還不能斷定,然而接著T銀行也花了幾乎相同的時間就已經說明了FNS是一個核心銀行的SOLUTION而已,再也不能說它是一個PACKAGE.嚴格說FNS僅僅提供一個架構(ON-LINE&BATCH)與樣本(DB&PROGRAM)而已,接下來就是銀行客戶依自身需求與包袱量身開發,這與過去UCP,SAFE,CAP,BENEFIT,CSF,NEO-APLIKA的開發方式,消耗時間與開發模式也沒甚麼不同?也許這樣說對FNS有點不公平,好歹C,T銀行都不否認參數化是比以前徹底,某些個人化的需求比以往容易達成.也許台灣的核心銀行主客觀條件都不適用一個PACKAGE,也許銀行客戶覺得FNS相對(iFlex)願意配合也是原因之一,也許有IBM的加持更是P,Cu銀行標案最後出線的主要原因.但是諸多原因都難以說服一個真正懂技術(FRAMEWORK)的人,那就是FNS從技術與應用觀點而言實在是太舊了,說白一點就好像把MAINFRAME的AP直接在UNIX上重寫一遍,但是這個這樣的新房子(UNIX NATIVE USAGE)事實上結構上是不如老房子(MAINFRAME OLTP)牢靠(只是維護MAINFRAME代價是高了不少),而這一點(FRAMEWORK-技術與應用)才是筆者認為值得去換核心系統的主要原因.
Comments
Package 的迷思
就筆者10餘年參與corebanking開發的經驗.f系統已是20餘年前的產品.設計的概念仍是20餘年前file的作法.只是現在將它直接改成RDB.有新增的功能.就用extend的方法.不斷的疊上去.但是其本質仍是國外的作法.相對於台灣金融.業務多樣化.變化快速.依筆者淺見.國外package並不見得適用.就如同C銀行第一家採用f系統.可是卻是客製化方法.來使用package.如果各位讀者有所注意.就會發現C銀行上線時.f系統並未將C銀行放在自己的客戶內.在它的網站也找不到C銀行的名字.一直到T銀行出現時.才將這二家銀行放進去.而現在B銀行和CU銀行都要用.另一家也想採用.不知道這幾家銀行當初是否了解package的特性.去作評估.若是要用package.卻以客製化的方式開發.那使用package的利基又在那裡?若全盤採用package的作法.那台灣一些特殊作法.如fisc.聯徵中心的規定.要如何應對?只能說參數化的系統.的確有它的好處.可是國外和國內的作法.是有所不同的.不知道在評估時.是否有考量這個因素.還是說因為人家可以用.所以我用就不會出事.也不用管它.好不好用.不好maintain 那是底下的人的事.事不關己.反正等到那時候.我已經高升.或者是已經被挖角到別的地方去高就.那是後面接手的人的事了....哎!真是沮喪
Add new comment