Sun, 2006-12-03 17:12 — F I N
核心銀行連線系統、通常由成千上萬支程式構成(依業務涵蓋範圍與程式結構)。依我的經驗如果在系統運轉中偶爾發生障害、這種情況最難查、要高手中的高手。因為可能是系統程式、抑可能是應用程式、抑可能是兩者間使用的限制所造成、所以要以全面性的觀點來思考、才可能迅速想到可能問題點、對症下藥。反之、如果集合兩者專家、個別從系統程式抑應用程式思考、則通常耗時費事、問題解決也頭痛醫頭、腳痛醫腳。最慘的狀況是問題發生時、來了一堆幫閒、七嘴八舌、看似集思廣義、實則亂槍打鳥、雖然最後總能解決問題、然情況好似元宵猜中燈謎、大家鼓掌、隨後一哄而散。然而現實的情況是愈來愈接近後者、前者已經瀕臨絕種。原因、一則甚少有人有心有機會經過長期歷練養成、二則系統愈趨複雜日益失去掌握、三則開發者往往不是維護者、又吝於指導維護者、維護者亦怠於了解全貌、又缺乏勇於任事負責、最後東切西切每個維護者僅僅負責一部份、四則高階IT管理理者大都重視策略大於管理、長於開疆闢土短於後勤補給、疏於內政而汲汲外交。以上等等皆是導致理想解決情況不再、而必需遷就妥協、大隊人馬齊聚一堂、看似集思廣益、其實各懷心思但系統求平安無過。最近有銀行正在進行新核心系統的開發、負責新系統開發的團隊相較於維護原系統的團隊更受高層重視、所以有次原系統的團隊與我聚會聊到此現象、有感「養」不如「生」之嘆、才興起撰寫本文念頭。
Comments
維護者被重視的程度真的不如開發者！
看到這個主題，個人心裡真的有著強烈的感受，或許不只我有這種感覺，我想只要是經歷過開發系統、負責維護運轉中系統的工作者，應該都會有相同的感想．
個人在銀行核心系統的領域中，參與由系統的設計、開發、運轉維護等工作，角色也在 user 及 vender 間相互轉換中，看到了這些現象，的確是如此．
我以為一個核心系統的雖然說會有它的生命週期，但應非一般所稱的十年就應該重新建置，通常應該是在系統經不同人的維護後疊床架屋的建置後，複雜度加深至失控後，就會遭重新建置而汰換的結果，而這個週期，平均來看大約為十年，我想這是一般生命週期產生的原因吧．
但也曾有少數的系統有例外，其原因大概是因為維護工作没有讓系統快速的加深複雜度至失控的階段，這就有賴維護者的努力．
但在現實的狀況中，維護工作通常被認為應該是簡單的，隨便找些人來就可以擔任，當有新功能要加入時，接手的維護者在趨吉避凶的前題下，就是往上疊，因為如果在原有架構下去調整及維護，一不小心影響原有運轉中的作業，將遭到四面八方的壓力，所以在最不會影響運轉中系統的前題下，開發者的成果往往較維護者輝煌，這也是造成維護者的角色是如此的下場了，真的，以目前各大行庫的系統來看，開發者真的較維護者被重視．
所以我有個結論是，一個核心系統導入後，如果無法有效的在原系統架構中作新功能的維護及調整時，其功能增加的快也代表著它的生命週期結速的快．
不過系統生命週期輪替快也給了新系統開發者更重要的角色，當然，維護者就得迅速的變更角色，以加深被重視程度了
"養" "生"之道
系統的一生就似人生，要"生"當然要找身材健美、命貌姣好、聰明賢淑的，懷胎10月在眾人的呵護下(通常都會過預產期)，終於有驚無險的投胎落地，此時紅包、油飯皆大歡喜，小Baby初見世面難免感染各種細菌，一時之間感冒、瀉肚不時發生，此時眾親友全力照顧，熬過艱難的襁褓期，周歲一過Baby日漸壯大，已可應付日常生活，就交給褓母、奶媽、佣人代"養"；接下來周遭大人們就開始對這個Baby的期待日漸提高，要學作文、彈琴、畫畫.....，現實情況下佣人是無法改進Baby的體質& 命運，沒經歷懷胎十月的心路歷程哪會了解Baby的五臟六腑，所以只能打補針吃藥、多吃點營養品嘍，久而久之就有一點發展不均衡，慢慢的畸形、腫瘤都出現，此時恁誰也難根治，只有拖一天算一天，最後總有一天.....；所以系統的命運在它出世前就已經決定，差別的是"生"母在懷孕期是否有補身子、亦或是褓母在扶"養"期是否盡責，其結果只是多活幾年而已。
Add new comment