Hierarchie portfolia

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

Úlohy

Kolekce technologií, které poskytují definovanou obchodní hodnotu, se nazývá úloha. 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 spoléhá při poskytování důležitých obchodních funkcí na několik úloh.

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 provozních fázích životního cyklu úlohy můžou být tyto role převedeny 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 jádrem každého portfolia. Obory nebo vrstvy definují způsob zobrazení těchto úloh a do jaké míry 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:

• Majetku: Nejmenší jednotka technické funkce, která podporuje úlohu nebo řešení.
• Pracovního vytížení: 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 jediným definovaným oborem úloha a její prostředky. Ostatní vrstvy můžou být explicitně definované při nasazení více úloh.

Portfolio IT

Pokud společnosti podporují úlohy prostřednictvím maticových nebo centralizovaných přístupů, existuje pravděpodobně širší hierarchie pro podporu těchto úloh:

• Cílové zóny: Cílové zóny poskytují úlohám nezbytné základní nástroje nebo sdílené potrubí, které jsou potřeba k podpoře jedné nebo více úloh. Cílové zóny jsou v cloudu tak důležité, že se celá metodologie připravenosti Cloud Adoption Framework 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 potřeba k tomu, aby úlohy fungovaly v rámci technologického a obchodního portfolia.
• Základ platformy: Tento organizační konstruktor 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 více cloudových platforem s odlišným nasazením základu platformy, aby mohli řídit více oblastí, hybridní řešení nebo dokonce multicloudová řešení.
• Portfolio: Díky technologickým perspektivám je portfolio kolekcí úloh, prostředků a podpůrných prostředků, které pokrývají všechny cloudové platformy. Prostřednictvím obchodního pohledu je portfolio kolekcí projektů, lidí, procesů a investic, které podporují a spravují technologické portfolio za účelem zajištění obchodních výsledků. Tyto dva objektivy dohromady zachycují portfolio.

Odpovědnost za hierarchii a pokyny

Každou vrstvu hierarchie portfolia spravuje zodpovědný tým. Následující diagram znázorňuje mapování mezi odpově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í týmy nebo jednotlivci. U některých variant této hierarchie je možné některé zodpovědné týmy sbalit, jak je popsáno dále v části Varianty odpovědnosti.

• Portfolio: Tým cloudové strategie a CCoE (Cloud Center of Excellence) používají metodologie strategie a plánování k vedení rozhodnutí, 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 týkajících se prostředí, cílových zón a úloh s vysokou prioritou.
• Cloudové platformy: Tým zásad správného řízení v cloudu zodpovídá za disciplíny, které zajišťují konzistenci napříč jednotlivými prostředími v souladu s metodologií řízení . Tým zásad správného řízení v cloudu zodpovídá za zásady správného řízení všech prostředků ve všech prostředích. Změny, které můžou vyžadovat výjimku nebo změnu zásad řízení, by se měl poradit s týmem zásad správného řízení v cloudu. Tým zásad správného řízení v cloudu by měl být také informován o pokroku při přechodu na úlohy a prostředky.
• Cílové zóny a základ cloudu: Tým cloudové platformy zodpovídá za vývoj cílových zón a nástrojů platformy, které podporují přechod. Tým cloudové automatizace zodpovídá za automatizaci vývoje těchto cílových zón a nástrojů platformy a za jejich průběžnou podporu. Oba týmy používají metodu Ready k vedení implementace. Oba týmy by měly být informovány o průběhu přechodu na úlohy a o všech změnách v podniku nebo prostředí.
• Pracovní vytížení: Přijetí probíhá na úrovni úloh. Týmy přechodu na cloud používají metodologie migrace a inovací k vytvoření škálovatelných procesů pro urychlení přechodu. Po dokončení přechodu se vlastnictví úloh pravděpodobně přenese na tým cloudového provozu, který používá metodiku správy k řízení provozu. Oba týmy by měly umět používat rozhraní Microsoft Azure Well-Architected Framework k provádění podrobných rozhodnutí o architektuře, která ovlivňují úlohy, které 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 příležitostně přispívat k funkcím cílové zóny.
• Aktiv: Za prostředky obvykle zodpovídá tým cloudového provozu. Tento tým používá směrný plán správy v metodologii správy k vedení rozhodování při řízení provozu. Měl by také používat Azure Advisor a azure Well-Architected Framework k provádění podrobných změn prostředků a architektury, které jsou potřeba k zajištění požadavků na provoz.

Varianty odpovědnosti

• Jedno prostředí: Pokud organizace potřebuje jenom jedno prostředí, CCoE se obvykle nevyžaduje.
• Jedna cílová zóna: Pokud má prostředí pouze jednu cílovou zónu, můžou být možnosti zásad správného řízení a platformy pravděpodobně sloučeny do jednoho týmu.
• Jedna úloha: Některé firmy potřebují jenom jednu úlohu nebo několik úloh v jedné cílové zóně a jednom prostředí. V těchto případech není potřeba oddělit povinnosti mezi týmy zásad správného řízení, platforem a provozními týmy.

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

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

Úlohy COTS

Tradičně podniky upřednostňují komerční softwarová řešení cots (cots), která podporují obchodní procesy. Tato řešení se instalují, konfigurují a pak používají. Po konfiguraci se architektura řešení nezměnila.

V těchto scénářích jakékoli přijetí řešení COTS na cloud končí přechodem na tým cloudového provozu. Tým cloudového provozu se pak stane technickým vlastníkem daného softwaru a přebírá 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 jednotlivá odvětví. V terminologii Microsoftu se dodavatelé těchto balíčků označují jako nezávislí dodavatelé softwaru (ISV). Mnoho výrobců softwaru nabízí službu pro nasazení a údržbu instance jejich softwarového balíčku ve vašich předplatných. Mohou také nabídnout verzi softwarového balíčku, která běží ve vlastním prostředí hostovaném v cloudu a poskytuje alternativu k dané úloze jako platforma jako služba (PaaS).

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

Ve vývoji s aktivními revizemi

Pokud řešení COTS nebo nabídka PaaS neodpovídá obchodním požadavkům nebo neexistuje řešení, podniky vytvářejí úlohy vyvinuté na míru. Tento přístup k úlohě obvykle využívá jen malé procento portfolia IT. Tyto úlohy ale mají tendenci řídit nepřiměřeně vysoké procento příspěvku IT k obchodním výsledkům, zejména výsledkům souvisejícím s novými výnosy. Tyto úlohy se obvykle dobře mapují na nové nápady inovací.

Vzhledem k různým přesunům, které mají kořeny v agilních metodologiích a postupech DevOps, upřednostňují tyto úlohy sladění podnikání a DevOps před tradiční správou IT. U těchto úloh nemusí několik let dojít k předání týmu cloudového provozu. V těchto 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.

Přerušení/oprava nebo ukončení vývoje

Jakmile vlastní vyvinutá úloha dosáhne nejvyšší vyspělosti, vývojový tým může být 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 je potřeba provést malé opravy, provozní tým vyzve vývojáře, aby chybu vyřešili.

V některých případech se vývojový tým přesune na projekt, který nakonec nahradí aktuální úlohu. Případně může tým pokračovat, protože obchodní příležitost podporovaná úlohou se postupně ukončuje. V těchto scénářích ukončení provozu funguje tým cloudového provozu jako technický vlastník, dokud úloha už není potřeba.

V obou scénářích tým cloudového provozu obvykle slouží jako dlouhodobý technický vlastník a ten, který rozhoduje. Tento tým bude pravděpodobně zatěžovat vývojáře aplikací, pokud provozní změny vyžadují významné změny architektury.

Důležité úlohy

V každé společnosti je několik úloh pro firmu příliš důležitých, než aby selhaly. U těchto důležitých úloh obvykle existují vlastníci provozu a vývoje s různými úrovněmi odpovědnosti. Tyto týmy by měly sladit provozní změny a změny architektury, aby se minimalizovala přerušení produkčního řešení.

Tyto scénáře vyžadují silné zaměření na oddělení povinností. Provozní tým obecně nese odpovědnost 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 osvojený 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 klíčové úlohy s požadovaným oddělením povinností patří úlohy, jako jsou SAP, Oracle nebo jiná řešení pro plánování podnikových zdrojů (ERP), která pokrývají několik obchodních jednotek ve společnosti.

Sladění portfolia podle strategie

Je důležité pochopit strategické cíle úsilí o přechod na cloud a sladit portfolio tak, aby podporovalo danou transformaci. Několik běžných typů strategického sladění portfolia pomáhá strukturovat hierarchii portfolia. Následující části obsahují příklady sladění portfolia a vlivu na hierarchii portfolia.

Portfolio vedené inovacemi nebo vývojem

Některé společnosti, zejména rychle se rozvíjející startupy, mají vyšší než průměrné procento vlastních vývojových projektů. V portfoliích náročných na vývoj jsou prostředí, cílová zóna a úlohy často komprimované, 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 sestava na úrovni aplikace a kanálu DevOps nahradit potřebu operací a funkcí zásad správného řízení. Tito zákazníci se budou pravděpodobně méně soustředit na provoz, zásady správného řízení nebo jiné podpůrné role. Typický je také větší důraz na odpovědnost týmů přechodu na cloud a cloudovou automatizaci.

Sladění portfolia: Portfolio IT se pravděpodobně zaměří na úlohy a vlastníky úloh, aby se mohli rozhodovat kriticky důležitá architektura. Tyto týmy pravděpodobně najdou větší hodnotu v pokynech k architektuře Azure Well-Architected Během osvojování a provozu.

Definice hranic: Logické hranice, a to i na úrovni podniku, se pravděpodobně zaměří na segmentaci produkčního a neprodukčního prostředí. Může také docházet k jasné segmentaci mezi produkty v softwarovém portfoliu společnosti. Občas také může docházet k segmentaci mezi instancemi vývoje a hostovaných zákazníků.

Portfolio řízené provozem

Nadnárodní podnikové organizace se zavedenějšími provozními týmy IT se obvykle více zaměřují na zásady správného řízení a provoz než na vývoj. V těchto organizacích se vyšší procento úloh obvykle shoduje s kategoriemi COTS nebo break/fix, které spravují techní vlastníci v týmu cloudového provozu.

Sladění portfolia: Portfolio IT bude sladěné s úlohami, ale tyto úlohy jsou pak sladěny s provozními jednotkami nebo organizačními jednotkami. Může existovat také organizace v oblasti modelů financování, odvětví nebo jiných požadavků na segmentaci firmy.

Definice hranic: Cílové zóny budou pravděpodobně seskupovat aplikace do archetypů aplikací, aby se podobné operace zachovaly v podobné segmentaci. Prostředí budou pravděpodobně odkazovat na fyzické konstrukce, jako jsou datové centrum, národní organizace, oblast poskytovatele cloudu nebo jiné provozní standardy organizace.

Portfolio vedené migrací

Podobně jako u provozních portfolií bude portfolio, které je z velké části vytvořeno prostřednictvím migrace, založeno na konkrétních obchodních faktorech, které vedly k migraci stávajících prostředků. Hlavním faktorem těchto ovladačů je obvykle datacentrum.

Sladění portfolia: Portfolio IT může být v souladu s úlohami, ale je pravděpodobnější, že je sladěné s aktivy. Pokud v historii společnosti došlo k přechodu na provoz IT, nemusí být mnoho prostředků aktivního použití snadno namapováno na financovanou úlohu. V těchto případech mnoho prostředků nemusí mít definovanou úlohu nebo jasného vlastníka úlohy až do pozdní fáze procesu migrace.

Definice hranic: Cílové zóny budou pravděpodobně seskupovat aplikace do hranic, které odrážejí segmentaci v místním prostředí. 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á lépe odpovídá portfoliu řízenému provozem.

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

Sladění s týmy zásad správného ří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 mohou portfolia a hranice prostředí nejlépe vyvážit potřeby inovací, provozu a migrace.

Sladění portfolia: Portfolia vedená zásadami správného řízení obvykle obsahují datové body, které zachycují podrobnosti o inovacích a operacích, jako jsou úloha, vlastník provozu, klasifikace dat a provozní důležitost. Tyto datové body vytvářejí dobře zaoblený pohled na portfolio.

Definice hranic: Hranice v portfoliu řízeném zásadami správného řízení obvykle upřednostňují operace před inovacemi a používají hierarchii řízenou skupinami pro správu, která se mapuje na kritéria obchodních jednotek a vývojových prostředí. Na každé úrovni hierarchie může mít hranice zásad správného řízení v cloudu různé stupně vynucování zásad, které umožňují vývoj a kreativní flexibilitu. Současně je možné požadavky na produkční úroveň aplikovat na produkční předplatná, aby se zajistilo oddělení povinností a konzistentní provoz.

Další kroky

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