포트폴리오 계층 구조

워크로드, 자산 및 지원 서비스의 포트폴리오 모두 함께 작동하는 방식을 이해하려면 포트폴리오 계층 구조를 설정해야 합니다. 이 문서에서는 포트폴리오 계층 구조 수준에 대한 명확한 정의와 팀이 각 수준에 대한 기대치를 제공할 수 있는 지침을 제공합니다. 이 문서 전체에서 계층의 각 수준을 범위라고 부릅니다.

작업량

정의된 비즈니스 가치를 제공하는 기술의 모음을 워크로드이라 한다. 컬렉션에는 애플리케이션, 서버 또는 가상 머신, 데이터, 디바이스 및 기타 유사하게 그룹화된 자산이 포함될 수 있습니다. 대부분의 기업은 중요한 비즈니스 기능을 제공하기 위해 여러 워크로드를 사용합니다.

일반적으로 비즈니스 이해 관계자와 기술 리더는 각 워크로드의 지속적인 지원에 대한 책임을 공유합니다. 워크로드 수명 주기의 일부 단계에서는 이러한 역할이 명확하게 명시되어 있습니다. 워크로드 수명 주기의 더 많은 운영 단계에서 이러한 역할은 공유 운영 관리 팀 또는 클라우드 운영 팀으로 전환될 수 있습니다. 워크로드 수가 증가함에 따라 역할(명시되거나 암시적)은 더 복잡하고 행렬화됩니다.

워크로드 및 해당 지원 자산은 모든 포트폴리오의 핵심입니다. 범위 또는 계층은 해당 워크로드를 보는 방법과 잠재적 지원 팀의 매트릭스에 의해 영향을 받는 정도를 정의합니다.

용어는 다를 수 있지만 모든 IT 솔루션에는 자산 및 워크로드가 포함됩니다.

• 자산: 워크로드 또는 솔루션을 지원하는 가장 작은 기술 기능 단위입니다.
• 워크로드: 비즈니스에 대한 IT 지원의 가장 작은 단위입니다. 워크로드는 일반적인 비즈니스 목표 또는 일반적인 비즈니스 프로세스 실행을 지원하는 인프라, 애플리케이션 및 데이터 자산의 컬렉션입니다.

첫 번째 워크로드를 배포하는 경우 워크로드와 해당 자산이 유일하게 정의된 범위일 수 있습니다. 다른 계층은 더 많은 워크로드가 배포될 때 명시적으로 정의될 수 있습니다.

IT 포트폴리오

회사에서 행렬 방식 또는 중앙 집중식 접근 방식을 통해 워크로드를 지원하는 경우 이러한 워크로드를 지원하기 위해 더 광범위한 계층 구조가 존재할 수 있습니다.

여러 퍼블릭 및 프라이빗 클라우드 플랫폼이 있는 IT 포트폴리오의

• 랜딩 존: 랜딩 존은 하나 이상의 워크로드를 지원하는 데 필요한 기본 유틸리티 또는 공유 배관을 워크로드에 제공합니다. 랜딩 존은 클라우드에서 매우 중요하므로 클라우드 채택 프레임워크의 전체 Ready 방법론이 랜딩 존에 중점을 둡니다. 자세한 정의는 랜딩 존이란?을 참조하세요.
• 기초 유틸리티: 이러한 공유 IT 서비스는 워크로드가 기술 및 비즈니스 포트폴리오 내에서 작동하기 위해 필수적입니다.
• Platform 기반: 이 조직 구성은 기본 솔루션을 중앙 집중화하고 모든 랜딩 존에 해당 컨트롤이 적용되도록 합니다.
• 클라우드 플랫폼: 전체 포트폴리오를 지원하기 위한 전반적인 전략에 따라 고객은 플랫폼 기반의 고유한 배포를 통해 여러 지역, 하이브리드 솔루션 또는 다중 클라우드 솔루션을 제어하는 여러 클라우드 플랫폼이 필요할 수 있습니다.
• 포트폴리오: 기술 렌즈를 통해 포트폴리오는 모든 클라우드 플랫폼에 걸쳐 있는 워크로드, 자산 및 지원 리소스의 모음입니다. 비즈니스 렌즈를 통해 포트폴리오는 비즈니스 결과를 주도하기 위해 기술 포트폴리오를 지원하고 관리하는 프로젝트, 사람, 프로세스 및 투자의 컬렉션입니다. 이 두 렌즈는 함께 포트폴리오를 포착합니다.

계층 구조 책임 및 지침

책임 있는 팀은 포트폴리오 계층 구조의 각 계층을 관리합니다. 다음 다이어그램에서는 책임 있는 팀과 비즈니스 의사 결정, 기술 결정 및 기술 구현을 지원하기 위한 지침 간의 매핑을 보여 줍니다.

계층 구조에 맞는 책임을 보여 주는

• 포트폴리오: 클라우드 전략 팀과 CCoE(클라우드 센터)는 전략 및 계획 방법론을 사용하여 전체 포트폴리오에 영향을 주는 결정을 안내합니다. 클라우드 전략 팀은 클라우드 포트폴리오 계층 구조의 엔터프라이즈 수준을 담당합니다. 클라우드 전략 팀은 환경, 랜딩 존 및 우선 순위가 높은 워크로드에 대한 의사 결정에 대해서도 알려야 합니다.
• 클라우드 플랫폼: 클라우드 거버넌스 팀은 거버넌스 방법론과 일치하여 각 환경에서 일관성을 보장하는 가드레일을 담당합니다. 클라우드 거버넌스 팀은 모든 환경의 모든 리소스에 대한 거버넌스를 담당합니다. 클라우드 거버넌스 팀은 예외 또는 관리 정책 변경이 필요할 수 있는 변경 내용에 대해 협의해야 합니다. 클라우드 거버넌스 팀은 워크로드 및 자산 채택 진행 상황도 알려야 합니다.
• 랜딩 존 및 클라우드 기반: 클라우드 플랫폼 팀은 채택을 지원하는 랜딩 존 및 플랫폼 유틸리티 개발을 담당합니다. 클라우드 자동화 팀은 이러한 랜딩 존 및 플랫폼 유틸리티의 개발 및 지속적인 지원을 자동화할 책임이 있습니다. 두 팀 모두 Ready 방법론을 사용하여 구현을 안내합니다. 두 팀 모두 워크로드 채택 진행 상황과 엔터프라이즈 또는 환경의 변경 내용을 알려야 합니다.
• 워크로드: 채택은 워크로드 수준에서 발생합니다. 클라우드 채택 팀은 Migrate 사용하고 방법론을 혁신하여 확장 가능한 프로세스를 설정하여 채택을 가속화합니다. 채택이 완료되면 워크로드의 소유권은 관리 방법론을 사용하여 운영 관리를 안내하는 클라우드 운영 팀으로 이전될 가능성이 높습니다. 두 팀 모두 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 제품이 포트폴리오 계층 구조지원하는 방법을 알아봅니다.