主張對IT組合進行現代化改造，就像主張給你的汽車換機油一樣，支持的理由是：如果不換，最終發(fā)動機會燒壞。

但當下進行改造的投資回報率如何呢?這是個精算問題。今天推遲現代化改造，從統(tǒng)計學的角度來看，肯定會招致不良后果，但這種風險何時會成為現實，同樣無法確定。

因此，根據你計劃在CIO職位上坐多久，你可以確定是否關注接下來的內容。

第一步：梳理現有資源

現代化改造始于了解你目前擁有什么，這些信息本應妥善保存在一個經過精心維護和管理的配置管理數據庫(CMDB，對非IT服務管理(ITSM)人士而言)中。多年來，我曾要求眾多客戶向我展示他們擁有的資源，到目前為止，我在尋找可靠、最新的CMDB的過程中，感覺自己就像一位硅基密碼生物學家，徒勞地尋找著IT領域的尼斯湖水怪。

要避免成為我們這些IT密碼生物學家中的一員，你首先需要一份IT所支持的應用程序清單，以及技術棧信息——即它所支持的業(yè)務架構，加上每個應用程序所依賴的存儲庫、集成、平臺、基礎設施和設施。

第二步：處置你的IT資產

處置涉及為你剛剛記錄的每一項資產確定未來狀態(tài)——即它的處置方式，首先，鎖定一個存在嚴重缺陷的應用程序，這能帶來商業(yè)利益，因為如果它沒有缺陷，就不會被視為有問題。

你有八種處置方式可供選擇：

? 擴展：對該資產進行投資，以提高其交付的價值。

? 保留：保留該資產，但僅進行維持其運行所必需的最小維護。

? 更新：對于商業(yè)應用程序，將其更新到供應商認為的當前版本的前一個版本。

? 替換：實施一個商業(yè)上可獲得的替代品，至少提供相同的功能，或者理想情況下，提供相同甚至更多的功能，另外，你也可以決定定制編碼一個替代品，但對于大多數IT部門來說，在大多數情況下，“能買則買，需建再建”是一個不可忽視的核心架構原則。

? 現代化：重構應用程序，使其符合現代架構和工程標準及實踐。

? 平臺遷移：重新編譯到成本更低的環(huán)境中，這指的是保持COBOL應用程序使用COBOL語言，但運行在更理想的平臺上，例如從Z/OS遷移到RHEL 10，但要注意平臺遷移的局限性：許多IT部門將應用程序“直接遷移”到新平臺，結果卻發(fā)現遷移并未帶來任何現代化改造。

? 整合：對于多個應用程序提供冗余業(yè)務功能的情況，將其中一個設為企業(yè)標準，并將其余的應用程序遷移到該標準上。

? 退役：對于不再需要的應用程序，歸檔其數據并停用，但要確保在無人監(jiān)管時也沒有人使用它。

第三步：警惕相互依賴和連鎖反應

僅確定一個應用程序的處置方式往往是不夠的，更改一個應用程序的處置方式可能會迫使其他應用程序及其技術棧(尤其是它所依賴的平臺)也做出處置方式的改變。

而且，幾乎可以肯定的是，對面向業(yè)務的應用程序所做的任何更改都會影響其他應用程序，并破壞一個或多個集成。

第四步：集成

集成是應用程序組合中的一個特例，它們通常是定制編碼的，往往很脆弱，相對不穩(wěn)定，而且一旦損壞并修復后，很難進行驗證。

特別是，集成容易受到語義沖突的影響。例如，一個CRM軟件包可能將“客戶”定義為個人，第二個可能將其定義為家庭，第三個可能將其定義為企業(yè)，而第四個可能將其定義為客戶企業(yè)的主要聯(lián)系人，至少可以說，同步它們的數據庫是很棘手的。

然后，業(yè)務戰(zhàn)略會發(fā)生變化，從專注于向個人銷售零售產品轉變?yōu)榕l(fā)業(yè)務模式。

第五步：執(zhí)行計劃——即使需要推翻大部分技術棧

我們本月和上月所討論的只是一個框架——一種記錄所有必要艱苦工作的方法，這些工作是為了使多層IT組合即使不能完全現代化，至少也能達到足夠的現代化水平。

實際上，召集足夠且合適的人員來對所有需要現代化的部分進行現代化改造，將是一項艱巨的任務，這就引出了這種情況中最不令人愉快的一個方面：一旦IT組合達到一定的過時程度，推倒重來可能比修復現有問題更具吸引力。

也許CIO會很幸運，現有的AI技術能發(fā)展到如此先進的程度，以至于可以逆向工程整個IT生產環(huán)境。

如果做不到這一點，那么用少數幾個全面的企業(yè)應用套件(如ERP、CRM以及類似規(guī)模和范圍的其他軟件包，這將導致大多數應用程序的處置方式轉變?yōu)檎?來替換整個組合，可能比試圖零碎地修復問題更為實際和經濟。