超過95%的《財富》1000強公司仍在使用IM——IBM的古老的層次DBMS（資料庫管理系統）。這是TwoBitHistory。org得出的資料。

相比之下，我自己做的非正式調查顯示，在優秀的IT開發人員中，幾乎沒有一個人對在該環境下工作有絲毫的興趣。

能夠吸引頂尖人才是CIO們更新改造應用程式的一個原因。這不是唯一的原因，卻是最重要的原因之一。其他原因包括減少許可費和支援費，以及提高靈活性和適應性。

只不過“更新改造”不像看起來那麼簡單直觀，還有幾個隱蔽的秘密，精明的CIO在制定決策時必須考慮到這些秘密。

01應用程式更新改造 是個複合問題

應用程式更新改造（酷孩子俱樂部的成員稱之為“應用程式改裝”）涉及使用一系列全然不同的方法來解決一系列全然不同的問題。

應用程式改裝可能意味著版本更新、平臺重建、平臺更換、語言更新改造、重構或COTS轉換，這取決於具體應用程式和你交談的物件。雖然它們統一叫“更新改造”，但幾乎沒有什麼共同之處。各自有陷阱，需要留意。一些陷阱眾所周知，另一些陷阱則較為隱蔽。

此外，更新改造有許多不同的含義本身就特別令人煩惱：在對特定的應用程式更新改造之前，你不僅要先決定是否對其更新改造，還要決定它需要哪種型別的更新改造，然後乘以整個IT環境中應用程式的數量。

02版本更新本身是一種債 （越晚做越糟糕）

一些IT團隊領導認為，只要做到以下這點，就表明自己有業務頭腦：“不純粹為了技術而購買技術”，再加上一句陳詞濫調：採取“如果它沒壞，就不要修理它”的做法來管理應用程式及它們執行所依賴的堆疊。

他們把這套邏輯搬到商業應用程式以及每個應用程式執行所依賴的每個平臺上：伺服器作業系統、DBMS、CMS（內容管理系統）、開發環境、桌面作業系統和瀏覽器等等，只有當特定的新功能帶來新的ROI（投資回報）時才更新。

可遺憾的是，“不是現在付費，就是以後付費”，這個定律仍然是正確的：與及時更新相比，“以後付費”需要的成本難免更高、帶來的破壞更大。

03平臺重建只解決一個變數

另一種流行的更新改造方法是，將遺留應用程式遷移到有相應平臺的開放環境（將整套堆疊都遷移過去），有一個不那麼隱秘的地方要注意。比如說，平臺重建意味著從大型機託管的z/OS+COBOL+CICS+DB2 遷移到x85託管的Linux + COBOL + CICS + DB2。在雲遷移中，這個叫“lift-and-shift”（平移）。

你得到的是降低的許可費和供應商支援費。隱蔽的秘密是，這是你得到的全部好處。

04平臺更換成本更高

平臺更換是更新改造方法之一，它只改變了應用程式執行所依賴的一個平臺，理由是平臺已過時，或丟失了市場份額和消費者心智佔有率。比如說，你可能將應用程式的DBMS由Sybase換成SQL Server。雖然這有時也叫“平臺重建”，但它與上述的平臺重建沒有任何共同之處。

你得到的是減少了使用過時技術帶來的風險和漏洞，此外還能享用更好的人才庫。但你無法得到降低的成本或任何改進的功能。事實上，成本反而增加，因為你不得不為更換平臺購買許可證。

05語言更新改造常常使 糟糕的情況更糟糕

誘人的銷售宣傳號稱：自動化工具可以從你的遺留COBOL程式碼中提取業務邏輯，並用一種現代化語言重寫。這常常透過將有100000行程式碼的COBOL應用程式換成有100000行程式碼的Java應用程式來完成。

這是語言更新改造方面最隱蔽的秘密：語言不僅僅涉及詞彙和語法，還涉及應用程式設計理念。

第二個隱蔽的秘密是：語言通常還帶來整批的預開發邏輯庫。編寫新應用程式的開發團隊得充分利用這些庫。很少有程式碼轉換器可以做到這一點，這意味著它們生成的轉換後代碼維護起來更困難。

好了，今天的文章分享到這就結束了，要是喜歡的朋友，請點個關注哦！——我是簡搭（jabdp），我為自己“帶鹽”，感謝大家關注。