포트폴리오 계층 구조 이해 및 맞춤Understand and align the portfolio hierarchy

비즈니스 요구 사항은 종종 정보 기술을 통해 지원, 향상 또는 가속화 됩니다.Business needs are often supported, improved, or accelerated through information technology. 정의 된 비즈니스 가치를 제공 하는 기술의 컬렉션을 작업 이라고 합니다.A collection of technologies that delivers defined business value is called a workload. 해당 컬렉션에는 응용 프로그램, 서버, 가상 컴퓨터, 데이터, 장치 및 기타 유사한 그룹 자산이 포함 될 수 있습니다.That collection might include applications, servers or virtual machines, data, devices, and other similarly grouped assets.

일반적으로 비즈니스 관련자와 기술 리더가 각 워크 로드의 지속적인 지원에 대 한 책임을 공유 합니다.Typically, a business stakeholder and technical leader share accountability for the ongoing support of each workload. 작업 수명 주기의 일부 단계에서는 이러한 역할을 명확 하 게 명시 합니다.In some phases of the workload lifecycle, those roles are clearly stated. 작업 주기의 더 많은 작업 단계에서 이러한 역할은 공유 작업 관리 팀 또는 클라우드 운영 팀으로 전환 될 수 있습니다.In more operational phases of a workload's lifecycle, those roles might be transitioned to a shared operations management team or cloud operations team. 워크 로드 수가 늘어나면 역할 (명시 되거나 암시 됨)은 더 복잡 해지고 더 matrixed.As the number of workloads increases, the roles (stated or implied) become more complex and more matrixed.

대부분의 기업은 여러 작업을 사용 하 여 중요 한 비즈니스 기능을 제공 합니다.Most businesses rely on multiple workloads to deliver vital business functions. 작업, 자산 및 지원 요소 (프로젝트, 사람, 프로세스 및 투자)의 컬렉션을 포트폴리오 라고 합니다.The collection of workloads, assets, and supporting factors (projects, people, processes, and investments) is called a portfolio. 비즈니스, 개발 및 운영 직원의 행렬에는 작업 및 지원 서비스가 모두 함께 표시 되는 방식을 보여 주는 포트폴리오 계층이 필요 합니다.The matrix of business, development, and operations staff requires a portfolio hierarchy to show how the workloads and supporting services all fit together.

이 문서에서는 포트폴리오 계층 수준에 대 한 명확한 정의를 제공 합니다.This article provides clear definitions for the levels of the portfolio hierarchy. 이 문서에서는 각 계층의 적절 한 책임이 있는 여러 팀과 해당 수준에 대 한 기대를 제공 하기 위해 해당 팀에 대 한 최상의 지침의 원본을 맞춥니다.The article aligns various teams with the appropriate accountability in each layer, along with the source of the best guidance for that team to deliver on the expectations for that level. 이 문서 전체에서 계층의 각 수준을 범위 라고도 합니다.Throughout this article, each level of the hierarchy is also called a scope.

포트폴리오 계층 구조Portfolio hierarchy

워크로드Workloads

워크 로드와 지원 자산은 모든 포트폴리오의 핵심입니다.Workloads and their supporting assets are at the core of any portfolio. 아래 추가 범위 또는 계층은 이러한 워크 로드를 보는 방법과 잠재적 지원 팀의 매트릭스에 의해 영향을 받는 범위를 정의 합니다.The additional scopes or layers below define how those workloads are viewed and to what extent they're affected by the matrix of potential supporting teams.

작업 및 자산을 함께 보여 주는 클라우드의 워크 로드 이미지

용어는 달라질 수 있지만 모든 IT 솔루션에는 자산 및 워크 로드가 포함 됩니다.Although the terms can vary, all IT solutions include assets and workloads:

  • 자산: 작업 또는 솔루션을 지 원하는 최소 기술 함수 단위입니다.Asset: The smallest unit of technical function that supports a workload or solution.
  • 워크 로드: 비즈니스에 대 한 IT 지원의 가장 작은 단위입니다.Workload: The smallest unit of IT support for the business. 작업은 일반적인 비즈니스 목표 또는 공통 비즈니스 프로세스의 실행을 지 원하는 자산 (인프라, 응용 프로그램 및 데이터)의 컬렉션입니다.A workload is a collection of assets (infrastructure, applications, and data) that supports a common business goal or the execution of a common business process.

첫 번째 워크 로드를 배포 하는 경우 워크 로드 및 해당 자산은 정의 된 유일한 범위 일 수 있습니다.When you're deploying your first workload, the workload and its assets might be the only defined scope. 다른 계층은 더 많은 워크 로드가 배포 될 때 명시적으로 정의 될 수 있습니다.The other layers might be explicitly defined as more workloads are deployed.

IT 포트폴리오IT portfolio

회사에서 matrixed 접근 방식이 나 중앙화 된 접근 방식을 통해 워크 로드를 지 원하는 경우 해당 워크 로드를 지원 하기 위해 더 광범위 한 계층이 있을 수 있습니다When companies support workloads through matrixed approaches or centralized approaches, a broader hierarchy likely exists to support those workloads:

공용 및 사설 클라우드 플랫폼이 여러 개인 IT 포트폴리오 이미지

  • 랜딩 영역: 랜딩 영역에서는 하나 이상의 작업을 지 원하는 데 필요한 플랫폼 기반 에서 제공 되는 필수 기본 유틸리티 (또는 공유 배관)를 사용 하 여 작업을 제공 합니다.Landing zones: Landing zones provide workloads with the necessary foundational utilities (or shared plumbing) that are provided from a platform foundation that's required to support one or more workloads. 클라우드 도입 프레임 워크의 전체 준비 방법이 랜딩 영역에 중점을 둔 클라우드에서는 랜딩 영역이 매우 중요 합니다.Landing zones are so critical in the cloud that the entire Ready methodology of the Cloud Adoption Framework focuses on landing zones. 자세한 정의는 방문 영역 이란? 을 참조 하세요.For a more detailed definition, see What is a landing zone?
  • 기본 유틸리티: 이러한 공유 IT 서비스는 기술 및 비즈니스 포트폴리오 내에서 작업을 수행 하는 데 필요 합니다.Foundational utilities: These shared IT services are required for workloads to operate within the technology and business portfolio.
  • Platform foundation: 이 조직 구성에서는 기본 솔루션을 중앙 집중화 하 고 모든 방문 영역에 대해 이러한 컨트롤이 적용 되도록 합니다.Platform foundation: This organizational construct centralizes foundational solutions and helps ensure that those controls are enforced for all landing zones.
  • 클라우드 플랫폼: 전체 포트폴리오 를 지 원하는 전체 전략에 따라 고객은 여러 지역, 하이브리드 솔루션 또는 심지어 다중 클라우드 솔루션을 관리 하기 위해 플랫폼 기반을 배포 하는 여러 클라우드 플랫폼을 필요로 할 수 있습니다.Cloud platforms: Depending on the overall strategy for supporting the full portfolio, customers might need multiple cloud platforms with distinct deployments of the platform foundation to govern multiple regions, hybrid solutions, or even multicloud solutions.
  • 포트폴리오: 포트폴리오는 기술 렌즈를 통해 모든 클라우드 플랫폼에 걸친 작업, 자산 및 지원 리소스의 모음입니다.Portfolio: Through a technology lens, the portfolio is a collection of workloads, assets, and supporting resources that span all cloud platforms. 비즈니스 렌즈를 통해 포트폴리오는 비즈니스 결과를 구동 하는 기술 포트폴리오를 지원 하 고 관리 하는 프로젝트, 사람, 프로세스 및 투자의 컬렉션입니다.Through a business lens, the portfolio is the collection of projects, people, processes, and investments that support and manage the technology portfolio to drive business outcomes. 이러한 두 lenses는 포트폴리오 를 캡처합니다.Together, these two lenses capture the portfolio.

계층 구조 책임 및 지침Hierarchy accountability and guidance

책임이 있는 팀은 포트폴리오 계층의 각 계층을 관리 합니다.An accountable team manages each layer of the portfolio hierarchy. 다음 다이어그램에서는 책임이 있는 팀과 비즈니스 의사 결정, 기술 결정 및 기술 구현을 지원 하기 위한 지침 간의 매핑을 보여 줍니다.The following diagram shows the mapping between the accountable team and the guidance to support its business decisions, technical decisions, and technical implementation.

참고

다음 목록에서 설명 하는 팀은 가상 팀 또는 개인 일 수 있습니다.The teams mentioned in the following list might be virtual teams or individuals. 이 계층 구조에 대 한 일부 변형의 경우 책임 변형에서 나중에 설명 하는 것 처럼 책임이 있는 팀 중 일부를 축소할 수 있습니다.For some variants of this hierarchy, some of the accountable teams can be collapsed as described later in the accountability variants.

계층 구조에 정렬 된 책임

  • 포트폴리오: 클라우드 전략 팀 및 클라우드 센터 (CCoE)는 전략 및 계획 방법론을 사용 하 여 전체 포트폴리오에 영향을 주는 결정을 안내 합니다.Portfolio: The cloud strategy team and the cloud center of excellence (CCoE) use the Strategy and Plan methodologies to guide decisions that affect the overall portfolio. 클라우드 전략 팀은 클라우드 포트폴리오 계층의 엔터프라이즈 수준에 책임이 있습니다.The cloud strategy team is accountable for the enterprise level of the cloud portfolio hierarchy. 또한 클라우드 전략 팀은 환경, 방문 영역 및 우선 순위가 높은 워크 로드에 대 한 의사 결정을 받아야 합니다.The cloud strategy team should also be informed of decisions about the environment, landing zones, and high-priority workloads.
  • 클라우드 플랫폼: 클라우드 거 버 넌 스 팀은 각 환경에서 제어 방법론에 맞춰 일관성을 유지 하는 분야를 담당 합니다.Cloud platforms: The cloud governance team is accountable for the disciplines that ensure consistency across each environment in alignment with the Govern methodology. 클라우드 거 버 넌 스 팀은 모든 환경에 있는 모든 리소스의 관리 책임을 담당 합니다.The cloud governance team is accountable for governance of all resources in all environments. 클라우드 거 버 넌 스 팀은 예외를 요구 하거나 정책을 관리 하는 변경 사항에 대해 문의 해야 합니다.The cloud governance team should be consulted on changes that might require an exception or change to governing policies. 또한 클라우드 거 버 넌 스 팀은 워크 로드 및 자산 채택을 통해 진행 상황을 알려 주어 야 합니다.The cloud governance team should also be informed of progress with workload and asset adoption.
  • 랜딩 영역 및 cloud foundation: 클라우드 플랫폼 팀은 도입을 지 원하는 랜딩 영역 및 플랫폼 유틸리티를 개발 하는 데 책임이 있습니다.Landing zones and cloud foundation: The cloud platform team is accountable for developing the landing zones and platform utilities that support adoption. 클라우드 자동화 팀은 이러한 방문 영역 및 플랫폼 유틸리티의 개발 및 지속적인 지원을 자동화 하는 데 책임이 있습니다.The cloud automation team is accountable for automating the development of, and ongoing support for, those landing zones and platform utilities. 두 팀 모두 준비 된 방법을 사용 하 여 구현을 안내 합니다.Both teams use the Ready methodology to guide implementation. 두 팀 모두 작업을 채택 하 고 엔터프라이즈 또는 환경에 대 한 변경 내용을 처리 해야 합니다.Both teams should be informed of progress with workload adoption and any changes to the enterprise or environment.
  • 워크 로드: 작업 수준에서 도입이 발생 합니다.Workloads: Adoption happens at the workload level. 클라우드 채택 팀은 마이그레이션 및 혁신 방법론을 사용 하 여 도입을 가속화 하는 확장 가능한 프로세스를 설정 합니다.Cloud adoption teams use the Migrate and Innovate methodologies to establish scalable processes to accelerate adoption. 채택이 완료 되 면 작업의 소유권이 관리 방법론을 사용 하 여 작업 관리를 안내 하는 클라우드 운영 팀으로 전송 될 가능성이 높습니다.After adoption is complete, the ownership of workloads is likely transferred to a cloud operations team that uses the Manage methodology to guide operations management. 두 팀 모두 Microsoft Azure Well-Architected 프레임 워크를 사용 하 여 지원 되는 워크 로드에 영향을 주는 세부적인 아키텍처 결정을 내려야 합니다.Both teams should be comfortable using the Microsoft Azure Well-Architected Framework to make detailed architectural decisions that affect the workloads they support. 두 팀 모두 랜딩 영역 및 환경에 대 한 변경 내용을 알려야 합니다.Both teams should be informed of changes to landing zones and environments. 두 팀이 모두 랜딩 영역 기능에 기여할 수 있습니다.Both teams might occasionally contribute to landing zone features.
  • 자산: 자산은 일반적으로 클라우드 운영 팀의 책임입니다.Assets: Assets are typically the responsibility of the cloud operations team. 이 팀은 관리 방법의 관리 기준을 사용 하 여 operations management 결정을 안내 합니다.That team uses the management baseline in the Manage methodology to guide operations management decisions. 또한 Azure Advisor 및 Azure Well-Architected 프레임 워크를 사용 하 여 작업 요구 사항에 대 한 자세한 리소스 및 아키텍처 변경을 수행 해야 합니다.It should also use Azure Advisor and the Azure Well-Architected Framework to make detailed resource and architectural changes that are required to deliver on operations requirements.

책임 변형Accountability variants

  • 단일 환경: 기업에는 하나의 환경만 필요한 경우 일반적으로 CCoE가 필요 하지 않습니다.Single environment: When an enterprise needs only one environment, a CCoE is typically not required.
  • 단일 방문 영역: 환경에 단일 방문 영역만 있는 경우 거 버 넌 스 및 플랫폼 기능이 하나의 팀으로 결합 될 수 있습니다.Single landing zone: If an environment has only a single landing zone, the governance and platform capabilities can likely be combined into one team.
  • 단일 워크 로드: 일부 회사에서는 단일 방문 영역 및 단일 환경에서 하나의 워크 로드 또는 소수의 워크 로드만 필요 합니다.Single workload: Some businesses need only one workload, or few workloads, in a single landing zone and a single environment. 이러한 경우에는 거 버 넌 스, 플랫폼 및 운영 팀 간에 업무를 분리 해야 할 필요가 거의 없습니다.In those cases, there's little need for a separation of duties between governance, platform, and operations teams.

일반적인 워크 로드 및 책임 예Common workload and accountability examples

다음 예에서는 포트폴리오 계층을 보여 줍니다.The following examples illustrate the portfolio hierarchy.

COTS 워크 로드COTS workloads

일반적으로 기업에서는 비즈니스 프로세스에 대 한 COTS (상용) 소프트웨어 솔루션을 선호 합니다.Traditionally, enterprises have favored commercial-off-the-shelf (COTS) software solutions to power business processes. 이러한 솔루션은 설치 및 구성 된 후 운영 됩니다.These solutions are installed, configured, and then operated. 구성 후에는 솔루션 아키텍처가 거의 변경 되지 않습니다.There is little change to the solutions architecture after configuration.

이러한 시나리오에서 COTS 솔루션의 모든 클라우드 채택은 클라우드 운영 팀으로 전환 하 여 종료 됩니다.In these scenarios, any cloud adoption of COTS solutions ends with a transition to a cloud operations team. 그런 다음 클라우드 운영 팀이 해당 소프트웨어의 기술 소유자가 되 고 구성, 비용, 패치 주기 및 기타 운영 요구를 관리 하는 책임을 가정 합니다.The cloud operations team then becomes the technical owner for that software and assumes accountability for managing configuration, cost, patching cycles, and other operational needs.

이러한 작업에는 회계 패키지, 물류 소프트웨어 또는 산업별 솔루션이 포함 됩니다.These workloads include accounting packages, logistics software, or industry-specific solutions. Microsoft 용어로 이러한 패키지의 공급 업체를 Isv (독립 소프트웨어 공급 업체) 라고 합니다.In Microsoft terminology, the vendors of these packages are called independent software vendors (ISVs). 대부분의 Isv는 구독에 소프트웨어 패키지의 인스턴스를 배포 하 고 유지 관리 하는 서비스를 제공 합니다.Many ISVs offer a service to deploy and maintain an instance of their software package in your subscriptions. 또한 클라우드 호스팅 환경에서 실행 되는 소프트웨어 패키지 버전을 제공 하 여 작업에 대 한 PaaS (platform as a service)를 제공할 수 있습니다.They might also offer a version of the software package that runs in their own cloud-hosted environment, providing a platform as a service (PaaS) alternative to the workload.

PaaS 제품을 제외 하 고, 클라우드 운영 팀은 해당 워크 로드에 대 한 기본 운영 규정 준수 요구 사항을 확인 해야 합니다.With the exception of PaaS offerings, cloud operations teams are responsible for ensuring basic operational compliance requirements for those workloads. 클라우드 운영 팀은 클라우드 거 버 넌 스 팀과 협력 하 여 비용, 성능 및 기타 아키텍처 핵심 요소를 맞춰야 합니다.A cloud operations team should work with the cloud governance team to align cost, performance, and other architecture pillars.

활성 수정 버전으로 개발In development with active revisions

COTS 솔루션 또는 PaaS 제품이 비즈니스 요구에 맞지 않거나 솔루션이 없는 경우 기업은 사용자 지정 개발 된 워크 로드를 빌드합니다.When a COTS solution or PaaS offering isn't aligned to the business need, or no solution exists, enterprises build custom-developed workloads. 일반적으로 적은 비율의 IT 포트폴리오는이 워크 로드 방법을 사용 합니다.Typically, a small percentage of the IT portfolio uses this workload approach. 그러나 이러한 워크 로드는 매우 높은 비율의 비즈니스 결과, 특히 새 수익 스트림과 관련 된 결과에 대 한 기여 비율을 구동 하는 경향이 있습니다.But these workloads tend to drive a disproportionately high percentage of IT's contribution to business outcomes, especially outcomes related to new revenue streams. 이러한 워크 로드는 새로운 혁신 아이디어에 잘 매핑되도록 합니다.These workloads tend to map well to new innovation ideas.

Agile 방법론 및 DevOps 방법으로 시작 되는 다양 한 움직임을 고려 하 여 이러한 워크 로드는 기존 IT 관리에 대 한 비즈니스/DevOps 정렬을 선호 합니다.Given various movements that are rooted in agile methodologies and DevOps practices, these workloads favor a business/DevOps alignment over traditional IT management. 이러한 워크 로드의 경우 클라우드 운영 팀에 몇 년간 전달 하지 못할 수 있습니다.For these workloads, there might not be a handoff to the cloud operations team for several years. 이러한 경우 개발 팀은 작업의 기술적 소유자 역할을 합니다.In those cases, the development team serves as the technical owner of the workload.

광범위 한 시간 및 관련 된 자본 제약 조건으로 인해 사용자 지정 개발 옵션은 종종 높은 가치의 기회로 제한 됩니다.Due to extensive time and associated capital constraints, custom development options are often limited to high-value opportunities. 일반적인 예로는 응용 프로그램 혁신, 심층 데이터 분석 또는 중요 업무용 비즈니스 기능이 있습니다.Typical examples include application innovations, deep data analysis, or mission-critical business functions.

중단/수정 또는 일몰 개발Break/fix or sunset development

사용자 지정 개발 된 워크 로드가 최대 완성에 도달 하면 개발 팀이 다른 프로젝트에 다시 할당 될 수 있습니다.After a custom-developed workload reaches peak maturity, the development team might be reassigned to other projects. 이러한 경우 기술 소유권은 일반적으로 클라우드 운영 팀으로 전환 됩니다.In these cases, technical ownership typically transitions to a cloud operations team. 작은 수정이 필요한 경우 운영 팀에서 개발자에 게 오류를 해결 하도록 등록 합니다.When there's a need for small fixes, the operations team will enlist developers to resolve the error.

경우에 따라 개발 팀이 현재 작업을 대체할 프로젝트로 이동 합니다.In some cases, the development team moves to a project that will eventually replace the current workload. 또는 워크 로드에서 지원 되는 비즈니스 기회가 단계적으로 진행 되 고 있으므로 팀이 진행 될 수도 있습니다. 다음은 클라우드 운영 팀이 더 이상 필요 하지 않을 때까지 기술 소유자 역할을 하는 일몰 시나리오의 예입니다.Alternatively, the team might move on because the business opportunity supported by the workload is being phased out. These are examples of sunset scenarios, where the cloud operations team serves as the technical owner until the workload is no longer needed.

두 시나리오에서 클라우드 운영 팀은 일반적으로 장기적인 기술 소유자 및 의사 결정자 역할을 합니다.In both scenarios, the cloud operations team typically serves as the long-term technical owner and decision maker. 운영 변경에 상당한 아키텍처 변화가 필요한 경우 해당 팀은 응용 프로그램 개발자를 등록할 가능성이 높습니다.That team will likely enlist application developers when operational changes require significant architectural changes.

중요 업무용 워크로드Mission-critical workloads

모든 회사에서 몇 가지 작업을 수행 하는 데는 비즈니스에 너무 중요 한 작업이 있습니다.In every company, a few workloads are too important to the business for them to fail. 이러한 업무에 중요 한 워크 로드를 사용 하는 경우 일반적으로 다양 한 수준의 책임이 있는 운영 및 개발 소유자가 있습니다.With these mission-critical workloads, there are usually operations and development owners with various levels of responsibility. 이러한 팀은 프로덕션 솔루션의 중단을 최소화 하기 위해 운영 변경 및 아키텍처 변경 사항을 맞춰야 합니다.Those teams should align operational changes and architectural changes to minimize disruptions to the production solution.

이러한 시나리오에서는 의무를 분리 하는 데 중점을 두어야 합니다.These scenarios require a strong focus on separation of duties. 업무 분리를 위해 운영 팀은 일반적으로 프로덕션 환경에서 일상적인 운영 변화에 대 한 책임을 보유 하 게 됩니다.To achieve separation of duties, the operations team will generally hold accountability for day-to-day operational changes in the production environment. 이러한 작업 변경에 아키텍처 변경이 필요한 경우 운영 팀이 프로덕션에 변경 내용을 적용 하기 전에 비프로덕션 환경에서 개발 또는 채택 팀이이를 완료 합니다.When those operational changes require an architectural change, they'll be completed by the development or adoption team in a nonproduction environment, before the operations team applies the changes to production.

의무를 분리 해야 하는 업무상 중요 한 워크 로드의 예로는 SAP, Oracle 또는 다른 ERP (엔터프라이즈 리소스 계획) 솔루션과 같은 작업을 예로 들 수가 있습니다.Examples of mission-critical workloads with a required separation of duties include workloads like SAP, Oracle, or other enterprise resource planning (ERP) solutions, which span multiple business units in the company.

전략 포트폴리오 맞춤Strategy portfolio alignment

클라우드 도입 활동의 전략적 목표를 이해 하 고 해당 변환을 지원 하도록 포트폴리오를 정렬 하는 것이 중요 합니다.It's important to understand the strategic objectives of the cloud adoption effort and align the portfolio to support that transformation. 몇 가지 일반적인 유형의 전략적 포트폴리오 맞춤 도움말은 포트폴리오 계층 구조를 구성 합니다.A few common types of strategic portfolio alignment help shape the structure of the portfolio hierarchy. 다음 섹션에서는 포트폴리오 계층에 대 한 포트폴리오 맞춤 및 영향의 예를 제공 합니다.The following sections provide examples of the portfolio alignment and impact on the portfolio hierarchy.

혁신 또는 개발-led 포트폴리오Innovation or development-led portfolio

특히 빠르게 증가 하는 설정 된 시작과 같은 일부 회사에서는 사용자 지정 개발 프로젝트의 백분율이 더 높습니다.Some companies, especially fast-growing established startups, have a higher-than-average percentage of custom development projects. 개발-많은 포트폴리오에는 환경, 방문 영역 및 워크 로드가 종종 압축 되므로 특정 워크 로드에 대 한 특정 환경 (프로덕션 또는 비프로덕션)이 있을 수 있습니다.In development-heavy portfolios, the environment, landing zone, and workloads are often compressed, so there might be specific environments (either production or nonproduction) for specific workloads. 이로 인해 환경, 방문 영역 및 워크 로드 간의 1:1 비율이 발생 합니다.This results in a 1:1 ratio between environment, landing zone, and workload.

환경에서 사용자 지정 솔루션을 호스트 하기 때문에 DevOps 파이프라인과 응용 프로그램 수준 보고 기능에서 작업 및 거 버 넌 스 기능에 대 한 필요성을 대체할 수 있습니다.Because the environment hosts custom solutions, the DevOps pipeline and application-level reporting might replace the need for operations and governance functions. 이러한 고객의 경우 운영, 거 버 넌 스 또는 기타 지원 역할에 대 한 초점이 감소할 가능성이 높습니다.For those customers, a reduced focus on operations, governance, or other supporting roles is likely. 클라우드 도입 및 클라우드 자동화 팀의 책임을 더욱 강력 하 게 강조 하는 것도 일반적입니다.A stronger emphasis on the responsibilities of the cloud adoption and cloud automation teams is also typical.

포트폴리오 맞춤: IT 포트폴리오는 작업 및 워크 로드 소유자에 게 중요 한 아키텍처 결정을 내리는 데 집중할 수 있습니다.Portfolio alignment: The IT portfolio will likely focus on workloads and workload owners to drive critical architecture decisions. 이러한 팀은 도입 및 운영 활동 중에 Azure Well-Architected Framework 지침에서 더 많은 가치를 찾을 수 있습니다.Those teams are likely to find more value in the Azure Well-Architected Framework guidance during adoption and operations activities.

경계 정의: 논리 경계는 엔터프라이즈 수준 에서도 프로덕션 및 비프로덕션 환경 조각화에 초점을 맞출 수 있습니다.Boundary definitions: The logical boundaries, even at an enterprise level, will likely focus on production and nonproduction environment segmentation. 또한 회사 소프트웨어 포트폴리오의 제품 간 조각화가 확실 하지 않을 수 있습니다.There might also be clear segmentation between products in the company's software portfolio. 때로는 개발과 호스팅된 고객 인스턴스 사이에 차이가 있을 수도 있습니다.At times, there might also be segmentation between development and hosted customer instances.

운영-led 포트폴리오Operations-led portfolio

IT 운영 팀이 더 많은 다국적 기업 조직은 일반적으로 개발 보다 거 버 넌 스 및 운영에 더 강력 하 게 집중 합니다.Multinational enterprise organizations with more established IT operations teams typically have a stronger focus on governance and operations than development. 이러한 조직에서는 일반적으로 클라우드 운영 팀 내에서 기술 소유자가 유지 관리 하는 COTS 또는 중단/수정 범주에 맞춰 더 높은 비율의 워크 로드를 수행 합니다.In these organizations, a higher percentage of workloads typically align to the COTS or break/fix categories, maintained by technical owners within the cloud operations team.

포트폴리오 맞춤: IT 포트폴리오는 워크 로드를 기준으로 정렬 되지만 이러한 워크 로드는 운영 유닛이 나 비즈니스 단위에 맞춰 정렬 됩니다.Portfolio alignment: The IT portfolio will be workload aligned, but those workloads are then aligned to operating units or business units. 또한 자금 모델, 산업 또는 기타 비즈니스 조각화 요구 사항에 대 한 조직이 있을 수 있습니다.There might also be organization around funding models, industry, or other business segmentation requirements.

경계 정의: 랜딩 영역에서는 응용 프로그램을 응용 프로그램 archetype로 그룹화 하 여 유사한 작업을 유사한 구분으로 유지할 수 있습니다.Boundary definitions: Landing zones will likely group applications into application archetypes to keep similar operations in a similar segmentation. 환경에서 데이터 센터, 국가, 클라우드 공급자 지역 또는 기타 운영 조직 표준과 같은 물리적 구문을 참조할 가능성이 높습니다.Environments will likely refer to physical constructs like datacenter, nation, cloud-provider region, or other operational organization standards.

마이그레이션-led 포트폴리오Migration-led portfolio

작업-led 포트폴리오와 마찬가지로, 마이그레이션을 통해 주로 빌드되는 포트폴리오는 기존 자산을 마이그레이션하기 위한 특정 비즈니스 드라이버를 기반으로 합니다.Similar to operations-led portfolios, a portfolio that is largely built through migration will be based on specific business drivers that led to the migration of existing assets. 일반적으로 데이터 센터는 해당 드라이버에서 가장 큰 요소입니다.Typically, the datacenter is the biggest factor in those drivers.

포트폴리오 맞춤: IT 포트폴리오는 워크 로드가 맞춰져 있을 수 있지만 자산이 정렬 될 가능성이 높습니다.Portfolio alignment: The IT portfolio might be workload aligned, but it's more likely asset aligned. 회사의 기록에서 IT 작업으로 전환 하는 경우 많은 활성 사용 자산이 투자 작업에 쉽게 매핑되지 않을 수 있습니다.If transitions to IT operations have happened in the company's history, many active-use assets might not be easily mapped to a funded workload. 이러한 경우 대부분의 자산에는 마이그레이션 프로세스가 지연 될 때까지 정의 된 워크 로드 또는 명확한 워크 로드 소유자가 없을 수 있습니다.In these cases, many assets might not have a defined workload or clear workload owner until late in the migration process.

경계 정의: 랜딩 영역은 응용 프로그램을 온-프레미스 조각화를 반영 하는 경계로 그룹화 할 수 있습니다.Boundary definitions: Landing zones will likely group applications into boundaries that reflect on-premises segmentation. 모범 사례는 아니지만 환경이 네트워크 조각화 방식을 나타내는 온-프레미스 데이터 센터 이름 및 방문 영역과 일치 하는 경우가 많습니다.Though not a best practice, environments often match the on-premises datacenter name and landing zones that represent network segmentation practices. 작업-led 포트폴리오와 더 밀접 하 게 일치 하는 구분을 준수 하는 것이 더 좋습니다.It's a better practice to adhere to segmentation that more closely aligns with an operations-led portfolio.

거 버 넌 스-led 포트폴리오Governance-led portfolio

거 버 넌 스 팀에 대 한 맞춤은 가능한 한 빨리 발생 해야 합니다.Alignment to governance teams should happen as early as possible. 거 버 넌 스 관행 및 클라우드 거 버 넌 스 도구를 통해 포트폴리오 및 환경 경계는 혁신, 운영 및 마이그레이션 활동의 요구에 가장 적합 한 균형을 맞출 수 있습니다.Through governance practices and cloud governance tooling, portfolios and environmental boundaries can best balance the needs of innovation, operations, and migration efforts.

포트폴리오 맞춤: 거 버 넌 스 포트폴리오는 작업, 운영 소유자, 데이터 분류 및 운영 상의 중요도와 같은 혁신 및 운영 세부 정보를 캡처하는 데이터 요소를 포함 하는 경향이 있습니다.Portfolio alignment: Governance-led portfolios tend to include data points that capture innovation and operations details, such as workload, operations owner, data classification, and operational criticality. 이러한 데이터 요소는 포트폴리오의 잘 둥근 뷰를 만듭니다.These data points create a well-rounded view of the portfolio.

경계 정의: 거 버 넌 스 포트폴리오의 경계는 비즈니스 단위 및 개발 환경에 대 한 조건에 매핑되는 관리 그룹 기반 계층을 사용 하면서 혁신 보다 작업을 선호 하는 경향이 있습니다.Boundary definitions: Boundaries in a governance-led portfolio tend to favor operations over innovation, while using a management-group-driven hierarchy that maps to criteria for business units and development environments. 계층의 각 수준에서 클라우드 거 버 넌 스 경계는 개발 및 독창적인 유연성을 허용 하기 위해 서로 다른 수준의 정책 적용을 수행할 수 있습니다.At each level of the hierarchy, a cloud governance boundary can have different degrees of policy enforcement to allow for development and creative flexibility. 동시에, 업무와 일관적인 작업의 분리를 위해 프로덕션 구독에 프로덕션 등급 요구 사항을 적용할 수 있습니다.At the same time, production-grade requirements can be applied to production subscriptions to ensure separation of duties and consistent operations.