應用組合的時間模型（容忍、投資、遷移、淘汰）

應用程式合理化會議於上午 9 點開始。到上午 11 點，團隊已對 400 個待處理應用程式中的 12 個進行了分類。這 12 個分類中，有 3 個已經過多次質疑、修改，甚至再次質疑。運行工資計算的 COBOL 批次程式顯然不屬於「淘汰」範疇，但它究竟是「容忍」還是「投資」呢？大家都認為技術上已經過時的舊式計費系統顯然屬於「遷移」範疇，但要遷移到什麼系統？依賴該系統的 17 個程式又該如何處理？會議原定於中午結束。中午時分，有人提議下週繼續。到了下個月，這項計畫悄悄停止了。

Gartner TIME 模型是企業 IT 領域中應用最廣泛的應用組合管理架構。它使用業務價值和技術匹配度這兩個評分維度，將組合中的每個應用歸類為四種處置方式之一：容忍 (Tolrate)、投資 (Invest)、遷移 (Migrate) 和淘汰 (Eliminate)。此框架邏輯嚴密、適用範圍廣，並被美國聯邦首席資訊長委員會的《應用合理化手冊》列為推薦方法。然而，在實踐中，它失敗的次數遠多於成功的次數，其原因雖被該框架的支持者提及，但很少深入探討：分類的有效性取決於其背後的證據。如果沒有結構性證據、真實的依賴關係計數、真實的複雜性度量以及從執行追蹤而非所有者訪談中得出的真實業務價值數據，TIME 分類就會淪為組織政治。關於應用處置方式的爭論往往始於「遷移」和「淘汰」階段，因為此時某些人最重視的應用岌岌可危，而這些爭論最終往往無果而終。

模型：兩軸四向

TIME 模型將每個應用程式繪製在 2×2 矩陣中。橫軸代表技術契合度，即應用程式目前的技術實現對其預期功能的支援程度，包括架構品質、可維護性、整合能力、安全性以及運作可靠性。縱軸代表業務價值，即應用程式的功能對組織的業務運作、收入成長、合規性或策略目標的重要性。

	高科技合身	低技術合身度
高商業價值	投資為其提供資金。該應用既具有重要的戰略意義，也具備可靠的技術可行性。投資以保持其領先地位。	遷移業務需要它，但技術不合適。應該更換平台，而不是功能。
低商業價值	容忍暫時先別管它。這個應用程式本身沒問題，但沒必要再投入更多資源。	排除把它淘汰吧。價值低，品質差，沒有理由保留它。

這種簡潔性是刻意為之。 TIME 的設計目的並非提供細緻的投資規劃，而是為投資組合中的每個應用提供明確的方向性決策。無法明確歸類的應用，則需要更多資訊才能進行分類。

四象限營運模式

TIME 的每個處置方式不僅僅是一個標籤，它是一種營運模式，決定了組織如何管理該應用程式的後續發展。

投資：最大價值提取

投資類應用是投資組合中的瑰寶：它們具有極高的商業價值和技術契合度。因此，值得在新功能開發、效能最佳化、整合擴展和技術更新維護方面投入最多的資源。如果投資類應用在技術更新、運行時環境老化、安全防護過時或依賴關係不斷累積等方面出現問題，那麼在人們察覺之前，它們就有可能滑向遷移階段。

投資營運承諾：

• 具備專門的工程能力，用於功能開發和技術維護
• 首要任務是安全性修補程式和合規性更新。
• 架構審查委員會負責所有重大變更
• 主動監控，並設定一級服務等級協定 (SLA) 目標

遷移：替換平台，保留功能

遷移的應用程式能夠執行組織真正需要的業務功能，但其運行的技術平台已不再適用，維護成本過高，擴展性差，且與現代整合環境脫節。業務價值足以證明遷移投資的合理性；而技術現狀使得持續投資現有平台的回報甚微。

「遷移」方案回答的是一個具體問題：該功能是否值得保留？如果值得保留，則進行遷移。至於遷移到哪個平台以及如何遷移，則是另一個獨立的決定，TIME 分類並不做此決定，它只是表明當前平台並非最佳選擇。

傳統環境中最常見的遷移場景：一個 COBOL 批次程序，它實現了關鍵的業務邏輯、複雜的監管計算、專有定價規則以及特定司法管轄區的稅務邏輯，而該程序運行在一個擴展、測試和集成成本高昂的平台上。邏輯本身無可取代，問題在於平台。因此，需要遷移到現代化的平台，該平台既能保留邏輯，又能提供業務目前所需的運作特性。

容忍：故意不作為，但有期限

「容忍」是最容易被誤解的象限。它並非意味著“這個應用沒問題”，而是意味著“這個應用的技術品質不足以支撐現在投入資源進行更改，其商業價值也不足以支撐將其淘汰”。這是一種在特定時期內接受現狀的深思熟慮的選擇，而非無限期的拖延。

「容忍」是一種限時暫停狀態，而非永久狀態。處於「容忍」象限的每個應用程式都應設定明確的審查日期（通常為 12 至 18 個月），並定義觸發提前重新分類的條件：無法修復的安全漏洞、依賴項的停用導致平台變更、業務價值的提升使應用程式值得投資，或業務功能變更導致其用途不再適用。

將「容忍」視為永久狀態的組織，恰恰累積了TIME模型旨在避免的技術債。一個在2019年被「容忍」的COBOL程序，如果到2026年仍然處於「容忍」象限，就意味著它額外獲得了七年的維護延期，而這些延期維護最終都需要進行，要么是出現故障時的緊急維護，要么是平台無法繼續支持時被迫遷移。

淘汰：人人做卻無人執行的決定

淘汰是最直接的分類，也是最少執行的處理方式。該應用程式業務價值低，技術適用性差，沒有理由保留它。將其停用。

執行失敗的案例屢見不鮮：雖然「淘汰」計畫的申請者熱情高漲，但幾乎從未真正付諸行動。一家大型金融機構在2024年進行的投資組合審查中，列出了87個待淘汰項目。 18個月後，其中71個項目仍在運作。從分類到最終終止，正是合理化計畫失去動力的根源所在。

消除計畫的執行面臨三大障礙：

隱藏的依賴關係。該應用程式最初被歸類為“消除型”應用程序，因為其表面上看起來是獨立運行的。然而，分類之後，結構分析顯示，有十二個其他程式會產生輸出，而該「消除型」候選應用程式需要處理這些輸出；此外，還有三個外部系統透過一個未公開的檔案介面向其發送資料。因此，該應用程式並非獨立運行，而是其他系統的隱藏基礎設施。必須重新評估其分類。

資料遷移障礙。該應用程式包含無法銷毀的資料、具有強制保留期限的監管記錄、必須遷移到後續系統的客戶資料以及審計流程每年查詢的歷史交易記錄。資料遷移必須先於系統停用，而資料遷移成本高昂。

監管義務。有些應用程式即使業務價值為零也無法停用，因為監管框架要求它們提供相應的功能。例如，用於產生季度監管申報表的報告應用程序，其監管價值無法體現在任何業務價值評估中。在監管義務轉移到其他系統之前，該應用程式必須繼續運作。

證據問題：為什麼《時代》雜誌在缺乏結構化資料的情況下會失敗

TIME 實作中最主要的失敗模式正如 Catio 文件中明確指出的那樣：部署方案的爭論始於「遷移」和「淘汰」這兩個選項，而這往往關乎某些人心儀應用程式的命運。在缺乏客觀證據的情況下，每一次分類都變成了一場談判。應用程式所有者力主“投資”，IT 團隊力主“遷移”，財務團隊則希望“淘汰”。最終，會議以「容忍」告終，因為這是最不具爭議的方案。

結構性證據透過衡量標準取代意見來解決這些爭論。

對於技術適配度分數而言，重要的證據是：

技術適配指標	來源	將分類向
每個程序的圈複雜度（平均值）	靜態代碼分析	低 = 擬合度較高，高 = 擬合度較低
死碼百分比	可達性分析	高死碼率 = 低適配率
扇入（入站依賴計數）	依賴關係映射	高扇入量增加耐受性超過消除性
副本分享範圍	複製依賴性分析	高共享度 = 高耦合度 = 低契合度
自上次發生重大變化以來的時間	Git/變更管理日誌	長期休眠可能表示程式碼已失效或穩定性問題。
安全漏洞數量	SAST掃描	高計數 = 低擬合度

對於企業價值評分而言，關鍵證據如下：

業務價值指標	來源	將分類向
每期交易量	JCL 執行日誌、排程器記錄	成交量高 = 價值高
下游扇出	依賴關係映射	高扇出率 = 更高價值（許多因素都依賴於此）
監理功能標誌	資料分類、合規性登記	當前值 = 最低值下限，不考慮其他分數
收入鄰近性	計費/收入系統的資料流分析	直接相鄰 = 更高價值
用戶數或 API 呼叫數	訪問日誌、網路流量	計數高 = 值較高

關鍵在於：對於傳統的 COBOL 系統，大多數此類指標無法透過組態管理資料庫 (CMDB) 條目、應用程式擁有者訪談或網路流量分析取得。它們只能透過對原始程式碼、執行日誌以及 JCL 作業調度進行結構分析來獲取，這些調度記錄了生產環境中實際運行的程式及其運行時間。

COBOL 與遺留系統技術匹配度評分

對於 COBOL 批次程式而言，標準的技術契合度評分標準、API 相容性、雲端原生就緒性、容器化支援以及微服務架構等都無關緊要。 COBOL 程序無法容器化；如果按照雲端原生標準進行評分，所有遺留程序的技術契合度得分都將為零，這對組織而言毫無意義。

對於 COBOL 和大型主機系統，技術匹配度評分需要符合 COBOL 特有的標準：

複雜度分數（權重：30%）：程序各段落和章節的平均圈複雜度。平均圈複雜度低於 10 的程式複雜度可控；高於 20 的程式結構複雜，維護成本高且風險較大。

可維護性評分（權重：25%）：由死代碼比例、共享副本範圍和代碼重複率綜合得出。一個程式如果死碼佔比高達 40%，共享副本數量達 15 個，且程式碼重複率很高，那麼即使其功能正確，其可維護性也較低。

依賴風險評分（權重：20%）：分支數量根據引入的依賴項的重要性進行加權。例如，一個專案如果從一級專案引入了 50 個依賴項，則其依賴風險較高，對其進行任何變更都需要協調 50 個下游專案。

時效性評分（權重：15%）： COBOL 方言和編譯器版本時效性、JCL 語法現代性以及資料庫介面（嵌入式 SQL 的舊程度、VSAM 與 DB2 的對比、僅批次與批次​​+CICS 的對比）。使用 COBOL-85 語法並嵌入 DB2 SQL 的程式比使用 COBOL-74 語法並僅透過 VSAM 檔案存取的程式更新。

安全態勢評分（權重：10%）：存在硬編碼憑證、未受保護的檔案存取、缺少檔案狀態檢查以及動態 SQL 建構中的 SQL 注入漏洞。

Technical Fit Score = (100 - complexity_score) × 0.30
                    + maintainability_score × 0.25
                    + (100 - dependency_risk) × 0.20
                    + currency_score × 0.15
                    + security_score × 0.10

Where each component is scored 0-100, with 100 being best.

此評分公式基於結構代碼分析而非定性評估，得出 0-100 的技術契合度評分。功能相同但結構特徵不同的兩個應用程式會產生不同的技術契合度評分，這些評分能夠準確反映維護和擴展每個應用程式所需的不同投入。

容忍漂移問題：維持象限的治理

在任何使用 TIME 卻缺乏明確「容忍」治理機制的組織中，「容忍」象限都會隨著時間的推移而累積債務。其機制很簡單：一個應用程式進入「容忍」象限是因為它不值得更改，然後它會無限期地停留在「容忍」象限，因為更改它永遠不會是最緊迫的事項。

寬容的治理原則可以防止無限期的拖延：

基於條件的重新分類觸發器：

• 已發現無法在 30 天內修復的安全漏洞 → 審查是否遷移或移除
• 供應商宣布應用程式所依賴的平台元件停止支援 → 審查遷移
• 業務價值評分提升至門檻以上（新的監管要求、業務模式變更）→ 審查是否投資或遷移
• 依賴項的淘汰迫使介面發生變化 → 審查遷移或消除方案
• 死代碼分析顯示該應用程式實際上已停止運行 → 審查並刪除

基於時間的審查節奏：

• 申請進入 Tolerate 系統後，將進行 12 個月的審查。
• 在 12 個月的複審中，申請將被明確重新分類或明確重新批准，並賦予新的 12 個月期限。
• 重新耐受性需要一份書面理由，說明為什麼條件沒有改變。
• 如果一項申請被重新審核超過兩次而未進行重新分類，則會觸發向架構審查委員會的升級審查。

Tolerate 註冊表：一份維護完善的列表，記錄了所有 Tolerate 應用程式及其分類日期、審核日期、所有者以及觸發重新分類的條件集。此註冊表在每次架構審核委員會會議上都會進行審核，而不僅僅是在年度專案組合審核中。

使「消除」成為可執行檔：彌合退役差距

「被列為淘汰項目」和「成功退休」之間的差距，正是合理化計畫停滯不前的原因。要彌補這一差距，就需要將每項「淘汰」決定都視為一個具有明確範圍、依賴關係和成功標準的項目，而不是一個既定的結論。

消除執行清單：

• 依賴關係驗證完成： 靜態分析證實，入站生產依賴項為零（不僅是文件記錄的依賴項為零，而是結構上驗證過的依賴項為零）。
• 數據處置方案已獲批准： 已確定監管方面的資料保留要求，資料遷移或歸檔計畫已獲得法律和合規部門的批准
• 下游通知完成： 所有使用該系統的所有者均已收到通知並確認無活動依賴關係。
• 監理義務查核完成： 該申請不涉及任何主動的監管申報、審計或合規要求。
• 退役所有者已指定： 指定負責執行退役工作的人員，而不僅僅是負責分類決定的人員。
• 已訂定回滾計畫： 如果停用過程中發現存在未發現的依賴關係，則應依照下列步驟恢復服務。
• 已確定的退役日期： IT 日曆上的具體日期，而不是「等我們有空的時候再說」。

結構分析關卡：在結構分析確認生產執行路徑中不存在任何入站依賴之前，不會執行「消除」決策，而是直接進入退役規劃階段。導致「消除」執行失敗的最常見原因是，在發布退役公告後才發現依賴關係，從而強制回溯。在發佈公告前進行結構依賴分析可以避免這種情況。

TIME重新評估週期

TIME分類並非一成不變。業務價值會隨著組織策略的演變而改變。技術契合度也會隨著應用程式的維護、擴展或老化而改變。模型只是一個快照；而作品集則需要動態的畫面。

年度全面重新評估：投資組合中的每個應用程式都將根據當前的業務價值和技術契合度標準進行評分。連續三年未發生變化的分類將接受專門審查，以確定該應用程式是否確實穩定（需記錄原因），或評估是否未能反映正在發生的變化。

事件觸發式重新評估：特定事件觸發立即重新分類審查：

• 合併或收購（新的投資組合組合）
• 影響合規義務的監理變化
• 主要平台生命週期結束公告（資料庫、作業系統、執行時期）
• 商業模式發生重大變化（新產品線、退出市場、組織結構重組）
• 涉及應用程式的安全事件

變更日誌規範：每次重新分類都會記錄以下資訊：先前分類、新分類、日期、變更依據以及審核者。每個應用程式的分類歷史記錄構成審計追踪，表明該組合得到了積極管理，而不是僅僅分類後就被遺忘。

SMART TS XL 為TIME分類提供證據

TIME模型的分類決策的準確性取決於背後的證據。對於具備組態管理資料庫（CMDB）、API監控和完善架構文件的現代應用程式而言，這些證據唾手可得。而對於CMDB不完整、維護人員已退休且依賴關係結構缺乏文件記錄的遺留COBOL系統，則必須透過對程式碼本身的結構分析來取得證據。

SMART TS XL“ 靜態程式碼分析 產生 COBOL 評分所需的各項技術指標：每個程式的圈複雜度、死碼百分比、安全模式發現（硬編碼憑證、未保護的文件存取）以及 COBOL 方言的時效性。這些指標源自於原始程式碼，而非開發人員的估算，並且無需任何人記住應用程式的功能。

應用程式依賴關係映射會產生扇入計數，以防止過早做出「消除」決策；也會產生扇出計數，以支援業務價值評分。無論應用程式擁有者如何評估其業務價值，一個擁有 45 個來自生產程式的入站相依性的應用程式都不是一個安全的「消除」候選對象。依賴項計數是凌駕於分類論證之上的結構性事實。

遺留系統現代化分析會產生死程式碼清單，從而改變分類：在 CMDB 中顯示為活動應用程式但沒有任何入站生產依賴項的程式是死程式碼候選者，根據結構證據（而不是業務所有者對可能從未聽說過的程式的評估）從容忍重新分類為消除。

影響分析功能使「消除」執行清單得以實現：在任何退役計畫開始之前，透過結構分析確認不存在任何入站生產依賴項。這是防止最常見的「消除」執行失敗的關鍵環節，即在發佈公告後才發現未發現的依賴項。

企業級搜尋功能使得在整個重新評估週期內，TIME 分類流程均可查詢：查找所有被歸類為“容忍”且審核日期在未來 30 天內的應用程序，所有被歸類為“淘汰”但未分配停用日期的應用程序，以及所有技術匹配度評分低於 30 分但仍被歸類為“值得關注”的應用程序。這些查詢是有效的管理工具，確保 TIME 模型始終是積極的管理工具，而非一次性的分類活動。

框架的好壞取決於其證據的充分性。

TIME模型的雙軸結構是正確的。業務價值和技術契合度是應用組合決策的正確維度。四種處置方式也是正確的選項。問題不在於框架本身，而在於組織所提供的證據基礎。

基於訪談資料和組態管理資料庫 (CMDB) 估算的分類會引發組織內部的爭論。而基於結構分析、複雜度測量、已驗證的依賴項數量以及程式碼衍生的技術適用性等因素的分類，則能得出站得住腳的決策。如果結構分析顯示其 COBOL 程式的平均圈複雜度為 35，40% 的程式碼為死程式碼，且存在 12 個安全漏洞，那麼主張「投資」而非「遷移」的應用程式擁有者的論點就難以成立。同樣，如果依賴項分析顯示存在 45 個來自生產環境的依賴項，那麼主張「淘汰」程序的 IT 團隊的論點也較為薄弱。

當證據確鑿時，TIME 模式就能發揮作用。組織透過對應用程式組合進行結構分析，為那些最需要合理化決策且最缺乏相關文件支援的遺留應用程式建立證據。