1단계. 애플리케이션 평가

이 단계의 목표는 다음과 같습니다:

• 애플리케이션 환경을 철저히 이해하고 최신 데이터 플랫폼에 맞게 애플리케이션을 준비하여 비즈니스에 영향을 주지 않으면서 가치 창출 시간을 가속화하고 현대화, 최적화 및 확장할 수 있습니다.

• 애플리케이션 환경을 프로파일링하여 변화에 따른 이점, 위험 및 비용을 식별합니다.

• 전략 및 계획, 구현, 마이그레이션 및 애플리케이션 현대화, 지속적인 지원에 이르기까지 E2E 서비스 세트를 제공합니다.

• 지속적인 비즈니스 가치를 제공하기 위한 재사용 가능한 관행과 도구를 제공하는 정책, 권장 사항 및 제어를 구축합니다.

평가 단계에서 애플리케이션 소유자와 설계자는 현대화 진단 플레이북을 사용하여 현대화 목표와 우선 순위를 검증합니다.

현대화 진단 플레이북 사용합니다

현대화 진단 플레이북은 기업이 현재 상태에서 미래 상태로 전환하는 데 따르는 가치를 결정하는 프로세스를 제공합니다. 여기에는 현대화에 수반되는 기술 변화가 포함됩니다.

진단 플레이북을 사용하여 클라우드 현대화를 위한 애플리케이션 또는 애플리케이션 제품군의 우선 순위를 결정하고 현대화 중에 해결해야 할 구성 요소를 식별합니다.

진단 차원

현대화 진단 플레이북은 애플리케이션 또는 애플리케이션 그룹의 현재 및 대상 (마이그레이션 후) 상태의 다음 차원을 이해하는 데 도움이 됩니다:

• 애플리케이션 그룹화 – 현대화를 위해 애플리케이션 (예: 기술 또는 운영 모델별)을 그룹화할 이유가 있습니까?

• 시퀀싱 – 종속성에 따라 애플리케이션을 현대화해야 하는 순서가 있습니까?

• 기술 – 기술 범주 (예: 미들웨어, 데이터베이스, 메시징)는 무엇입니까?

• 종속성 – 애플리케이션이 다른 시스템이나 미들웨어에 대한 주요 종속성을 가지고 있습니까?

• 환경 – 개발, 테스트 및 프로덕션 환경이 얼마나 많이 사용됩니까?

• 스토리지 – 스토리지 요구 사항은 무엇입니까 (예: 테스트 데이터의 사본 수)?

• 운영 모델 – 애플리케이션의 모든 구성 요소가 지속적 통합 및 지속적 전달 (CI/CD) 파이프라인을 채택할 수 있습니까?

  • 그렇다면 애플리케이션 팀과 누구에게 어떤 인프라 책임을 배분해야 할까요?

  • 그렇지 않다면 운영팀에 맡겨야 할 인프라 책임은 (예: 패치 작업) 무엇입니까?

• 전송 모델:

  • 애플리케이션 또는 애플리케이션 그룹을 기반으로 플랫폼 변경, 리팩터링, 재작성, 대체 중 무엇을 해야 할까요?

  • 현대화의 어느 부분에서 클라우드 네이티브 서비스를 사용해야 할까요?

• 기술 세트 – 어떤 전문 지식이 필요한가요? 예:

  • 처음부터 컨테이너 및 서버리스 기술을 사용하여 모듈식 아키텍처로 애플리케이션을 구축하기 위한 클라우드 애플리케이션 배경.

  • DevOps 전문 지식을 통해 오픈 소스, AWS 툴 및 서비스를 사용하여 CI/CD 프로세스, 코드형 인프라, 자동화 또는 애플리케이션 관찰 가능성 분야의 솔루션을 개발합니다.

• 현대화 접근 방식 – 애플리케이션의 현재 상태, 클라우드 기술 선택, 현재의 기술 부채, CI/CD, 모니터링, 기술 및 운영 모델을 고려할 때 수행해야 할 기술적 마이그레이션 작업은 무엇입니까?

• 현대화 타이밍 – 현대화 시기에 영향을 미칠 수 있는 비즈니스 포트폴리오 타이밍 고려 사항 또는 기타 계획된 작업 고려 사항은 무엇입니까?

• 인프라의 단위 및 총 비용 – 경제성 분석에 근거하여 구내 작업량과 AWS 작업량을 유지하는 데 드는 연간 비용은 얼마입니까?

이러한 차원을 기준으로 애플리케이션을 평가하면 클라우드로 현대화를 추진하면서 비즈니스, 기술 및 경제성을 지속적으로 파악하는 데 도움이 됩니다.

빌딩 블록

애플리케이션을 현대화할 때 관찰 결과를 비즈니스 민첩성, 조직 민첩성, 엔지니어링 효율성의 세 가지 구성 요소로 분류할 수 있습니다.

• 비즈니스 민첩성 — 비즈니스 요구 사항을 요구 사항으로 전환하기 위한 비즈니스 내 효율성과 관련된 사례. 전달 조직이 비즈니스 요청에 얼마나 대응하고 있는지, 기능을 프로덕션 환경에 릴리스하는 데 있어 비즈니스가 어느 정도 통제할 수 있는지.

• 조직 민첩성 – 전달 프로세스를 정의하는 관행. 예를 들어 애자일 방법론과 DevOps 행사, 역할 할당 및 명확성, 조직 전반의 전반적인 협업, 커뮤니케이션 및 지원 등이 있습니다.

• 엔지니어링 효율성 – 품질 보증, 테스트, CI/CD, 구성 관리, 애플리케이션 설계, 소스 코드 관리와 관련된 개발 사례.

지표 식별

고객에게 중요한 것을 제공하고 있는지 알아보려면 개선을 주도하고 제공을 가속화하는 조치를 구현해야 합니다. 목표, 질문, 지표 (GQM) 는 측정값이 이러한 기준을 충족하는지 확인하기 위한 효과적인 프레임워크를 제공합니다. 이 프레임워크를 사용하여 다음 단계에 따라 목표를 달성할 수 있습니다:

1. 수행 중인 목표 또는 결과를 파악하세요.

2. 목표 달성 여부를 판단하기 위해 반드시 답해야 할 질문을 도출하세요.

3. 질문에 적절하게 답하기 위해 무엇을 측정해야 하거나 측정할 수 있는지 결정하세요. 측정에는 다음 2가지 카테고리가 있습니다:

   • 제품 메트릭은 고객에게 중요한 것을 제공하고 있는지 확인하는 데 도움이 됩니다.

   • 소프트웨어 제공 라이프사이클을 개선하는 데 도움이 되는 운영 메트릭입니다.

제품 지표

제품 지표는 비즈니스 성과에 초점을 맞추므로 새로운 작업 범위에 대한 투자수익률 (ROI) 이 결정될 때 설정해야 합니다. 제품 메트릭을 설정하는 데 유용한 기법 중 하나는 새로운 작업 범위가 구현되면 비즈니스에 어떤 변화가 생길지 묻는 것입니다. 이러한 생각을 현대화 기능이 제공되었을 때 무엇이 사실인지에 초점을 맞춘 테스트 형식으로 공식화하는 것이 도움이 됩니다.

예를 들어, 기존 시스템에서 트랜잭션을 마이그레이션하면 클라이언트를 온보딩할 수 있는 새로운 기회가 열릴 것이라고 생각한다면 어떤 점이 개선될까요? 다음 클라이언트를 온보딩하려면 얼마나 많은 용량을 확보해야 할까요? 그 결과를 검증하기 위한 테스트는 어떻게 구성될까요? 이 시나리오의 경우 제품 지표에는 다음과 같은 항목이 포함됩니다:

• 비즈니스 가치 테스트 또는 가설을 식별하세요 (예: x퍼센트의 트랜잭션 용량을 확보하면 신규 비즈니스의 y퍼센트를 확보할 수 있음).

• 기준을 정하세요 (예: x개 거래의 현재 용량이 y명의 고객을 지원할 수 있음).

• 결과 검증 (예를 들어, 용량이 x퍼센트 개선되었는데 이제 y퍼센트의 신규 비즈니스를 도입할 수 있을까요?)

운영 지표

소프트웨어 제공 라이프사이클을 개선하고 현대화를 가속화하고 있는지 판단하려면 소프트웨어 제공에 소요되는 리드 타임과 구현 시간을 알아야 합니다. 즉, 비즈니스 요구 사항을 프로덕션 환경에서 기능으로 얼마나 빨리 전환할 수 있을까요?

유용한 운영 지표는 다음과 같습니다:

• 리드 타임 – 요청에서 생산까지 작업 범위가 이동하는 데 시간이 얼마나 걸립니까?

• 주기 시간 – 처음부터 끝까지 작업 범위를 구현하는 데 시간이 얼마나 걸립니까?

• 배포 빈도 – 변경 내용을 프로덕션에 얼마나 자주 배포합니까?

• 서비스 복원 시간 – 장애 복구에 걸리는 시간 (평균 복구 시간 또는 MTTR로 측정) 은 얼마나 걸립니까?

• 변경 실패율 – 평균 장애 간격 (MTBF)은 얼마입니까?