銀行如何降低對老舊系統的依賴？

大多數金融機構和服務提供者都有自己的成熟的系統，多年來該等系統一直完美地執行著機構的日常業務。但時至今日，該等系統技術過時、維護和支援成本高企，且在無縫滿足新的市場需求、業務要求和監管要求方面面臨種種局限，導致該等系統的問題多於益處。

該等系統就是標題所說的老舊系統或老舊應用程式，加特納（Gartner）將其定義為『可能基於過時的技術，但對日常運營至關重要的資訊系統』。該定義一語中的，因為金融機構一直面臨的主要挑戰是老舊系統的現代化改造所涉及的所需的時間、成本、工作和風險，尤其是針對關鍵的核心系統。

毫無疑問，金融科技業的興起和數位服務的快速發展給金融機構帶來了新的挑戰和壓力，要求它們迅速提升服務，保留客戶和業務團隊的需求。換言之，要在競爭激烈的市場中維持業務。然而，這種改進是說易行難。

許多金融機構已經啟動老舊系統的現代化改造，其他金融機構還處於評估規劃階段。總的來說，金融機構如今是否堅守老舊系統取決於所擁有的系統、業務規模、服務類別以及內部業務運營的複雜性。

無論是哪種情形，金融機構在該等現代化之旅中都面臨部分共性問題，包括時至今日支出的成本、後續的時間和成本。技術、業務性質和市場需求的不斷變化，會讓新興的現代化系統短短幾年內就過時嗎？

所有該等問題都是現實存在的。金融機構如何保證在老舊系統的現代化改造中獲得可接受的投資回報？簡言之，金融機構如何降低對老舊系統的依賴並加快數位轉型？

過去十年間，技術公司和解決方案提供商嘗試了不同的方法，試圖在維持當前老舊系統的優勢（包括多年來積累下來的商業底蘊和穩定性），與金融服務轉型（包括營造一種全管道使用者友好型全數位客戶體驗）之間尋找最佳平衡點。

業務流程建模

過去十年間，機構開始考慮將業務流程建模（BPM）納入老舊系統轉型計畫。該等解決方案帶來了新的挑戰，包括需要重新審視機構的整個流程和活動以構建清晰的服務目錄，然後將結果分解為各項活動。該等活動可以映射至可以暴露於前端系統，並與老舊系統集成的小型元件。現在，每個新流程都已納入老舊系統和現代化數位系統之間的外部集成層，這是該等方案背後的基本原理。

從面向服務的架構到微服務架構

在金融解決方案的設計中引入面向服務的架構（SOA），是將老舊系統遷移到現代化系統的早期方案之一。但這項技術的自然演進卻催生了一種更強大更靈活的技術，即微服務架構。

微服務架構的作用是增強SOA早期引入的功能。隨著過去十年間雲計算的發展，它在某種程度上已成為將老舊系統遷移到雲原生基礎架構的事實上的標準。

最終引入了一種新的解決方案，以適應基於雲託管和基於雲的基礎架構的新趨勢。新型微服務架構使機構能夠在微服務之間建立一個一對一的，或者（透過事件匯流排）促進端到端事務編排的獨立通信層。機構開始將後端老舊服務本身視為微服務，並將其與新的數位化現代化系統集成時，事件匯流排就尤為重要。

這種方案讓金融機構能夠維持對老舊系統的投資，同時可以無縫遷移到新的現代化系統，逐步實現數位化服務，在不妨礙正常業務運營的情況下滿足業務需求。

此外，它還允許金融機構透過持續集成持續交付（CI/CD）服務，不斷評估、分析和提升新型數位化服務，以提高客戶滿意度縮短服務上市時間，便於機構逐步推出服務。

ProgressSoft遵循相關的微服務架構方案，具體方法是引入一組解決方案，作為金融機構的中間數位轉換層，以及著手從新推出的數位銀行平臺（Digital Banking Platform）遷移到通用支付中心（Payments Hub）。所有這些都基於具有豐富的應用程式設計發展介面（API）的微服務架構。該等API有助於實現平滑集成和現代化，老舊系統的改造和成本幾乎為零。

那麼金融機構什麼時候應該從其老舊系統遷移相關的流程/服務？

金融機構的老舊系統現代化數位轉型之旅不是權宜之計或短期收益計畫。其中包括多個階段，該等階段基於每個機構各自的戰略、路線圖以及各自認定的最簡可行產品（MVP）。在計畫執行期間，業務流程和服務性質將隨著市場需求或內部業務要求而不斷變化。

因此，我們始終建議金融機構避免對老舊系統進行新的投資，以應對這些變化。相反，應該在集成老舊系統的微服務編排平臺中維護新引入的端到端服務，或者完全遷移到新平臺，讓老舊系統從事簡單的事務記錄和總帳分錄工作。

我們發現，遵循該等建議的金融機構可以最大限度地減少對老舊系統的依賴，鼓勵內部團隊加速數位化服務，同時減少該等過程涉及的時間、成本和風險。它還允許機構視情形淘汰老舊系統，因為新的功能性特定服務現在可以滿足其所有內部外部業務需求。