Hierarchie portfolia

Abyste pochopili, jak portfolio úloh, prostředků a podpůrných služeb společně fungují, musíte vytvořit hierarchii portfolia. Tento článek obsahuje jasné definice úrovní vaší hierarchie portfolia a pokyny pro týmy, které budou poskytovat očekávání pro každou úroveň. V tomto článku se každá úroveň hierarchie označuje také jako rozsah.

Pracovní vytížení

Kolekce technologií, které poskytují definovanou obchodní hodnotu, se nazývá pracovní zátěž. Kolekce může zahrnovat aplikace, servery nebo virtuální počítače, data, zařízení a další podobně seskupené prostředky. Většina firem využívá více úloh k poskytování důležitých obchodních funkcí.

Obchodní účastník a technický vedoucí obvykle sdílejí odpovědnost za průběžnou podporu jednotlivých úloh. V některých fázích životního cyklu úloh jsou tyto role jasně uvedeny. V dalších provozních fázích životního cyklu úlohy se tyto role můžou převést na tým pro správu sdílených operací nebo tým cloudového provozu. S rostoucím počtem úloh se role (uvedené nebo předpokládané) stávají složitějšími a více maticovými.

Úlohy a jejich podpůrné prostředky jsou základem jakéhokoli portfolia. Obory nebo vrstvy definují, jak se tyto úlohy zobrazují a v jakém rozsahu jsou ovlivněny maticí potenciálních podpůrných týmů.

I když se podmínky můžou lišit, všechna IT řešení zahrnují prostředky a úlohy:

• Asset: Nejmenší jednotka technické funkce, která podporuje úlohy nebo řešení.
• Úlohy: Nejmenší jednotka podpory IT pro firmu. Úloha je kolekce infrastruktury, aplikací a datových prostředků, které podporují společný obchodní cíl nebo provádění společného obchodního procesu.

Při nasazování první úlohy může být úloha a její prostředky jediným definovaným oborem. Ostatní vrstvy můžou být explicitně definovány při nasazení dalších úloh.

IT portfolio

Když společnosti podporují úlohy prostřednictvím maticových přístupů nebo centralizovaných přístupů, existuje pravděpodobně širší hierarchie, která tyto úlohy podporuje:

• Základní zóny : Základní zóny poskytují pracovní zátěži nezbytné základní nástroje nebo sdílené infrastruktury, které jsou potřeba pro podporu jedné nebo více pracovních zátěží. Cílové zóny jsou v cloudu tak kritické, že se celá metodologie Ready architektury přechodu na cloud zaměřuje na cílové zóny. Podrobnější definici najdete v tématu Co je cílová zóna?
• Základní nástroje: Tyto sdílené IT služby jsou vyžadovány, aby pracovní zátěže fungovaly v rámci technologického a obchodního portfolia organizace.
• Základ platformy: Tato organizační konstrukce centralizuje základní řešení a pomáhá zajistit, aby se tyto kontroly vynucují pro všechny cílové zóny.
• cloudové platformy: V závislosti na celkové strategii podpory celého portfolia můžou zákazníci potřebovat několik cloudových platforem s odlišnými nasazeními základu platformy, aby mohli řídit více oblastí, hybridních řešení nebo dokonce multicloudová řešení.
• Portfolio: Prostřednictvím technologie je portfolio kolekcí úloh, prostředků a podpůrných prostředků, které pokrývají všechny cloudové platformy. Prostřednictvím obchodního objektivu je portfolio kolekcí projektů, lidí, procesů a investic, které podporují a spravují technologické portfolio a podporují obchodní výsledky. Společně tyto dva objektivy zachycují portfolio.

Odpovědnost v hierarchii a pokyny

Zodpovědný tým spravuje každou vrstvu hierarchie portfolia. Následující diagram znázorňuje mapování mezi zodpovědným týmem a pokyny pro podporu obchodních rozhodnutí, technických rozhodnutí a technické implementace.

Poznámka

Týmy uvedené v následujícím seznamu můžou být virtuálními týmy nebo jednotlivci. U některých variant této hierarchie lze některé odpovědné týmy sbalit, jak je popsáno v pozdějších variantách odpovědnosti.

• Portfolio: Tým cloudové strategie a CCoE (Cloud Center of Excellence) používá metodologie strategie a plánu pro rozhodování, která ovlivňují celkové portfolio. Tým cloudové strategie zodpovídá za podnikovou úroveň hierarchie cloudového portfolia. Tým cloudové strategie by měl být také informován o rozhodnutích o prostředí, cílových zónách a úlohách s vysokou prioritou.
• Cloudové platformy: tým správy cloudu zodpovídá za rámce, které zajišťují konzistenci v každém prostředí v souladu s metodologií řízení. Tým odpovědný za správu cloudu odpovídá za správu všech prostředků ve všech prostředích. Tým zásad správného řízení v cloudu by se měl poradit se změnami, které můžou vyžadovat výjimku nebo změnu zásad správného řízení. Tým řízení v cloudu by měl být také informován o pokroku v přijímání úloh a prostředků.
• vstupní zóny a základ cloudu: tým cloudové platformy zodpovídá za vývoj vstupních zón a nástrojů platformy, které podporují adopci. Tým pro automatizaci cloudu zodpovídá za automatizaci vývoje a průběžné podpory těchto cílových zón a nástrojů platformy. Oba týmy používají metodu Ready k provádění implementace. Oba týmy by měly být informovány o pokroku při přechodu na úlohy a o všech změnách v podniku nebo prostředí.
• Pracovní zátěže: Osvojení probíhá na úrovni pracovní zátěže. Týmy přechodu na cloud používají metodologie Migrate a Inovace k vytváření škálovatelných procesů pro zrychlení přechodu. Po dokončení adoptování se vlastnictví úloh pravděpodobně přenese do cloudového provozního týmu, který používá metodu Spravovat k usměrňování řízení provozu. Oba týmy by se měly cítit pohodlně používat Microsoft Azure Well-Architected Framework k provádění podrobných architektonických rozhodnutí, která ovlivňují zátěže, jež podporují. Oba týmy by měly být informovány o změnách cílových zón a prostředí. Oba týmy můžou občas přispívat k vlastnostem přistávací oblasti.
• Majetek: Majetek je obvykle odpovědností týmu pro správu cloudových operací. Tento tým používá směrný plán správy v metodologii Manage k řízení rozhodnutí o řízení provozu. K provádění podrobných změn prostředků a architektury, které jsou potřeba k zajištění provozních požadavků, by také měla používat Azure Advisor a azure Well-Architected Framework.

Varianty odpovědnosti

• jedno prostředí: Pokud podnik potřebuje jenom jedno prostředí, CCoE se obvykle nevyžaduje.
• cs-CZ: jedna cílová zóna: Pokud má prostředí jenom jednu cílovou zónu, možnosti správy a platformy se mohou sloučit do jednoho týmu.
• Jedno pracovní zatížení: Některé firmy potřebují pouze jedno pracovní zatížení nebo několik pracovních zatížení, a to v jedné cílové zóně a jednom prostředí. V takových případech není velká potřeba oddělovat povinnosti mezi týmy zásad správného řízení, platformy a provozu.

Běžné příklady úloh a odpovědnosti

Následující příklady znázorňují hierarchii portfolia.

Úlohy COTS

Podniky tradičně upřednostňovaly softwarová řešení typu COTS (commercial-off-the-shelf) k řízení obchodních procesů. Tato řešení se instalují, konfigurují a pak provozují. Po konfiguraci došlo k malé změně architektury řešení.

V těchto scénářích končí jakékoliv přijetí cloudových řešení COTS přesunem k týmu pro provoz v cloudu. Tým pro provoz cloudu se pak stane technickým vlastníkem daného softwaru a předpokládá odpovědnost za správu konfigurace, nákladů, cyklů oprav a dalších provozních potřeb.

Mezi tyto úlohy patří účetní balíčky, logistický software nebo řešení specifická pro dané odvětví. V terminologii Microsoftu se dodavatelé těchto balíčků nazývají nezávislí dodavatelé softwaru (ISV). Nezávislí výrobci softwaru často nabízejí službu pro nasazení a údržbu instance jejich softwarového balíčku ve vašem předplatném. Můžou také nabídnout verzi softwarového balíčku, který běží ve vlastním prostředí hostovaného v cloudu a poskytuje alternativu k úloze platformu jako službu (PaaS).

Kromě nabídek PaaS zodpovídají týmy cloudového provozu za zajištění základních požadavků na dodržování provozních předpisů pro tyto úlohy. Tým cloudového provozu by měl spolupracovat s týmem zásad správného řízení v cloudu za účelem sladění nákladů, výkonu a dalších pilířů architektury.

Vývoj s aktivními revizemi

Pokud řešení COTS nebo nabídka PaaS nejsou v souladu s obchodní potřebou nebo neexistuje žádné řešení, podniky vytvářejí vlastní vyvinuté úlohy. Tento přístup k úlohou se obvykle používá pouze v malém procentu portfolia IT. Tyto úlohy ale mají tendenci řídit nepoměrně vysoké procento příspěvku IT k obchodním výsledkům, zejména výsledkům souvisejícím s novými zdroji příjmů. Tyto úlohy mají tendenci dobře odpovídat novým inovativním nápadům.

Vzhledem k různým přesunům, které jsou zakotveny v agilních metodologiích a postupech DevOps, tyto úlohy upřednostňují sladění podniku/DevOps s tradiční správou IT. U těchto pracovních zátěží nemusí dojít k předání týmu cloudového provozu po několik let. V takových případech slouží vývojový tým jako technický vlastník úlohy.

Vzhledem k rozsáhlým časovým a kapitálovým omezením jsou možnosti vlastního vývoje často omezené na příležitosti s vysokou hodnotou. Mezi typické příklady patří inovace aplikací, hloubková analýza dat nebo klíčové obchodní funkce.

Vývoj přerušení/opravy nebo západu slunce

Jakmile vlastní vyvinutá úloha dosáhne špičkové vyspělosti, může být vývojový tým znovu přiřazen k jiným projektům. V těchto případech technické vlastnictví obvykle přechází na tým cloudového provozu. Pokud potřebujete malé opravy, provozní tým zapíše vývojáře, aby chybu vyřešil.

V některých případech se vývojový tým přesune na projekt, který nakonec nahradí aktuální úlohu. Případně se tým může posunout dál, protože obchodní příležitost podporovaná pracovní zátěží se postupně ukončuje. V těchto scénářích ukončení tým pro provoz cloudu působí jako technický vlastník, dokud už pracovní zátěže nejsou potřeba.

V obou scénářích tým cloudového provozu obvykle slouží jako dlouhodobý technický vlastník a rozhodovací tvůrce. Tento tým pravděpodobně zapíše vývojáře aplikací, když provozní změny vyžadují významné změny architektury.

Klíčové úlohy

V každé firmě se najdou některé úlohy, které jsou pro podnik tak důležité, že nesmí selhat. U těchto kritických úloh obvykle existují provozní a vývojářští vlastníci s různými úrovněmi odpovědnosti. Tyto týmy by měly sladit provozní změny a změny architektury, aby se minimalizovaly přerušení produkčního řešení.

Tyto scénáře vyžadují silné zaměření na oddělení povinností. Provozní tým bude obecně zodpovídat za každodenní provozní změny v produkčním prostředí. Pokud tyto provozní změny vyžadují změnu architektury, dokončí je vývojový nebo adoptionový tým v neprodukčním prostředí předtím, než provozní tým změny použije v produkčním prostředí.

Mezi příklady důležitých úloh s požadovaným oddělením povinností patří úlohy, jako je SAP, Oracle nebo jiná řešení pro plánování podnikových zdrojů (ERP), která zahrnují několik organizačních jednotek ve společnosti.

Sladění portfolia strategie

Je důležité porozumět strategickým cílům úsilí o přechod na cloud a sladit portfolio na podporu této transformace. Několik běžných typů strategického zarovnání portfolia pomáhá strukturovat strukturu hierarchie portfolia. Následující části obsahují příklady sladění portfolia a vlivu na hierarchii portfolia.

Inovace nebo portfolio řízené vývojem

Některé společnosti, zejména rychle rostoucí startupy, mají vyšší než průměrné procento vlastních vývojových projektů. V portfoliech náročných na vývoj se prostředí, cílová zóna a úlohy často komprimují, takže pro konkrétní úlohy můžou existovat specifická prostředí. Výsledkem je poměr 1:1 mezi prostředím, cílovou zónou a úlohou.

Vzhledem k tomu, že prostředí hostuje vlastní řešení, může kanál DevOps a generování sestav na úrovni aplikace nahradit potřebu operací a funkcí správy a řízení. Tito zákazníci pravděpodobně sníží zaměření na operace, správu nebo jiné podpůrné role. Je také typickým důrazem na zodpovědnosti týmů přechodu na cloud a automatizace cloudu.

Sladění portfolia: IT portfolio se pravděpodobně zaměří na úlohy a vlastníky úloh, aby se mohli rozhodovat o kritické architektuře. Tyto týmy budou pravděpodobně v pokynech k rozhraní Azure Well-Architected Framework během aktivit přechodu a provozu najít další hodnotu.

definice hranic: Logické hranice, i na úrovni podniku, se pravděpodobně zaměří na segmentaci produkčního a neprodukčního prostředí. Mezi produkty v softwarovém portfoliu společnosti může být také jasné segmentace. V některých případech může existovat také segmentace mezi vývojovými a hostovanými instancemi zákazníků.

Portfolio řízené provozními týmy

Nadnárodní podnikové organizace s více zavedenými provozními týmy IT mají obvykle silnější zaměření na zásady správného řízení a provoz než vývoj. V rámci těchto organizací se vyšší procento pracovních zátěží obvykle shoduje s kategoriemi COTS nebo break/fix, které zajišťují techničtí vlastníci v týmu pro provoz v cloudu.

Sladění portfolia: Portfolio IT bude sladěno s pracovními zátěžemi, které dále budou sladěny s provozními nebo obchodními jednotkami. Může také existovat organizace kolem modelů financování, odvětví nebo jiných požadavků na obchodní segmentaci.

definice hranic: Přistávací zóny pravděpodobně seskupí aplikace do archetypů aplikací, aby podobné operace zůstaly ve stejné segmentaci. Prostředí budou pravděpodobně odkazovat na fyzické konstrukce, jako jsou datacentrum, národ, oblast poskytovatele cloudu nebo jiné provozní standardy organizace.

Portfolio vedené migrací

Podobně jako portfolia založená na operacích bude portfolio, které je z velké části postaveno prostřednictvím migrace, založené na konkrétních obchodních faktorech, které vedly k migraci stávajících prostředků. Datové centrum je obvykle největším faktorem mezi těmito činiteli.

Sladění portfolia: Portfolio IT může být orientované na pracovní zátěž, avšak s větší pravděpodobností je orientované na aktiva. Pokud v historii společnosti došlo k přechodům na IT operace, možná nebude mnoho aktiv v aktivním používání snadno přiřadit k financované úloze. V těchto případech nemusí mít mnoho prostředků definovanou úlohu nebo jasného vlastníka úlohy až pozdě v procesu migrace.

definice hranic: cílové zóny pravděpodobně seskupí aplikace do hranic, které odrážejí místní segmentaci. I když se nejedná o osvědčený postup, prostředí často odpovídají názvu místního datacentra a cílovým zónám, které představují postupy segmentace sítě. Lepším postupem je dodržovat segmentaci, která je lépe v souladu s portfoliem řízeném provozem.

Portfolio řízené zásadami správného řízení

Sladění s týmy řízení by mělo proběhnout co nejdříve. Díky postupům správného řízení a nástrojům zásad správného řízení v cloudu, portfoliím a hranicím životního prostředí je možné co nejlépe vyvážit potřeby inovací, provozu a migrace.

sladění portfolia: portfolia řízené zásadami správného řízení mají tendenci zahrnovat datové body, které zaznamenávají podrobnosti o inovacích a operacích, jako jsou úlohy, vlastník provozu, klasifikace dat a provozní důležitost. Tyto datové body vytvářejí dobře zaoblené zobrazení portfolia.

definice hranic: Hranice v portfoliu vedeném správou mají tendenci upřednostňovat operace před inovacemi a současně používat hierarchii vedenou řízením, která souvisí s kritérii pro obchodní jednotky a prostředí pro vývoj. Na každé úrovni hierarchie může hranice zásad správného řízení v cloudu mít různé stupně vynucování zásad, které umožní vývoj a kreativní flexibilitu. Současně lze požadavky na produkční úroveň použít u produkčních předplatných, aby se zajistilo oddělení povinností a konzistentních operací.

Další kroky

Zjistěte, jak produkty Azure podporují hierarchii portfolia.