경쟁 우선 순위 균형 조정

디지털 변환의 성공은 비즈니스 및 기술 이해 관계자가 경쟁 우선 순위의 균형을 맞추는 능력에 따라 결정됩니다.

다른 디지털 변환과 마찬가지로 클라우드 채택은 채택 수명 주기 전반에 걸쳐 경쟁 우선 순위를 노출합니다. 그리고 다른 형태의 변환과 마찬가지로, 이러한 우선 순위의 균형을 맞추는 능력은 비즈니스 가치 실현에 큰 영향을 미칩니다. 이러한 경쟁 우선 순위의 균형을 맞추려면 이해 관계자 간에 개방적이고 때로는 어려운 대화가 필요하며 때로는 개별 기여자.

이 문서에서는 각 방법론을 구현하는 동안 일반적으로 논의되는 몇 가지 경쟁 우선 순위를 간략하게 설명합니다. 클라우드 채택 전략을 개발할 때 이러한 토론을 준비하는 데 도움이 될 수 있습니다.

다음 섹션은 이전 클라우드 채택 수명 주기 다이어그램의 흐름에 맞춥니다. 그러나 클라우드 채택은 순차적인 프로세스가 아니라 반복적인 프로세스이며, 이러한 경쟁 우선 순위는 클라우드 채택 과정에서 다양한 지점에서 다시 나타날 수 있음을 인식하는 것이 중요합니다.

클라우드 채택 프레임워크 방법의 일반 테마

모놀리식 솔루션과 고급 계획은 모두 시간이 지남에 따라 부정확할 수 있는 일련의 가정을 기반으로 합니다. 클라우드를 채택하는 것은 종종 비즈니스 및 기술 팀을 위한 새로운 환경입니다. 대부분의 새로운 환경과 마찬가지로 초기 가정이 잘못된 것으로 입증될 가능성이 있습니다.

지연된 기술 결정의 입증된 민첩한 원칙을 따르는 것이 이 프레임워크 내의 대부분의 지침에 선호되는 접근 방식입니다. 이러한 접근 방식은 일관된 패턴을 따릅니다. 일반 엔드 상태를 설정하고, 초기 구현으로 신속하게 이동하고, 가정을 테스트 및 유효성을 검사하고, 잘못된 가정을 해결하기 위해 일찍 리팩터링합니다. 이러한 유형의 성장형 사고방식은 학습을 최대화하고 비즈니스 가치에 대한 위험을 최소화하지만 어느 정도의 모호성은 편하게 받아들어야 합니다.

모호성은 때로는 거짓 가정보다 더 무섭거나 더 위험할 수 있습니다. 이 프레임워크는 구현 중에 학습 및 모호성 해결의 우선 순위를 지정하지만, 많은 상황에서는 팀이 분석 기반 또는 가정 기반 접근 방식의 우선 순위를 지정해야 합니다. 다음 섹션에서는 두 번째 심층 반복이 유용할 수 있는 경우를 설명하기 위해 하나 이상의 "확장된 범위 예제"를 제공합니다.

전략 단계 중 균형 조정

전략 방법론의 핵심 목표는 이해 관계자 간의 맞춤을 개발하는 것입니다. 정의된 후 정렬된 전략적 위치는 각 방법론 전체에서 동작을 구동하여 기술 결정이 원하는 비즈니스 결과에 부합하도록 합니다. 이해 관계자 간의 연계를 촉진하면 일반적인 경쟁 우선 순위 집합인 근거 의 깊이와 비즈니스에 미치는 영향에 대한 시간이 만들어집니다.

경쟁 우선 순위:

• 근거의 깊이: 이해 관계자는 전략적 방향에 맞추기 전에 심층적인 재무 분석과 완전한 비즈니스 정당성을 원하는 경우가 많습니다. 아쉽게도 데이터 수집 및 분석을 허용하려면 해당 수준의 분석 기간이 연장되어야 할 수 있습니다.

• 비즈니스에 미치는 영향: 반대로, 이해 관계자는 정의된 기간 내에 비즈니스 결과를 제공하는 것에 대해 책임을 지는 경우가 많습니다. 시간이 많이 걸리는 분석 및 평가는 기술 작업이 시작되기도 전에 이러한 결과를 위험에 빠뜨릴 수 있습니다.

최소 범위: 올바른 잔액을 찾으려면 프로세스 초기에 관련자 토론이 필요합니다. 전략 방법론은 이 초기 작업 중에 맞춤 범위를 제한할 것을 제안합니다. 제안된 접근 방식에서 관련자는 핵심 동기, 측정 가능한 결과 및 높은 수준의 비즈니스 타당성을 중심으로 조정하는 데 중점을 줍니다. 그런 다음 이해 관계자는 필요한 학습 기회를 유도하기 위해 몇 가지 초기 프로젝트 또는 파일럿을 신속하게 커밋해야 합니다.

확장된 범위 예제: 초기 비즈니스 분석에서 비즈니스에 부정적인 영향을 미칠 위험이 높은 경우 이해 관계자는 비즈니스 근거를 파악하는 동안 속도를 늦추고 심층 분석을 더 신중하게 평가해야 할 수 있습니다.

계획 단계 중 균형 조정

전략 단계에서와 마찬가지로 계획 단계에서 초기 계획의 깊이와 지연된 기술 결정의 균형을 유지해야 합니다.

경쟁 우선 순위:

• 클라우드의 기술 구현에 대한 초기 계획의 깊이는 종종 많은 가정을 기반으로 합니다. 특히 팀에 기술 격차가 있는 경우 환경에서 검색 간격이 발생하거나 워크로드에 아키텍처 최종 상태가 명확하게 정의되어 있지 않습니다. 이러한 모든 가정은 자세한 클라우드 채택 계획에서 일반적입니다. 이러한 가정을 확인하거나 개선하기 위해서는 실험, 파일럿 및 질적 분석이 필요합니다.

• 지연된 기술 결정은 나중에 기술 결정이 내려질수록 더 정확하다는 가정을 기반으로 합니다. 민첩한 제품 계획의 원칙에 따라 기술 결정을 지연하여 충분한 정보를 바탕으로 적시에 결정을 내릴 수 있습니다. 그러나 이 방법은 초기 계획에서 더 모호합니다.

최소 범위: 관리 가능한 계획 내에서 프롬프트 작업을 추진하기 위한 민첩한 제품 개발 방법을 제안합니다. 계획 방법론은 이 균형을 달성하기 위해 다음 단계를 권장합니다.

1. 자동화된 검색 도구를 사용하여 전체 디지털 자산을 인벤토리에 추가하지만 증분 합리화를 사용하여 다음 1~3개월의 작업을 계획합니다.
2. 신속하게 이동할 수 있도록 조직을 적절히 맞춥니다.
3. 할당된 팀에 대한 기술 준비 계획을 만듭니다. 전략 및 계획 템플릿을 사용하여 초기 백로그를 신속하게 배포합니다.

확장된 범위 예제: 클라우드 채택 계획의 제공은 시간에 민감하거나 영향력이 큰 비즈니스 이벤트에 대한 응답일 수 있습니다. 성공하려면 고정된 기간 동안 많은 수의 자산을 이동해야 하는 경우 이전 단계에는 더 심층적인 계획 노력이 따르는 경우가 많습니다. 이러한 시나리오에서 성공의 열쇠는 충분한 계획을 세우고 나중에 전체 참여를 계획하는 것입니다. 이 방법은 계획이 비즈니스 결과를 차단할 가능성을 줄입니다.

준비 단계 중 균형 조정

팀이 클라우드 채택에 대한 첫 번째 단계를 준비할 때 채택 시간과 장기 운영 간에 우선 순위가 경쟁되는 경우가 많습니다. 팀은 당면한 작업에 적합하고 잘 관리되는 것 사이의 균형에 어려움을 겪을 수 있습니다. 이러한 노력은 플랫폼을 개발하는 데 물리적 자산 및 획득 주기가 필요한 기존 IT 환경에서 필요합니다. 그러나 전체 IT 플랫폼이 코드에 정의되면 리팩터링과 같은 기존 개발 전술은 처음부터 잘 관리될 필요성을 줄입니다.

경쟁 우선 순위:

• 장기 운영: 조직은 현재 운영 관리, 거버넌스 및 보안 시스템과 기능 패리티를 충족하는 클라우드 환경을 갖기 위해 차단되는 경우가 많습니다. 한 연구에서는 조직의 90% 이상이 이러한 사고 방식을 극복하기 위해 지원이 필요했습니다. 이 차단기는 몇 달의 지연을 야기하여 비즈니스 영향을 늦추거나 방지할 수 있습니다.

• 채택 시간: Azure Policy와 같은 클라우드 기반 도구, IaC(Infrastructure as Code) 및 관리 그룹과 같은 CI/CD(지속적인 통합 및 지속적인 업데이트) 접근 방식 및 관리 그룹은 IT 플랫폼에서 리팩터링 프로세스를 간소화할 수 있습니다. 또한 미리 정의된 랜딩 존은 이미 많은 기능 패리티 요구 사항을 충족하는 환경에 대한 배포를 가속화하기 위한 권장 사항을 제공합니다. 이러한 도구는 장기 운영에 미치는 영향을 최소화하면서 출시 시간을 가속화할 수 있는 기회를 제공합니다.

최소 범위: 준비 방법론은 신속한 채택에서 장기 운영에 이르는 직접적인 경로를 간략하게 설명합니다. 이 방법은 환경을 리팩터링하는 데 사용할 수 있는 도구에 대한 기본 소개부터 시작합니다. 이 도구는 요구 사항을 고려하여 IaC 모델과 함께 제공되는 미리 정의된 랜딩 존을 선택할 수 있도록 안내합니다. 그런 다음 클라우드 채택 과정에서 코드를 리팩터링하여 운영, 보안 및 관리를 개선할 수 있습니다.

확장된 범위 예제: 채택 계획이 클라우드에서 1,000개 이상의 자산(애플리케이션, 인프라 또는 데이터 자산)을 호스트하기 위해 중간 목표(24개월 이내)를 요구하는 팀의 경우 랜딩 존에 대한 보다 강력한 보기를 권장합니다. 이러한 상황에서는 초기 랜딩 존 대화 중에 거버넌스 및 관리 방법론을 고려해야 합니다. 그러나 이러한 심층 고려 사항은 종종 클라우드 채택 계획에 몇 주 또는 몇 달을 더 추가합니다. 비즈니스 결과에 미치는 영향을 최소화하기 위해 채택 팀은 클라우드에서 실제 워크로드를 파일럿하는 동시에 보다 성숙한 랜딩 존 및 중앙 아키텍처 솔루션을 만들어야 합니다.

마이그레이션 단계 중 균형 조정

마이그레이션 중에 채택 팀은 일반적으로 워크로드가 현재 구성에서 클라우드에 다시 호스팅된다고 가정합니다. 이 가정은 클라우드 기능을 더 잘 활용하기 위해 모든 워크로드를 다시 아키텍처화하기 위한 미래 예측 계획과 경쟁합니다. 두 보기는 상호 배타적이지 않으며 공통 프로세스를 사용하여 관리할 때 무료로 사용할 수 있습니다.

경쟁 우선 순위:

• 다시 호스팅: 조직은 현재 구성에서 클라우드에 모든 자산을 복제본(replica) 하는 리프트 앤 시프트 방식과 마이그레이션을 동일시하는 경우가 많습니다. 이 접근 방식은 IT 포트폴리오 내에서 거의 표류하지 않습니다. 또한 기존 데이터 센터에서 자산을 사용 중지하는 가장 빠른 방법입니다.

• 다시 보관: 각 워크로드의 아키텍처를 현대화하면 비용, 성능 및 운영 전반에 걸쳐 클라우드 채택의 가치를 극대화할 수 있습니다. 그러나 이 방법은 속도가 느리며 종종 각 애플리케이션의 소스 코드에 액세스해야 합니다.

최소 범위: 초기 단계 계획 중에는 이 선택이 초기 비즈니스 가정을 기반으로 하며 기술적인 결정이 아니라는 점을 명확히 이해하고 계획에 다시 호스팅 옵션을 사용합니다. 마이그레이션 방법론에서 클라우드 채택 팀은 마이그레이션된 각 워크로드에 대해 이 가정에 이의를 제기합니다. 이 방법론은 각 워크로드 또는 워크로드 그룹에 대한 평가/마이그레이션/승격 접근 방식을 따라 마이그레이션 팩터리를 만듭니다. 평가 단계에서 채택 팀은 각 워크로드의 기술적 적합성과 아키텍처를 평가합니다. 아키텍처의 많은 구성 요소가 리팩터링 및 현대화를 위해 선택되는 경향이 있기 때문에 이러한 평가 작업에서는 순수한 리프트 앤 시프트 접근 방식이 발생하는 경우는 거의 없습니다.

확장된 범위 예제: 기본프레임 또는 다중 계층 마이크로 서비스 애플리케이션과 같은 중요 업무용 또는 민감도가 높은 워크로드의 경우 평가 단계에서 워크로드에 대한 보다 철저한 평가가 필요할 수 있습니다. 이러한 재설치 상황에서는 Azure Well-Architected Review 및 Azure Well-Architected Framework 를 사용하여 평가 중에 워크로드 요구 사항을 구체화해야 합니다.

혁신 단계 동안 균형 조정

진정한 고객 대면 혁신은 계획된 기능 집합을 제공해야 하는 필요성과 고객 공감 개발 프로세스 구현 간에 충돌하는 우선 순위를 자주 만듭니다.

경쟁 우선 순위:

• 기능 중심: 혁신에 대한 초기 계획은 고객의 요구를 충족하는 일련의 기능을 제공하기 위해 기존 디지털 자산 및 클라우드 기능을 기준으로 수립됩니다. 계획에서 기술 구현을 추진할 수 있도록 쉽게 허용하여 기능 중심 개발 노력으로 이어집니다. 이러한 접근 방식은 종종 일시적인 이해 관계자 만족도로 이어지지만 고객 행동에 영향을 주는 혁신을 주도할 가능성을 줄입니다.

• 고객 공감: 초기 계획은 개발의 비즈니스 측면에서 중요한 부분이며 정기적인 보고에 포함되어야 합니다. 그러나 고객 공감을 목표로 학습, 측정 및 구축하는 것은 혁신 노력의 성공을 보다 정확하게 측정하는 것입니다. 기능보다 고객에 초점을 맞추면 단기 및 장기 고객 만족도 및 비즈니스 영향이 발생할 가능성이 높습니다.

최소 범위: 혁신 방법론은 비즈니스 가치 합의를 통해 전략과 계획을 통합하는 방법을 보여 줍니다. 그런 다음, 이 가이드에서는 구현을 위한 혁신 및 모범 사례의 각 분야를 가속화할 수 있는 클라우드 네이티브 도구를 소개합니다. 마지막으로 프로세스 개선 섹션에서는 클라우드 채택 과정에서 계획 및 전략을 존중하면서 고객 공감을 구축하는 방법을 보여 줍니다. 이 방법은 가능한 한 적은 기술을 사용하여 혁신을 제공하는 데 중점을 둡니다.

확장된 범위 예제: 혁신은 경우에 따라 중요 업무용 또는 민감도가 높은 워크로드에 따라 달라집니다. 고객이 내부 사용자인 경우 개발 노력은 가장 빠른 반복 중에 중요 업무용 및 높은 민감도일 수 있습니다. 이러한 시나리오에서 채택 팀은 Azure Well-Architected Review 및 Azure Well-Architected Framework 를 사용하여 프로세스 초기에 고급 아키텍처 디자인을 평가해야 합니다.

거버넌스 단계 중 균형 조정

클라우드 거버넌스의 관행은 속도와 민첩성, 잘 관리되는 환경이라는 두 가지 경쟁 우선 순위 간의 균형입니다. 클라우드 거버넌스 팀은 균일한 제어를 통해 비즈니스에 대한 위험을 평가하고 최소화하며, 변화를 최소화하는 데 중점을 둡니다. 채택 팀은 새로운 위험이 요구되고 본질적으로 변화를 야기하는 비즈니스 결과를 주도하는 데 중점을 둡니다.

경쟁 우선 순위:

• 잘 관리: 위험을 최소화하도록 설계된 모든 제어는 변경의 특정 측면을 차단하거나 디자인 옵션을 제한합니다. 제어는 잘 관리되는 환경에 필수적입니다. 그러나 컨트롤이 격리되어 설계되고 배포될 때 방지하려는 위험만큼 손상될 수 있습니다.
• 속도 및 민첩성: 속도와 민첩성은 디지털 경제에서 기본적인 비즈니스 요구 사항입니다. 두 가지 모두 혁신이나 채택에 대한 방해 요인을 최소화하면서 변화를 주도할 수 있는 능력이 필요합니다. 그러나 거버넌스 없이 변경이 주도되면 예기치 않은 방식으로 비즈니스에 해를 끼칠 수 있는 새로운 위험이 발생합니다.

최소 범위: 거버넌스 방법론은 거버넌스와 채택 모두 격리된 상태로 발생해서는 안 된다는 것을 의미합니다. 이 방법론은 거버넌스 분야에 대한 이해와 비즈니스 위험, 정책 및 프로세스에 대한 대화에서 시작됩니다. 거버넌스 팀은 클라우드 채택 전반에 걸쳐 적극적인 참여자로서 클라우드 채택 계획 내에서 실질적인 위험을 해결하기 위해 최소 안전 장치 집합을 구현할 수 있습니다. 시간이 지남에 따라 거버넌스 팀은 새로운 위험을 충족하기 위해 이러한 안전 장치를 리팩터링하고 확장할 수 있습니다. 이 방법은 학습 및 혁신을 극대화하면서 위험을 최소화합니다.

확장된 범위 예제: 특히 채택 초기에 비즈니스 위험이 높은 경우 클라우드 거버넌스 팀은 거버넌스 구현의 확장을 가속화해야 할 수 있습니다. 동일한 지침과 연습을 사용하여 더 높은 수준의 거버넌스를 추가할 수 있지만 더 빨리 진행해야 할 수도 있습니다. 일부 시나리오에서는 첫 번째 랜딩 존을 개발하는 동안 고급 거버넌스 상태가 필요할 수도 있습니다.

관리 단계 중 균형 조정

운영 관리를 위한 IT 비즈니스 모델은 지난 10년 동안 지속적으로 발전해 왔다. 하드웨어 기본 테넌스가 IT의 핵심 가치 제안에서 더 멀어짐에 따라 운영 관리에 대한 견해가 바뀌었습니다. IT가 비즈니스 가치를 제공하는 데 초점을 맞추면서 운영 관리 팀은 노옵스와 저작물과 광범위한 투자의 균형을 유지해야 하는 필요성으로 인해 갈등을 빚고 있습니다.

경쟁 우선 순위:

• 광범위한 투자: 가동 중단 방지, 신속한 복구 및 환경 전반에 걸친 모니터링에 동등하게 투자하는 것은 기존의 운영 관리 접근 방식입니다. 이 방법은 비용이 많이 들 수 있으며 클라우드 공급업체에서 제공하는 지원 제품을 복제하는 경우도 있습니다.

• No-ops 및 low-ops: 클라우드 네이티브 운영 도구를 사용하여 이전에 직원이 제공한 반복적이고 되풀이되는 작업을 최소화합니다. 이러한 운영 종속성을 줄이면 직원들은 다른 방법으로 가치를 추진할 수 있습니다. 그러나 격리에서 이 방법은 하위 작업 지원으로 이어질 수 있습니다.

최소 범위: 관리 방법론은 클라우드 네이티브 작동 중단 기준을 설정하는 것을 제안합니다. no-ops 기준이 모든 비즈니스 요구를 충족하지는 않음을 인정하고, 비즈니스와 협력하여 약정을 정의하고 투자를 더 잘 조정합니다. 모든 워크로드에 대한 일반적인 요구 사항을 충족하도록 기준을 확장합니다. 그런 다음, 플랫폼 팀 또는 특정 워크로드 팀이 잘 관리되는 환경 내에서 잘 관리되는 솔루션을 유지 관리할 수 있도록 합니다.

확장된 범위 예제: 대부분의 환경에서 워크로드의 적은 비율의 비즈니스 가치는 IT 운영에 대한 심층 투자를 정당화합니다. 이러한 워크로드의 경우 IT 팀은 Azure Well-Architected Review 및 Azure Well-Architected Framework를 사용하여 더 심층적인 작업을 안내하려고 할 수 있습니다.

조직 단계 중 균형 조정

이 문서에 설명된 경쟁 우선 순위는 속도 및 민첩성에 대한 비즈니스 요구를 충족하는 IT의 드라이브를 반영합니다. 비즈니스 결과에 대한 더 나은 지원을 제공하기 위해 조직도 또는 가상 팀 구조에 대한 변경 내용에 동일한 변화가 나타납니다. IT 리더가 팀 구조를 반영함에 따라 일반적으로 중앙 집중식 제어와 위임된 제어라는 두 가지 경쟁 우선 순위가 해결됩니다.

경쟁 우선 순위:

• 중앙 집중식 제어: 이 운영 모델은 엄격한 정책을 적용하는 데 필요한 모든 컨트롤의 중앙 집중화에 중점을 둡니다. 이 모델에서 IT는 혁신, 속도 및 민첩성에 방해가 됩니다. 그러나 IT는 더 높은 수준의 안정성, 규정 준수 및 보안을 보장할 수 있습니다.

• 위임된 제어: 이 분산 운영 모델에서는 각 DevOps 팀 또는 비즈니스 애플리케이션 팀이 비즈니스 목표를 달성하는 데 필요한 솔루션에 따라 고유한 컨트롤 집합을 제공할 것으로 가정합니다. 이 모델에서 IT 팀은 위험을 방지하지만 가능한 경우 적용된 기술 제약 조건의 수를 최소화하는 데 도움이 되는 지침을 제공합니다.

최소 범위: 대부분의 조직은 시간이 지남에 따라 자연스러운 진화를 거닐고 있습니다. 구성 방법론은 가장 일반적인 일련의 진화에 대해 간략히 설명합니다. 팀에서 위임된 제어 접근 방식을 제공하기 위해 CCoE(클라우드 센터) 구조로 전환하는 것이 좋습니다.

확장된 범위 예제: 많은 상황에서 중앙 집중식 제어가 필요합니다. 타사 규정 준수 요구 사항 및 임시 보안 노출은 중앙 집중식 제어를 위한 트리거의 두 가지 예입니다. 이러한 상황에서는 일반적으로 제한 정책과 고정된 제어를 설정해야 합니다. 그러나 혁신과 채택을 계속하려면 중앙 IT 팀이 각 워크로드의 중요도 및 민감도에 따라 이러한 제어를 제공하는 것이 좋습니다. 제어 수준이 낮지만 범위 또는 위험 프로필이 축소된 환경을 제공하면 제어가 필요한 경우에도 유연성을 사용할 수 있습니다.

다음 단계

마이그레이션, 혁신 및 실험의 균형을 조정하여 클라우드 마이그레이션 작업의 가치를 극대화하는 방법을 알아봅니다.

포트폴리오 균형 조정