로드맵 구현
로드맵을 설정한 후에는 로드맵을 구현해야 합니다. 여기에서 바로 고객이 다음 과제에 직면합니다. 고객이 사고하는 데 시간을 보냈고 이제 실천해야 하기 때문입니다. 전략을 구현에 연결하려면 다음 단계를 수행하는 것이 좋습니다.
어디서 어떻게 시작할지 결정
쉽게 들릴 수 있지만 달성해야 할 일이 많기 때문에 종종 시작점을 찾기 어렵고 논란의 여지가 있는 질문일 때도 있습니다. 클라우드로 이전하는 조직은 집중해야 할 부분이 많으며, 상황에 맞지 않으면 이니셔티브가 부담스러워질 수 있습니다. 수년 동안 고객 추세가 발전했지만 일관된 출발점은 혁신적인 리더십입니다. 지침과 전략을 하향식으로 추진하고 미션 선언문, 원칙 및 PR-FAQ를 생성하면 중간 관리자와 개인이 자율적으로 의사 결정을 내리고, 명확성을 높이며, 클라우드 트랜스포메이션에서 비즈니스 가치를 창출할 수 있습니다. 이 연습 또는 이와 유사한 작업을 수행하지 않은 경우 첫 번째 태스크로 사용하는 것이 좋습니다.
이 연습 중에 다른 기술 트랜스포메이션과 달리 클라우드 트랜스포메이션은 기술을 비즈니스에 더 가깝게 배치한다는 점을 인식해야 합니다. 기술은 비즈니스가 민첩성, 안정성, 비용 최적화 및 유사한 성과를 지원하여 더 광범위한 목표를 달성하기 위해 사용하는 수단입니다. 기술과 비즈니스로 이 트랜스포메이션을 계획하고, 조직의 3~5년 전략에서 지원하며, 진행 중인 목표를 식별하고, 필요할 때 되돌리는 것을 두려워하지 않아야 합니다.
성공을 위한 구성
클라우드 마이그레이션, 채택 및 트랜스포메이션 목표를 달성하기 위한 조직의 구조는 조직이 성숙함에 따라 달라집니다. 이를 이해하고, 준비하며, 의도적으로 행동하는 것이 성공을 보장하는 핵심입니다.
일반적으로 여정을 시작할 때 가장 큰 팀은 온프레미스 환경에서 작업합니다. 그런 다음 클라우드 채택이 증가함에 따라 이러한 팀은 클라우드 플랫폼을 빌드, 성숙, 운영 및 최적화하기 위해 마이그레이션하므로 조직은 이러한 각 단계에서 새로운 작업 방식에 적응해야 합니다. 조직이 워크로드 중 5~10%를 클라우드로 이전할 경우(시작 단계에서 규모 조정 단계로 전환) 어렵지만 중요한 변화가 발생하는 것을 확인했습니다. 이 시점에서 조직은 온프레미스 팀을 통해 클라우드 리소스를 운영합니다. 마이그레이션이 풀타임 변경의 가치를 높일 만큼 규모가 크지 않기 때문입니다. 따라서 이러한 팀은 기존 책임과 새로운 책임 간의 균형을 맞춰야 합니다. 동시에 현재 클라우드 서비스를 운영하라는 요청을 받은 온프레미스 팀에는 새로운 기술이 필요하고, 이 기술을 습득하는 학습 곡선은 매우 가파릅니다.
조직을 이해하고 이러한 변경을 지원하는 계획을 개발하려면 IT 조직 전반에서 팀 토폴로지를 살펴보는 것이 좋습니다. 고객과 함께 이 방법을 사용하여 IT 조직 내에서 종종 조직 구조와 다른 기능의 배열 및 상호 연결을 이해한 다음 AWS COM 프레임워크를 사용하여 변환 단계 및 마일스톤을 달성하기 위해 구성하는 방법에 대한 지침을 제공합니다. 필요할 수 있는 조직 구조에 대한 모든 변경 사항은 이 연습에서 알려줍니다.
고객과 함께 사용한 토폴로지에는 분산형, 중앙 집중식 및 페더레이션 모델이 포함됩니다. 이는 AWS Well-Architected Framework, 운영 우수성 원칙에서 다루는 운영 모델 2x2 표현을 기반으로 확장됩니다.
탈중앙화
다양한 지역이나 업계 세그먼트에서 운영하는 대규모 글로벌 기업은 종종 다음 다이어그램에 나와 있는 분산형 모델을 사용합니다. 이러한 기업에서 개별 사업부에는 다른 리전 또는 사업부와 겹칠 수 있는 자체 IT 조항이 있습니다. 그러나 이는 종종 리전 내에서 자율성과 전문화를 제공하는 방법으로 이해되고 받아들여지기도 합니다.
분산형 접근 방식을 사용하는 경우 각 리전 또는 사업부에 해당 리전 또는 사업부의 요구 사항에 맞게 조정된 자체 클라우드 운영 모델이 있음을 의미합니다.
중앙화
중앙 집중식 IT 기능은 가장 자주 보는 모델입니다. 이 모델이 적용되면 고객은 클라우드 운영 모델을 설정할 때 동일한 토폴로지를 유지하려고 합니다. 다음 다이어그램에 이 내용이 잘 설명되어 있습니다.
이 모델에서 중앙 팀은 자체 클라우드 운영 모델을 보유한 워크로드 팀이 사용할 수 있는 선별된 플랫폼을 제공합니다. 이 접근 방식을 사용하면 워크로드 팀은 사용 중인 플랫폼의 서비스, 운영 또는 보안에 대해 걱정하지 않고도 최종 고객에게 제공하는 가치에 집중할 수 있습니다. 이 모델은 소규모 회사에 적합합니다. 그러나 대규모 글로벌 조직에서는 수백 또는 수천 개의 워크로드 팀이 있을 수 있습니다. 중앙 플랫폼의 이점을 잃지 않고 이 규모에서 관리하기 위해 조직은 자주 페더레이션 모델로 전환하며, 이는 다음 섹션에 요약되어 있습니다.
연동됨
많은 조직이 페더레이션 IT 모델을 채택하는 이유는 클라우드 플랫폼을 담당하는 중앙 기능을 제공하면서 워크로드 수준에서 다양한 운영 모델을 허용하기 때문입니다. 즉, 중앙 팀은 가장 낮은 공통 분모로 작업해야 한다는 제약 조건 없이 조직에 가능한 최상의 플랫폼을 제공하는 데 집중할 수 있습니다. 다음 다이어그램에서는 페더레이션 모델을 보여줍니다.
대규모 조직에서 페더레이션 모델은 엔지니어링 팀에 필요한 자율성을 제공하는 동시에 중앙 팀이 모든 워크로드에 공통된 플랫폼과 차별화되지 않은 과중한 작업을 제공하도록 지원합니다. 이 모델에서 중앙 팀은 엔지니어링 팀과 동일한 제품 중심 방식으로 작업해야 하지만 이들의 제품은 바로 플랫폼입니다.
여정과 일치하도록 토폴로지 변경
선택하는 토폴로지는 회사의 규모에 따라 다르지만 클라우드 여정의 단계에 맞게 조정됩니다. 부서 또는 팀의 구성은 정적이지 않지만 클라우드 채택의 각 단계에 따라 변경됩니다. 즉, 환경 변화에 따라 다양한 토폴로지를 설계, 논의 및 보강할 수 있습니다. 영향을 미치는 요인의 예는 다음과 같습니다.
-
개념 증명(POC)에서 파일럿 워크로드로 진행
-
지리적 또는 사업부 확장
-
제품 중심 팀으로 이전
-
공유되는 구성 요소 또는 패턴에서 규모의 경제를 활용할 수 있는 기회
-
아키텍처 요구 사항보다 애플리케이션 및 서비스 설계에 영향을 미치는 콘웨이의 법칙
실현 -
클라우드 우선 규정 또는 기타 하향식 이니셔티브
-
호환되지 않는 팀 목표나 조직으로 인해 KPI 또는 비즈니스 목표 누락
변화를 주도하는 메커니즘 설정
Amazon 내에서 메커니즘은 입력을 출력으로 변환하고 조직 레버에서 조립되는 전체 프로세스로 정의됩니다. 여기에서는 데이터와 피드백을 사용하여 프로세스를 지원하고 성과를 이행하도록 보장합니다. 조직마다 다르기 때문에 모든 클라우드 운영 모델 여정은 다르지만 변화를 주도하려면 모두에 메커니즘이 필요합니다.
클라우드 운영 모델을 구현하는 데 필요한 변경 사항에 맞게 메커니즘을 이해하고 개발하는 데 시간을 할애하는 것이 좋습니다. 널리 사용되는 접근 방식은 애자일 원칙을 채택하는 것입니다. 애자일 메커니즘은 사일로화된 팀 간의 조직 및 프로세스 기반 장벽을 허물고 피드백 루프를 생성하여 조직이 가장 큰 비즈니스 가치를 창출할 가장 영향력 있는 활동에서 혁신하는 데 시간을 할애하도록 합니다.
점진적으로 성숙도 개발
클라우드 운영 모델의 맥락에서 성숙도는 역량이 클라우드 우선 작업 방식에 얼마나 근접한지를 나타냅니다. 예를 들어 프로세스가 얼마나 자율적이고, 혁신(회사 변경)과 비교했을 때 평소와 같이 비즈니스를 관리(회사 운영)하려면 사람의 개입이 얼마나 필요한지를 나타냅니다. 활동이 전자에 더 많이 가중치를 부여하면 (클라우드) 성숙도가 낮고, 후자인 경우 성숙도가 더 높습니다. 성숙도 척도가 낮다고 해서 부정적인 것이 아니며, 이는 여정의 현재 위치를 반영합니다. 목표는 현재 위치와 도달해야 할 위치를 이해하는 것입니다. AWS 고객과 협력할 때 AWS COM 프레임워크 내의 성숙도 척도를 사용하여 여정의 단계를 제공합니다.
메커니즘을 사용하여 AWS COM 프레임워크 역량 전반에 걸쳐 성숙도를 점진적으로 높이는 것이 좋습니다. 이러한 방식으로 고객과 협력한 방법에 대한 예제에서는 성숙도 검토 및 우선순위(입력)를 성숙도 증가(출력)로 변환한 다음 게임 데이
조직의 역량을 성숙시키고 로드맵의 특정 시간에 특정 역량에 필요한 변화를 점진적으로 빌드하는 데 주의를 기울이면 전략이 구현과 연결됩니다. 또한 이전 업적을 기반으로 빌드할 경우 규모의 경제도 활용하는 데 도움이 됩니다.