기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 포트폴리오 분석 및 마이그레이션 계획
이 평가 단계는 포트폴리오 검색 및 [초기 계획 섹션에서 시작된 포트폴리오 수준 검색 및](portfolio-discovery-initial-planning.md) 분석을 완료하는 데 중점을 둡니다. 목표는 애플리케이션 및 인프라의 초기 포트폴리오에 대한 기준을 반복하고 설정하는 것입니다. 이 기준에는 모든 종속성 식별, 마이그레이션을 위한 합리화 모델 반복, 자세한 비즈니스 사례 생성, 마이그레이션 웨이브 계획 요약이 포함됩니다. 따라서 필요한 데이터 충실도가 높아집니다. 이 단계에는 시간 투자가 필요합니다. 평가 결과를 가속화하려면 검색 도구와 같은 프로그래밍 방식의 데이터 소스를 최대한 많이 사용하는 것이 좋습니다.
이 단계의 주요 결과는 다음과 같습니다.
+ 충실도가 높은 애플리케이션 및 인프라 인벤토리
+ 각 애플리케이션에 대한 상위 수준 마이그레이션 전략
+ 신뢰도가 높은 마이그레이션 웨이브 플랜
+ 세부 비즈니스 사례
# 전체 평가 데이터 요구 사항 이해
다음 표에서는 마이그레이션의 애플리케이션 및 관련 인프라에 대한 전체 포트폴리오 보기를 얻는 데 필요한 정보를 설명합니다.
테이블은 다음 약어를 사용합니다.
+ R, 필수
+ O, 선택 사항의 경우
+ 해당 없음, 해당 없음
**애플리케이션**
| **속성 이름** | **설명** | **인벤토리 및 우선순위 지정** | **세부 비즈니스 사례** | **권장 충실도 수준(최소)** |
| --- | --- | --- | --- | --- |
| 고유한 식별자 | 애플리케이션 ID를 예로 들 수 있습니다. 일반적으로 기존 CMDBs 또는 기타 내부 인벤토리 및 제어 시스템에서 사용할 수 있습니다. 조직에 고유 ID가 정의되지 않은 경우 고유 IDs를 생성하는 것이 좋습니다. | R | R | 높음 |
| 애플리케이션 이름 | 이 애플리케이션이 조직에 알려진 이름입니다. 해당하는 경우 상용 off-the-shelf(COTS) 공급업체 및 제품 이름을 포함합니다. | R | R | 높음 |
| COTS입니까? | 예 또는 아니요. 상용 애플리케이션인지 내부 개발인지 여부 | R | R | 높음 |
| COTS 제품 및 버전 | 상용 소프트웨어 제품 이름 및 버전 | R | R | 높음 |
| 설명 | 기본 애플리케이션 함수 및 컨텍스트 | R | R | 높음 |
| 중요도 | 예: 전략적 또는 수익 창출 애플리케이션 또는 중요한 함수 지원 | R | R | 높음 |
| Type | 예: 데이터베이스, 고객 관계 관리(CRM), 웹 애플리케이션, 멀티미디어, IT 공유 서비스 | R | R | 높음 |
| 환경 | 예: 프로덕션, 사전 프로덕션, 개발, 테스트, 샌드박스 | R | R | 높음 |
| 규정 준수 및 규제 | 워크로드에 적용되는 프레임워크(예: HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) 및 규제 요구 사항 | R | R | 높음 |
| 종속성 | 내부 및 외부 애플리케이션 또는 서비스에 대한 업스트림 및 다운스트림 종속성. 운영 요소와 같은 비기술적 종속성(예: 유지 관리 주기). | R | O | 높음 |
| 인프라 매핑 | 애플리케이션을 구성하는 물리적 및/또는 가상 자산에 매핑 | R | R | 높음 |
| 라이선스 | 상품 소프트웨어 라이선스 유형(예: Microsoft SQL Server Enterprise) | R | R | 중간-높음 |
| 비용 | 소프트웨어 라이선스, 소프트웨어 운영 및 유지 관리 비용 | 해당 사항 없음 | R | 중간-높음 |
| 사업부 | 예: 마케팅, 재무, 영업 | R | R | 높음 |
| 소유자 세부 정보 | 애플리케이션 소유자의 연락처 정보 | R | R | 높음 |
| DR 정보 | 재해 복구 구성 요소 | R | R | 높음 |
| 마이그레이션 전략 | 예를 들어 로 마이그레이션하기 위한 6R 중 하나 AWS | R | R | 높음 |
| 지원 티켓 | 중단, 속도 저하, 트랜잭션 제한 및 배치 기간 초과의 생산성 및 재정적 영향을 평가하는 데 도움이 되는 12\$124개월의 데이터 | O | R | 중간 |
**인프라**
| **속성 이름** | **설명** | **인벤토리 및 우선순위 지정** | **비즈니스 사례** | **권장 충실도 수준(최소)** |
| --- | --- | --- | --- | --- |
| 고유한 식별자 | 서버 ID를 예로 들 수 있습니다. 일반적으로 기존 CMDBs 또는 기타 내부 인벤토리 및 제어 시스템에서 사용할 수 있습니다. 조직에 고유 ID가 정의되지 않은 경우 고유 IDs를 생성하는 것이 좋습니다. | R | R | 높음 |
| 네트워크 이름 | 네트워크의 자산 이름(예: 호스트 이름) | R | R | 높음 |
| DNS 이름(정규화된 도메인 이름 또는 FQDN) | DNS 이름 | R | O | 높음 |
| IP 주소 및 넷마스크 | 내부 및/또는 퍼블릭 IP 주소 | R | R | 높음 |
| 애셋 유형 | 예: 물리적 또는 가상 서버, 하이퍼바이저, 컨테이너, 디바이스, 데이터베이스 인스턴스 | R | R | 높음 |
| 제품 이름 | 상용 공급업체 및 제품 이름(예: VMware ESXi, IBM Power Systems, Exadata) | R | R | 높음 |
| 운영 체제 | 예: REHL 8, Windows Server 2019, AIX 6.1 | R | R | 높음 |
| 구성 | 할당된 CPU, 코어 수, 코어당 스레드 수, 총 메모리, 스토리지, 네트워크 카드 | R | R | 높음 |
| 사용률 | CPU, 메모리, 스토리지 피크 및 평균. 데이터베이스 인스턴스 처리량. | R | R | 높음 |
| 라이선스 | 상품 라이선스 유형(예: RHEL Standard) | R | R | 높음 |
| 공유 인프라입니까? | 인증 공급자, 모니터링 시스템, 백업 서비스 및 유사한 서비스와 같은 공유 서비스를 제공하는 인프라 서비스를 나타내는 예 또는 아니요 | R | R | 높음 |
| 애플리케이션 매핑 | 이 인프라에서 실행되는 애플리케이션 또는 애플리케이션 구성 요소 | R | R | 높음 |
| 비용 | 하드웨어, 유지 관리, 운영, 스토리지(SAN, NAS, 객체), 운영 체제 라이선스, 랙 공간 공유, 데이터 센터 오버헤드 등 베어 메탈 서버의 전체 로드 비용 | 해당 사항 없음 | R | 중간-높음 |
| 예상 데이터 전송량(인/아웃) | 예를 들어, 30일 동안 하루에 걸쳐 인프라 자산당 | O | R | 중간 |
**네트워크**
| **속성 이름** | **설명** | **인벤토리 및 우선순위 지정** | **비즈니스 사례** | **권장 충실도 수준(최소)** |
| --- | --- | --- | --- | --- |
| 파이프 크기(Mb/s), 중복성(Y/N) | 현재 WAN 링크 사양(예: 1000Mb/s 중복) | R | R | 중간-높음 |
| 링크 사용률 | 최대 및 평균 사용률, 아웃바운드 데이터 전송(GB/월) | R | R | 중간-높음 |
| 지연 시간(ms) | 연결된 위치 간의 현재 지연 시간입니다. | R | O | 높음 |
| 비용 | 현재 월별 비용 | 해당 사항 없음 | R | 중간-높음 |
**마이그레이션**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html)
# 애플리케이션 포트폴리오의 기준 설정
신뢰도가 높은 마이그레이션 웨이브 플랜을 생성하려면 애플리케이션 포트폴리오 및 관련 인프라에 대한 기준을 설정해야 합니다. 포트폴리오 기준은 기술 종속성 및 마이그레이션 전략을 포함하여 마이그레이션 범위에 대한 포괄적인 보기를 제공합니다. 포트폴리오 기준은 마이그레이션 범위에 속하는 애플리케이션과 [전체 평가 데이터 요구 사항 이해 섹션에 설명된 데이터](understanding-complete-assessment-data-requirements.md) 포인트가 수집되는지에 대한 명확성을 제공합니다. 마찬가지로 연결된 모든 인프라(컴퓨팅, 스토리지 네트워크)가 이해되고 애플리케이션에 매핑됩니다.
기술 종속성은 다음 네 가지 범주로 설명할 수 있습니다.
+ **Application-to-infrastructure** 종속성은 소프트웨어와 물리적 또는 가상 하드웨어 간의 연결을 설정합니다. 예를 들어 CRM 애플리케이션과 해당 애플리케이션이 설치된 가상 머신 간에는 종속성이 있습니다.
+ **애플리케이션 구성 요소** 종속성은 서로 다른 인프라 자산에서 실행되는 구성 요소가 상호 작용하는 방식을 설명합니다. 애플리케이션 구성 요소 종속성의 예로는 가상 머신에서 실행되는 웹 프런트 엔드, 다른 가상 머신에서 실행되는 애플리케이션 계층, 데이터베이스 클러스터에서 실행되는 데이터베이스가 있습니다.
+ **Application-to-application** 종속성은 애플리케이션 또는 애플리케이션 구성 요소와 다른 애플리케이션 또는 해당 구성 요소 간의 상호 작용과 관련이 있습니다. application-to-application 종속성의 예로는 결제 처리 애플리케이션과 주식 관리 애플리케이션이 있습니다. 이러한 애플리케이션은 독립적이지만 정의된 API 작업을 사용하여 지속적으로 상호 작용합니다.
+ **인프라 서비스 자체가 애플리케이션이라는 점을 고려할 때 Application-to-infrastructure ** 서비스 종속성은 기술적으로 application-to-application 종속성입니다. 그러나 별도로 분류하는 것이 좋습니다. 주된 이유는 인프라 서비스가 일반적으로 많은 애플리케이션에서 공유되므로 종속성 추적이 길기 때문입니다. 또한 일반적으로 다른 마이그레이션 전략과 패턴을 따릅니다. 예를 들어 로드 밸런서는 여러 애플리케이션에 대한 밸런싱 풀을 포함할 수 있습니다. 중요한 것은 종속 애플리케이션과 함께 개별적으로 마이그레이션될 수 있는 풀에 대한 종속성이며, 로드 밸런서 자체가 유지되거나 retired.In 추가하여 application-to-infrastructure 서비스 종속성을 개별화하면 잘못된 종속성 그룹을 방지하는 데 도움이 됩니다. 거짓 종속성 그룹은 여러 비즈니스 애플리케이션이 함께 그룹화되는 경우입니다. 즉, 인프라 서비스에 대한 일반적인 종속성이 있는를 동시에 마이그레이션해야 합니다. 예를 들어 Active Directory와 같은 인증 서비스는 대규모 애플리케이션 그룹과 연결될 수 있습니다. 핵심은 이러한 애플리케이션에 개별적으로 접근하고 클라우드 환경에서와 같은 서비스를 활성화하여 종속성을 해결하는 AWS Directory Service for Microsoft Active Directory것입니다.
포트폴리오의 기준을 설정할 때 각 애플리케이션 구성 요소에 대한 마이그레이션 전략을 확인하는 것이 좋습니다. 마이그레이션 전략은 마이그레이션을 위한 6R 중 하나가 됩니다([6R 마이그레이션 전략 반복](iterating-6-rs-migration-strategy-selection.md) 섹션 참조). 포트폴리오 기준에서 6R 중 하나를 각 애플리케이션과 연결해야 합니다. 또한 6R 전략은 애플리케이션의 각 인프라 구성 요소와 연결되어야 합니다.
종속성 및 마이그레이션 전략을 포함하여 포트폴리오의 기준 버전을 설정하려면 자동 검색 도구를 사용합니다([검색 도구의 필요성 평가](understanding-initial-assessment-data-requirements.md#discovery-tooling) 참조). 애플리케이션 소유자 및 인프라 팀과 같은 주요 이해관계자로부터 수집한 정보로 데이터를 보완합니다. 이 단계의 데이터 [요구 사항 섹션에](understanding-complete-assessment-data-requirements.md) 설명된 속성 및 충실도 수준과 일치하는 전체 포트폴리오 인벤토리를 얻을 때까지 데이터를 계속 수집합니다. 결과 데이터 세트는 마이그레이션을 추진하는 데 중요한 역할을 합니다.
마이그레이션 범위와 사용 가능한 도구에 따라이 활동을 완료하는 데 몇 주가 걸릴 수 있습니다.
# 우선 순위 지정 기준 반복
마이그레이션 웨이브 계획을 생성하기 전에 애플리케이션 우선 순위 기준을 반복하여 파일럿 애플리케이션 선택에서 장기 웨이브 계획으로 전환하는 것이 좋습니다.
이전 단원에서는 간단한 클라우드 지원 애플리케이션의 우선 순위를 지정하는 기본 우선 순위 지정 기준을 도입했습니다([애플리케이션 우선 순위 지정](prioritization-and-migration-strategy.md#prioritizing-applications) 참조). 이는 초기 단계에서 중요하지 않은 애플리케이션부터 시작하여 마이그레이션 프로세스를 구체화하고 학습한 교훈을 통합하는 것이 권장되기 때문입니다. 그러나이 단계에서 장기 계획을 생성하려면 애플리케이션을 마이그레이션하는 순서가 비즈니스 동인에 맞게 조정되어야 합니다. 새 기준을 적용하면 웨이브 계획을 위한 주요 입력이 될 애플리케이션의 새 순위가 생성됩니다.
애플리케이션 포트폴리오에서 사용 가능한 데이터 포인트를 검토하고 비즈니스 동인을 기반으로 애플리케이션 우선 순위를 결정할 속성을 선택합니다.
먼저 비즈니스 동인을 검증합니다([비즈니스 동인 및 기술 지침 원칙](business-drivers-technical-guiding-principles.md) 참조). 그런 다음 비즈니스 동인에 따라 마이그레이션을 위해 애플리케이션의 우선순위를 지정하는 데 도움이 되는 속성을 선택합니다.
다음 표에는 혁신을 위한 비즈니스 동인에 부합하는 우선순위 지정 기준의 예가 나와 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
다음 표에는 빠른 비용 절감을 위한 비즈니스 동인에 맞는 우선순위 지정 기준의 예가 나와 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
우선 순위 기준을 테스트하고 일반적으로 출력에 동의할 때까지 반복합니다. 기준 버전을 얻으려면 최소 3회 또는 4회의 반복이 필요합니다.
# 6Rs 마이그레이션 전략 선택 반복
이 단계에서는 6R 의사 결정 트리를 반복하고 발전시키는 것이 좋습니다. [마이그레이션을 위한 R 유형 결정](prioritization-and-migration-strategy.md#migration-r-type) 섹션에는 기본 결정 트리가 도입되었습니다. 트리를 수정하고, 초기 파일럿 애플리케이션의 마이그레이션 전반에서 학습한 내용을 고려하고, 비즈니스 동인, 우선순위 기준 및 고유한 상황에 부합하는지 확인하는 것이 좋습니다. 샘플 애플리케이션으로 의사 결정 트리를 검증하고 여전히 예상 전략을 생성하는지 확인합니다. 그렇지 않으면 그에 따라 로직을 업데이트합니다. 결과 트리는 애플리케이션 포트폴리오의 기준을 설정하고 각 애플리케이션 구성 요소에 마이그레이션 전략을 할당하는 데 중요합니다.
이전 [6R 섹션에서](prioritization-and-migration-strategy.md#migration-r-type) 설명한 대로 6R은 인프라에도 적용되며 그에 따라 할당하는 것도 중요합니다. 특정 애플리케이션 구성 요소에는 마이그레이션 전략이 있지만 인프라 수준에서 각 인프라 자산은 지원하는 애플리케이션 구성 요소에 대해 설정된 전략과 다를 수 있는 지정된 마이그레이션 전략을 따릅니다.
6Rs 의사 결정 트리는 애플리케이션 구성 요소에만 적용됩니다. 인프라에 대한 마이그레이션 전략은 애플리케이션에 대해 선택한 전략에서 파생됩니다. 예를 들어 리플랫포밍될 애플리케이션 구성 요소의 경우 해당 구성 요소를 호스팅하는 현재 인프라는 사용 중지될 수 있습니다.
마이그레이션 전략이 각 애플리케이션 구성 요소 및 관련 인프라에 할당되었는지 확인합니다. 이 정보는 필요한 노력, 용량 및 기술을 추정할 때와 마이그레이션 웨이브 계획을 생성할 때 중요한 요소가 됩니다.
6R 결정에 대한 자세한 내용은 [AWS Migration Hub 전략 권장](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/) 사항을 참조하세요.
# 웨이브 계획
웨이브 계획에서 종속성 그룹은 해결할 수 없는 기술적 및 비기술적 종속성이 있는 애플리케이션 및 인프라 모음입니다. 이러한 종속성으로 인해 종속성 그룹의 애플리케이션과 인프라는 동시에 또는 특정 날짜에 마이그레이션해야 합니다. 예를 들어, 지연 시간이 짧은 요구 사항이나 트래픽이 많은 볼륨 및 복잡한 쿼리가 있는 가상 머신에서 실행되는 애플리케이션과 별도의 가상 머신에서 실행되는 데이터베이스는 클라우드에서 한 구성 요소를 운영하고 온프레미스에서 다른 구성 요소를 운영하는 대신 함께 마이그레이션될 가능성이 높습니다. 마찬가지로 지연 시간이 짧은 유사한 요구 사항이 있는 API를 통해 상호 작용하는 독립 애플리케이션도 동시에 마이그레이션됩니다.
마이그레이션 웨이브는 일반적으로 4\$18주에 걸쳐 있으며 하나 이상의 마이그레이션 이벤트를 포함할 수 있습니다. 종속성 그룹은 웨이브로 결합되므로 웨이브에 하나 이상의 종속성 그룹이 포함될 수 있습니다. 웨이브에는 마이그레이션에 필요한 다른 활동도 포함되어 있습니다. 여기에는 AWS 인프라 설정(예: 랜딩 존, 보안 및 운영), 마이그레이션 도구, 데이터 복제, 전환 계획, 테스트 및 마이그레이션 후 지원과 같은 마이그레이션 활동이 포함됩니다.
성공을 측정하고 진행 상황을 추적하려면 성과 및 비즈니스 동인에 따라 웨이브를 조정해야 합니다. 이는 파도 지속 시간 및 파도에 포함된 종속성 그룹에도 영향을 미칩니다. 웨이브 완료에는 측정 가능한 업적이 반영되어야 합니다. 파도 계획은 기술 가이드 원칙과 같은 다른 요인도 결합할 수 있습니다. 예를 들어, 웨이브는 환경(예: 개발, 테스트, 프로덕션) 또는 마이그레이션 전략(예: 리호스팅 웨이브, 리플랫포밍 웨이브)에 의해 정의될 수 있습니다.
효과적이고 신뢰도가 높은 마이그레이션 웨이브 플랜을 생성하려면 애플리케이션 포트폴리오, 관련 인프라(컴퓨팅, 스토리지, 네트워크), 종속성 매핑 및 마이그레이션 전략을 전체적으로 파악해야 합니다.
[애플리케이션 포트폴리오의 기준을 설정하는](baseline-application-portfolio.md) 단원에서는 네 가지 범주의 기술 종속성을 설명했습니다. 이러한 종속성은 마이그레이션 웨이브 생성과 종속성 그룹의 정의에 기여합니다. 종속성 그룹은 종속성의 중요도에 따라 결정됩니다. 또한 비기술적 종속성을 고려해야 합니다. 예를 들어 애플리케이션 릴리스 일정, 유지 관리 기간, 월말 분기말 처리와 같은 주요 비즈니스 날짜가 웨이브 플랜에 영향을 미칩니다.
종속성이 *소프트*인지 *하드*인지 확인합니다. 소프트 종속성은 두 개 이상의 자산 간 또는 자산과 제약 조건 간의 관계로, 구성 요소의 위치에 따라 달라지지 않습니다. 예를 들어 동일한 로컬 네트워크(또는 동일한 인프라)에서 작동하는 두 시스템은 해당 시스템 중 하나를 클라우드로 이동하여 분할할 수 있지만 다른 하나는 온프레미스에 남아 있습니다. 또 다른 예는 유지 관리 활동에 영향을 주지 않고 유지 관리 기간 동안 마이그레이션할 수 있는 시스템입니다.
하드 종속성은 위치에 따라 두 개 이상의 자산 또는 자산과 제약 조건 간의 관계입니다. 예를 들어 동일한 로컬 네트워크에서 작동하고 애플리케이션 서버와 데이터베이스 서버 간의 통신에 짧은 지연 시간에 크게 의존하는 두 시스템은 엄격한 종속성을 갖습니다. 이러한 시스템 중 하나만 클라우드로 이동하면 해결할 수 없는 기능 또는 성능 문제가 발생합니다. 마찬가지로 리소스 가용성(예: 마이그레이션을 수행하는 팀) 또는 지정된 기간에만 두 시스템을 마이그레이션할 수 있는 유지 관리 기간과 같은 운영 제약 조건과 같은 비기술적 이유로 인해 이러한 자산에 대한 엄격한 종속성이 발생할 수 있습니다.
마이그레이션 웨이브 플랜을 생성하려면 특수 검색 도구와 같은 신뢰할 수 있는 데이터 소스에서 종속성을 분석하여 종속성 그룹을 결정하고이 정보를 애플리케이션 우선 순위 기준 및 운영 상황과 결합합니다. 우선 순위 순위 순위 상단의 애플리케이션은 초기 마이그레이션 웨이브를 대상으로 해야 합니다. 리소스 가용성, 위험 허용 범위, 비즈니스 및 기술적 제약 조건, 경험 및 기술을 기반으로 파도 용량(파도에 포함될 수 있는 애플리케이션 수)을 결정합니다. 전문 서비스 또는 AWS 마이그레이션 역량 파트너와 협력하여 AWS 프로세스 전반에 걸쳐 전문가를 지원할 수 있습니다.
우선 순위 지정 기준은 애플리케이션을 클라우드로 이동하는 순서의 초기 표시입니다. 그러나 종속성 그룹은 지정된 시간에 이동할 애플리케이션의 실제 결정자입니다. 이는 우선 순위가 높은 애플리케이션이 순위 중간 또는 하단에 있는 애플리케이션에 대해 엄격한 종속성을 가질 수 있기 때문입니다.
마이그레이션 전략은 파도 구성에도 영향을 미칩니다. 예를 들어 몇 주 또는 몇 달의 분석, 설계, 테스트 및 준비가 필요할 수 있는 리팩터링 전략이 필요한 우선 순위가 높은 애플리케이션은 이후 웨이브에 배치될 가능성이 높습니다.
## 웨이브 플랜 생성
애플리케이션 웨이브를 마이그레이션하기 위한 사전 조건은 애플리케이션 포트폴리오 데이터와 웨이브에서 마이그레이션할 애플리케이션 그룹에 대한 자세한 애플리케이션 평가입니다. 세부 평가에는 웨이브의 애플리케이션 목록, 관련 인프라 세부 정보, 대상 설계 및 각 애플리케이션의 마이그레이션 전략이 포함되어야 합니다.
파도 소유권 및 거버넌스를 설정하는 것은 파도 작업, 프로그램 종속성, 변경 관리, 문제 및 위험을 관리하고 추적하는 데 중요합니다. 계획을 관리하기 위한 거버넌스 프레임워크가 마련되어 있는지 확인합니다.
웨이브 플랜을 간략하게 설명하려면 기본 웨이브 구성으로 시작합니다. 파도 내에서는 어떻게 되나요? 초기 입력이 정의되면 웨이브가 시작될 수 있습니다. 일반적으로 활동은 다음과 같습니다.
1. 전환 계획을 구체화합니다. 이 활동은 다른 내부 및 외부 팀과의 조정을 포함하여 마이그레이션 시점에 수행해야 하는 실행서와 단계를 간략하게 설명해야 합니다.
1. 롤백 계획을 구체화합니다. 문제가 발생할 경우 애플리케이션을 롤백하려면 어떻게 해야 합니까?
1. 대상 인프라를 준비합니다. 예를 들어 AWS 랜딩 존(, 보안AWS 계정, 네트워킹, 인프라 서비스, 기타 지원 인프라)을 생성하거나 확장할 수 있습니다.
1. 대상 인프라를 테스트합니다.
1. 마이그레이션 도구를 운영합니다. 예를 들어 복제 에이전트를 설치하고 데이터 전송을 시작합니다.
1. 전환 계획 및 런북 드라이 런을 수행합니다. 참여하는 모든 팀원을 그룹화하고 모든 단계를 미리 검토합니다.
1. 데이터 복제 및 인프라 배포를 모니터링합니다.
1. 에서 인프라 및 애플리케이션 운영 준비 상태를 확인합니다 AWS.
1. 보안 준비 상태를 확인합니다.
1. 해당하는 경우 규정 준수 및 규제 요구 사항(예: 마이그레이션 전 및 마이그레이션 후 워크로드 검증)을 확인합니다.
1. 애플리케이션을 로 마이그레이션 AWS 하고 가동 전 테스트를 수행합니다.
1. 운영 팀과 마이그레이션 팀이 문제를 해결할 수 있고 최적화를 적용할 수 있는 3일 등의 기간 동안 마이그레이션 후 지원을 제공합니다.
1. 마이그레이션 후 검토를 수행합니다. 학습한 내용을 문서화하고 향후 웨이브에 통합합니다.
1. 보고를 위한 지표의 운영 인계 및 획득을 확인하여 웨이브 종료를 수행합니다.
이러한 각 활동의 소요 시간은 범위의 복잡성, 파도 용량, 관련된 사람 및 고유한 상황에 따라 결정됩니다. 가능하면 파도가 작을수록 지연 또는 마이그레이션 차단기의 영향을 줄일 수 있기 때문에 더 좋습니다. 팀과 함께 파도의 기본 지속 시간을 결정합니다.
다음으로 날짜를 분석하여 빈 웨이브의 초기 상위 수준 구조(아직 애플리케이션이 할당되지 않음)를 생성합니다. 다음 질문을 고려하세요.
+ 총 마이그레이션 프로그램 길이는 얼마입니까?
+ 기한은 어떻게 됩니까?
+ 고정된 데이터 센터 종료 날짜가 있나요?
+ 콜로케이션 계약 종료일이 있나요?
+ 애플리케이션 및 인프라 새로 고침 주기란 무엇입니까?
+ 애플리케이션 유지 관리 및 릴리스 주기는 어떻게 됩니까?
+ 마이그레이션을 피해야 하는 날짜(예: 릴리스 및 유지 관리 주기, 연말, 공휴일, 월말 처리)가 있나요?
이러한 고려 사항을 고려하여 웨이브를 계획에 표시합니다. 마이그레이션 프로세스를 가속화하려면 가능하면 겹치는 웨이브를 사용하는 것이 좋습니다. 겹치는 파도의 핵심은 파도 내에서 발생하는 일을 정의하고 고려하는 것입니다. 일반적으로 배포 활동, 대상 인프라 검증 및 데이터 동기화는 웨이브의 상반기 동안 발생합니다. 하반기는 실제 마이그레이션, 테스트 및 운영 인계에 중점을 둡니다. 즉, 프로세스의 각 절반에 서로 다른 팀이 관여하며 효율성을 어느 정도 높일 수 있습니다. 예를 들어, 대상 인프라 준비에 관여한 팀이 작업을 완료하자마자 다음 웨이브의 요구 사항에 대한 작업을 시작할 수 있습니다. 일반적으로 대부분의 웨이브는 마이그레이션에 대한 공장과 유사한 접근 방식을 용이하게 하기 위해 길이와 구조가 비슷한 것이 좋습니다. 그러나 웨이브 계획 프로세스 중에 종속성 또는 운영 요구 사항을 충족하도록 지정된 웨이브의 크기를 확장할 수 있습니다.
그런 다음 식별된 종속성 그룹을 기반으로 포함할 수 있는 종속성 그룹 수를 기준으로 웨이브의 최대 크기를 결정합니다. 파도 크기는 일반적으로 위험 선호도(예: 병렬 변경을 허용할 수 있는 정도) 및 리소스 가용성(예: 사용 가능한 리소스, 기술 및 예산으로 병렬 변경을 수행할 수 있는 정도)에 따라 결정됩니다. 그러나 초기 계획 중에 리소스 요구 사항 및 가용성에 의해 제한되지 않습니다. 둘 이상의 종속성 그룹을 포함하는 파도는 향후 반복에서 더 작은 파도로 분해될 수 있습니다.
지정된 웨이브에 대한 종속성 그룹이 확인되면 웨이브 마이그레이션을 위한 리소스 요구 사항을 검토합니다. 리소스 요구 사항에 따라 파도 크기(포함된 종속성 그룹 수)를 조정하는 것이 좋습니다. 이로 인해 파도가 작거나 커질 수 있습니다. 모든 웨이브가 정의될 때까지 필요에 따라 웨이브 플랜을 반복합니다.
## 변경 관리
마이그레이션 프로그램의 수명 주기 동안 애플리케이션 및 관련 인프라 포트폴리오가 변경됩니다. 장기 실행 마이그레이션 프로그램은 정상적인 비즈니스 진화 및 변화와 공존합니다. 애플리케이션은 마이그레이션을 기다리면서 계속 진화합니다. 서버가 추가 또는 제거되고 새 인프라가 온프레미스에 배포됩니다. 웨이브 또는 종속성 그룹의 범위는 변경해야 합니다. 특히 마이그레이션 날짜에 가까워지거나, 이전에 알려지지 않은 종속성이 식별되거나, 인벤토리에 새 서버가 포함된 경우 변경이 필요합니다. 마이그레이션 자체 중에이 문제가 발생할 수 있습니다.
범위 변경은 종속성 그룹 및 웨이브에 영향을 미칩니다. 변경을 처리하고 영향을 최소화하려면 범위 제어 메커니즘을 설정하는 것이 중요합니다. 범위 변경 제어 메커니즘을 사용하려면 범위에 대한 단일 정확한 소스를 정의해야 합니다. 마이그레이션 프로그램 거버넌스에서 정의한 범위 또는 .csv 파일, 스프레드시트 또는 데이터베이스를 관리하는 도구일 수 있습니다. 조치를 취할 수 있도록 변경 사항을 식별하고, 영향을 분석하고, 관련 이해관계자에게 변경 사항을 전달해야 합니다. 그 결과 웨이브 플랜이 반복됩니다.
# 세부 비즈니스 사례
이 단계에서는 변환 프로그램을 지원하기 위해 더 높은 수준의 세부 정보를 제공하기 위해 비즈니스 사례의 범위를 검증하고 확장하는 것이 좋습니다. 빠르게 조합된 초기 방향성 비즈니스 사례는 기본 단계와 다음 수준의 세부 계획에 투자할 수 있는 충분한 확신을 제공하도록 설계되었습니다.
세부 비즈니스 사례를 개발하면 다음과 같은 방법으로이 계획 프로세스를 지원합니다.
+ 마이그레이션 및 현대화해야 할 사항, 선택할 옵션, 작업의 단계화 및 우선 순위 지정 방법을 결정하는 데 도움이 되는 재무 분석 제공
+ 세부적으로 재검토하여 원래 방향성 재무 사례를 검증, 개선 및 개발합니다.
+ 인프라 비용 절감 가능성
+ 내부 IT 생산성 및 아웃소싱된 운영 효율성
+ 프로그램 설정, 마이그레이션 및 현대화에 필요한 투자 추정치
+ 마이그레이션이 가져오는 추가 가치 동인을 추적하기 위한 프로세스 식별, 규모 추정 및 설정
세부 비즈니스 사례에서는 다음을 설정합니다.
+ 최소한 마이그레이션의 첫 단계를 구현하기 위한 권한 및 투자를 확보하기 위한 목표 기반
+ 프로그램에 대한 기준 최소 재무 성과 기대치
+ 다양한 마이그레이션 설계 및 우선순위 결정이 이루어지는 재정적 근거에 대한 명확성. 따라서 프로그램 과정에서 상황과 사람이 변경될 때 새로운 리더십이 정보에 입각한 선택을 할 수 있습니다.
+ 워크로드 마이그레이션 및 작업 시작 시 초기 사용 데이터를 사용할 수 있게 된 후 탐색할 비용 최적화의 증분 영역에 대한 인사이트
+ 복원력과 민첩성 향상으로 인해 클라우드 혁신이 비즈니스에 미치는 가치 추정
+ 복원력 및 민첩성 개선으로 인한 재무 수익률을 추정하는 데 사용되는 관련 KPIs, 지표 및 가정은 프로그램에서 주요 이점 실현을 추진하기 위한 기준을 형성합니다.
## 사례에 필요한 시나리오 결정
세부 비즈니스 사례를 구축할 때는 일반적으로 비즈니스 사례가 사용되는 다양한 목적을 지원하기 위해 여러 시나리오를 개발해야 합니다.
**최소 변경 시나리오** - 최소 재무 성과 기대치를 평가하려면 상태 할당량에 대한 최소 예상 변경을 가정하는 시나리오를 준비합니다. 최악의 시나리오인이 시나리오는 마이그레이션에 투자할 권한을 얻을 때 유용한 지원입니다. 이 시나리오는 가용성 및 복원력과 같은 다른 quality-of-service 요구 사항에 대한 최소 예상 용량 증가 수준과 최소 변경 사항을 모델링합니다. 최소 변경 사항은 현재 운영 모델에 대해 최저 비용과 최소 리소스 비효율성을 생성합니다.
**가능성이 가장 높은 시나리오** - 프로그램 전략 및 우선순위 결정을 알리려면 비즈니스가 발생할 것으로 예상되는 상황을 반영하는 시나리오를 준비합니다. 이 시나리오에는 비즈니스의 높은 수준의 서비스 품질(특히 가용성 및 복원력)에 대한 수요를 충족하기 위해 가능한 최대 사용률 증가 또는 감소와 업그레이드 비용이 포함되어야 합니다.
**기타 특정 시나리오** - 비즈니스 사례에 큰 영향을 미칠 수 있는 가정이 여전히 필요한 경우 가정이 사실인 경우와 그렇지 않은 경우 모두에 대한 시나리오를 개발합니다. 그러나 이러한 대체 시나리오의 수를 절대 최소값으로 유지하는 것이 좋습니다. 총 3\$14개 이상의 시나리오를 생성하면 진행 속도가 느려지고 비용이 많이 들고 혼란스러우며 유지 관리가 어려워집니다. 가능하면 실험을 수행하고 더 큰 가정을 제거하기 위해 노력합니다.
## 인프라 및 마이그레이션 비용 모델 검증 및 구체화
포트폴리오 분석을 완료하고 대상의 설계 및 크기를 준비한 후 각 시나리오에 대해의 현재 운영 모델(COM) 및 향후 운영 모델(FOM)에 대한 실행 비용 추정치 AWS 를 AWS 서비스구체화합니다. 일반적으로 다음에 대한 추정치를 구체화해야 합니다.
+ 하이퍼바이저 호스트 서버, 베어 메탈 서버, 스토리지, 네트워크 디바이스, 보안 어플라이언스 하드웨어 새로 고침, 설치 및 유지 관리의 **COM 인프라 비용**. 시나리오에 필요한 용량에 대한 실제 요금 및 할인 수준으로 이를 계산합니다.
+ 공간, 쿨링, 전력, 랙, 무정전 전원 공급 장치(UPS), 케이블, 물리적 보안 시스템을 포함한 **COM 데이터 센터 및 공동 배치 시설 비용은** 성장에 맞게 크기가 조정되고 용량을 충족하도록 지정되며 시나리오의 고가용성 및 재해 복구(DR) 수준을 충족합니다.
+ WAN 링크, 콘텐츠 전송 네트워크 및 가상 프라이빗 네트워크(VPNs) 비용을 포함한 **COM 네트워크 서비스 비용은** 시나리오의 연결, 대역폭, 처리량 및 지연 시간 요구 사항에 대한 계약 요금을 사용하여 계산됩니다.
+ 시나리오의 사용량 증가 또는 감소를 제공하기 위해 기존 계약에 따른 **COM 애플리케이션 및 인프라 소프트웨어 비용**입니다.
+ 정교한 서비스 아키텍처, 인스턴스 크기, 선호 요금 모델, 예상 사용량 및 사용량 변동성에 따라 필요에 따라 기술 지원 및 관리형 서비스를 포함한 **FOM AWS 유틸리티 비용**.
+ 최종 **애플리케이션 설계, 애플리케이션을 실행하는 인프라 구성, 시간 경과에 따른 성장, 라이선스 이전성 규칙을 기반으로 하는 FOM 애플리케이션 라이선스**입니다.
+ **FOM 마이그레이션 및 현대화 비용 추정치**는 시나리오의 기준 마이그레이션 웨이브 계획을 반영하도록 개선되었으며 각 워크로드, 특히 리플랫폼, 리구매 또는 리팩터링할 워크로드에 대한 비용을 제공하도록 자세히 설명되었습니다.
+ 자산 상각 및 계약 조기 종료 비용 추정치를 포함한 **FOM 폐기** 비용, 기준 마이그레이션 웨이브 계획의 폐기 시점을 반영하도록 수정, 상각을 최소화하기 위해 용도를 변경할 수 있는 자산과 전환할 수 있는 자산 확인, 물리적 자산 및 미디어의 폐기 비용.
+ **마이그레이션 병렬 실행 비용은** 각 마이그레이션 전환 시점과 각 기존 서비스 폐기 시점을 반영하도록 개선되었습니다.
## IT 생산성 및 IT 운영 개선 및 효율성 가치 모델 지원
방향성 비즈니스 사례와 마찬가지로 IT 운영 및 지원과 관련된 가치 모델을 구체화하고 개발하는 데는 두 가지 주요 접근 방식이 있습니다. 선택하는 접근 방식은 COM이 사내에서 관리되는지 아니면 계약업체 또는 아웃소싱 서비스를 통해 관리되는지에 따라 달라집니다.
*내부 팀 생산성 개선*
IT 운영 및 지원이 사내에서 관리되는 경우 비즈니스 사례의 초점은 다음과 같습니다.
+ 마이그레이션 및 범위에 포함된 운영 자동화로 인한 생산성 향상 식별 및 정량화
+ 사내 팀의 여유 시간을 다른 일반적으로 가치가 높은 활동에 쉽고 생산적으로 적용할 수 있는지 검증하여 팀에 진행 기회를 제공하고 팀에 더 큰 보상을 제공하며 조직에 더 많은 가치를 제공합니다.
팀 내 각 역할의 각 구성원이 다양한 정기 활동에 얼마나 많은 시간을 할애하는지 평가하고 다양한 활동에 대한 예상 워크로드 감소에 대한 지침을 제공합니다.
다음 표는 대량의 IT 운영을 소비하고 팀의 다양한 역할에 걸쳐 노력을 지원하는 작업에 대한 활동별 일반적인 워크로드 감소 수준에 대한 초기 지침을 제공합니다. 이 표에는 생산성 달성 방법에 대한 설명이 포함되어 있습니다.
**참고**
나열된 활동은 일반적으로 여러 역할의 팀원이 수행하므로 팀의 전체 역할 집합에서 각 작업에 대한 생산성 절감을 평가해야 합니다. 예를 들어 인프라 타워(예: 컴퓨팅, 스토리지, 네트워킹)별로 구성된 IT 운영 팀에서는 각 타워의 타워 리드에 자본 지출 계획 및 예산 책정이 일반적일 수 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html)
다음 표에는 워크로드 감소 수준별 예상 절감액이 나와 있습니다.
| **수준** | **예상** |
| --- | --- |
| 매우 높음 | 85% - 100% |
| 높음 | 60% - 90% |
| 중간 | 30% - 70% |
| 낮음 | 10% - 35% |
| 최소화 | 0% - 10% |
이러한 지표는 생산성 향상을 평가하고 이를 세부 비즈니스 사례에 포함하기 위한 출발점을 제공합니다. 실제 생산성 향상은 특정 상황에 따라 달라집니다. 범위의 중간점과 하단 모두에서 생산성 절감을 계산하여 일반적인 시나리오와 보수적인 시나리오를 추정하는 것이 유용할 수 있습니다.
프로그램이 진행됨에 따라 역할별로 각 활동에 소요된 시간에 대한 실제 데이터를 캡처하는 것이 중요합니다. 이 데이터는 운영을 추정하기 위한 개선된 기반을 구축하고 새로운 프로젝트 및 서비스 확장에 대한 비용을 지원합니다.
*아웃소싱된 IT 운영 및 비용 절감 지원*
IT 운영 및 지원이 주로 계약업체와 아웃소싱되거나 관리되는 경우 파트너 AWS 주도(AMS)를 포함한 관리형 서비스 솔루션을 제공하는 AWS 파트너에게 견적을 요청하여 향후 운영 모델(FOM)에 대한 비용 할당을 준비할 수 있습니다. [AWS Managed Services](https://aws.amazon.com/managed-services/partners/) [또한 방향성 비즈니스 사례 생성](directional-business-case.md) 섹션의 [운영 비용 최적화 구축에](directional-business-case.md#building-operational-cost-optimization) 대한 하위 섹션에 설명된 대로 AWS 계정 관리자에게 문의하여 AMS 가격을 직접 요청할 수 있습니다.
자세한 비즈니스 사례의 경우 벤치마크 수치를 수정된 AWS 서비스 자재 명세서 및 예상 서비스 소비, AMS 패키지 및 필요한 옵션, 필요한 서비스 수준에 따른 인용 부호로 바꿉니다. 비용에는 일회성 구현 구성 요소와 소비 기반 실행 속도가 포함됩니다.
나머지 IT 작업, 마이그레이션되지 않을 서비스에 대해 유지되어야 하는 지원 AWS, 계약 벌금(예: 조기 종료)이 있는 경우 일회성 비용을 포함합니다.
## 복원력 가치 모델 개발
에서 광범위한 고 AWS가용성, 재해 복구 및 내결함성 아키텍처를 구성할 수 있습니다. 소비 기반 요금은 서비스 사용 시에만 요금이 청구됨을 의미합니다. 이 두 가지 요소를 함께 사용하면 복원력을 위해 뛰어난 비용 성능을 얻을 수 있습니다.
또한 AWS 고객은 이를 사용하여 워크로드의 복원력을 개선했습니다. [IDC 2018 설문](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) 조사는 참여 고객이 연간 73% 더 적은 중단, 평균 복구 시간(MTTR) 58% 감소, 생산성 손실 94% 감소를 달성하는 예를 제공합니다. 동일한 설문 조사에 따르면 복원력 향상을 통해 얻은 재정적 이점이 IT 인프라 비용 절감 이점보다 50% 더 큰 것으로 나타났습니다.
또한 애플리케이션의 소프트웨어 개발 수명 주기를 현대화하여 추가 복원력을 확보할 수 있습니다. 테스트 자동화가 포함된 CI/CD 파이프라인이 비즈니스 민첩성 향상을 지원하기 위해 도입되는 경우 개발 주기 초기에 소프트웨어 결함이 발견되어 소프트웨어 유지 관리 비용이 크게 절감됩니다.
비즈니스 사례에이 값을 평가하고 포함하려면 먼저 애플리케이션 비즈니스 소유자와 협력하여 마이그레이션할 각 워크로드의 *총 이점 기회를* 파악합니다**. ** 여기에는 다음 항목이 포함될 수 있습니다.
+ 서비스 중단 횟수, 평균 기간 및 특성:
+ 서비스 중단의 예로는 중단, 성능 저하, 계획된 배치 및 유지 관리 기간 오버런, 주요 함수의 버그, 피크 기간 동안의 액세스 제한 등이 있습니다.
+ 전자 상거래 시스템과 같은 수익 창출 서비스 중단으로 인한 수익에 미치는 영향:
+ 중단 시간 및 트랜잭션 비율에 따라 서비스 중단을 통해 완료할 수 없는 트랜잭션 수
+ 영향을 받는 각 트랜잭션의 평균 값
+ 지원 엔지니어가 프로덕션 시스템의 결함을 해결하는 데 드는 추가 비용과 개발 프로세스 초기에 결함을 발견하는 데 드는 비용 비교
+ 내부 사용자의 생산성 및 시간 손실 비용에 미치는 영향
그런 다음 서비스 중단으로 인한 예상 시간과 더 보수적인 시간 단축을 평가하여 복원력을 높일** **수 있습니다. 예를 들어 다음 항목을 포함하는 것이 좋습니다.
+ 고가용성 아키텍처를 사용하여 중단 및 MTTR 수를 줄이고 복구 시간 목표(RTO) 및 복구 시점 목표(RPO)를 개선했습니다.
+ 자동 조정과 같은 기능을 사용하여 속도 저하 감소, 용량 제한 제거 및 배치 처리 오버런 방지
+ CI/CD 파이프라인 구현과 비용 최소화를 위해 스핀업 및 스핀다운 인프라에 대한 자동 회귀 테스트를 통해 프로덕션에서만 검색되는 애플리케이션 버그 수 감소
마이그레이션 및 현대화할 애플리케이션 포트폴리오에 대해 이를 결합하고 사례의 각 연도에 대해 예상되고 보수적인 비즈니스 가치 수치를 계산합니다. 이점은 마이그레이션 일정에 따라 증가한 다음 기여 애플리케이션의 사용량 증가 기대치에 따라 볼륨을 확장해야 합니다.
## 비즈니스 민첩성 가치 모델 개발
비즈니스 민첩성은 AWS 고객이 마이그레이션하는 주요 이유입니다 AWS. [IDC 2018 고객 설문 조사에](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) 따르면 비즈니스 민첩성 이점은 측정된 총 이점의 47%를 차지했으며 인프라 비용 절감으로 인한 이점의 5배 이상을 차지했습니다. AWS
모든 혁신에서 얻을 수 있는 모든 비즈니스 민첩성 이점을 정확하게 예측하는 것은 어렵습니다. 그러나 많은 수의 사용자를 지원하거나 비즈니스 차별화의 소스인 애플리케이션에 집중하면 이러한 이점의 중요한 부분을 모델링하여 기본 세부 비즈니스 사례에 포함할 수 있습니다.
마이그레이션이 진행됨에 따라 더 많은 이점이 정량화 가능해짐에 따라 비즈니스 민첩성 가치 모델을 점진적으로 구체화하고 확장합니다. 이렇게 하면 비즈니스 사례가 관련성을 유지하므로 프로그램을 주도하는 데 사용할 수 있는 기본 의사 결정 지원 도구로 사용할 수 있습니다.
비즈니스 민첩성 가치 모델을 구축하려면 다음 지침을 사용합니다.
+ 다음과 같이 최고의 비즈니스 성과 개선을 추진할 기회가 있는 워크로드를 선택합니다.
+ 수익 생성 워크로드
+ 효율성을 높이고 비즈니스에서 비용을 절감할 수 있는 범위가 있는 비즈니스 운영 워크로드
+ 대규모 사용자 기반을 지원하는 비즈니스 생산성 도구
+ 수익 및 효율성 생성 워크로드의 경우 다음을 수행합니다.
+ 메이저 및 마이너 애플리케이션 업그레이드가 주도할 것으로 예상되는 수익 증가 또는 운영 효율성을 현실적이고 보수적으로 평가합니다.
+ AWS 애플리케이션 개발 속도를 높이고 인프라 배포 시간을 단축할 수 있는 연간 메이저 및 마이너 릴리스 수 증가를 추정합니다. 이에 대한 일부 기준 지표는 IDC 보고서에 제공됩니다.
+ 현실적이고 보수적인 혜택 기대치를 계산합니다. 비즈니스 사례 기간 동안 매핑하여 각 워크로드가 마이그레이션된 후 일정 시간 동안 효율성을 최대로 높일 수 있습니다.
+ 비즈니스 생산성 도구의 경우 다음을 수행합니다.
+ 메이저 및 마이너 애플리케이션 업그레이드가 주도할 것으로 예상되는 시간 절감을 현실적이고 보수적으로 평가합니다.
+ 영향을 받는 사용자 기반에서 인력의 평균 시간과 노력을 추정합니다.
+ 수치를 사용하여 메이저 및 마이너 릴리스 빈도를 늘리고 비즈니스 사례 기간 동안의 이점을 계산합니다.
개발자 생산성이 향상되고 시작 시간이 단축되면 추가 리소스가 필요하지 않으므로 할인된 현금 흐름, NPV, ROI, MIRR 및 페이백 계산에 포함할 수 있도록 각 워크로드의 순 혜택 라인을 비즈니스 사례 현금 흐름 모델에 추가합니다.