앱 포트폴리오를 위한 TIME 모델(관용, 투자, 이전, 제거)

애플리케이션 합리화 회의가 오전 9시에 시작됩니다. 오전 11시까지 팀은 대상 애플리케이션 400개 중 12개를 분류했습니다. 그중 3개는 이미 이의 제기, 수정, 그리고 다시 이의 제기를 거쳤습니다. 급여를 처리하는 COBOL 배치 프로그램은 분명히 제거 대상은 아니지만, 용인해야 할까요, 아니면 투자해야 할까요? 모두가 기술적으로 부적합하다고 동의하는 기존 청구 시스템은 분명히 마이그레이션해야 하지만, 무엇으로 마이그레이션해야 하며, 해당 시스템에 의존하는 17개의 프로그램은 어떻게 될까요? 회의는 정오까지 예정되어 있습니다. 정오에 누군가 다음 주에 계속하자고 제안합니다. 다음 달이 되자, 이 프로젝트는 조용히 결과물을 내놓지 못하고 중단됩니다.

가트너 TIME 모델은 기업 IT에서 가장 널리 사용되는 애플리케이션 포트폴리오 관리 프레임워크입니다. 이 모델은 비즈니스 가치와 기술적 적합성이라는 두 가지 평가 기준을 사용하여 포트폴리오 내 모든 애플리케이션을 '관용(Tolerate)', '투자(Invest)', '이전(Migrate)', '제거(Eliminate)'의 네 가지 상태로 분류합니다. 이 프레임워크는 논리적으로 타당하고 적용 범위가 넓으며, 미국 연방 CIO 협의회의 애플리케이션 합리화 플레이북에서 권장 방법론으로 인용되기도 합니다. 그러나 실제 적용에서는 성공보다 실패하는 경우가 더 많은데, 그 이유는 프레임워크 지지자들이 언급은 하지만 제대로 설명하지 않는 부분입니다. 바로 분류의 타당성은 그 근거가 되는 증거에 달려 있다는 것입니다. 구조적 근거, 실제 의존성 분석, 실제 복잡성 측정, 소유자 인터뷰가 아닌 실행 추적을 통해 도출된 실제 비즈니스 가치 데이터가 없다면, TIME 분류는 조직 내 정치적인 문제로 전락하게 됩니다. 특히 '이전'과 '제거' 단계에서는 자신이 선호하는 애플리케이션의 위치를 ​​두고 논쟁이 시작되고, 이러한 논쟁은 결코 해결되지 않습니다.

모델: 두 개의 축, 네 가지 성향

TIME 모델은 모든 애플리케이션을 2×2 행렬에 나타냅니다. 가로축은 기술적 적합성으로, 애플리케이션의 현재 기술 구현이 의도된 기능을 얼마나 잘 지원하는지를 나타냅니다. 여기에는 아키텍처 품질, 유지보수성, 통합 기능, 보안 상태, 운영 안정성이 포함됩니다. 세로축은 비즈니스 가치로, 애플리케이션 기능이 조직의 비즈니스 운영, 수익 창출, 규정 준수 또는 전략적 목표에 얼마나 중요한지를 나타냅니다.

	고도의 기술력이 적용된 제품	로우 테크니컬 핏
높은 사업 가치	사다투자하십시오. 이 애플리케이션은 전략적으로 중요할 뿐만 아니라 기술적으로도 우수합니다. 선두 자리를 유지할 수 있도록 투자하십시오.	마이그레이션비즈니스에는 필요하지만 기술이 잘못됐습니다. 기능이 아니라 플랫폼을 교체해야 합니다.
낮은 사업 가치	참다지금은 그대로 두세요. 애플리케이션 자체는 괜찮지만 추가 투자를 할 가치는 없습니다.	제거하다폐기하세요. 가치도 낮고 품질도 떨어져서 계속 보유할 이유가 없습니다.

단순함은 의도적인 것입니다. TIME은 세부적인 투자 계획을 수립하기 위한 것이 아니라, 포트폴리오 내 모든 투자 대상에 대해 명확한 방향성 결정을 내리도록 설계되었습니다. 명확하게 분류할 수 없는 투자 대상은 분류를 위해 추가 정보가 필요한 투자 대상입니다.

4사분면 운영 모델

각 TIME 분류는 단순한 명칭이 아니라, 조직이 향후 해당 애플리케이션을 관리하는 방식을 결정하는 운영 모델입니다.

투자: 최대 가치 추출

투자 대상 애플리케이션은 포트폴리오의 핵심 자산입니다. 높은 비즈니스 가치와 뛰어난 기술적 적합성을 갖추고 있기 때문입니다. 이러한 애플리케이션은 신규 기능 개발, 성능 최적화, 통합 확장, 기술 최신성 유지 관리에 가장 적극적인 투자를 정당화합니다. 기술 최신성이 떨어지거나, 런타임이 노후화되거나, 보안 상태가 구식화되거나, 의존성 문제가 누적되는 투자 대상 애플리케이션은 문제가 발생하기 전에 미분류될 위험이 있습니다.

Invest의 운영 약정 사항:

• 기능 개발 및 기술 유지 관리를 위한 전담 엔지니어링 역량
• 최우선 보안 패치 및 규정 준수 업데이트
• 모든 주요 변경 사항에 대한 건축 심의 위원회 검토
• 1단계 수준에서 SLA 목표를 포함한 사전 예방적 모니터링

마이그레이션: 플랫폼 교체, 기능 유지

마이그레이션 대상 애플리케이션은 조직에 진정으로 필요한 비즈니스 기능을 수행하지만, 기술 플랫폼이 더 이상 적합하지 않고, 유지 관리 비용이 너무 많이 들고, 확장성이 떨어지며, 최신 통합 환경과 단절되어 있습니다. 비즈니스 가치는 마이그레이션 투자를 정당화하지만, 현재 플랫폼의 기술적 상태를 고려할 때 지속적인 투자는 수익률이 낮습니다.

마이그레이션 결정은 다음과 같은 구체적인 질문에 대한 답을 제시합니다. 해당 기능을 유지할 가치가 있는가? 그렇다면 마이그레이션을 진행합니다. 어떤 플랫폼으로 마이그레이션할지, 그리고 어떻게 마이그레이션할지는 TIME 분류에서 결정하는 사항이 아니며, 단지 현재 플랫폼이 적합한 해결책이 아니라는 점만 확인합니다.

기존 환경에서 가장 흔한 마이그레이션 시나리오는 다음과 같습니다. 핵심 비즈니스 로직, 복잡한 규제 계산, 독자적인 가격 책정 규칙, 관할 지역별 세금 로직 등을 구현하는 COBOL 배치 프로그램이 있는데, 확장, 테스트 및 통합 비용이 많이 드는 플랫폼에서 실행되는 경우입니다. 로직 자체는 대체 불가능하지만, 플랫폼이 문제입니다. 이러한 경우, 로직을 보존하면서 현재 비즈니스에 필요한 운영 특성을 제공하는 최신 플랫폼으로 마이그레이션해야 합니다.

용인하다: 기한이 있는 의도적인 무대응

'관용'은 가장 오해받는 사분면입니다. 이는 "이 애플리케이션은 괜찮다"는 의미가 아닙니다. "이 애플리케이션의 기술적 품질이 지금 당장 변경하기 위한 투자를 정당화할 만큼 높지 않고, 비즈니스 가치 또한 이를 제거할 만큼 높지 않다"는 의미입니다. 무기한 연기가 아니라, 정해진 기간 동안 현상 유지를 수용하는 의도적인 선택입니다.

'허용'은 일정 기간 동안 유지하는 것이지 영구적인 상태가 아닙니다. '허용' 영역에 있는 모든 애플리케이션은 명확한 검토 날짜(일반적으로 12~18개월)와 조기 재분류를 유발하는 조건을 정의해야 합니다. 이러한 조건에는 패치할 수 없는 보안 취약점, 플랫폼 변경을 강제하는 종속성 제거, 애플리케이션에 투자할 가치가 생기는 비즈니스 가치 증가, 또는 애플리케이션의 목적을 없애는 비즈니스 기능 변경 등이 포함됩니다.

Tolerate 상태를 영구적인 것으로 간주하는 조직은 TIME 모델이 방지하고자 했던 기술 부채를 정확히 축적하게 됩니다. 2019년에 Tolerate 상태로 분류되어 2026년에도 여전히 Tolerate 영역에 있는 COBOL 프로그램은 결국 문제가 발생했을 때 긴급하게 처리하거나 플랫폼을 더 이상 지원할 수 없을 때 강제로 Migrate해야 하는 유지보수 작업을 7년 더 미뤄온 셈입니다.

제거: 모두가 내리지만 아무도 실행하지 않는 결정

제거는 가장 간단한 분류이지만 실제로 실행되는 경우는 가장 적습니다. 해당 애플리케이션은 비즈니스 가치가 낮고 기술적 적합성도 떨어지므로 유지할 이유가 없습니다. 폐기하십시오.

실행 실패 사례는 이미 잘 알려져 있습니다. '제거 대상'으로 분류되는 경우는 많지만 실제로 조치가 취해지는 경우는 거의 없습니다. 한 대형 금융기관의 2024년 포트폴리오 검토에서는 87개의 '제거 대상'이 선정되었는데, 18개월 후에도 71개만 여전히 운영되고 있었습니다. 분류와 폐기 사이의 간극이 바로 합리화 프로그램이 추진력을 잃는 지점입니다.

Elimate 실행을 방해하는 세 가지 구체적인 장애물은 다음과 같습니다.

숨겨진 종속성. 해당 애플리케이션은 겉보기에는 독립 실행형으로 보였기 때문에 제거 대상으로 분류되었습니다. 그러나 분류 후 구조 분석 결과, 다른 12개의 프로그램이 제거 대상 애플리케이션이 처리하는 출력을 생성하거나, 3개의 외부 시스템이 문서화되지 않은 파일 인터페이스를 통해 해당 애플리케이션으로 데이터를 전송하는 것으로 드러났습니다. 즉, 해당 애플리케이션은 독립 실행형이 아니라 다른 시스템의 숨겨진 인프라 역할을 하고 있는 것입니다. 따라서 해당 분류를 재검토해야 합니다.

데이터 마이그레이션의 걸림돌. 해당 애플리케이션에는 파기할 수 없는 데이터, 의무 보존 기간이 있는 규제 기록, 후속 시스템으로 이전해야 하는 고객 데이터, 감사 프로세스에서 매년 조회하는 과거 거래 기록 등이 있습니다. 데이터 마이그레이션은 시스템 폐기 전에 완료되어야 하며, 데이터 마이그레이션에는 상당한 비용이 소요됩니다.

규제 의무. 일부 애플리케이션은 비즈니스 가치가 0이더라도 규제 체계에서 해당 애플리케이션이 제공하는 기능을 요구하기 때문에 폐기할 수 없습니다. 분기별 규제 제출 서류를 생성하는 보고 애플리케이션은 비즈니스 가치 조사에는 나타나지 않지만 규제 측면에서 중요한 가치를 지닙니다. 규제 의무가 다른 시스템으로 이전될 때까지 해당 애플리케이션은 계속 실행되어야 합니다.

증거 문제: ​​구조적 데이터 없이는 TIME이 실패하는 이유

TIME 구현에서 가장 심각한 실패 원인은 Catio 문서에서 정확히 지적하는 바와 같습니다. 바로 '이동(Migrate)'과 '제거(Eliminate)' 단계에서의 배치 논쟁인데, 이 단계에서는 누군가의 개인적인 선호도가 걸려 있습니다. 객관적인 증거가 없으면 모든 분류는 협상이 됩니다. 애플리케이션 소유자는 '투자(Invest)'를 주장하고, IT 팀은 '이동'을 주장하며, 재무팀은 '제거'를 원합니다. 결국 회의는 가장 논쟁이 적은 '관용(Tolerate)' 단계로 끝나게 됩니다.

구조적 증거는 의견을 측정으로 대체함으로써 이러한 협상을 해결합니다.

기술적 적합성 평가에서 중요한 근거는 다음과 같습니다.

기술적 적합성 지표	출처	분류 방식을 다음과 같이 변경합니다.
프로그램당 순환 복잡도(평균)	정적 코드 분석	낮음 = 적합도 높음, 높음 = 적합도 낮음
데드 코드 비율	도달 가능성 분석	높은 데드코드 = 낮은 적합도
팬인(수신 종속성 개수)	종속성 매핑	높은 팬인 증가는 허용 범위를 제거하고 더 나은 결과를 가져옵니다.
공책 공유 범위	COPY 종속성 분석	공유가 많을수록 결합도가 높아지고 적합도가 낮아집니다.
마지막 의미 있는 변화 이후 경과 시간	Git/변경 관리 로그	장기간의 휴면은 사용되지 않는 코드 또는 안정성을 나타낼 수 있습니다.
보안 취약점 개수	SAST 스캔	높은 수치 = 낮은 적합도

비즈니스 가치 평가에서 중요한 증거는 다음과 같습니다.

비즈니스 가치 지표	출처	분류 방식을 다음과 같이 변경합니다.
기간별 거래량	JCL 실행 로그, 스케줄러 기록	높은 거래량은 높은 가치를 의미합니다.
다운스트림 팬아웃	종속성 매핑	팬아웃이 높을수록 가치가 높아집니다 (많은 사람들이 이에 의존합니다).
규제 기능 플래그	데이터 분류, 규정 준수 등록	현재 가치 = 다른 점수와 관계없이 최소값
수익 인접성	청구/수익 시스템으로의 데이터 흐름 분석	직접 인접할수록 가치가 높아집니다.
사용자 수 또는 API 호출 횟수	접근 로그, 네트워크 트래픽	높은 수치는 높은 값을 의미합니다.

핵심적인 통찰은 다음과 같습니다. 기존 COBOL 시스템의 경우, 이러한 지표 대부분은 CMDB 항목, 애플리케이션 소유자 인터뷰 또는 네트워크 트래픽 분석에서 얻을 수 없습니다. 이러한 지표는 소스 코드의 구조적 분석, 실행 로그, 그리고 실제 운영 환경에서 언제 무엇이 실행되는지를 기록하는 JCL 작업 스케줄러를 통해 얻을 수 있습니다.

COBOL 및 레거시 시스템에 대한 기술적 적합성 평가

표준 기술 적합성 평가 기준인 API 호환성, 클라우드 네이티브 지원 여부, 컨테이너화 지원, 마이크로서비스 아키텍처는 COBOL 배치 프로그램에는 적용되지 않습니다. COBOL 프로그램은 컨테이너화할 수 없으므로, 클라우드 네이티브 기준에 따라 평가하면 모든 레거시 프로그램에 대해 기술 적합성 점수가 0점으로 나오는데, 이는 조직에 아무런 유용한 정보를 제공하지 못합니다.

COBOL과 메인프레임 시스템의 경우, 기술 적합성 점수를 평가하려면 COBOL 관련 특정 기준이 필요합니다.

복잡성 점수(가중치: 30%): 프로그램의 단락 및 섹션 전체에 걸친 평균 순환 복잡도입니다. 평균 순환 복잡도가 10 미만인 프로그램은 관리 가능한 수준의 복잡성을 가지며, 20 이상인 프로그램은 구조적 복잡성으로 인해 유지 관리 비용이 많이 들고 위험합니다.

유지보수성 점수(가중치: 25%): 사용되지 않는 코드 비율, 카피북 공유 범위, 코드 중복률을 종합적으로 고려합니다. 사용되지 않는 코드가 40%이고, 공유되는 카피북이 15개이며, 코드 중복이 심한 프로그램은 기능적 정확성과 관계없이 유지보수성이 낮습니다.

종속성 위험 점수(가중치: 20%): 상위 프로그램들의 중요도에 따라 가중치를 부여한 팬인(Fan-in) 개수입니다. 1차 프로그램에서 50개의 종속성을 가진 프로그램은 종속성 위험이 높으며, 해당 프로그램에 대한 변경 사항은 50개의 하위 프로그램을 조정해야 합니다.

최신성 점수(가중치: 15%): COBOL 방언 및 컴파일러 버전, JCL 구문 최신성, 데이터베이스 인터페이스(내장 SQL 사용 여부, VSAM vs DB2, 배치 전용 vs 배치+CICS). DB2 내장 SQL을 사용하는 COBOL-85 구문으로 작성된 프로그램은 VSAM 파일 접근만 사용하는 COBOL-74로 작성된 프로그램보다 최신 버전으로 간주됩니다.

보안 상태 점수(가중치: 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점 범위의 기술 적합성 점수를 산출합니다. 기능은 동일하지만 구조적 특성이 다른 두 시설은 서로 다른 기술 적합성 점수를 받게 되며, 이러한 점수는 각 시설을 유지 및 확장하는 데 필요한 투자 규모를 정확하게 반영합니다.

표류 허용 문제: 유지 사분면을 위한 거버넌스

Tolerate는 명시적인 Tolerate 관리 없이 TIME을 사용하는 모든 조직에서 시간이 지남에 따라 부채가 누적되는 영역입니다. 메커니즘은 간단합니다. 애플리케이션은 변경할 가치가 없기 때문에 Tolerate 영역에 진입하고, 변경이 최우선 순위가 아닌 경우가 많기 때문에 무기한 Tolerate 영역에 남아 있게 됩니다.

관용적인 거버넌스 규율은 무기한 연기를 방지합니다.

조건 기반 재분류 트리거:

• 30일 이내에 패치할 수 없는 보안 취약점이 발견되었습니다 → 마이그레이션 또는 제거 검토
• 벤더가 애플리케이션이 의존하는 플랫폼 구성 요소의 지원 종료를 발표했습니다 → Migrate 검토
• 사업 가치 점수가 임계값 이상으로 상승(새로운 규제 요건, 사업 모델 변경 등) → 투자 또는 이전 검토
• 종속성 제거로 인해 인터페이스가 변경됩니다 → 마이그레이션 또는 제거 검토
• 데드 코드 분석 결과 애플리케이션이 사실상 비활성화된 것으로 나타났습니다 → 제거 검토

시간 기반 검토 주기:

• Tolerate 시스템에 제출된 신청서는 12개월 후 검토 예정일로 등록됩니다.
• 12개월 검토 시, 해당 신청서는 명시적으로 재분류되거나 새로운 12개월 날짜와 함께 명시적으로 재허용됩니다.
• 재허가를 위해서는 조건이 변경되지 않은 이유를 문서로 설명하는 서면 근거가 필요합니다.
• 두 번 이상 재허가를 받았지만 재분류되지 않은 애플리케이션은 아키텍처 검토 위원회로 이관됩니다.

Tolerate 레지스트리: 모든 Tolerate 애플리케이션의 분류 날짜, 검토 날짜, 소유자 및 재분류를 유발하는 조건 세트를 포함하는 목록입니다. 이 레지스트리는 연례 포트폴리오 검토뿐만 아니라 모든 아키텍처 검토 위원회 회의에서 검토됩니다.

제거 실행 가능성 확보: 폐기 격차 해소

"제거 대상으로 분류됨"과 "성공적으로 폐기됨" 사이의 간극이 바로 합리화 프로그램이 정체되는 지점입니다. 이 간극을 해소하려면 각 제거 결정을 단순한 결론이 아닌, 명확한 범위, 의존 관계 및 성공 기준을 갖춘 프로젝트로 취급해야 합니다.

Eliminate 실행 체크리스트:

• 종속성 검증이 완료되었습니다: 정적 분석 결과, 프로덕션 환경으로 들어오는 종속성이 전혀 없는 것으로 확인되었습니다 (문서화된 종속성뿐만 아니라 구조적으로 검증된 종속성도 0개입니다).
• 데이터 폐기 계획 승인됨: 법무 및 규정 준수 부서에서 데이터 보존 요건을 확인하고 데이터 마이그레이션 또는 아카이빙 계획을 승인했습니다.
• 하위 시스템 알림 완료: 모든 시스템 소유자에게 알림이 전송되었고 활성 종속성이 없음을 확인했습니다.
• 규제 의무 이행 확인 완료: 해당 신청서에는 활성 규제 제출, 감사 또는 규정 준수 요건이 없습니다.
• 폐기 담당자 지정됨: 단순히 분류 결정뿐 아니라, 폐기 절차 실행을 담당할 책임자를 지정해야 합니다.
• 롤백 계획이 정의되었습니다: 서비스 중단 과정에서 미발견된 종속성이 드러날 경우 서비스 복원 절차
• 폐기 예정일: IT 일정에 명시된 구체적인 날짜여야 하며, "나중에 처리하면"이어서는 안 됩니다.

구조 분석 단계: 제거 결정은 프로덕션 실행 경로에서 들어오는 종속성이 전혀 없음을 구조 분석을 통해 확인할 때까지 폐기 계획 단계로 진행되지 않습니다. 제거 실행 실패의 가장 일반적인 원인은 폐기 발표 후 종속성이 발견되어 되돌리기가 불가피해지는 경우입니다. 발표 전에 구조적 종속성 분석을 수행하면 이러한 문제를 방지할 수 있습니다.

TIME 재평가 주기

시간 분류는 영구적인 것이 아닙니다. 조직의 전략이 발전함에 따라 비즈니스 가치도 변화합니다. 기술적 적합성 또한 애플리케이션이 유지 관리되거나 확장되거나 노후화됨에 따라 달라집니다. 모델은 특정 시점의 스냅샷일 뿐이며, 포트폴리오는 끊임없이 변화하는 모습을 필요로 합니다.

연례 종합 재평가: 포트폴리오에 포함된 모든 신청서는 현재의 사업 가치 및 기술적 적합성 기준에 따라 평가됩니다. 3년 연속으로 분류가 변경되지 않은 경우, 해당 신청서가 실제로 안정적인지(이유를 문서화해야 함) 또는 평가가 현재 발생하고 있는 변화를 반영하지 못하는지 여부를 특별히 검토합니다.

이벤트 기반 재평가: 특정 이벤트 발생 시 즉각적인 재분류 검토가 진행됩니다.

• 합병 또는 인수(새로운 포트폴리오 결합)
• 규정 준수 의무에 영향을 미치는 규제 변경
• 주요 플랫폼 지원 종료 발표 (데이터베이스, 운영 체제, 런타임)
• 사업 모델의 중대한 변화 (신제품 라인 출시, 시장 철수, 조직 개편)
• 애플리케이션 관련 보안 사고

변경 로그 관리 원칙: 모든 재분류 사항은 이전 분류, 새 분류, 날짜, 변경 근거, 승인자와 함께 기록됩니다. 각 애플리케이션의 분류 이력은 포트폴리오가 단순히 분류만 하고 방치하는 것이 아니라 적극적으로 관리되고 있음을 보여주는 감사 추적 자료가 됩니다.

방법 SMART TS XL TIME 분류에 대한 증거를 제공합니다.

TIME 모델의 분류 결정은 그 결정의 근거가 되는 증거만큼만 정확합니다. CMDB가 구축되어 있고, API 모니터링이 가능하며, 아키텍처가 문서화된 최신 애플리케이션의 경우, 이러한 증거를 쉽게 확보할 수 있습니다. 하지만 CMDB가 불완전하고, 담당자가 은퇴했으며, 의존성 구조가 문서화되지 않은 레거시 COBOL 포트폴리오의 경우, 증거는 코드 자체에 대한 구조적 분석을 통해 얻어야 합니다.

SMART TS XL의 정적 코드 분석 COBOL 평가에 필요한 기술적 적합성 입력값(프로그램별 순환 복잡도, 데드 코드 비율, 보안 패턴 발견 사항(하드코딩된 자격 증명, 보호되지 않은 파일 접근), COBOL 방언 최신성)을 생성합니다. 이러한 지표는 개발자의 추정치가 아닌 소스 코드에서 도출되며, 애플리케이션의 기능을 누군가가 기억해야 하는 상황에 의존하지 않습니다.

애플리케이션 종속성 매핑은 조기 제거 결정을 방지하는 팬인 카운트와 비즈니스 가치 점수 산정을 지원하는 팬아웃 카운트를 생성합니다. 운영 프로그램에서 45개의 종속성을 가진 애플리케이션은 소유자가 비즈니스 가치를 어떻게 평가하든 관계없이 제거 대상으로 간주하기에 적합하지 않습니다. 종속성 개수는 분류 기준보다 우선하는 구조적 요소입니다.

레거시 현대화 분석은 분류를 변경하는 데드 코드 목록을 생성합니다. CMDB에 활성 애플리케이션으로 나타나지만 인바운드 프로덕션 종속성이 전혀 없는 프로그램은 데드 코드 후보로 간주되어 구조적 증거에 기반하여 '허용'에서 '제거'로 재분류됩니다. 이는 비즈니스 소유자가 프로그램의 존재조차 몰랐을 수도 있다는 점에 대한 평가에 근거한 것이 아닙니다.

영향 분석 기능을 통해 제거 실행 체크리스트를 완료할 수 있습니다. 이 체크리스트는 구조적 분석을 통해 서비스 종료 계획을 시작하기 전에 프로덕션 환경과의 종속성이 전혀 없음을 확인하는 데 사용됩니다. 이는 가장 흔한 제거 실행 실패 원인인 발표 후 드러나는 미발견 종속성을 방지하는 핵심적인 단계입니다.

엔터프라이즈 검색 기능을 통해 TIME 분류 프로세스를 재평가 주기 전반에 걸쳐 조회할 수 있습니다. 예를 들어, 향후 30일 이내에 검토 예정인 '허용(Tolerate)'으로 분류된 모든 애플리케이션, 폐기 예정일이 지정되지 않은 '제거(Eliminate)'로 분류된 모든 애플리케이션, 기술 적합성 점수가 30점 미만이지만 여전히 '투자(Invest)'로 분류된 모든 애플리케이션을 찾을 수 있습니다. 이러한 조회 기능은 TIME 모델을 일회성 분류 작업이 아닌 지속적인 관리 도구로 유지하는 데 필요한 거버넌스 도구입니다.

프레임워크는 그 근거가 얼마나 타당한지에 따라 그 가치가 결정됩니다.

TIME 모델의 2축 구조는 올바릅니다. 비즈니스 가치와 기술적 적합성은 애플리케이션 포트폴리오 결정을 위한 적절한 차원입니다. 네 가지 접근 방식 또한 올바른 선택지입니다. 문제는 프레임워크 자체가 아니라, 조직이 프레임워크에 적용하는 근거 자료의 정확성입니다.

인터뷰 데이터와 CMDB 추정치를 기반으로 한 분류는 조직 내 논쟁을 불러일으킵니다. 반면 구조 분석, 측정된 복잡성, 검증된 의존성 개수, 코드 기반의 기술적 적합성을 바탕으로 한 분류는 타당한 결정을 도출합니다. 예를 들어, 구조 분석 결과 순환 복잡도가 평균 35, 사용되지 않는 코드가 40%, 보안 취약점이 12개 발견된 경우, COBOL 프로그램을 마이그레이션이 아닌 투자 대상으로 간주해야 한다고 주장하는 애플리케이션 소유자는 설득력이 떨어집니다. 반대로 의존성 분석 결과 프로덕션 환경에서 사용되는 의존성이 45개나 되는 경우, 프로그램을 제거해야 한다고 주장하는 IT 팀은 설득력이 약해집니다.

TIME 모델은 증거가 뒷받침될 때 효과적입니다. 조직은 애플리케이션 포트폴리오에 대한 구조적 분석을 통해 합리화 결정이 가장 시급하지만, 그러한 결정을 내리는 데 필요한 문서가 가장 부족한 레거시 애플리케이션에 대한 증거를 구축할 수 있습니다.