CCoE(클라우드 전문가 조직) 기능

많은 IT 조직은 비즈니스 및 기술 민첩성을 달성하기 위한 핵심 목표를 공유합니다. CCoE(클라우드 전문가 조직)는 조직이 이 목표를 추구하면서 속도와 안정성의 균형을 맞추는 데 도움이 되는 기능입니다.

기능 구조

CCoE 모델을 사용하려면 다음 각 리소스 간에 협업이 필요합니다.

• 클라우드 채택(솔루션 설계자)
• 클라우드 전략(프로그램 및 프로젝트 관리자)
• 클라우드 거버넌스
• 클라우드 플랫폼
• 클라우드 자동화

효과

이 기능이 제대로 구성되고 지원되면 참가자는 혁신 및 마이그레이션 활동을 가속화하면서 전체 변경 비용을 줄이고 비즈니스 민첩성을 높일 수 있습니다. 성공적으로 구현되면 이 함수는 출시 시간이 눈에 띄게 감소할 수 있습니다. 팀 사례가 성숙함에 따라 안정성, 성능 효율성, 보안, 유지 관리 효율성 및 고객 만족도를 포함한 품질 지표가 개선됩니다. 이러한 효율성, 민첩성 및 품질 향상은 회사가 대규모 클라우드 마이그레이션 노력을 구현할 계획이거나 클라우드를 사용하여 시장 차별화와 관련된 혁신을 추진하려는 경우에 특히 중요합니다.

성공하면 CCoE 모델은 IT에서 상당한 변화를 만듭니다. CCoE 접근 방식에서 IT는 비즈니스의 브로커, 파트너 또는 대표 역할을 합니다. 이 모델은 비즈니스와 IT 자산 간 작업 단위 또는 추상화 계층으로 IT의 기존 관점에서 벗어난 패러다임 전환입니다.

다음 이미지는 이 변화에 대한 비유를 제공합니다. CCoE 접근 방식이 없으면 IT는 제어와 중앙 책임을 제공하는 데 집중하여 교차로의 정지등처럼 작동할 수 있습니다. CCoE가 성공하는 경우 IT의 역할은 자유와 위임된 책임에 초점을 맞추는 원형 교차로와 유사합니다.

두 방법 모두 유효합니다. 책임과 관리에 대해 대안이 되는 시각입니다. CCoE 모델은 일련의 지침 및 확립된 반복 가능한 제어를 준수하면서 사업부에서 자체적인 결정을 내릴 수 있는 셀프 서비스 모델을 설정하려는 경우 기술 전략에 적합할 수 있습니다.

주요 책임

CCoE 팀의 주요 임무는 클라우드 네이티브 또는 하이브리드 솔루션을 통해 클라우드 채택을 가속화하는 것입니다.

CCoE의 목표는 다음과 같습니다.

• 민첩한 접근 방식을 사용하여 비즈니스 요구 사항을 캡처하고 구현하여 최신 IT 조직을 구축할 수 있습니다.
• 보안, 규정 준수 및 관리 정책에 맞는 재사용 가능한 배포 패키지를 사용합니다.
• 운영 절차에 따라 기능적인 Azure 플랫폼을 유지 관리합니다.
• 클라우드 네이티브 도구 사용을 검토하고 승인합니다.
• 시간이 지남에 따라 일반적으로 필요한 플랫폼 구성 요소 및 솔루션을 표준화하고 자동화합니다.

모임 주기

유기적 협업을 허용하고 공통 리포지토리 또는 솔루션 카탈로그를 통해 성장을 추적하는 것이 중요합니다. 자연스러운 상호 작용을 최대화하지만 모임을 최소화합니다. 클라우드 채택 팀에서 호스트하는 릴리스 모임과 같은 되풀이 모임은 데이터 입력을 제공할 수 있습니다. 그러나 이 함수가 완성되면 전용 모임을 제한합니다. 각 릴리스 계획을 공유한 후 모임을 호스트하면 이 팀의 최소 접점을 제공할 수 있습니다.

솔루션 및 제어

CCoE의 각 멤버는 현재 IT 제어 세트로 이어진 필요한 제약 조건, 위험 및 보호를 이해해야 합니다. CCoE는 해당 이해를 클라우드 네이티브(또는 하이브리드) 솔루션 또는 제어로 전환하여 셀프 서비스 비즈니스 성과를 가능하게 합니다. 솔루션이 만들어지면 다양한 활동을 위한 가드레일 역할을 하는 제어 또는 자동화된 프로세스의 형태로 다른 팀과 공유됩니다. 이러한 가드레일은 팀 활동을 안내하고 마이그레이션 또는 혁신 노력의 참가자에게 책임을 위임하는 데 도움이 됩니다.

다음 표에서는 이 전환의 몇 가지 예를 설명합니다.

시나리오	CCoE 이전 솔루션	CCoE 이후 솔루션
프로덕션 환경에서 SQL Server 인스턴스 프로비전	네트워크, IT 및 데이터 플랫폼 팀은 며칠 또는 몇 주 동안 구성 요소를 프로비전합니다.	서버가 필요한 팀은 Azure SQL Database의 PaaS(Platform as a Service) 인스턴스를 배포합니다. 또는 배포는 클라우드에 대한 모든 IaaS(Infrastructure as a Service) 자산에 대해 사전 승인된 템플릿을 몇 시간 안에 사용할 수 있습니다.
개발 환경 프로비저닝	네트워크, IT, 개발 및 DevOps 팀은 사양에 동의하고 환경을 배포합니다.	개발 팀은 자체 사양을 정의하고 할당된 예산에 따라 환경을 배포합니다.
데이터 보호를 개선하기 위해 보안 요구 사항 업데이트	네트워킹, IT 및 보안 팀은 여러 환경에서 네트워킹 디바이스 및 VM(가상 머신)을 업데이트하여 보호를 추가합니다.	클라우드 거버넌스 도구는 모든 클라우드 환경의 모든 자산에 즉시 적용할 수 있는 정책을 업데이트하는 데 사용됩니다.

협상

지속적인 협상 프로세스는 CCoE 활동의 근원입니다. CCoE 팀은 중앙 제어를 줄이기 위해 기존 IT 기능과 협상합니다. 이 협상에서 비즈니스에 대한 절충은 자유, 민첩성 및 속도이며 기존 IT 팀에 대한 절충은 새로운 솔루션으로 제공됩니다. 새로운 솔루션은 기존 IT 팀에 다음 이점 중 하나 이상을 제공합니다.

• 일반적인 문제를 자동화하는 기능
• 일상적인 좌절 감소로 일관성 개선
• 새로운 기술 솔루션을 알아보고 배포할 기회
• 심각도가 높은 인시던트 감소(빠른 수정 또는 심야 호출기 의무 응답 필요)
• 기술 범위를 넓히고 더 광범위한 주제를 다루는 기능
• 기술 효과 해결을 위한 상위 수준 비즈니스 솔루션 참여
• 사소한 유지 관리 작업 감소
• 기술 전략 및 자동화 증가

이러한 이점 대신에 기존 IT 기능은 다음 가치를 교환할 수 있습니다.

• 수동 승인 프로세스를 통한 제어 이해
• 변경 제어를 통한 안정성 이해
• 필요하고 반복적인 작업 완료를 통한 작업 보안 이해
• 기존 IT 솔루션 공급업체에 대한 준수를 통한 일관성 이해

건전한 클라우드 제공 회사에서 이 협상 프로세스는 동료와 파트너 IT 팀 간의 동적 대화입니다. 기술 세부 정보는 복잡할 수 있지만 IT가 목표를 이해하고 CCoE 활동을 지원하는 경우 관리가 가능합니다. IT가 지원하지 않으면 CCoE 성공 실현에 관한 다음 섹션이 마찰을 극복하는 데 도움이 될 수 있습니다.

CCoE 성공 실현

이 모델을 진행하기 전에 성장 우선 사고방식에 대한 회사의 허용 범위와 중앙 책임 해제와 관련된 IT의 편안함 수준을 살펴봅니다. 앞에서 설명한 것처럼 CCoE는 민첩성과 속도에 대한 제어를 교환합니다.

이런 종류의 변화에는 시간, 실험 및 협상이 필요합니다. 프로세스 중에 충돌과 차질이 있을 수 있지만 팀이 계속 부지런하고 실험을 단념하지 않는 경우에는 민첩성, 속도 및 안정성 개선에 성공할 가능성이 높습니다. 가장 큰 성공 요인 중 하나는 리더십 및 주요 관련자의 지원입니다.

핵심 이해 관계자

IT 리더십은 첫 번째의 가장 분명한 관련자입니다. IT 관리자는 중요한 역할을 하지만 이 모델을 구현하려면 CIO 및 기타 경영진 수준의 IT 리더의 지원이 필요합니다.

비즈니스 관련자의 필요성은 분명하지 않습니다. 비즈니스 민첩성과 출시 시간은 CCoE를 형성하기 위한 주요 동기입니다. 마찬가지로 주요 관련자는 이러한 영역에 흥미가 있습니다. 비즈니스 관련자의 예로는 기간 업무 리더, 재무 임원, 운영 임원 및 비즈니스 제품 소유자가 있습니다.

비즈니스 관련자의 지원

비즈니스 관련자의 지원은 CCoE 활동을 가속화할 수 있습니다. CCoE 활동의 대부분은 비즈니스 민첩성과 속도를 장기적으로 개선하는 데 중점을 두고 있습니다. 현재 운영 모델의 효과와 개선의 가치를 정의하는 것은 CCoE에 대한 가이드 및 협상 도구로서 중요합니다. CCoE에 대한 지원을 높이기 위해 설명서에서 다음 항목을 설정하거나 명확하게 정의하는 것이 좋습니다.

• 예상된 비즈니스 결과 및 목표.

• 속도, 민첩성, 안정성 및 비용 문제와 같은 현재 IT 프로세스의 문제.

• 시장 점유율 손실, 기능 및 기능의 경쟁사 이익, 열악한 고객 경험 및 예산 증가와 같은 이러한 고통 요소의 역사적 영향.

• 현재 고통 요소 및 운영 모델에 의해 차단되는 비즈니스 개선 기회.

• 이러한 기회와 관련된 타임라인 및 메트릭

이 데이터 포인트는 IT에 대한 공격이 아닙니다. 대신 CCoE 팀이 과거에 대해 배우고, 현실적인 백로그를 설정하고, 개선 계획을 세웁니다.

이해 관계자의 지속적인 지원 및 참여

CCoE 팀은 일부 영역에서 빠른 수익을 입증할 수 있지만 비즈니스 민첩성 및 출시 시간과 같은 상위 수준의 목표는 훨씬 더 오래 걸릴 수 있습니다. 성숙하는 동안 CCoE 팀이 낙담하거나 다른 IT 활동에 집중하기 위해 구성원을 끌어당길 위험이 높습니다.

CCoE 활동의 처음 6~9개월 동안 비즈니스 관련자는 IT 리더십 및 CCoE와 매월 만나는 것이 좋습니다. 이 모임에는 공식 절차가 거의 필요하지 않습니다. CCoE 멤버와 해당 리더십에게 프로그램의 중요성을 상기시키기만 하면 CCoE 성공에 크게 도움이 될 수 있습니다.

또한 비즈니스 관련자는 CCoE 팀이 경험하는 진행 상황 및 차단 문제에 대한 정보를 유지하는 것이 좋습니다. 해당 활동은 기술 세부 정보처럼 보일 수 있지만 비즈니스 관련자는 팀의 열기가 식거나 팀이 다른 우선 순위로 인해 산만해질 때 참여할 수 있도록 계획의 진행 상황을 파악해야 합니다.

IT 관련자의 지원

IT 관련자의 지원에는 다음 활동이 포함되어야 합니다.

• 비전 지원: 성공적인 CCoE 활동을 위해서는 기존 IT 팀 멤버와 많은 협상이 필요합니다.

  잘 되면 모든 IT가 솔루션에 기여하고 변화에 익숙해집니다. 경우에 따라 기존 IT 팀의 일부 멤버는 제어 메커니즘을 유지하려고 할 수 있습니다. 이러한 상황이 발생하면 IT 이해 관계자가 CCoE를 지원하는 것이 CCoE의 성공에 매우 중요합니다. IT 이해 관계자는 CCoE의 전반적인 목표를 장려하고 강화하여 블록을 적절한 협상으로 해결해야 합니다. 드문 경우지만 IT 이해 관계자들은 CCoE의 진행 상황을 파악하기 위해 교착 상태 또는 동률 투표를 중단해야 기본 수도 있습니다.

• 초점 유지: CCoE는 리소스가 제한된 IT 팀에 중요한 참여가 될 수 있습니다.

  단기 프로젝트에서 강력한 설계자를 제거하여 장기적인 개선에 초점을 맞추면 CCoE에 속하지 않는 팀 멤버에게 어려움이 생길 수 있습니다. IT 리더십과 IT 관련자는 계속해서 CCoE의 목표에 초점을 맞추어야 합니다. IT 리더와 IT 관련자의 지원이 있으면 CCoE 업무를 위해 일상적인 운영 중단의 우선 순위를 낮출 수 있습니다.

• 버퍼 만들기: CCoE 팀은 새로운 접근 방식을 실험합니다.

  일부 새로운 접근 방식은 기존 작업 또는 기술 제약 조건과 잘 맞지 않습니다. CCoE 팀은 실험이 실패할 때 다른 팀의 압박이나 의지를 경험할 수 있습니다. "빠른 실패" 학습 기회의 결과로부터 CCoE 팀을 장려하고 버퍼링하는 것이 중요합니다. 팀이 이러한 실험에서 배우고 더 나은 솔루션을 찾을 수 있도록 성장 사고방식에 책임을 묻는 것이 똑같이 중요합니다.

다음 단계

CCoE 모델에는 클라우드 플랫폼 기능과 클라우드 자동화 기능이 필요합니다. 다음 단계에서는 클라우드 플랫폼 기능을 조정합니다.

클라우드 플랫폼 함수