自從接下這一份系統整合的工作也已經一年半了,終於 project 也將近到了尾聲.  回想起這過程中的酸甜苦辣, 雖然很辛苦, 但是也學了很多. 我將陸陸續續整理出我這一年半來作系統整合的心路歷程,放在這個部落格上. 也作為日後如果有人需要同樣的經驗時, 可以做一個參考.

我在IT產業也已經有十幾年的經驗了, 而且也都是在金融業的 IT 部門工作. 但是把兩家在台灣各有五十多年歷史的銀行之資料整合在一起, 真的是頭一次遇到.  尤其這兩家銀行中, 一家是本土銀行, 系統在台灣並自行開發. 非常的 flexible, 任何產品都可以做. 另外一家是在台外商銀行龍頭.  系統在國外, 有國外的開發流程與 standard 產品. 套一句老闆常說的話, 這是兩家 DNA 完全不一樣的銀行, 就好像橘子對蘋果一樣, 可是又要把他們的資料應塞在一起, 可想而知其中的困難與挑戰. 不過老闆既然說要作, 也就只好硬著頭皮作下去了.

系統整合可以分為兩部分, 第一部份是先定義出兩邊系統的差異 (gaps), 並且決定 gap 是要修改系統呢? 還是要作 data cleanup? 或是要轉成其他的產品?  第二部分則是要作資料轉換,把資料從 Sunset 的系統轉到存留系統.  我們定義出來來要轉換的產品有客戶基本資料, 台外幣活存, 台幣支存, 台外幣定存, 放款, 基金, 連動債, 預設帳戶, 對帳單, 台灣稅務資料, 美國稅務資料, 以及會計系統...等等.

在作資料轉換的第一件事就是要先針對轉出資料與轉入資料之間作 data mapping.  由於決議是要以外商銀行的系統作為存留系統.  因此由新加坡的開發中心提供資料格式作為討論的基礎.  他們以其他國家作過的資料整合專案的檔案格式作為範例寄給我們.  不過有很多欄位並不適用於台灣, 所以建議這些欄位都放空白. 沒想到這卻是 night mare 的開始.

以台幣活存資料為例子, 資料格式檔裡面每一筆 record 的長度有 2150 bytes, 但是真正需要的欄位只有差不多 10 來個.  也就是說其他欄位都不適用於台灣, 因此 default 放 0 或 space. 當我們一筆資料一筆資料來看的時候, 一筆差一千多個 bytes 沒有什們感覺 (真的必須承認, 當時是 overlook 這一塊), 可是當我們有一百多萬筆資料的時候, 這一個檔案就佔了差不多3.4 G, 從主機傳到台灣的 file server, 再傳到新加坡的主機上, 就要花六個小時.  但是其中有1G多的資料是 either space or 0.  也就是說有一半以上的檔案資料與傳輸時間是多餘的.

我以往作的專案, 資料庫以及要傳輸的檔案都是在同一棟大樓. 或者是說網路頻寬從來都不是我們必須考量的地方.  受到了這樣一個震撼教育以後, 馬上聯絡新加坡的IT 人員, 重新討論檔案格式.  不過程式已經寫好了, 如果要整個重寫, 有實務上的困難.  重新研究檔案 layout後, 發現從 1200 byte 開始, 全部都是 space.  所以我們就把1200 byte 之後的資料全部 truncate 掉.  檔案大小也從 3.4 G 降下來到 1.7G.  雖然還是很大, 但是總是省了一半的時間.

經過這一次的經驗, 以後如果還有資料轉換的案子的話, 一定要謹記, 只傳該傳的資料.  任何 default 值都應該要寫在程式裡面, 而不要含在檔案裡面.  其實這應該是一個蠻 common sense 的東西. 但是有了這一個震撼教育, 讓我有更深刻的體悟.