클라우드 조직 안티패턴
고객은 종종 조직 구조 내에서 클라우드 채택 안티패턴을 경험합니다. 많은 요인으로 인해 이러한 문제가 발생할 수 있습니다.
- 도구 집합
- 파트너
- 엔지니어
- 잘못 정렬된 IT 부서
성공적인 클라우드 채택 시나리오에서 이러한 요인의 역할을 이해하는 것이 중요합니다.
안티패턴: IT를 비용 센터로 처리
많은 회사에서 IT 부서를 비용 센터로 취급합니다. 이 접근 방식은 IT가 회사에 가치를 추가하지 않는다는 인식으로 이어질 수 있습니다. 직원들이 IT를 도우미가 아닌 제공자로 볼 때, 그들은 사기를 잃을 수 있습니다. 또한 회사가 올바른 인재를 유치하는 것도 어렵습니다. 동기 부여 감소 및 긴 수명 주기가 결과를 초래합니다. IT 작업의 품질이 저하될 수 있으며 사일로 및 영역이 형성될 수 있습니다.
예: IT를 비용 센터로 처리
기업은 CFO(최고 재무 책임자)를 담당하는 비용 센터로 IT 부서를 관리합니다. 관리 보드는 IT를 회사의 가장 큰 비용 동인 중 하나인 느린 서비스 공급자로 인식합니다. 관리 보드는 모바일 사업부가 IT 부서에서 주문한 대부분의 자산을 소비하고 있다는 사실을 인식하지 못합니다. IT는 사용할 모든 사업부에 대한 데이터 센터를 구입하지만 모바일 사업부는 이 대형 자산을 가져옵니다. 이사회는 IT를 인에이블러 또는 파트너로 않습니다.
기본 결과: IT를 인에이블러로 보기
IT 부서를 비용 센터로 관리하는 대신 다음 방법 중 하나를 고려합니다.
- 차지백: 사업부는 IT 비용을 예산의 운영 비용과 같이 처리합니다.
- 쇼백 또는 어웨어니스백: IT는 에이전트로 역할합니다. 비즈니스에 보고할 때 IT는 모든 직접 비용을 관련 사업부에 할당합니다.
클라우드를 도구로 사용하여 비용 및 비즈니스 투명성을 높입니다. 예를 들어 비용 투명성을 높이기 위해 Cost Management 분야 구현합니다. 그러면 여러 사업부의 비용을 더 잘 알 수 있습니다. IT 부서를 해당 단위의 인에이블러로 볼 수 있습니다.
투명성을 향상하려면 클라우드로 이동할 때 가시성, 책임성 및 최적화에 집중합니다. 자세한 내용은 비용을 절약하는 조직을 구축하는 방법 참조하세요.
안티패턴: 비즈니스에 관여하지 않고 새로운 기술에 투자
IT 부서는 종종 강력한 플랫폼 및 도구 집합을 빌드하고 배포하는 데 상당한 인적 및 재무 리소스를 투자합니다. 그러나 디자인 및 개발 단계에서 IT가 사업부와 요구 사항을 고려하지 못하는 경우가 있습니다. 이러한 누락은 사업부와의 관련성을 최소화하는 새로운 플랫폼으로 이어집니다. 그런 다음 직원들은 새로운 기술을 받아들이기를 주저합니다. 부실하거나 느린 채택은 결과를 초래할 수 있습니다. 사업부에서 플랫폼을 사용하지 않는 경우에도 IT 내에서 좌절이 발생합니다.
예: 사업부를 포함하지 않고 플랫폼 설정
데이터 분석 회사의 IT 부서는 사업부를 포함하지 않고 Azure 플랫폼을 설정하고 사용자 지정합니다. 플랫폼을 사용하는 동안 사업부 개발자는 다음을 수행합니다.
- 배포에 필요한 권한이 없다는 것을 알게 됩니다.
- 제한된 수의 서비스만 사용할 수 있습니다.
- 승인 주기를 연장하는 지원 티켓을 발급합니다.
- 새 플랫폼을 의심하기 시작합니다.
결국 일부 개발자는 IT 규칙 및 규정의 번거로움을 피하기 위해 Azure 구독을 직접 구매합니다. 섀도 IT가 나타납니다. 회사는 그림자 IT를 거의 제어할 수 없기 때문에 높은 보안 위험이 발생합니다.
기본 결과: 의사 결정에 사업부 포함
엔터프라이즈 지원 클라우드 플랫폼을 배포할 때 IT 사일로 만들지 않습니다. 설계 및 개발 프로세스에서 사업부의 개발자 및 TDM(기술 의사 결정자)을 참여시킵니다. 플랫폼 채택을 개선하려면 사업부의 의견을 경청하세요.
Azure 모범 사례 및 디자인 원칙으로, 채택 속도를 높이고 개발자를 위해 조정된 클라우드 채택 프레임워크 엔터프라이즈 규모 랜딩 존의 시작 지침에 대해서는 을 참고하세요. 규정 준수와 유연성 사이의 적절한 균형을 맞습니다. 예를 들어 개발 환경을 민첩하게 유지하면서 거버넌스 및 보안 정책을 충족하는 방법을 찾습니다.
안티패턴: 핵심 비즈니스 기능 아웃소싱
컨설팅 파트너 및 MSP(관리 서비스 공급자)는 클라우드 경험에서 중요한 역할을 할 수 있습니다. 그러나 기업은 파트너와 MSP의 작업이 비즈니스에서 가장 큰 가치를 제공하지 않는다는 주의를 기울여야 합니다. MSP 또는 클라우드 컨설턴트에게 책임을 아웃소싱하는 회사는 이러한 공급자에 의존해서는 안 됩니다.
예: 클라우드 채택 및 마이그레이션 아웃소싱
연구소에는 시간이 중요한 클라우드 마이그레이션 프로젝트가 있습니다. 클라우드 채택 과정을 단축하기 위해 MSP를 고용하여 Azure 기반을 구축하고 마이그레이션을 구현합니다. 이 연구소는 클라우드 채택 단계에 대해 배우고 기술을 구축하는 대신 모든 Azure 책임을 MSP에 넘겨주도록 선택합니다. 연구소에는 클라우드 또는 Azure 지식이 없으므로 MSP는 모든 의사 결정을 주도하여 MSP에 종속된 연구소를 만듭니다.
선호하는 결과: 중요한 디자인 영역을 회사의 책임으로 만들기
좋은 비용 절감 전략으로 아웃소싱을 염두에 두십시오. 그러나 다음과 같은 중요한 디자인 영역이 포함될 때 회사 내에서 결정을 내립니다.
- 거버넌스
- 위험
- 컴플라이언스
- 신원
보안 자산에 중요한 이러한 영역 및 기타 영역에 대해 회사 내부에서 책임을 져야 합니다. 외부 파트너를 사용하여 채택 과정을 가속화합니다. 그러나 공급자에 의존하지 않으려면 모든 것을 아웃소싱하지 마십시오.
안티패턴: 클라우드 엔지니어를 개발하는 대신 기술 의사 결정자 고용
기업은 올바른 인력을 찾는 데 중요합니다. 따라서 초기 클라우드 채택 단계에서 TDM을 고용하거나 빌드하는 경우가 많습니다. 성공적인 클라우드 여정은 TDM을 사용합니다. 그러나 더 중요한 것은 클라우드 채택에는 모든 실습 정신과 깊은 기술 기술을 갖춘 엔지니어가 필요하다는 것입니다.
예: TDM만 고용
한 연구소는 클라우드 경험을 이끌기 위해 여러 TDM을 고용합니다. 초기 상위 수준 개념 단계가 종료되면 구현 단계가 시작됩니다. 그런 다음, 연구소는 클라우드 배포가 온-프레미스 배포와 다르게 작동한다는 것을 인식합니다. 개념 및 정책 기반 거버넌스를 IaC(Infrastructure as code)를 제대로 구현하려면 추가 클라우드 엔지니어링 노력이 필요합니다.
기본 결과: 구현 단계에 클라우드 엔지니어 사용
엔지니어는 클라우드 자동화 및 랜딩 존 개념을 올바르게 구현하는 데 필수적입니다. 서비스 모델을 채택할 때 책임과 태스크가 크게 바뀔 수 있습니다. 책임을 클라우드 공급자로 전환하면 프로덕션으로 더 빠르게 전환할 수 있습니다. 의사 결정에 TDM을 사용할 수도 있지만, 심층 엔지니어링 지식이 필요한 작업에는 유능한 클라우드 엔지니어를 사용할 수 있습니다. 그런 다음 클라우드에서 제공하는 이점을 실현할 수 있습니다.