Pochopení a zarovnání hierarchie portfoliaUnderstand and align the portfolio hierarchy

Obchodní potřeby se často podporují, zdokonalují nebo urychlují prostřednictvím informačních technologií.Business needs are often supported, improved, or accelerated through information technology. Kolekce technologií, které poskytují definovanou obchodní hodnotu, se nazývá zatížení.A collection of technologies that delivers defined business value is called a workload. Tato kolekce může zahrnovat aplikace, servery, virtuální počítače, data, zařízení a další podobně seskupené prostředky.That collection might include applications, servers or virtual machines, data, devices, and other similarly grouped assets.

Podniková strana a technická vedoucí pracovníky mají zpravidla odpovědnost za průběžnou podporu jednotlivých úloh.Typically, a business stakeholder and technical leader share accountability for the ongoing support of each workload. V některých fázích životního cyklu úloh jsou tyto role jasně uvedené.In some phases of the workload lifecycle, those roles are clearly stated. V produkčních fázích životního cyklu pracovního cyklu můžou být tyto role převedené na tým pro správu sdíleného provozu nebo cloudového týmu provozu.In more operational phases of a workload's lifecycle, those roles might be transitioned to a shared operations management team or cloud operations team. Jak se zvyšuje počet úloh, role (uvedené nebo odvozené) se stanou složitější a mají větší matice.As the number of workloads increases, the roles (stated or implied) become more complex and more matrixed.

Většina firem spoléhá na více úloh na poskytování důležitých obchodních funkcí.Most businesses rely on multiple workloads to deliver vital business functions. Shromažďování úloh, prostředků a podpůrných faktorů (projektů, osob, procesů a investic) se nazývá portfolio.The collection of workloads, assets, and supporting factors (projects, people, processes, and investments) is called a portfolio. Matice zaměstnanců pro firmy, vývoj a provoz vyžaduje hierarchii portfolia, která ukazuje, jak se všechny úlohy a podpůrné služby vejdou dohromady.The matrix of business, development, and operations staff requires a portfolio hierarchy to show how the workloads and supporting services all fit together.

Tento článek poskytuje jasné definice pro úrovně v hierarchii portfolia.This article provides clear definitions for the levels of the portfolio hierarchy. Článek zarovnává různé týmy s odpovídající zodpovědností v každé vrstvě spolu se zdrojem nejlepších pokynů pro daný tým k zajištění očekávání pro danou úroveň.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. V celém tomto článku se pro každou úroveň hierarchie označuje také obor.Throughout this article, each level of the hierarchy is also called a scope.

Hierarchie portfoliaPortfolio hierarchy

ÚlohyWorkloads

Úlohy a jejich podpůrné prostředky jsou v jádru každého portfolia.Workloads and their supporting assets are at the core of any portfolio. Níže uvedené další obory nebo vrstvy definují, jak se tyto úlohy zobrazují a v jakém rozsahu jsou ovlivněny matricí potenciálních pomocných týmů.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.

Obrázek úlohy v cloudu, zobrazení úloh a prostředků dohromady

I když se tyto výrazy můžou lišit, všechna IT řešení zahrnují prostředky a úlohy:Although the terms can vary, all IT solutions include assets and workloads:

  • Prostředek: Nejmenší jednotka technické funkce, která podporuje úlohu nebo řešení.Asset: The smallest unit of technical function that supports a workload or solution.
  • Pracovní zatížení: Nejmenší jednotka podporovaná pro firmu.Workload: The smallest unit of IT support for the business. Zatížení je kolekce prostředků (infrastruktury, aplikací a dat), která podporuje běžný obchodní cíl nebo provádění běžného obchodního procesu.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.

Při nasazení první úlohy může být zatížení a jeho prostředky jediným definovaným oborem.When you're deploying your first workload, the workload and its assets might be the only defined scope. Ostatní vrstvy můžou být explicitně definované, protože se nasazují další úlohy.The other layers might be explicitly defined as more workloads are deployed.

Portfolio ITIT portfolio

Když společnosti podporují úlohy prostřednictvím maticových přístupů nebo centralizovaných přístupů, k podpoře těchto úloh nejspíš existuje širší hierarchie:When companies support workloads through matrixed approaches or centralized approaches, a broader hierarchy likely exists to support those workloads:

Obrázek portfolia IT s několika veřejnými a privátními cloudy

  • Cílové zóny: Zóny pro vykládku poskytují úlohy s potřebnými základními nástroji (nebo sdílenými domovními instalacemi), které jsou k dispozici od základu platformy , který je vyžadován pro podporu jedné nebo více úloh.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. Zóny pro vykládku jsou v cloudu tak kritické, že se v cílové zóně zaměřuje celá metodika rozhraní pro přijetí do cloudu.Landing zones are so critical in the cloud that the entire Ready methodology of the Cloud Adoption Framework focuses on landing zones. Podrobnější definici najdete v tématu co je cílová zóna? .For a more detailed definition, see What is a landing zone?
  • Základní nástroje: Tyto služby sdíleného IT jsou potřebné k tomu, aby úlohy fungovaly v rámci technologických a obchodních portfolií.Foundational utilities: These shared IT services are required for workloads to operate within the technology and business portfolio.
  • Platform Foundation: Tato organizační konstrukce centralizovat základní řešení a pomáhá zajistit, aby se tyto ovládací prvky vynutily pro všechny zóny pro vykládku.Platform foundation: This organizational construct centralizes foundational solutions and helps ensure that those controls are enforced for all landing zones.
  • Cloudové platformy: V závislosti na celkové strategii podpory celého portfolia můžou zákazníci potřebovat více cloudových platforem s různými nasazeními platformy Platform, aby bylo možné řídit více oblastí, hybridních řešení nebo dokonce i řešení s více cloudy.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: V rámci technologického objektivu je portfolio kolekce úloh, prostředků a podpůrných prostředků, které zahrnují všechny cloudové platformy.Portfolio: Through a technology lens, the portfolio is a collection of workloads, assets, and supporting resources that span all cloud platforms. Portfolio je prostřednictvím obchodního objektivu kolekce projektů, osob, procesů a investic, které podporují a spravují portfolio technologie, aby bylo možné řídit obchodní výsledky.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. Spolu tato dvě rozptylová skla zachytí portfolio.Together, these two lenses capture the portfolio.

Zodpovědnost a doprovodné materiály k hierarchiiHierarchy accountability and guidance

Tým s účtem spravuje každou vrstvu hierarchie portfolia.An accountable team manages each layer of the portfolio hierarchy. Následující diagram znázorňuje mapování mezi týmem s účtem a pokyny pro podporu jeho obchodních rozhodnutí, technických rozhodnutí a technické implementace.The following diagram shows the mapping between the accountable team and the guidance to support its business decisions, technical decisions, and technical implementation.

Poznámka

Týmy, které jsou uvedené v následujícím seznamu, můžou být virtuálními týmy nebo jednotlivci.The teams mentioned in the following list might be virtual teams or individuals. Pro některé varianty této hierarchie je možné, že některé týmy s účty mohou být sbaleny, jak je popsáno dále v tématu varianty zodpovědnosti.For some variants of this hierarchy, some of the accountable teams can be collapsed as described later in the accountability variants.

Zodpovědnosti zarovnané na hierarchii

  • Portfolio: Tým strategie cloudu a cloudové centrum excelence (CCoE) využívají strategii a naplánují metodologie pro rozhodování, která mají vliv na celkové portfolio.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. Tým cloudové strategie je účet pro podnikovou úroveň hierarchie portfolia cloudu.The cloud strategy team is accountable for the enterprise level of the cloud portfolio hierarchy. Tým cloudové strategie by měl také informovat o rozhodnutích týkajících se prostředí, cílových zón a úloh s vysokou prioritou.The cloud strategy team should also be informed of decisions about the environment, landing zones, and high-priority workloads.
  • Cloudové platformy: Tým zásad správného řízení cloudu je platný pro disciplíny, které zajišťují konzistenci napříč jednotlivými prostředími v rámci sbližování s metodologií řízení.Cloud platforms: The cloud governance team is accountable for the disciplines that ensure consistency across each environment in alignment with the Govern methodology. Tým zásad správného řízení cloudu je účet pro řízení všech prostředků ve všech prostředích.The cloud governance team is accountable for governance of all resources in all environments. Tým zásad správného řízení cloudu by se měl obrátit na změny, které by mohly vyžadovat výjimku, nebo změnit zásady řízení.The cloud governance team should be consulted on changes that might require an exception or change to governing policies. Tým zásad správného řízení cloudu by měl také informovat o pokroku v průběhu plnění úloh a prostředků.The cloud governance team should also be informed of progress with workload and asset adoption.
  • Zóny pro vykládku a Cloud Foundation: Tým cloudové platformy je vydaný pro vývoj zón pro vykládku a nástrojů platforem, které podporují přijetí.Landing zones and cloud foundation: The cloud platform team is accountable for developing the landing zones and platform utilities that support adoption. Tým služby Cloud Automation pro automatizaci vývoje a průběžné podpory pro tyto zóny pro vykládku a nástroje platformy.The cloud automation team is accountable for automating the development of, and ongoing support for, those landing zones and platform utilities. Oba týmy používají pro implementaci Průvodce připravenou metodologií.Both teams use the Ready methodology to guide implementation. Oba týmy by se měly informovat o pokroku při přijímání úloh a všech změnách v podniku nebo prostředí.Both teams should be informed of progress with workload adoption and any changes to the enterprise or environment.
  • Úlohy: K přijetí dochází na úrovni zatížení.Workloads: Adoption happens at the workload level. Týmy pro přijetí cloudu využívají metodologii migrace a inovace k navázání škálovatelných procesů pro urychlení přijetí.Cloud adoption teams use the Migrate and Innovate methodologies to establish scalable processes to accelerate adoption. Po dokončení přijetí se vlastnictví zatížení bude nejspíš přenést do cloudového týmu, který používá metodologii správy operací.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. Oba týmy by měly být příjemné pomocí Microsoft Azure Well-Architected Framework, aby mohli provádět podrobná rozhodnutí o architektuře, která mají vliv na úlohy, které podporují.Both teams should be comfortable using the Microsoft Azure Well-Architected Framework to make detailed architectural decisions that affect the workloads they support. Oba týmy by měly být informovány o změnách v zónách a prostředích pro vykládku.Both teams should be informed of changes to landing zones and environments. Oba týmy můžou příležitostně přispívat k funkcím cílové zóny.Both teams might occasionally contribute to landing zone features.
  • Prostředky: Prostředky jsou obvykle zodpovědností týmu cloudových operací.Assets: Assets are typically the responsibility of the cloud operations team. Tento tým používá standardní hodnoty správy v metodologii správy pro účely rozhodování o správě operací.That team uses the management baseline in the Manage methodology to guide operations management decisions. Měl by také používat Azure Advisor a Azure Well-Architected Framework k zajištění podrobných změn prostředků a architektury, které jsou nutné k zajištění požadavků na operace.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.

Varianty odpovědnostiAccountability variants

  • Jedno prostředí: Když podnik potřebuje jenom jedno prostředí, CCoE se obvykle nevyžaduje.Single environment: When an enterprise needs only one environment, a CCoE is typically not required.
  • Zóna s jednou cílovou oblastí: Pokud má prostředí jenom jednu cílovou zónu, možnosti zásad správného řízení a platformy se pravděpodobně zkombinují do jednoho týmu.Single landing zone: If an environment has only a single landing zone, the governance and platform capabilities can likely be combined into one team.
  • Jedno zatížení: Některé firmy potřebují jenom jednu úlohu nebo několik úloh v jedné cílové zóně a jednom prostředí.Single workload: Some businesses need only one workload, or few workloads, in a single landing zone and a single environment. V těchto případech je potřeba oddělení povinností mezi týmy pro řízení, platformy a provozem.In those cases, there's little need for a separation of duties between governance, platform, and operations teams.

Běžné úlohy a příklady zodpovědnostiCommon workload and accountability examples

Následující příklady ilustrují hierarchii portfolia.The following examples illustrate the portfolio hierarchy.

COTS úlohyCOTS workloads

Podniky v tradičním průmyslu mají v rámci pracovních procesů k dispozici řešení pro prodej mimo polici (COTS).Traditionally, enterprises have favored commercial-off-the-shelf (COTS) software solutions to power business processes. Tato řešení jsou nainstalovaná, nakonfigurovaná a potom provozovaná.These solutions are installed, configured, and then operated. Po konfiguraci se Architektura řešení trochu nemění.There is little change to the solutions architecture after configuration.

V těchto scénářích se všechna cloudová přijetí řešení COTS ukončí s přechodem na tým cloudových operací.In these scenarios, any cloud adoption of COTS solutions ends with a transition to a cloud operations team. Tým cloudových operací se pak od tohoto softwaru stal technickým vlastníkem a předpokládá zodpovědnost za správu konfigurace, nákladů, cyklů oprav a dalších provozních potřeb.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.

Tyto úlohy zahrnují účetní balíčky, logistický software nebo řešení specifická pro konkrétní odvětví.These workloads include accounting packages, logistics software, or industry-specific solutions. V terminologii Microsoftu se dodavatelé těchto balíčků nazývají nezávislí výrobci softwaru (ISV).In Microsoft terminology, the vendors of these packages are called independent software vendors (ISVs). Mnoho prodejců softwaru nabízí službu pro nasazení a údržbu instance svého softwarového balíčku ve vašich předplatných.Many ISVs offer a service to deploy and maintain an instance of their software package in your subscriptions. Můžou také nabízet verzi softwarového balíčku, který běží ve vlastním prostředí hostovaném v cloudu, a nabízí alternativu k zatížení platformy jako služby (PaaS).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.

S výjimkou nabídek PaaS jsou týmy cloudových operací zodpovědné za zajištění základních požadavků na provozní dodržování předpisů pro tyto úlohy.With the exception of PaaS offerings, cloud operations teams are responsible for ensuring basic operational compliance requirements for those workloads. Tým cloudových operací by měl spolupracovat s týmem cloudového řízení, aby mohl zarovnávat náklady, výkon a další pilíře architektury.A cloud operations team should work with the cloud governance team to align cost, performance, and other architecture pillars.

Ve vývoji s aktivními revizemiIn development with active revisions

Když se COTS řešení nebo nabídka PaaS nerovná potřebám podniku nebo žádné řešení neexistuje, podniky sestavují vlastní úlohy vyvinuté v podnicích.When a COTS solution or PaaS offering isn't aligned to the business need, or no solution exists, enterprises build custom-developed workloads. Tento přístup k pracovním postupům obvykle používá malé procento portfolia IT.Typically, a small percentage of the IT portfolio uses this workload approach. Ale tyto úlohy mají za následek neúměrné vysoké procento příspěvku k obchodním výsledkům, zejména výsledky týkající se nových toků příjmů.But these workloads tend to drive a disproportionately high percentage of IT's contribution to business outcomes, especially outcomes related to new revenue streams. Tyto úlohy jsou obvykle dobře namapované na nové podněty pro inovace.These workloads tend to map well to new innovation ideas.

Vzhledem k různým pohybům, které jsou v souladu s agilními metodologiemi, a DevOps postupy, tyto úlohy přizpůsobují od tradiční správy IT zarovnání firmy/DevOps.Given various movements that are rooted in agile methodologies and DevOps practices, these workloads favor a business/DevOps alignment over traditional IT management. Pro tyto úlohy se může stát, že se tým cloudových operací po dobu několika let neodkazuje.For these workloads, there might not be a handoff to the cloud operations team for several years. V těchto případech vývojový tým slouží jako technický vlastník úlohy.In those cases, the development team serves as the technical owner of the workload.

S ohledem na rozsáhlá a přidružená kapitálová omezení se vlastní možnosti vývoje často omezí na příležitosti s vysokou hodnotou.Due to extensive time and associated capital constraints, custom development options are often limited to high-value opportunities. Mezi typické příklady patří inovace aplikací, hloubková analýza dat nebo klíčové obchodní funkce.Typical examples include application innovations, deep data analysis, or mission-critical business functions.

Vývoj pro přerušit/opravit nebo slunceBreak/fix or sunset development

Po dosažení špičky pro vlastní úlohy se vývojový tým může znovu přiřadit jiným projektům.After a custom-developed workload reaches peak maturity, the development team might be reassigned to other projects. V těchto případech se technické vlastnictví obvykle přechází na tým cloudových operací.In these cases, technical ownership typically transitions to a cloud operations team. Pokud je potřeba vyřešit drobné opravy, bude provozní tým zakládat vývojáře, aby chybu vyřešil.When there's a need for small fixes, the operations team will enlist developers to resolve the error.

V některých případech vývojový tým přesune do projektu, který bude nakonec nahradit aktuální úlohu.In some cases, the development team moves to a project that will eventually replace the current workload. Tým se také může přesunout, protože obchodní příležitost podporovaná úlohou se právě vytváří. Jedná se o příklady scénářů slunce, kde tým cloudových operací slouží jako technický vlastník, dokud nebude úloha nepotřebná.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.

V obou scénářích cloudové provozní týmy obvykle slouží jako dlouhodobý technický vlastník a rozhodovací tvůrce.In both scenarios, the cloud operations team typically serves as the long-term technical owner and decision maker. Tento tým bude nejspíš zařadit vývojáře aplikací, když provozní změny vyžadují významné změny v architektuře.That team will likely enlist application developers when operational changes require significant architectural changes.

Důležité úlohyMission-critical workloads

V každé společnosti jsou některé úlohy pro firmu moc důležité, aby mohly selhat.In every company, a few workloads are too important to the business for them to fail. S těmito úlohami, které jsou důležité pro práci, se obvykle nachází a vlastníci vývoje s různými úrovněmi zodpovědnosti.With these mission-critical workloads, there are usually operations and development owners with various levels of responsibility. Tyto týmy by měly zarovnávat provozní změny a strukturální změny, aby se minimalizovalo přerušení produkčního řešení.Those teams should align operational changes and architectural changes to minimize disruptions to the production solution.

V těchto scénářích se vyžaduje silný fokus na oddělení povinností.These scenarios require a strong focus on separation of duties. Aby bylo možné dosáhnout oddělení povinností, bude provozní tým obecně držet zodpovědnost za každodenní provozní změny v produkčním prostředí.To achieve separation of duties, the operations team will generally hold accountability for day-to-day operational changes in the production environment. Pokud tyto provozní změny vyžadují architekturu, budou dokončeny týmem pro vývoj nebo přijetí v neprodukčním prostředí, před tím, než provozní tým uplatní změny v produkčním prostředí.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.

Mezi důležité úlohy, které jsou potřeba oddělením, patří úlohy, jako jsou SAP, Oracle nebo jiná řešení pro plánování podnikových zdrojů (ERP), která zaujímají více obchodních jednotek ve společnosti.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.

Zarovnání portfolia strategieStrategy portfolio alignment

Je důležité pochopit strategické cíle úsilí o přijetí cloudu a zařadit portfolio do podpory této transformace.It's important to understand the strategic objectives of the cloud adoption effort and align the portfolio to support that transformation. Několik běžných typů strategického zarovnání portfolia vám může pořídit strukturu hierarchie portfolia.A few common types of strategic portfolio alignment help shape the structure of the portfolio hierarchy. Následující části obsahují příklady zarovnání portfolia a vlivu na hierarchii portfolia.The following sections provide examples of the portfolio alignment and impact on the portfolio hierarchy.

Inovace nebo portfolio LED pro vývojInnovation or development-led portfolio

Některé společnosti, zejména rychle rostoucí navázaná spuštění, mají vyšší průměrnou procentuální hodnotu pro vlastní vývojové projekty.Some companies, especially fast-growing established startups, have a higher-than-average percentage of custom development projects. V případě vývoje – těžké portfolia, prostředí, cílová zóna a úlohy se často komprimují, takže pro konkrétní úlohy můžou existovat konkrétní prostředí (buď produkční, nebo neproduktivní).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. Výsledkem je 1:1 poměr mezi prostředím, cílovou zónou a úlohou.This results in a 1:1 ratio between environment, landing zone, and workload.

Vzhledem k tomu, že prostředí je hostitelem vlastních řešení, může kanál DevOps a vytváření sestav na úrovni aplikace nahradit potřeby operací a funkcí zásad správného řízení.Because the environment hosts custom solutions, the DevOps pipeline and application-level reporting might replace the need for operations and governance functions. Pro tyto zákazníky je nejmenším zaměření na operace, řízení nebo jiné podpůrné role.For those customers, a reduced focus on operations, governance, or other supporting roles is likely. Typickým důrazem na zodpovědnosti při přijímání v cloudu a týmy pro cloudovou automatizaci jsou taky typické.A stronger emphasis on the responsibilities of the cloud adoption and cloud automation teams is also typical.

Zarovnání portfolia: Portfolio IT se zřejmě bude soustředit na úlohy a vlastníky úloh, aby bylo možné řídit kritická rozhodnutí o architektuře.Portfolio alignment: The IT portfolio will likely focus on workloads and workload owners to drive critical architecture decisions. Tyto týmy budou po dobu přijetí a provozu nejspíš v pokynech pro Azure Well-Architected Framework najít více hodnot.Those teams are likely to find more value in the Azure Well-Architected Framework guidance during adoption and operations activities.

Definice hranic: Logické hranice, dokonce i na úrovni podniku, se zřejmě budou soustředit na produkční a neproduktivní prostředí.Boundary definitions: The logical boundaries, even at an enterprise level, will likely focus on production and nonproduction environment segmentation. Může také docházet k jasnému segmentaci mezi produkty v portfoliu softwaru společnosti.There might also be clear segmentation between products in the company's software portfolio. V některých případech může být segmentace mezi vývojovými a hostovanými instancemi zákazníků také rozdělená.At times, there might also be segmentation between development and hosted customer instances.

Portfolio LED operacíOperations-led portfolio

Organizacím s více organizacemi v oblasti podniku s více zavedenými provozními týmy se obvykle důrazně zaměříte na řízení a provoz, než na vývoj.Multinational enterprise organizations with more established IT operations teams typically have a stronger focus on governance and operations than development. V těchto organizacích se obvykle zvyšuje procento úloh v kategorii COTS nebo porušit/opravit, které zachovává techničtí vlastníci v rámci týmu cloudových operací.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.

Zarovnání portfolia: Portfolio IT bude zarovnané na úlohy, ale tyto úlohy se pak zarovnají na provozní jednotky nebo obchodní jednotky.Portfolio alignment: The IT portfolio will be workload aligned, but those workloads are then aligned to operating units or business units. Mohou být také organizace týkající se finančních prostředků, odvětví nebo jiných požadavků na segmentaci firmy.There might also be organization around funding models, industry, or other business segmentation requirements.

Definice hranic: Zóny pro vykládku budou nejspíš seskupit aplikace do aplikace archetypes, aby byly podobné operace podobné segmentaci.Boundary definitions: Landing zones will likely group applications into application archetypes to keep similar operations in a similar segmentation. Prostředí budou nejspíš označovat fyzické konstrukce, jako jsou datacentra, země, oblast poskytovatele cloudu nebo jiné standardy provozní organizace.Environments will likely refer to physical constructs like datacenter, nation, cloud-provider region, or other operational organization standards.

Portfolio vedlo ke migraciMigration-led portfolio

Podobně jako portfolia řízené operacemi, portfolio, které je převážně sestavená prostřednictvím migrace, bude založené na konkrétních obchodních ovladačích, které vedly k migraci stávajících assetů.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. Většinou je datacentrum největší faktor v těchto ovladačích.Typically, the datacenter is the biggest factor in those drivers.

Zarovnání portfolia: Portfolio IT může být zarovnané na úlohy, ale je pravděpodobnější, že je zarovnaný.Portfolio alignment: The IT portfolio might be workload aligned, but it's more likely asset aligned. Pokud se v historii společnosti vyskytly přechody na operace IT, spousta aktivních prostředků použití nemusí být snadno namapována na zatížení financované.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. V těchto případech nemusí mít mnoho prostředků definovanou úlohu nebo může zrušit vlastnictví úlohy až do opožděného procesu migrace.In these cases, many assets might not have a defined workload or clear workload owner until late in the migration process.

Definice hranic: Zóny pro vykládku budou nejspíš seskupit aplikace do hranic, které odráží místní segmentaci.Boundary definitions: Landing zones will likely group applications into boundaries that reflect on-premises segmentation. I když se nejedná o osvědčený postup, prostředí se často shodují s názvem místního datacentra a zónami pro vykládku, které reprezentují postupy segmentace segmentace sítě.Though not a best practice, environments often match the on-premises datacenter name and landing zones that represent network segmentation practices. Je vhodnější dodržet segmentaci, která se podrobněji rovná s portfoliom řízeným operací.It's a better practice to adhere to segmentation that more closely aligns with an operations-led portfolio.

Portfolio LED pro řízeníGovernance-led portfolio

Zarovnání na týmy zásad správného řízení by mělo probíhat co nejdříve.Alignment to governance teams should happen as early as possible. Díky postupům zásad správného řízení a nástrojům zásad správného řízení cloudu můžou portfolia a hranice prostředí nejlépe vyvážit požadavky na inovace, provoz a migrace.Through governance practices and cloud governance tooling, portfolios and environmental boundaries can best balance the needs of innovation, operations, and migration efforts.

Zarovnání portfolia: Portfolia na základě zásad správného řízení mají za následek zahrnutí datových bodů, které zaznamenávají informace o inovacích a operacích, jako jsou úlohy, vlastník operací, klasifikace dat a kritická provozní náročnost.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. Tyto datové body vytvářejí dobře zaoblený pohled na portfolio.These data points create a well-rounded view of the portfolio.

Definice hranic: Hranice v portfoliu na základě zásad správného řízení mají v úmyslu upřednostnit operace při inovacích a přitom používat hierarchii řízenou skupinou, která se mapuje na kritéria pro obchodní jednotky a vývojová prostředí.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. Na každé úrovni hierarchie může mít hranice řízení cloudu různé stupně vynucování zásad, aby bylo možné vyvíjet a kreativní flexibilitu.At each level of the hierarchy, a cloud governance boundary can have different degrees of policy enforcement to allow for development and creative flexibility. Ve stejnou dobu se požadavky na produkční prostředí můžou použít na produkční předplatná, aby se zajistilo oddělení povinností a konzistentní operace.At the same time, production-grade requirements can be applied to production subscriptions to ensure separation of duties and consistent operations.