導語
在上週的
微信
《
XX
》
中介紹了更新改造應用程式的5大潛規則，
今天繼續分享乾貨：
06
重構真正實現更新改造
所以當然費錢又耗時
重構是一種更新改造方法，將過時的應用程式結構轉換成成熟可靠的實踐，比如規範資料，或將整體式程式碼的結構換成微服務架構。
一些工具聲稱可以自動處理這種重組的大部分工作。可以試用一下，反正是供應商出錢，直到幾個精心選擇的產品讓你相信這些工具名副其實。
還要注意：一些版本的自動化重構原封不動地保留了應用程式的行為。雖然這確實最大限度地減少了業務中斷，但它沒有將隔夜批處理應用程式轉換成近實時處理，架構上的變化最有可能帶來競爭優勢。
重構帶來了顯著的業務效益，具體表現是提高了適應性和靈活性。但是天下沒有免費的午餐。就重構而言，更不會像麥當勞的簡易午餐這樣實惠。架構更新改造帶來了好處，但它費錢又費力。
07
COTS轉換
實際上
是最好的更新改造方法
更新改造應用程式組合的最佳途徑常常是，把當前的應用程式“生態系統”換成別人編寫的現代應用程式套件。這絕非靈丹妙藥——凡是曾經改用COTS/SaaS 套件的人都知道這有多難，但它常常是風險最小、最乾淨的方法，可以把平臺和架構過時的一系列應用程式換成平臺和架構大有前景、可以幫助企業實現既定未來的應用程式。
08
瞭解自己有什麼應用程式
比自動化更費勁
前面我們剖析了各種更新改造方法的隱蔽的秘密，還有一些更隱蔽的秘密需要提防。在更新改造應用程式之前，你需要擁有它、知道它是如何構建的，這樣才能知道上面討論的哪些型別的更新改造方法可能適用。
遺憾的是，儘管一流自動化發現工具的所有一流供應商做出了種種一流的承諾，但這些工具只對發現伺服器有用，沒法發現有什麼應用程式在伺服器上執行。
更為隱秘的是，如果你的應用程式清單文件不完整，以至於你需要自動發現工具，說明其實你沒有將每個應用程式執行所依賴的平臺（開發環境、伺服器作業系統、DBMS、內容管理系統以及其他工具）一一記入文件。除非你知道這一點，否則就無法選擇上面討論的哪種更新改造方法會帶來最大的好處。
09
軟體是觀點
應用程式整合是論點
每個業務應用程式都表達了開發團隊關於組織的某個方面應如何執行的觀點，其觀點的語法用程式碼寫下來，其詞彙被融入到應用程式的資料設計中。
如果兩個或多個應用程式的範圍出現重疊——舉一個簡單的例子，當應收賬款系統和CRM系統都維護客戶資料時，就需要自動化來保持兩套記錄同步。再算上應用程式組合中的所有應用程式的重疊之處，結果可能是成百上千個自定義的點對點介面程式：每當開發團隊新增或更改一個應用程式時，需要修改和迴歸測試所有這些介面程式。
ESB（企業服務匯流排）或類似的技術有助於減少為每個應用程式定義單一介面的絕對數量。
但除了數量龐大的介面外，還有語義不一致問題——也就是說，你的應收賬款系統和CRM系統的客戶資料模型不一樣，協調同一實體的不同定義使整合一開始就很棘手，維護起來更為棘手。
ESB無法解決不同語義的問題，因為這個問題首先不是技術問題，而是開發人員意見不一致。
10
更新改造IT員工比
更新改造
他們支援的應用程式更難
你的員工隊伍可能很擅長維護和改進組成當前應用程式架構的那些應用程式和底層平臺，他們可能還很瞭解如何使用他們的應用程式，讓公司按預期執行。
他們可能不是非常瞭解你的更新改造計劃和將要實施替換的應用程式和平臺。
如果你的更新改造計劃會實現，你就需要他們像現在一樣瞭解替換系統。
除此之外，你還需要他們變得很能幹，以便他們發現：只有熟悉可用工具和當前情形的聰明人才能發現改進業務的機會。
一個隱蔽的秘密是，讓他們捲鋪蓋走人，改而招聘接班人，這招無濟於事。
當然，你可以解僱他們，但是找到有能力的接班人並不省錢，也不容易。不管接班人的能力有多強，有一條經驗法則是：換員工需要公司支付相當於一年的薪水，這個成本通常過高。
11
運作順暢的IT組織
很少需要更新改造
運作順暢的IT組織會實行生命週期管理，他們會一直保持所有系統是最新的。這使得預算易於管理——應用程式改裝穩定有序，很少有“大爆炸式”的專案，一個附帶的好處是你的員工隊伍可以與應用程式和平臺一樣保持與時俱進。
作者：Bob Lewis是一名高階管理和IT顧問，專注於IT和業務組織效能、戰略到行動的規劃以及業務/IT整合。