기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

작업 4: 애플리케이션 심층 분석 프로세스 정의

이제 애플리케이션 우선 순위 지정을 위한 규칙 및 프로세스 설정을 완료했으므로 각 애플리케이션의 우선 순위를 구체화하는 데 도움이 되는 애플리케이션 심층 분석을 수행합니다. 가장 높은 우선 순위부터 가장 낮은 우선 순위까지 한 번에 하나의 애플리케이션에 대해 애플리케이션 심층 분석을 수행합니다. 포트폴리오 팀이 여러 개인 프로젝트의 경우 각 팀은 동시에 다른 애플리케이션에 대해 애플리케이션 심층 분석을 수행할 수 있습니다.

심층 분석 중에는 애플리케이션 마이그레이션의 복잡성에 영향을 미치는 종속성과 같은 예상치 못한 문제가 발생할 수 있습니다. 이 경우 이전 단계에서 정의한 복잡성 점수 기준을 수정하고 그에 따라 점수 시트를 업데이트하여 향후 애플리케이션에 대해 보다 정확한 복잡성 점수를 얻어야 합니다. 그런 다음 새로운 복잡성 점수를 사용하여 애플리케이션 우선 순위를 업데이트할 수 있습니다.

이 작업은 다음 단계로 구성됩니다.

1단계: 애플리케이션 워크숍 프로세스 정의

워크숍 프로세스는 애플리케이션 심층 분석을 위한 가장 효율적인 접근 방식 중 하나입니다. 이 프로세스를 사용하면 이해관계자, 애플리케이션 소유자 및 포트폴리오 팀과 협력하여 애플리케이션을 평가하고 분석할 수 있습니다. 목표는 아키텍처, 비즈니스 목적, 종속성 및 환경을 포함하여 애플리케이션의 현재 상태를 명확하게 이해하는 것입니다. 그런 다음 애플리케이션의 크기와 복잡성에 대한이 세부 정보를 사용하여 애플리케이션의 대상 상태를 설계합니다.

각 워크숍은 일반적으로 1~8시간 동안 지속되지만 복잡성이 높은 애플리케이션에는 추가 시간이 필요할 수 있습니다. 또한 리소스 가용성, 기본 설정, 애플리케이션의 크기 및 복잡성에 따라 워크숍을 여러 회의로 나눌 수 있습니다.

예상 결과 식별

애플리케이션 워크숍을 수행하기 전에 의제를 설정하고 워크숍의 예상 결과 또는 워크숍에서 수집해야 하는 정보를 정의해야 합니다. 이렇게 하면 워크숍 참가자가 워크숍을 준비하고, 회의를 대상으로 유지하며, 워크숍이 끝날 때까지 애플리케이션의 우선 순위 지정, 계획 수립 및 마이그레이션에 필요한 모든 정보를 확보할 수 있습니다.

표준 예상 결과 세트를 정의하고 애플리케이션 우선 순위 런북에 문서화하는 것이 좋습니다. 워크숍을 준비할 때 표준 예상 결과를 사용하고 특정 애플리케이션에 대해 새 결과를 추가합니다.

다음과 같이 애플리케이션 워크숍에 대한 표준 예상 결과 세트를 정의합니다.

다음은 애플리케이션 워크숍에서 예상되는 결과의 예입니다.

애플리케이션 워크숍 규칙 정의

애플리케이션 워크숍을 수행하기 전에 워크숍을 관리하는 규칙을 정의해야 합니다. 일반적인 규칙에는 워크숍 길이, 워크숍에 필요할 수 있는 도구, 고려해야 할 일정 고려 사항 또는 기한이 포함됩니다. 이렇게 하면 회의를 대상으로 유지하고 워크숍에서 내린 결정이 마이그레이션 일정에 부합하도록 할 수 있습니다.

애플리케이션 우선 순위 실행서에 애플리케이션 워크숍 규칙을 문서화하는 것이 좋습니다.

다음과 같이 애플리케이션 워크숍 규칙을 정의합니다.

다음은 애플리케이션 워크숍 규칙의 예입니다.

애플리케이션 워크숍 프로세스 정의

애플리케이션 워크숍을 수행하기 위한 표준 프로세스를 정의하는 것이 중요합니다. 이렇게 하면 일관된 경험을 보장하고 워크숍 참가자에 대한 기대치를 설정하여 워크숍의 효율성을 개선할 수 있습니다.

애플리케이션 워크숍 프로세스에는 세 단계가 있습니다.

애플리케이션 우선순위 지정을 위한 런북 템플릿에는 애플리케이션 워크숍을 준비, 수행 및 마무리하기 위한 표준 step-by-step 프로세스가 포함되어 있습니다. 다음과 같이 애플리케이션 워크숍 프로세스를 정의합니다.

단계 종료 기준

2단계: 애플리케이션 매핑 프로세스 정의

애플리케이션 매핑은에서 식별하고 검증한 마이그레이션 패턴에 각 애플리케이션을 할당하는 프로세스입니다4단계: 마이그레이션 패턴 검증. 이 단계에서는 애플리케이션을 평가하는 데 사용할 규칙을 정의합니다. 그런 다음 각 애플리케이션을 평가하는 데 사용할 프로세스를 정의합니다. 각 애플리케이션을 마이그레이션 패턴의 사용 사례에 매핑하면 마이그레이션 도구, 마이그레이션을 완료하는 데 필요한 기술, 마이그레이션 패턴의 복잡성을 식별하는 데 도움이 됩니다.

애플리케이션을 항상 단일 패턴으로 마이그레이션하는 것은 아닙니다. 동일한 애플리케이션에 여러 패턴이 필요할 수 있는 경우에 대한 자세한 내용은이 섹션 애플리케이션 매핑 프로세스 정의뒷부분의 섹션을 참조하세요.

애플리케이션 매핑 규칙

애플리케이션 매핑 규칙은 애플리케이션을 평가하고 적절한 마이그레이션 패턴을 식별하는 데 도움이 됩니다. 각 규칙은 애플리케이션을 평가하고 패턴의 기준을 일치시키는 데 사용해야 하는 모든 정보로 구성됩니다.

포트폴리오 플레이북 템플릿에서 애플리케이션 우선 순위 지정을 위한 런북 템플릿에는 애플리케이션 매핑 규칙을 문서화하기 위한 섹션이 포함되어 있습니다. 다음과 같이 프로세스를 정의합니다.

다음 표에는 애플리케이션 매핑 규칙의 예가 나와 있습니다.

애플리케이션 매핑 프로세스 정의

애플리케이션을 마이그레이션 패턴에 매핑할 때는 검색 팀에 애플리케이션에 대한 검색 데이터를 요청하는 것이 좋습니다. 이 데이터에는 일반적으로 권장 마이그레이션 패턴(R 패턴 또는 R 점수라고도 함), 사용률 정보, 애플리케이션 종속성 및 평가에 사용할 수 있는 기타 정보와 같은 정보가 포함됩니다. 이 애플리케이션을 자세히 살펴보면서 이전에 식별된 마이그레이션 패턴을 변경하기로 결정할 수 있습니다.

데이터가 있으면 애플리케이션을에서 식별한 비즈니스 및 기술 기준과 비교할 수 있습니다2단계: 비즈니스 및 기술 동인 식별. 애플리케이션 우선 순위 실행서에 드라이버를 기록했습니다. 기준을 기준으로 애플리케이션을 평가하면 애플리케이션에 대해 여러 마이그레이션 패턴을 선택하거나 비용, 일정 또는 기타 제한 사항에 따라 패턴을 제거할 수 있습니다.

다음은 단일 애플리케이션에서 여러 마이그레이션 패턴을 사용해야 하는 비즈니스 드라이버의 예입니다. 온프레미스 SQL Server 데이터베이스를 Amazon DynamoDB로 마이그레이션하려고 하지만 데이터 센터 계약이 만료되기 때문에 기업은 제안된 일정보다 빨리 마이그레이션하여 다시 플랫폼화하려고 합니다. 이 비즈니스 동인을 해결하려면 애플리케이션의 마이그레이션 계획을 2패턴 접근 방식으로 수정합니다. 먼저 애플리케이션을 클라우드로 리호스팅하여 데이터 센터에서 제거합니다. 나중에 애플리케이션이 클라우드에 있으면 제안된 일정에 따라 애플리케이션을 리플랫포밍할 수 있습니다.

또한 애플리케이션이 여러 계층으로 구성된 애플리케이션인 n-티어 애플리케이션인지도 고려해야 합니다. 애플리케이션 계층은 애플리케이션의 가로 계층을 호스팅하는 물리적 서버 그룹입니다. N 티어 애플리케이션은 각 티어마다 다른 전략이 필요할 수 있으며 애플리케이션 티어를 다른 웨이브로 마이그레이션하도록 선택할 수 있기 때문에 더 복잡합니다. 예를 들어 프레젠테이션, 비즈니스 서비스 및 데이터베이스 계층으로 구성된 애플리케이션이 있는 경우 각 계층에 대해 다른 패턴을 매핑할 수 있습니다.

그런 다음 애플리케이션 우선 순위 런북에 정의한 애플리케이션 매핑 규칙을 기준으로 애플리케이션을 평가합니다. 자세한 내용은 이 섹션 앞부분에 있는 애플리케이션 매핑 규칙 내용을 참조하세요.

애플리케이션을 하나 이상의 패턴에 매핑한 후 애플리케이션 소유자와 함께이 결정을 검토하고 확인합니다. 애플리케이션 소유자는 선택한 패턴을 확인해야 하며 마이그레이션을 계획하고 수행하는 데 도움이 되어야 합니다. 현재 애플리케이션 소유자는 경험을 기반으로 인사이트를 제공하거나 마이그레이션과 관련하여 예상되는 문제를 공유할 수도 있습니다.

애플리케이션을 하나 이상의 마이그레이션 패턴에 매핑하고 애플리케이션 소유자와 패턴을 확인한 경우 애플리케이션 우선 순위 실행서의 애플리케이션 매핑 테이블에 애플리케이션, 패턴 ID, 패턴 이름 및 관련 드라이버를 기록합니다.

포트폴리오 플레이북 템플릿에서 애플리케이션 우선순위 지정을 위한 런북 템플릿에는 애플리케이션 매핑을 위한 표준 step-by-step 프로세스가 포함되어 있습니다. 다음과 같이 프로세스를 정의합니다.

다음 표는 샘플 애플리케이션 매핑 테이블입니다. 애플리케이션 우선 순위 지정을 위해 제공된 런북 템플릿에는 애플리케이션 매핑 프로세스의 결과를 기록할 수 있는 빈 테이블이 포함되어 있습니다.

단계 종료 기준

3단계: (선택 사항) 애플리케이션 대상 상태 정의

이 단계에서는 애플리케이션의 대상 상태 또는 향후 상태를 문서화하는 데 사용하는 속성과 프로세스를 정의합니다. 대상 상태는 마이그레이션 후 애플리케이션이 대상 클라우드 환경에서 작동하는 방식입니다. 대상 환경은 대상 플랫폼 또는 서비스 및 비즈니스 요구 사항에 따라 달라집니다. 대상 환경은 AWS 클라우드 또는 AWS Managed Services (AMS)일 수 있습니다.

대상 상태를 정의하면 프로젝트 관리자, 마이그레이션 컨설턴트, 아키텍트, 애플리케이션 소유자 및 이해관계자가 효과적으로 협업할 수 있습니다. 팀은이 프로세스를 사용하여 문제를 미리 식별하고 해결하며 대상 상태 환경을 보다 효율적으로 구현할 수 있습니다.

일부 애플리케이션의 경우이 단계는 선택 사항입니다. 마이그레이션하는 애플리케이션이 독립 실행형이거나 복잡성이 낮은 경우이 단계를 건너뛸 수 있습니다. 리호스팅과 같이 애플리케이션을 수정하지 않는 마이그레이션 전략에는이 단계가 필요하지 않을 수 있습니다. 그러나 리플랫포밍 및 리아키텍트와 같은 보다 복잡한 마이그레이션 전략의 경우 마이그레이션을 시작하기 전에 대상 상태를 정의해야 합니다.

워크숍은 애플리케이션의 현재 상태를 심층적으로 이해하므로 워크숍을 완료한 후 대상 상태를 초안으로 작성하는 것이 좋습니다. 또한 애플리케이션을 마이그레이션 패턴에 매핑하면 추가 인사이트를 얻을 수 있으며 대상 상태를 정의해야 하는지 여부를 식별하는 데 도움이 됩니다. 예를 들어 Application Migration Service 또는 Cloud Migration Factory를 사용하여 애플리케이션을 Amazon EC2에 리호스팅 패턴에 매핑하는 경우 전략이 리호스팅되었음을 확인했으므로이 애플리케이션의 대상 상태를 정의할 필요가 없을 수 있습니다.

대상 상태 속성

대상 상태를 정의하고 애플리케이션에 대한 결정을 내릴 때 다음 대상 상태 속성을 고려하는 것이 좋습니다.

대상 상태 프로세스 정의

애플리케이션 대상 상태를 정의하려면 포트폴리오 플레이북 템플릿에서 사용할 수 있는 제공된 템플릿인 애플리케이션 대상 상태 워크시트(Excel 형식)를 사용하는 것이 좋습니다. 템플릿에는 사용하거나 수정할 수 있는 표준 속성이 포함되어 있습니다. 다음과 같이 애플리케이션 대상 상태를 문서화하는 프로세스를 정의합니다.

애플리케이션 대상 상태의 샘플

다음 표는 애플리케이션 대상 상태 워크시트를 사용하여 애플리케이션의 대상 상태를 문서화하는 방법의 예를 보여줍니다.

단계 종료 기준

4단계: 애플리케이션 심층 분석 프로세스 완료

이제 포트폴리오 워크스트림이이 작업에서 설정한 워크숍, 규칙 및 프로세스를 사용하여 애플리케이션에 대한 심층 분석을 수행하는 방법을 정의합니다. 이는 포트폴리오 워크스트림이 마이그레이션의 구현 단계에서 참조하는 프로세스입니다.

애플리케이션 우선 순위 실행서에서 다음과 같이이 프로세스를 사용자 지정합니다.