應用程式現代化權威指南

什么是應用程式現代化

簡單來說，軟體現代化、老舊系統現代化或老舊應用現代化都是指替換或升級舊軟體的程序，根據系統的情況和公司的情況，對軟體進行現代化改造的方案從輕微修改到完全更換都可以，比方說我們要升級一架飛機，有時可以使用新的航空電子設備、新型號的發動機或舒適的座椅對其進行改裝，有時候就干脆賣了換一架新的，

進行現代化改造的原因

對老舊系統進行現代化改造的主要驅動因素可以分為兩類：一類是希望通過改造消除對舊系統繼續升級維護的技術成本和風險，另一類是希望利用新技術帶來的各種便利，

老舊技術的風險

當聊起使用老舊技術開發的系統時，開發人員通常會說：“如果能用，就先不要動它”，例如，很多企業仍然在使用幾十年前開發的 COBOL 應用系統，這些系統到現在仍然非常穩定，而且速度快，只要不出問題，似乎可以一直這么用下去，但是萬一需要修改或者排除小問題，麻煩就來了，現在已經很難找到 COBOL 開發人員了，當時撰寫這些系統的人大多已經退休，而年輕的開發人員已經不再會想要學習這樣的開發語言，即便輾轉找到一個，他也要花費很長的時間先熟悉并理解代碼，

還有一個風險是，如果老舊系統中使用第三方的軟體，而該軟體已經不繼續提供支持了，這樣就進入了死胡同，在想辦法替換這個軟體之前，只能希望不要出任何漏洞和問題，

采用新技術

與此同時，新的技術和架構范式如雨后春筍般的涌現：

• Web 和移動端 UI 提供了非常好的用戶體驗；
• 容器化技術將應用程式與運行環境進行解耦，以便應用程式能運行在任何環境并且產生相同的行為；
• 微服務架構提高了應用的可伸縮性和彈性，并且打破了大型整體式應用系統的復雜性，技術支持和功能修改也相對容易；
• DevOps 工具可在最短的時間內交付新版本的應用，避免了人為干預；
• 公共云提供即用型服務、無盡的可擴展性和最高水平的容錯性，而只需最少的維護作業，

最后，現代開發語言更容易理解，更不容易出錯，新的生態系統中包括上千個多個經過多次驗證的庫和功能強大的開發人員工具，這些工具能提供代碼完成、除錯、重構、智能提示和糾錯功能，所有這些都提高了開發人員的作業效率，有助于更快地開發高級別的應用系統，

在當今瞬息萬變的數字世界中，生存的首要能力就是適應性，但是，仍在使用老舊軟體的企業根本無法跟上競爭的步伐，在老舊系統上花費了很多，等待了很久，但是仍然無法提供客戶想要的功能，

比爾蓋茨曾經說過：

“唯一成功的大型公司是那些能先于他人淘汰自己產品的公司”

應用系統何時才算過時？

我們看到，每年都有閃亮的新框架和技術出現，是否意味著使用前兩年技術的業務系統過時了？當然不是，“過時”是一個相對的術語，只能在特定的環境中考慮，

在企業級軟體世界中，10-20 年是應用系統的正常生命周期，在此期間，內部或供應商會為該系統提供積極的支持，并且可以根據業務需求進化，一些獨立的后臺系統甚至可以是更老舊的軟體，而不會對業務的靈活性產生明顯影響，但是另一方面，面向終端客戶的門戶或者 App 可能需要每隔幾年進行一次完整的系統現代化改造才能保持競爭力，

因此，如果滿足下列條件，我們才能說這個軟體“過時”了：

• 無法再提供技術支持了，例如，供應商倒閉，且無法找到能提供支持的人員了，
• 無法提供能滿足新的系統級或者業務級需求的更新，例如，一個桌面客戶端軟體無法為用戶提供基于瀏覽器的訪問；或者，應用系統中寫死了部分業務邏輯，但是這部分邏輯與現有的業務流程沖突了，
• 只有在淘汰的軟體或者硬體設備中才能運行，例如，一個手機 App 只能在塞班系統中運行；或者，一個網頁需要使用 Flash 播放器，

這里提到的局限性，也包括雖然可以，但是需要花費難以接受的代價，

現代化改造還是數字化轉型？

這是在踏上現代化征程之前必須回答的戰略問題，數字化轉型不僅要求 IT 環境現代化，還要求改變業務流程，抓住新的數字領域的機會，

我們假想一個簡單的例子，一家傳統的零售銀行，業務由大型機上的 COBOL 軟體提供支持，當變革的時機到來時，銀行可以選擇對軟體和硬體進行現代化改造，但一般來說，這個任務非常困難、漫長而且昂貴，而同時，金融科技方面的創業公司，由于沒有歷史遺留問題，并且無需分析生產系統之間的盤根錯節，他們可以輕裝上陣而輕松領先，

或者，銀行可以保持一切原樣，而在新的綠地開展新的金融科技業務，通過這種方式，銀行可以不受約束地使用一流的技術和實踐，例如，沒有物體辦公室、使用手機上的超級 App，由人工智能驅動的評分系統等，一段時間后，就可以停止舊業務并將客戶遷移到新平臺，這樣的方案與企業應用程式現代化相比，資料更容易遷移，現有的客戶群、豐富的銀行經驗以及一流的技術相結合，完全可以成為一個強大的組合，

希望上面這個極簡的例子能說明現代化改造和數字化轉型之間的區別，

現代化改造策略

以下問題的答案決定了最佳的應用程式現代化策略：

• 我們想要達到什么結果？
• 我們有什么資源？
• 我們是否擁有應用系統的源代碼，是否可以對其進行修改？
• 有問題的系統與其他系統之間是否有互相依賴的關系？
• 系統宕機的話是不是嚴重的問題？必須 7x24 小時全天候運行嗎？

下面我們給出一些現代化改造的選項，從最容易最便宜的一直到最難最貴的，

推遲改造

等一等有時候是最好的選擇，推遲不是說不做，而是從當前的利弊分析，進行現代化改造所需要的開銷和承擔的風險大于業務上能得到的收益，或者當前無法為現代化改造分配所需的資源（例如，業務主管在負責其他優先級更高的事情），又或者問題系統所依賴的其他系統要先進行改造，如果從遠期利益判斷，進行現代化改造是一件必須做的重要事情，那么請不要從任務佇列中洗掉，重要的事情如果一直不做，就會變得緊急且代價昂貴，

改變部署環境

現代化改造的一種選擇是進行部署環境的改造，將業務系統遷移至新的基礎架構，一般來說是指進行容器化部署，通過本地 Kubernetes 實體進行托管或者部署至公有云環境，這種相對簡單的改造可以將系統從老舊的硬體環境中獨立出來，一方面可以避免由于硬體老化造成的損失并減少維護費用，另一方面能提高硬體的使用率和業務的彈性，

選擇新平臺

這個與上一個選項有點類似，選擇新的平臺是指通過對業務系統的簡單修改，從而使用一些云服務，比如資料庫、人員認證、全文檢索服務等，是將除了應用系統本身之外的其他部分進行優化，達到降本增效的目的，

應用系統前端改造

還有一個比較流行的改造方案就是僅對應用系統的前端進行改造，一般來說，只需要對后臺系統進行相對簡單的修改就可以將應用系統的功能通過類似 REST API 的方式進行開放，然后其他應用程式可以通過 API 與原系統進行互動，隨著 Web 和移動端的流行，我們還可以開發新的 Web 端和移動端應用程式，呼叫這些開放的 API，為終端用戶提供更好的體驗，這種方案雖說沒有對后臺系統進行太大的改動，但是面向用戶側卻得到了有力提升，并且可以結合上面兩個選項同步進行，

重構

業務系統往往在構建初期，并沒有預料到后來將要面對的更多更復雜的業務，因此隨著時間推移，系統的彈性不能滿足需求或者由于修修補補已經變得不堪重負，這種情況下，只能通過重構或者重新設計來拯救老系統，最流行的方案就是將原本的單體應用拆分成微服務應用，還有一些其他的方案，例如，對負擔最重的業務進行優化、使用快取、使用集群部署、將部分資料遷移至 NoSQL 資料庫等等，最重要的是保證在重構的程序中，業務系統的主要功能沒有變化，

完全重寫

現代化改造的終極方案就是“復刻替換”或者完全重寫，此時，業務系統就完全替換成一個新的系統了，當有下列問題時，這個選項可能是最好的或者唯一的選擇：

• 系統的功能已經無法滿足業務需要并且無法通過簡單修補實作新的功能
• 沒有資源或者技術修改原有系統的原始碼
• 市場上有更新更好，且支持更完備的產品出現

除非我們已經有一個能替換的產品并且帶有完善的遷移工具，否則“復刻替換”不會是一個簡單的任務，因此，針對系統的不同復雜度，有兩種不同的方案：

1. “大爆炸”式

對于體諒較小或者不太復雜的系統，我們推薦使用這種方案，重新設計全新的方案，并付諸實施，進行完整的測驗之后，定制詳細的遷移方案，然后沐浴更衣，一次將系統完全替換，理論上，我們還需要有一個回滾的 plan B，如果出問題至少還能用老系統頂一下，

2. 逐步替換

這個方案一般用于體量比較大或核心業務系統，比如 ERP 之類，也有那種需要 7x24 小時運行的系統，比如出租車調度系統等，一個替換方案是將單體系統拆分為不同的微服務，保證每個微服務業務相對單一且容易替換，這樣可以逐個擊破，還有一種替換方案是“并行”，新舊系統并行運行，但需要保證資料的同步和一致性，這種方案的好處是業務不會因為新系統的不穩定而中斷，

如何開始現代化改造？

現實中，不同的公司具有不同程度的愿景和風險偏好，而在預算、時間、資源以及復雜的業務系統架構等方面也面臨著不同程度的困難和約束，現代化改造的根本目的一個是為了降本增效，另一個是為了捕捉新的市場機會，

因此，業務系統進行現代化改造的行程最好從對現有的業務系統進行評估開始，以符合公司愿景和風險偏好的原則確定是否要進行舊系統的現代化改造，并且從預算、時間、資源、系統復雜度等方面確定進行改造的方式方法，比如使用投資回報率（ROI）作為關鍵評估指標，

在這個程序中，保持合理的現代化要求非常重要，例如，系統的的可擴展性通常被高估，導致產生不必要的成本，并采取了次優的策略，根據 ROI 指標和系統的依賴關系，可以確定現代化程序的優先級并選擇最佳的現代化解決方案，

Jmix 能否支撐？

Jmix 是一個開源應用程式開發平臺，可以在“完全重寫”的現代化改造方案中顯著減少所需的成本和時間，

Jmix 是面向開發人員的少代碼高效平臺，無需為交付的應用系統支付高昂的許可費用，

Jmix 支持在已有資料庫上直接運行，在“并行”的逐步替換方案中通過該功能提供完美支持，

很多團隊和業務系統已經從傳統的 Delphi、MS Lightswitch、FoxPro、Oracle Forms 等平臺遷移至 Jmix，

Jmix 通用高生產力應用平臺兼顧了低代碼平臺的開發速度和傳統開發的靈活性：

1. 自然貼合 - 使用以資料為中心的開發方法和企業級 UI 組件實作企業應用系統的現代化
2. 未來驗證 - 基于數百萬開發者信任的主流開源技術架構
3. 易上手 - 使用 Java 或 Kotlin 作為唯一開發語言，并提供可視化開發工具幫助新人入門
4. 高效率 - 以創紀錄的時間開發大型應用系統，支持大量的資料模型和業務邏輯
5. 云支持 - 支持任何云環境部署或私有部署，不依賴供應商的基礎設施
6. 成本效益 - 基于 Jmix 構建的應用系統在交付和使用時，無需支付任何使用費

更多有關 Jmix 的功能，可以訪問 Jmix 中國 官網進行了解，

常見問題

• 什么是老舊系統現代化？

  老舊系統現代化是指對不再能滿足業務需求的系統進行升級或替換的程序，

• 為什么需要對老舊系統進行現代化改造？

  1. 缺少能對現有系統提供支撐的專業人員或資源，
  2. 已經不再提供維護的第三方庫或組件，
  3. 系統無法提供對新業務功能的支持，

• 如何定義系統是否老舊？

  1. 無法獲取對系統的技術支持，
  2. 無法通過可接收的成本實作對系統修改以支持新業務，
  3. 系統依賴其他“過時”的系統，

• 目前有什么現代化改造的策略？

  1. 接受風險，繼續等待，
  2. 改變部署環境，
  3. 選擇新平臺，
  4. 替換面向終端用戶的前端界面，
  5. 重構，
  6. 完全重寫，

如果對我們提供的內容有意見或者建議，歡迎聯系我們：

blog：https://blog.abmcode.com

wechat：abmcode_gh

標籤：其他

上一篇：ERP系統能給企業帶來的那些好處

下一篇：在線客服系統原始碼開發實戰總結：動態加載js檔案實作粘貼一段js的sdk代碼，直接引入插件效果