포트폴리오 계층 구조
워크로드, 자산 및 지원 서비스 포트폴리오 가 모두 함께 작동하는 방식을 이해하려면 포트폴리오 계층 구조를 설정해야 합니다. 이 문서에서는 포트폴리오 계층 구조 수준에 대한 명확한 정의와 팀이 각 수준에 대한 기대치를 충족할 수 있는 지침을 제공합니다. 이 문서에서는 계층의 각 수준을 범위라고도 합니다.
워크로드
정의된 비즈니스 가치를 제공하는 기술 컬렉션을 워크로드라고 합니다. 컬렉션에는 애플리케이션, 서버 또는 가상 머신, 데이터, 디바이스 및 기타 유사하게 그룹화된 자산이 포함될 수 있습니다. 대부분의 기업은 중요한 비즈니스 기능을 제공하기 위해 여러 워크로드를 사용합니다.
일반적으로 비즈니스 관련자와 기술 리더는 각 워크로드의 지속적인 지원에 대한 책임을 공유합니다. 워크로드 수명 주기의 일부 단계에는 이러한 역할이 명확하게 명시되어 있습니다. 워크로드 수명 주기의 더 많은 운영 단계에서 이러한 역할은 공유 운영 관리 팀 또는 클라우드 운영 팀으로 전환될 수 있습니다. 워크로드 수가 증가함에 따라 역할(명시적 또는 암시적)이 더 복잡해지고 얽히게 됩니다.
워크로드 및 해당 지원 자산은 모든 포트폴리오의 핵심입니다. 범위 또는 계층은 해당 워크로드를 보는 방법과 잠재적 지원 팀의 매트릭스의 영향을 어느 정도까지 정의합니다.
용어는 다를 수 있지만 모든 IT 솔루션에는 자산 및 워크로드가 포함됩니다.
- 자산: 워크로드 또는 솔루션을 지원하는 기술 기능의 최소 단위입니다.
- 워크로드: 비즈니스에 대한 IT 지원의 최소 단위입니다. 워크로드는 일반적인 비즈니스 목표 또는 일반적인 비즈니스 프로세스 실행을 지원하는 인프라, 애플리케이션 및 데이터 자산의 컬렉션입니다.
첫 번째 워크로드를 배포하는 경우 워크로드 및 해당 자산이 유일하게 정의된 범위일 수 있습니다. 다른 계층은 더 많은 워크로드가 배포될 때 명시적으로 정의될 수 있습니다.
IT 포트폴리오
회사에서 매트릭스 방식 또는 중앙 집중식 접근 방식을 통해 워크로드를 지원하는 경우 이러한 워크로드를 지원하기 위한 더 광범위한 계층 구조가 존재할 수 있습니다.
- 랜딩 존: 랜딩 존은 하나 이상의 워크로드를 지원하는 데 필요한 기본 유틸리티 또는 공유 배관을 워크로드에 제공합니다. 랜딩 존은 클라우드에서 매우 중요하기 때문에 클라우드 채택 프레임워크 전체 준비 방법론이 랜딩 존에 중점을 둡니다. 자세한 정의는 랜딩 존이란?을 참조하세요.
- 기본 유틸리티: 이러한 공유 IT 서비스는 워크로드가 기술 및 비즈니스 포트폴리오 내에서 작동하는 데 필요합니다.
- 플랫폼 기반: 이 조직 구조는 기본 솔루션을 중앙 집중화하고 해당 컨트롤이 모든 랜딩 존에 적용되도록 하는 데 도움이 됩니다.
- 클라우드 플랫폼: 전체 포트폴리오를 지원하기 위한 전반적인 전략에 따라 고객은 여러 지역, 하이브리드 솔루션 또는 다중 클라우드 솔루션을 제어하기 위해 플랫폼 기반의 고유한 배포가 있는 여러 클라우드 플랫폼이 필요할 수 있습니다.
- 포트폴리오: 기술 관점에서 포트폴리오는 모든 클라우드 플랫폼에 걸쳐 있는 워크로드, 자산 및 지원 리소스의 컬렉션입니다. 비즈니스 관점에서 포트폴리오는 비즈니스 결과를 주도하기 위해 기술 포트폴리오를 지원하고 관리하는 프로젝트, 사람, 프로세스 및 투자의 컬렉션입니다. 포트폴리오에는 이 두 관점이 모두 적용됩니다.
계층 구조 책임 및 지침
담당 팀은 포트폴리오 계층 구조의 각 계층을 관리합니다. 다음 다이어그램에서는 담당 팀 간의 매핑과 비즈니스 의사 결정, 기술 결정 및 기술 구현을 지원하는 지침을 보여 줍니다.
참고
다음 목록에 언급된 팀은 가상 팀 또는 개인일 수 있습니다. 이 계층 구조의 일부 변형의 경우 책임 변형의 뒷부분에서 설명한 대로 일부 담당 팀이 축소될 수 있습니다.
- 포트폴리오: 클라우드 전략 팀과 CCoE(클라우드 센터)는 전략 및 계획 방법론을 사용하여 전체 포트폴리오에 영향을 주는 결정을 안내합니다. 클라우드 전략 팀은 클라우드 포트폴리오 계층 구조의 엔터프라이즈 수준에 대한 책임을 집니다. 또한 클라우드 전략 팀은 환경, 랜딩 존 및 우선 순위가 높은 워크로드에 대한 결정을 통보받아야 합니다.
- 클라우드 플랫폼: 클라우드 거버넌스 팀은 거버넌스 방법론에 따라 각 환경의 일관성을 보장하는 분야에 대해 책임을 집니다. 클라우드 거버넌스 팀은 모든 환경의 모든 리소스에 대한 거버넌스를 담당합니다. 클라우드 거버넌스 팀은 관리 정책에 대한 예외 또는 변경이 필요할 수 있는 변경 사항에 대해 협의해야 합니다. 클라우드 거버넌스 팀은 워크로드 및 자산 채택과 관련된 진행 상황도 알고 있어야 합니다.
- 랜딩 존 및 클라우드 기반: 클라우드 플랫폼 팀은 채택을 지원하는 랜딩 존 및 플랫폼 유틸리티를 개발할 책임이 있습니다. 클라우드 자동화 팀은 이러한 랜딩 존 및 플랫폼 유틸리티에 대한 개발 및 지속적인 지원을 자동화할 책임이 있습니다. 두 팀 모두 준비 방법론을 사용하여 구현을 안내합니다. 두 팀은 모두 워크로드 채택 진행 상황과 엔터프라이즈 또는 환경의 변경 사항을 알고 있어야 합니다.
- 워크로드: 채택은 워크로드 수준에서 발생합니다. 클라우드 채택 팀은 마이그레이션 및 혁신 방법론을 사용하여 채택을 가속화하는 확장 가능한 프로세스를 설정합니다. 채택이 완료되면 워크로드의 소유권은 관리 방법론을 사용하여 운영 관리를 안내하는 클라우드 운영 팀으로 이전될 가능성이 높습니다. 두 팀은 모두 Microsoft Azure Well-Architected Framework를 능숙하게 사용하여 지원되는 워크로드에 영향을 주는 세부적인 아키텍처 결정을 내릴 수 있어야 합니다. 두 팀은 모두 랜딩 존 및 환경에 대한 변경 내용을 알고 있어야 합니다. 두 팀은 모두 때때로 랜딩 존 기능에 기여할 수 있습니다.
- 자산: 자산은 일반적으로 클라우드 운영 팀의 책임입니다. 해당 팀은 관리 방법론의 관리 기준을 사용하여 운영 관리 결정을 안내합니다. 또한 Azure Advisor 및 Azure Well-Architected Framework를 사용하여 운영 요구 사항을 충족하는 데 필요한 세부적인 리소스 및 아키텍처 변경을 수행해야 합니다.
책임 변형
- 단일 환경: 엔터프라이즈에 하나의 환경만 필요한 경우 CCoE는 일반적으로 필요하지 않습니다.
- 단일 랜딩 존: 환경에 단일 랜딩 존만 있는 경우 거버넌스 및 플랫폼 기능이 한 팀으로 결합될 수 있습니다.
- 단일 워크로드: 일부 기업은 단일 랜딩 존과 단일 환경에서 하나의 워크로드 또는 몇 개의 워크로드만 필요합니다. 이러한 경우 거버넌스, 플랫폼 및 운영 팀 간에 업무를 분리할 필요가 거의 없습니다.
일반적인 워크로드 및 책임 예제
다음 예제에서는 포트폴리오 계층 구조를 보여 줍니다.
COTS 워크로드
기존에는 기업이 비즈니스 프로세스를 구동할 때 상용 COTS(상업용 제품 및 서비스) 소프트웨어 솔루션을 선호했습니다. 이러한 솔루션은 설치, 구성 후 작동합니다. 구성 후 솔루션 아키텍처에는 거의 변화가 없습니다.
이러한 시나리오에서 COTS 솔루션의 클라우드 채택은 클라우드 운영 팀으로 전환되면서 끝납니다. 그런 다음, 클라우드 운영 팀은 해당 소프트웨어의 기술 소유자가 되며 구성, 비용, 패치 주기 및 기타 운영 요구 사항 관리를 담당합니다.
이러한 워크로드에는 회계 패키지, 물류 소프트웨어 또는 산업별 솔루션이 포함됩니다. Microsoft 용어에서 이러한 패키지의 공급업체를 ISV(독립 소프트웨어 공급업체)라고 합니다. 많은 ISV는 구독에서 소프트웨어 패키지의 인스턴스를 배포하고 유지 관리하는 서비스를 제공합니다. 또한 자체 클라우드 호스팅 환경에서 실행되는 소프트웨어 패키지 버전을 제공하여 워크로드 대신 PaaS(Platform as a Service)를 제공할 수도 있습니다.
PaaS 제품을 제외하고 클라우드 운영 팀은 해당 워크로드에 대한 기본 운영 규정 준수 요구 사항을 보장할 책임이 있습니다. 클라우드 운영 팀은 클라우드 거버넌스 팀과 협력하여 비용, 성능 및 기타 아키텍처 핵심 요소를 조율해야 합니다.
활성 수정 버전으로 개발 중
COTS 솔루션 또는 PaaS 제품이 비즈니스 요구 사항에 맞지 않거나 솔루션이 없는 경우 기업은 사용자 지정 개발 워크로드를 빌드합니다. 일반적으로 IT 포트폴리오의 일부만 이 워크로드 접근 방식을 사용합니다. 그러나 이러한 워크로드는 비즈니스 결과, 특히 새로운 수익원과 관련된 결과에 대한 IT 기여도가 불균형적으로 높은 비율을 차지하는 경향이 있습니다. 이러한 워크로드는 새로운 혁신 아이디어에 잘 매핑되는 경향이 있습니다.
민첩한 방법론 및 DevOps 관행에 뿌리를 둔 다양한 이동을 고려할 때 이러한 워크로드는 기존 IT 관리보다 비즈니스/DevOps 맞춤을 선호합니다. 이러한 워크로드의 경우 몇 년 동안 클라우드 운영 팀에 전달되지 않을 수 있습니다. 이러한 경우 개발 팀은 워크로드의 기술 소유자 역할을 합니다.
광범위한 시간 및 자본 제약 조건으로 인해 사용자 지정 개발 옵션은 종종 높은 가치의 기회로 제한됩니다. 일반적인 예로는 애플리케이션 혁신, 심층 데이터 분석 또는 중요 업무용 비즈니스 기능이 있습니다.
중단/수정 또는 일몰 개발
사용자 지정 개발 워크로드가 최대 완성도에 도달하면 개발 팀이 다른 프로젝트에 다시 할당될 수 있습니다. 이러한 경우 기술 소유권은 일반적으로 클라우드 운영 팀으로 전환됩니다. 작은 수정이 필요한 경우 운영 팀은 개발자에게 오류 해결을 요청합니다.
경우에 따라 개발 팀은 결국 현재 워크로드를 대체할 프로젝트로 이동합니다. 또는 워크로드에서 지원하는 비즈니스 기회가 단계적으로 중단되기 때문에 팀이 계속 진행할 수 있습니다. 이러한 종료 시나리오에서 클라우드 운영 팀은 워크로드가 더 이상 필요하지 않을 때까지 기술 소유자 역할을 합니다.
두 시나리오에서 클라우드 운영 팀은 일반적으로 장기 기술 소유자 및 의사 결정권자 역할을 합니다. 운영 변경을 위해 대대적인 아키텍처 변경이 필요한 경우 해당 팀은 애플리케이션 개발자를 참여시킬 가능성이 높습니다.
중요 업무용 워크로드
모든 회사에는 비즈니스에 너무 중요하여 실패할 수 없는 몇 가지 워크로드가 있습니다. 이러한 중요 업무용 워크로드에는 일반적으로 다양한 책임 수준이 있는 운영 및 개발 소유자가 있습니다. 이러한 팀은 운영 변경 및 아키텍처 변경을 조율하여 프로덕션 솔루션의 중단을 최소화해야 합니다.
이러한 시나리오에서는 의무 분리에 중점을 두는 것이 필요합니다. 운영 팀은 일반적으로 프로덕션 환경의 일상적인 운영 변경에 대한 책임을 맡게 됩니다. 이러한 운영 변경에 아키텍처 변경이 필요한 경우 개발 또는 채택 팀이 비프로덕션 환경에서 이러한 변경을 완료한 후 운영 팀이 프로덕션에 변경 내용을 적용합니다.
의무 분리가 필요한 중요 업무용 워크로드의 예로는 SAP, Oracle 또는 회사의 여러 사업부에 걸쳐 있는 다른 ERP(엔터프라이즈 리소스 계획) 솔루션과 같은 워크로드가 있습니다.
전략 포트폴리오 조율
클라우드 채택 활동의 전략적 목표를 이해하고 해당 변환을 지원하기 위해 포트폴리오를 조율하는 것이 중요합니다. 몇 가지 일반적인 유형의 전략적 포트폴리오 조율은 포트폴리오 계층 구조의 구조를 형성하는 데 도움이 될 수 있습니다. 다음 섹션에서는 포트폴리오 정렬의 예와 포트폴리오 계층 구조에 미치는 영향을 제공합니다.
혁신 또는 개발 주도 포트폴리오
일부 회사, 특히 빠르게 성장하는 신생 기업은 사용자 지정 개발 프로젝트의 평균보다 높은 비율을 가지고 있습니다. 개발이 많은 포트폴리오에서는 환경, 랜딩 존 및 워크로드가 압축되는 경우가 많으므로 특정 워크로드에 대한 특정 환경이 있을 수 있습니다. 그 결과 환경, 랜딩 존 및 워크로드 간의 비율이 1:1입니다.
환경에서 사용자 지정 솔루션을 호스트하기 때문에 DevOps 파이프라인 및 애플리케이션 수준 보고가 운영 및 거버넌스 기능을 대체할 수 있습니다. 이러한 고객은 운영, 거버넌스 또는 기타 지원 역할에 대한 집중을 줄일 수 있습니다. 클라우드 채택 및 클라우드 자동화 팀의 책임에 더 중점을 두는 것도 일반적입니다.
포트폴리오 맞춤: IT 포트폴리오는 워크로드 및 워크로드 소유자에 집중하여 중요한 아키텍처 결정을 내릴 수 있습니다. 이러한 팀은 채택 및 운영 활동 중에 Azure Well-Architected Framework 지침에서 더 많은 가치를 찾을 수 있습니다.
경계 정의: 논리적 경계는 엔터프라이즈 수준에서도 프로덕션 및 비프로덕션 환경 세분화에 초점을 맞출 가능성이 높습니다. 또한 회사의 소프트웨어 포트폴리오에 있는 제품 간에 명확한 구분이 있을 수 있습니다. 때때로 개발 인스턴스와 호스팅되는 고객 인스턴스 간에 구분이 있을 수 있습니다.
운영 주도 포트폴리오
IT 운영 팀이 더 많이 있는 다국적 기업 조직은 일반적으로 개발보다 거버넌스 및 운영에 더 중점을 둡니다. 이러한 조직에서 워크로드의 비율이 높을수록 일반적으로 클라우드 운영 팀 내의 기술 소유자가 유지 관리하는 COTS 또는 중단/수정 범주에 맞춰 조정됩니다.
포트폴리오 맞춤: IT 포트폴리오는 워크로드에 맞게 조정되지만 해당 워크로드는 운영 단위 또는 사업부에 맞게 조정됩니다. 또한 자금 조달 모델, 산업 또는 기타 비즈니스 세분화 요구 사항 중심의 조직이 있을 수 있습니다.
경계 정의: 랜딩 존은 애플리케이션을 애플리케이션 원형으로 그룹화하여 유사한 운영을 유사한 부분으로 유지할 수 있습니다. 환경은 데이터 센터, 국가, 클라우드 공급자 지역 또는 기타 운영 조직 표준과 같은 물리적 구조를 참조할 가능성이 높습니다.
마이그레이션 주도 포트폴리오
운영 주도 포트폴리오와 마찬가지로, 마이그레이션을 통해 주로 구축되는 포트폴리오는 기존 자산의 마이그레이션으로 이어진 특정 비즈니스 동인을 기반으로 합니다. 일반적으로 데이터 센터는 해당 동인의 가장 큰 요소입니다.
포트폴리오 맞춤: IT 포트폴리오는 워크로드에 맞출 수 있지만 자산에 맞춰질 가능성이 높습니다. 회사 기록에서 IT 운영으로의 전환이 발생한 경우 많은 활성 사용 자산이 자금 지원 워크로드에 쉽게 매핑되지 않을 수 있습니다. 이러한 경우 마이그레이션 프로세스 후반까지 많은 자산에 정의된 워크로드가 없거나 명확한 워크로드 소유자가 없을 수 있습니다.
경계 정의: 랜딩 존은 온-프레미스 구분을 반영하는 경계로 애플리케이션을 그룹화할 가능성이 높습니다. 모범 사례는 아니지만 환경은 네트워크 세분화 사례를 나타내는 온-프레미스 데이터 센터 이름 및 랜딩 존과 일치하는 경우가 많습니다. 운영 주도 포트폴리오에 더 밀접하게 부합하는 세분화를 준수하는 것이 더 좋습니다.
거버넌스 주도 포트폴리오
거버넌스 팀에 대한 조정은 가능한 한 빨리 이뤄져야 합니다. 포트폴리오 및 환경 경계는 거버넌스 사례 및 클라우드 거버넌스 도구를 통해 혁신, 운영 및 마이그레이션 활동의 요구 사항을 가장 잘 분산할 수 있습니다.
포트폴리오 맞춤: 거버넌스 주도 포트폴리오에는 워크로드, 운영 소유자, 데이터 분류 및 운영 중요도와 같은 혁신 및 운영 세부 정보를 캡처하는 데이터 요소가 포함되는 경향이 있습니다. 이러한 데이터 요소는 포트폴리오에 대한 다목적 보기를 만듭니다.
경계 정의: 거버넌스 주도 포트폴리오의 경계는 비즈니스 단위 및 개발 환경의 기준에 매핑되는 관리 그룹 기반 계층 구조를 사용하는 동시에 혁신보다 운영을 선호하는 경향이 있습니다. 계층 구조의 각 수준에서 클라우드 거버넌스 경계는 다양한 수준의 정책 적용을 통해 개발 및 창의적인 유연성을 허용할 수 있습니다. 동시에 프로덕션 등급 요구 사항을 프로덕션 구독에 적용하여 의무 분리 및 일관된 운영을 보장할 수 있습니다.
다음 단계
Azure 제품이 포트폴리오 계층 구조를 지원하는 방법을 알아봅니다.