將遺留應用程序拖入現代時代是當今數字戰略的關鍵支柱。但它也比你想象得更難、更昂貴，而且回報更少。

根據TwoBitHistory.org的調查數據顯示，超過95%的《財富》1000強企業仍在使用IMS——IBM古老的分層數據庫管理系統(Database Management System，簡稱DBMS)。

[[415028]]

相比之下，我自己的非正式調查結果顯示，根本沒有任何最佳IT開發人員會對在這種環境中工作感興趣。

吸引頂尖人才的能力是首席信息官(CIO)對其應用程序組合進行現代化改造的一個原因——并非唯一原因，而是最重要的原因之一。其他原因還包括減少許可和支持費用，以及提高靈活性和適應性。

事實上，“現代化”并不像看起來那么簡單，它還有一些不為人知的秘密，聰明的CIO會在他們的決策中充分考慮這些秘密。

1. 應用程序現代化是一個復合問題

應用程序現代化涵蓋了針對一系列非常不同的問題的一系列非常不同的解決方案。

根據應用程序和您交談的對象，應用程序現代化可能意味著版本更新、平臺改造、平臺更換、語言現代化、重構或商用現成品/技術(COTS)轉換。雖然它們都被稱為“現代化”，但它們幾乎沒有共同之處。每個都有需要注意的陷阱。有些是眾所周知的;而其他一些則更為隱蔽和不為人知。

此外，現代化意味著很多不同的事情這一事實本身就特別令人煩惱：在對給定的應用程序進行現代化改造之前，您不僅需要決定是否對其進行現代化改造，還必須決定它需要哪種類型的現代化改造。然后乘以您投資組合中的應用程序數量。

2. 版本更新是其自身的債務形式

一些IT領導團隊認為他們“不為技術而購買技術”的做法非常具有商業頭腦，并且不斷地將一個陳腐的技術堆疊在另一個陳腐的技術之上，采取“如果它沒壞，就不要修復它”的方法來管理應用程序及其運行的堆棧。

他們還將這種邏輯應用于商業應用程序以及每個應用程序運行的每個平臺——服務器操作系統、DBMS、CMS、開發環境、桌面操作系統、瀏覽器等等——僅在特定的新功能帶來特定的新投資回報率(ROI)時才更新。

不幸的是，“后治理”的法則仍然占據主導地位：與保持最新狀態相比，“后治理”總是成本更高且更具破壞性的。

3. 重新平臺化(replatforming)只解決一個變量

將遺留應用程序遷移到具有相應平臺的開放環境是另一種流行的現代化方法。例如，平臺改造意味著從大型機托管的z/OS + COBOL + CICS + DB2遷移到x85托管的Linux + COBOL + CICS + DB2。在云遷移中，這稱為“直接遷移(lift-and-shift)”。

通過這種方法，你可以降低許可和供應商支持費用。

4. 平臺更換成本更高

平臺更換也是一種現代化方法，它只更換一個應用程序運行的平臺，理由是它已經過時或失去市場份額。例如，您可以將應用程序的數據庫管理系統(DBMS)從Sybase切換到SQL Server。雖然這種方法有時也被稱為“重新平臺化(replatforming)”，但它與上述重新平臺化沒有任何共同之處。

通過這種方法你會得到什么呢?使用過時技術帶來的風險和漏洞會變得更少;同時也會獲得更好的人才庫。你無法得到什么呢?降低成本或任何改進的功能。相反地，成本還會增加，因為你必須獲得更新平臺的許可。

5. 語言現代化往往使糟糕的情況變得更糟

誘人的銷售宣傳說，自動化工具將從您的遺留COBOL代碼中提取您的業務邏輯，并用現代語言重寫它。這通常是通過將100000行代碼的COBOL應用程序替換為100000行代碼的 Java應用程序來實現的。

這是語言現代化最黑暗的秘密：語言不僅僅是詞匯和語法。語言會帶走應用程序設計理念。

第二個最黑暗的秘密：語言通常也會帶走整個預先開發的邏輯庫。編寫新應用程序的開發團隊會利用這些庫。很少有代碼轉換器可以做到這一點，這意味著它們生成的轉換后的代碼更難維護。

6. 重構真正地現代化。所以當然是昂貴和耗時的

重構是一種現代化技術，可將過時的應用程序結構轉換為符合經過驗證的實踐——例如，規范化數據，或將單體代碼重構為微服務架構。

一些工具聲稱可以自動化大部分這種重構工作。無論如何，可以嘗試一下，直至選出合適的工具。

需要注意的是：某些版本的自動重構確切地保留了應用程序的行為。雖然這確實最大限度地減少了業務中斷，但它并沒有將隔夜批處理應用程序轉換為近實時處理——這種架構變化最有可能推動競爭優勢。

重構以提高適應性和靈活性的形式提供了重要的業務利益。但是“天下沒有免費的午餐”，架構現代化確實可以帶來成果，但它既昂貴又費力。

7. COTS轉換可能聽起來不像是一種現代化技術……但它確實是，而且通常是最好的現代化替代方案

通常，現代化應用程序組合的最佳途徑是用其他人編寫的現代應用程序套件替換當前狀態的應用程序“生態系統”。但這遠非靈丹妙藥——任何曾經參與轉換至COTS/SaaS套件的人都知道這有多困難——但它通常是替換一組應用程序風險最小且最干凈利索的方法。

8. 了解你擁有的東西并不能完全依靠自動化

現在我們已經了解了您選擇的各種現代化方法的秘密，不過，還有一些更基本的東西需要提防。在對應用程序進行現代化改造之前，您需要知道自己擁有哪些應用程序以及它們是如何構建的，以便您了解剛才討論的哪些現代化類型可能適用。

可悲的是，盡管所有出色的自動發現工具廠商都做出了“出色”的承諾，但這些工具僅用于發現服務器，而不是在服務器上運行的應用程序。

更糟糕的是，如果你的應用程序清單文檔不完整，你也無法完整地記錄平臺——開發環境、服務器操作系統、DBMS、內容管理系統和其他工具——每個應用程序在其上運行。只有認識到這一點，并充分了解自己擁有什么，你才能開始選擇上面討論的哪些現代化方法將提供最大的好處。

9. 軟件是一種意見——這使得應用程序集成成為一個論點

每個業務應用程序都編碼了開發團隊關于組織的某些方面應該如何運行的意見。其意見的語法是寫在代碼中的。其詞匯被融入到應用程序的數據設計中。

當兩個或多個應用程序的范圍重疊時——舉一個簡單的例子，當應收賬款和CRM系統都維護客戶數據時——需要自動化來保持兩組記錄的同步。將投資組合中的所有應用程序重疊加起來，結果可能是數百個自定義點對點接口程序，每次開發團隊添加或更改應用程序時，所有這些程序都需要進行修改和回歸測試。

企業服務總線 (ESB) 或類似技術可以幫助減少為每個應用程序定義單個接口的接口數量。

但除了接口數量龐大之外，還存在語義錯位的問題——也就是說，您的應收賬款和CRM系統的客戶數據模型不同。協調同一實體的這些不同定義，是使集成在開始時變得棘手并且更難以維護的原因。

企業服務總線 (ESB) 無法解決不同語義的問題，因為首先這不是技術問題，而且開發商也不同意。

10. 現代化IT勞動力通常比現代化他們支持的應用程序更難

您的員工可能非常擅長維護和增強構成您當前應用程序架構的應用程序和底層平臺。他們也是蘊含豐厚知識的“寶庫”，能夠保障他們的應用程序幫助業務按預期運行。但是，他們在您的現代化計劃將實施的替換應用程序和平臺方面能力并不突出。

如果您的現代化計劃能夠奏效，您將需要他們像現在一樣勝任替換工作。

除此之外，您還需要他們變得更有能力，以便他們能夠發現只有熟悉可用工具和當前情況的聰明人才能改進業務的機會。

“幸運的”黑暗秘密是：簡單地辭退他們，并雇傭替代者是行不通的。

當然，你可以選擇直接辭退他們。但是尋找稱職的替代者既昂貴又耗時耗力，而且即便他們的替代者多么稱職，經驗法則告訴我們，更換員工的成本相當于一個員工一年的工資——這無疑是十分昂貴的。

最后一個原因可以參見下條。

11. 運行良好的IT組織很少需要現代化

運行良好的IT組織會實踐生命周期管理。 他們會始終將所有事物保持最新狀態。這也使得預算易于管理——應用程序現代化工作穩定，幾乎沒有“大爆炸”情況，并且還有愉快的附帶福利，即讓您的員工隊伍與應用程序和平臺一起保持現代化。