많은 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 모델에는 클라우드 플랫폼 함수 및 클라우드 자동화 함수가 필요합니다. 다음 단계는 클라우드 플랫폼 함수를 맞추는 것입니다.