兩家擁有類似規模的 COBOL 系統組合的機構做出了不同的現代化決策。一家機構選擇平台重構：將 COBOL 程式遷移到雲端基礎設施，使用 AWS 大型主機現代化或 COBOL 模擬層，在保留程式碼的同時淘汰了實體大型主機。在 18 個月內，他們將基礎設施成本降低了 40%，該計畫被認為取得了成功。另一家機構嘗試了相同的方法，但在 12 個月後遇到了瓶頸，於是轉向架構重構，將最關鍵的程式重建為 Java 微服務。這次轉型成本是原預算的兩倍，而且耗時三年。
起點相同，結果卻截然不同。差異不在於工具、供應商或團隊，而在於第二個組織選擇了平台重構，但其係統存在架構限制，新平台無法滿足這些限制，例如 CICS 事務依賴、VSAM 文件結構以及即時性要求，而重構後的程式碼如果不進行根本性的重新設計，就無法滿足這些要求。這個決定是在對系統缺乏足夠了解的情況下做出的，因此根本無法做出正確的判斷。
COBOL 中每條路徑的實際意義
通用定義眾所周知。關鍵在於每條路徑對於 COBOL 程式的具體意義，因為 COBOL 程式的架構、執行模型和資料結構與現代應用程式之間存在差異，這些差異會直接影響哪條路徑可行。
COBOL平台重構
平台重構是將 COBOL 程式遷移到新的作業系統環境（通常是雲端基礎架構）的過程，同時基本上保持程式碼不變。 COBOL 程式可以在新平台上編譯和運行，既可以原生運行（使用 IBM 在 Linux 上的 COBOL 編譯器），也可以透過模擬層運行。仿真層會攔截主機特有的呼叫（例如 CICS、VSAM、JES），並將其轉換為雲端原生等效函數。
平台重構保留了什麼：
- COBOL 原始碼
- 程式的邏輯、計算和業務規則
- 批次執行模型（PERFORM 循環，順序檔案處理）
- 資料結構（記錄佈局、副本定義）
- JCL作業結構（為新的調度器重寫，但邏輯上等效）
平台遷移會帶來哪些改變：
- 實體基礎設施（z/OS → 雲端 Linux）
- I/O 子系統（VSAM → 託管文件儲存或資料庫，取決於工具）
- 作業排程器（JES2/JES3 → AWS Batch、Azure Logic Apps 或同等產品）
- 成本模型（基於 MIPS 的計費 → 基於消費量的雲端計費）
關鍵要點：當問題出在平臺本身、執行 z/OS 的成本、基礎設施依賴性或 MIPS 計費模式時，平台重構是正確的選擇。但當問題出在程式碼或架構時，平台重構則是錯誤的做法。
重構 COBOL
架構重構改變了系統的根本設計。業務邏輯得以保留，或從 COBOL 原始碼重新派生，但它使用新的語言、新的執行模型以及新的資料層來實現。最終得到的系統能夠實現 COBOL 系統的功能，但在結構上卻與 COBOL 系統截然不同。
架構重構會改變什麼：
- 程式語言（COBOL → Java、Python、Go、C#）
- 執行模型（批次 → 事件驅動、串流或基於 API）
- 資料層（VSAM 檔案 → 關聯式資料庫、NoSQL、雲端原生儲存）
- 事務模型（CICS 偽對話式 → RESTful 無狀態服務）
- 整合模式（共享資料集 → API 合約、訊息佇列）
重新設計必須保留的內容：
- COBOL 實現的每項業務規則，包括未記錄的邊界情況。
- 每一次計算，包括壓縮十進制算術的數值精度特性
- 所有資料轉換，包括 MOVE 語句中的隱式轉換
- 所有錯誤情況，包括下游系統可能依賴的特定檔案狀態代碼和異常終止行為
注意：架構重構最常見的失敗模式是發現 COBOL 程式碼中包含一些從未在其他任何地方記錄過的業務規則。新系統在某些特定極端情況下的行為與舊系統不同，這並非由於實現錯誤，而是因為規範不完整。因此，在開始架構重構之前，必須從 COBOL 原始碼中提取並記錄業務邏輯。
影響此決定的 COBOL 特有因素
通用現代化框架將平台重構和架構重構主要視為成本、時間安排和風險的決策。而對於 COBOL 語言而言，一些特定於該語言及其執行時期環境的技術因素會強烈影響最終決策的方向。
CICS 事務依賴關係
CICS（客戶資訊控制系統）是許多 COBOL 程式用於互動式工作負載的事務處理中介軟體。發出 EXEC CICS 呼叫的 COBOL 程式隱式依賴 CICS 事務伺服器，以實現螢幕管理、終端通訊、任務排程和程式控制。
平台遷移影響： Micro Focus CICS 模擬、OpenFrame 以及一些 AWS 大型主機現代化功能等工具會模擬 CICS 語意。如果 CICS 的使用方式標準且規範，則仿真可能有效。但如果程式依賴 CICS 內部機制、通訊區域操作、同步點控製或任務級存儲，則仿真精度會降低。
架構重構的意義：將 CICS 程式轉換為 REST API 後，必須將其偽對話式交易模型重新設計為無狀態互動。這是一項架構變更，而非程式碼轉換。
訊號顯示需要重新架構：大量使用 CICS，涉及複雜的逗號區處理、後端事務連結或同步點邏輯。
VSAM 檔案架構
VSAM（虛擬儲存存取方法）是大多數 COBOL 生產程式所使用的索引檔案系統。 VSAM 檔案具有特定的存取模式，包括 KSDS 鍵控順序存取、ESDS 條目順序存取和 RRDS 相對記錄訪問，這些模式在雲端原生儲存中沒有直接對應的實作方式。
平台重構的影響：模擬層會將 VSAM 的讀寫操作轉換為底層檔案或資料庫操作。對於簡單的順序訪問或基於鍵的訪問，這種方式有效。但對於複雜的交替鍵存取、跨多個程式共享的 VSAM 集群，或對效能要求較高的隨機存取模式，模擬會增加延遲和複雜性。
重新架構的意義：用關聯式資料庫取代 VSAM 需要將記錄佈局對應到表格模式，處理隱式資料類型轉換，並將每個檔案存取重寫為使用 SQL 或 ORM。
訊號表示需要重新架構：許多程式共用 VSAM 檔案、替代索引存取模式或模擬無法滿足的即時效能要求。
批量處理與即時處理的需求
COBOL 批次處理程序旨在按計劃時間視窗順序處理大量記錄。許多銀行、保險和政府系統仍然運行夜間批次作業，以處理數百萬筆交易、產生報告並更新主文件。
平台遷移的意義：批次語意可以很好地遷移到雲端批次執行（AWS Batch、Azure Batch）。順序處理模型在平台變更後依然有效。如果需求只是在更經濟的基礎架構上執行相同的批次作業，那麼平台遷移就能直接解決這個問題。
架構重構的影響：如果業務需求發生變化，例如從夜間批次改為近實時處理，從基於文件的交換改為 API 集成，從單體批處理運行改為獨立觸發的微服務，那麼平台重構無法滿足新的需求，架構必須進行相應的調整。
訊號推動架構重構：利害關係人要求即時處理、基於 API 的整合、事件驅動架構或亞秒響應時間，而批次語意無法提供這些。
無需外部規範的嵌入式業務邏輯
這是COBOL特有的一個最容易被忽略的因素。主要風險包括：嵌入在幾十年前程式碼中的關鍵業務規則遺失，以及系統行為文件不足。 COBOL程序通常包含業務規則唯一倖存的規範。例如，要求進行特定計算的法規制定於1983年，而理解該法規的業務分析師已於2001年退休。因此，COBOL程式碼不僅僅是實現，它本身就是文檔。
平台重構的意義在於：由於程式碼得以保留，業務規則也能完整保留。這是平台重構最強而有力的論點之一。
架構重構的意義：必須先從 COBOL 原始碼中提取業務規則，然後再重新實作。 <cite index=”28-1″>缺乏文件、緊密耦合的程式碼會在每個階段都增加工作量。 </cite> 如果提取不完整，新系統的規範就會與舊系統不同，而這些差異會在生產環境中顯現出來。
決策框架：八個問題
在選擇道路之前，這八個問題可以提供所需的證據，使人們能夠自信地做出決定，而不是憑空猜測。
1. 推動這現代化進程的主要動力是什麼？
- 基礎設施成本 → 平台重構就夠了
- 平台依賴性（z/OS）→重新平台即可。
- 即時性需求 → 需要重新架構
- 整合需求（API）→可能需要重新架構
- 可維護性/人才可用性 → 重新架構或重構
2. CICS 耦合程度如何？列舉所有 EXEC CICS 呼叫。統計包含超過 20 個不同 CICS 指令的程式數量。如果模擬保真度不確定，那麼 CICS 耦合程度高的程式不適合進行平台遷移。
3. VSAM 存取模式是什麼？識別使用備用金鑰、共用簇或對效能要求高的隨機存取來存取 VSAM 檔案的程式。這些都是平台重構風險指標。
4. 業務邏輯是否已在外部文件中記錄？如果 COBOL 原始碼是唯一的權威規範，則重新架構需要將業務邏輯提取作為先決步驟，而不是並行工作。
5. 批次視窗容差是多少？如果業務需要以更低的成本實現相同的批次模型，則進行平台重構。如果業務需要即時實現相同的處理功能，則進行架構重構。
6. 依賴關係的複雜度如何？一個擁有五十個下游依賴項、資料集、子程序和 JCL 呼叫程序的程序，比獨立的實用程式具有更高的架構重構風險。依賴關係結構決定了遷移順序和測試範圍。
7. 程式碼中有多少百分比是無效代碼？在進行任何轉換之前，將無效代碼排除在外可以降低兩種方案的工作量。對於架構重構程序，未被排除的無效代碼將以全部成本進行轉換，然後被丟棄。
8. 複雜度分佈如何？每個程式的圈複雜度超過 50，或包含超過 20 個副本，顯示這些程式架構重構成本高且平台遷移風險較大。這些程式需要單獨處理，而不是批量分配路徑。
應用此框架：四個 COBOL 系統設定檔
| 帳戶 | 特徵： | 推薦路徑 | 合理 |
|---|---|---|---|
| 穩定批次實用程式 | 順序檔案 I/O，無 CICS，邏輯文件完善，複雜度低 | 重新平台 | 平臺成本才是問題所在；程式碼本身並非瓶頸。 |
| CICS密集型線上交易 | 大量使用 EXEC CICS、commarea 依賴關係、偽對話模型 | 重構者 | CICS 模擬風險高；可能需要即時支援 |
| VSAM 主檔案處理器 | 複雜的VSAM存取模式，多個程式共享，讀取量高 | 首先評估仿真保真度；若模擬有效，則重新建置平台。 | VSAM 模擬是決策變數。 |
| 業務邏輯庫 | 未成文規則，無外部規範，具有很高的監管意義 | 先提取邏輯，然後選擇 | 如果沒有事先提取業務邏輯，重新架構的風險是不可接受的。 |
關鍵要點： <cite index=”30-1″>在實務中，大型企業會採用混合方法：對穩定的部分進行平台重構，重構難以維護的程式碼，重寫少數需要新功能的系統，並淘汰不再使用的部分。 </cite> 決策並非針對整個專案組合，而是針對特定的工作負載，根據證據對每個專案或專案組單獨進行決策。
混合方法：先進行平台重構，必要時再進行架構重構
一個實用的原則是：先重新託管或重新建置平台以快速止損，然後再重構或重新架構那些真正具有競爭優勢的系統。
對於大多數擁有大量 COBOL 程序的組織而言，實際操作順序如下：
第一階段：對符合條件的程序進行平台遷移。對於沒有 CICS、I/O 操作簡單直接、邏輯清晰且複雜度低的程序，可以以可預測的工作量和風險進行平台遷移。這可以快速降低基礎設施成本，並增強組織信心。
第二階段：評估複雜程序。對於存在 CICS 耦合、複雜 VSAM 模式或未記錄業務邏輯的程序，在選擇解決方案之前需要進行單獨分析。在此階段，需要提取業務邏輯並進行結構分析，以確定是否需要重新架構以及重構的範圍。
第三階段：重構存在架構障礙的程序。對於無法在重構後的基礎架構上滿足業務需求、即時性要求、API整合和事件驅動處理的程序，將採用絞殺圖模式進行重構：在重構後的程序旁邊建立新服務，隨著每個元件的驗證，逐步將流量路由到新實現，並在所有流量遷移完畢後停用舊程序。
第四階段：淘汰失效代碼。在結構分析中被識別為失效的程序將被排除在兩個路徑之外並停用，從而在無需任何轉換工作的情況下降低持續維護成本。
在做出任何決定之前，分析必須先得出哪些結果？
上述決策框架在輸入資料為證據而非估計值時能得到更準確的結果。提供這些輸入資料的結構分析需要解析實際的 COBOL 原始程式碼，而不是依賴文件或開發人員的知識。
分析必須針對每個項目確定以下內容：
一份完整的程序清單，包括文件中未涵蓋的程序。在大型 COBOL 環境中，未記錄的程式數量通常超過總數的 20%。依賴關係圖，顯示哪些程序呼叫了哪些其他程序，哪些資料集被共享，哪些 JCL 作業呼叫了哪些程序。每個程式的 CICS 指令清單，包括呼叫的數量、類型和複雜度。 VSAM 存取模式分析，包括存取方法、程式間共用的檔案以及具有備用索引的檔案。圈複雜度分佈，確定哪些程式結構簡單，哪些程式是任何轉換的高風險候選程式。死代碼識別，確定哪些程式和段落沒有入站執行路徑。業務邏輯提取，以可用於驗證任一路徑輸出的形式，提取每個程式實現的規則。
如果沒有這份清單，路徑決策就是在資訊不完整的情況下做出的。程式被分配到平台重構專案是基於一些假設，而這些假設在模擬過程中揭示規劃階段未曾發現的架構限制時，就會被證明是錯誤的。
SMART TS XL 產生決策前證據
SMART TS XL“ 遺產現代化 分析可自動執行上述結構清單，同時解析每個 COBOL 程式、副本、JCL 作業和 VSAM 檔案引用，以建立統一的依賴關係模型，從而使路徑決策基於證據。
應用程式依賴關係映射產生跨程式呼叫圖和資料集共享圖，從而確定依賴關係的複雜性，而依賴關係的複雜性是直接影響平台重構模擬風險以及架構重構範圍和順序的最直接因素。
靜態程式碼分析會為專案組合中的每個程式產生複雜度指標、CICS 呼叫清單和死代碼識別資訊。對於圈複雜度高於閾值且與 CICS 耦合度高的程序，系統會自動將其標記為需要重新架構或評估的候選程序，而不是批量分配給平台重構。
JCL展開解析符號參數並建立完整的批次執行依賴鏈，該依賴鏈定義了哪些 JCL 作業呼叫哪些程式、以什麼順序呼叫哪些程式以及使用哪些資料集，從而提供了操作上下文，該上下文決定了任一路徑的輸出必須如何運作才能滿足批次調度要求。
影響分析功能可在專案啟動前明確每條路徑的範圍：對於任何選定進行架構重構的程序，影響分析會列出所有必須更新、重新測試或與重構元件協調的依賴程序。對於平台重構候選程序，同樣的分析會辨識哪些共享資料集和共享子程序會造成跨程序依賴關係，而這些依賴關係必須得到一致的處理。
企業搜尋功能讓整個程式中的完整清單都可以查詢：在幾秒鐘內，跨越數百萬行 COBOL 程式碼，尋找使用特定 CICS 指令的每個程式、存取特定 VSAM 叢集的每個程式、定義特定資料結構的每個副本。
那些能夠正確做出這項決策的組織，是基於結構性證據而非專案計畫假設做出決策的。結構性證據是指… SMART TS XL 產生。
