[[128312]]

遺留系統含有成千上萬個執行一大批業務功能的服務組件。比如說，假設貴企業運行的一個內部遺留系統中的一套組件向企業高管提供一份統計報告。為了趕在截至日之前獲得這份每周提交的報告，該高管應該考慮將必要的組件遷移到新的軟件即服務(SaaS)應用程序。

如果經濟可行性研究表明這種遷移是明智的決策，他應該與其他高管以及由開發人員、系統工程師和業務分析人員組成的一個團隊合作，將遺留系統細分成多個組件，然后著手開發那個應用程序。

1. 識別遺留系統資產

開發團隊、高管和遺留系統負責人需要識別遺留系統的資產。這些資產包括如下：

• 說明文檔，包括遺留系統的描述和流程圖以及災難恢復計劃;
• 公司內部數據中心所在的設施;
• 與遺留系統有關的利益相關者;這包括當前用戶(包括高管)、開發人員、系統管理員和業務分析人員;
• 遺留系統運行在上面的IT基礎設施;以及
• 開發人員的技術技能，比如在平臺即服務(PaaS)上開發SaaS應用程序，讓開發人員能夠在虛擬環境共享技能。

2. 發現必要的組件及依賴關系

開發人員應該掃描源代碼，查找供以后提取的服務組件。源代碼包括主程序及其與子例程之間的接口，子例程可能采用了不同于主程序語言的編程語言編寫而成。

下一步是，開發人員識別主程序和子例程中的組件之間的依賴關系。服務組件的依賴關系可能與其他服務組件的依賴關系之間存在多對多的關系。

在識別組件的過程中，開發人員還應該設計一份流程圖，幫助自己將服務組件彼此之間的依賴關系具象化。

3. 提取組件

開發人員應確定應該從遺留系統提取哪些組件。提取服務組件的簡易性取決于下面五個因素：

• 源代碼一開始編寫得有多好;
• 源代碼打補丁、再打補丁有多頻繁，以修復軟件錯誤;
• 遺留系統的說明文檔是否定期更新;
• 開發人員的技術技能(比如，遺留系統的原始開發人員可能再也找不到);以及
• 服務組件的依賴關系具有的復雜性。

4: 接受或拒絕提取的組件

一旦開發人員厘清了依賴關系，他可以接受或拒絕依賴關系。接受依賴關系并不總是意味著按原狀接受服務組件。開發人員可能需要重新設計服務組件的結構，以滿足新的業務需求。結合依賴關系有望消除重復或類似的服務功能，因而減少了服務組件的數量。開發人員把所有被接受的服務組件放入到一個組件庫，以便在構建SaaS應用程序時使用。

構建和安裝SaaS應用程序

在PaaS上構建SaaS應用程序時，開發人員應該確定：

1. 用戶、開發人員、系統管理員和業務分析人員期望從SaaS應用程序獲得什么樣的東西，然后選擇SaaS應用程序運行所需的云部署類型：私有云、公有云還是混合云。

2. 根據用戶、開發人員、系統開發人員和業務分析人員的預期要求構建應用程序時，使用哪些被接受的服務組件。

3. 什么方法將服務組件編排到松散耦合的SaaS應用程序最經濟高效，并測試該應用程序的結果是否滿足預期目標。松散耦合是指，應用程序在等待用戶響應的同時，應用程序的其余部分可以繼續運行。

安裝應用程序后，開發人員應該監控SaaS應用程序的性能以及業務需求方面出現的任何變化，這些變化可能需要更新及重新設計應用程序的服務組件。

英文原文：Four steps to take before migrating legacy components to a SaaS app