Vyvážení portfolia

Článek
07/11/2023

Přechod na cloud je snaha o správu portfolia, která se chytře maskuje za technickou implementaci. Stejně jako každé cvičení při správě portfolia je i vyrovnávání portfolia velmi důležité. Na strategické úrovni to znamená vyvážení migrace, inovace a experimentování za účelem co nejlepšího využití cloudu. Když se úsilí o přechod na cloud příliš naklání jedním směrem, prosadí se složitost. Tento článek provede čtenáře přístupy k dosažení rovnováhy v portfoliu.

Obecné rozšíření rozsahu

Vyvážení portfolia je strategické ze své podstaty. Proto je strategický také přístup v tomto článku použitý. V tomto článku se předpokládá, že čtenář vyhodnotil stávající digitální aktiva nebo zahájil tento proces, aby se strategie zřídila v rozhodnutích řízených daty. Cílem tohoto přístupu je pomoci při vyhodnocování úloh, aby se zajistilo řádné vyvážení v rámci portfolia prostřednictvím kvalitativních otázek a vylepšení portfolia.

Zadokumentujte obchodní výsledky

Před vyvážením portfolia je důležité zdokumentovat a sdílet obchodní výsledky, které pohání úsilí o migraci do cloudu. S dokumentováním a sdílením požadovaných obchodních výsledků vám může pomoct následující tabulka. Je důležité zmínit, že většina firem najednou usiluje o dosažení několika výsledků. Důležitost tohoto cvičení spočívá v objasnění výsledků, které jsou nejpříměji spojené se snahou o migraci do cloudu:

Výsledek	Měřeno podle	Cíl	Časový rámec	Priorita pro tuto snahu
Snížení nákladů na IT	Rozpočet datacentra	Snížení o 2 mil. USD	12 měsíců	1
Výstup z datacentra	Ukončení datacentra	2 datacentra	6 měsíců	2
Zvýšení svižnosti firmy	Zlepšení doby uvedení na trh	Zkrácení doby nasazení o šest měsíců	2 roky	3
Vylepšení prostředí pro zákazníky	Spokojenost zákazníků (CSAT)	Zlepšení o 10 %	12 měsíců	4

Důležité

Výše uvedená tabulka je fiktivní příklad a neměla by sloužit ke stanovování priorit. V mnoha případech lze tuto tabulku považovat za antipattern, protože úspora nákladů je vyšší než prostředí pro zákazníky.

Výše uvedená tabulka by mohla přesně znázorňovat priority týmu cloudové strategie a týmu přechodu na cloud. Kvůli krátkodobým omezením klade tento tým větší důraz na snížení nákladů na IT a dává větší prioritu opuštění datacenter jako způsobu, jak požadovaného snížení nákladů na IT dosáhnout. Díky zdokumentování konkurenčních priorit v této tabulce ale může tým přechodu na cloud pomoct týmu cloudové strategie s identifikováním příležitostí k lepšímu sladění implementace nadřazené strategie portfolia.

Rychlé jednání při zachování rovnováhy

Pokyny týkající se přírůstkové racionalizace digitálního majetku navrhují přístup, kdy racionalizace začíná u nevyvážené pozice. Tým cloudové strategie by měl vyhodnotit všechny úlohy z hlediska kompatibility s přístupem založeným na změně hostitele. Takový přístup se navrhuje, protože umožňuje rychlé vyhodnocení složitého digitálního majetku na základě kvantitativních dat. Vytvoření takového prvotního předpokladu umožňuje týmu přechodu na cloud, aby se rychle zapojil, čímž se zkrátí čas k dosažení obchodních výsledků. Jak je ale v uvedeném článku zmíněno, kvalitativní otázky v portfoliu zajistí potřebné vyvážení. Tento článek dokumentuje proces dosažení slíbeného vyvážení.

Důležitost rozhodnutí o ukončení a vyřazení

V tabulce v části zdokumentování obchodních výsledků výše chybí klíčový výsledek, který by podporoval nejdůležitější cíl snížení nákladů na IT. Když se kdekoli v seznamu obchodních výsledků nachází snížení nákladů na IT, je důležité vzít v úvahu potenciál ukončení nebo vyřazení úloh. V některých scénářích může úspora nákladů pocházet z toho, že se nemigrují úlohy, které nevyžadují krátkodobou investici. Někteří zákazníci hlásí úspory nákladů přesahující 20 % úspor celkových nákladů díky vyřazení nedostatečně využívaných úloh.

V rámci vyvážení portfolia, které lépe odráží rozhodnutí o ukončení a vyřazení, se týmu cloudové strategie a týmu přechodu na cloud doporučuje, aby během fází hodnocení a migrace pokládaly u každé úlohy následující otázky:

Používali koncoví uživatelé tuto úlohu v posledních šesti měsících?
Je provoz koncových uživatelů konzistentní nebo rostoucí?
Bude firma tuto úlohu vyžadovat za 12 měsíců?

Pokud je odpověď na některou z těchto otázek ne, může být úloha kandidátem na vyřazení. Pokud vlastník aplikace potvrdí možnost vyřazení, nemusí mít smysl migrovat úlohu. Vede to k několika kvalifikačním otázkám:

Je možné pro tuto úlohu stanovit plán vyřazení nebo plán ukončení?
Dá se tato úloha vyřadit před opuštěním datacentra?

Pokud je odpověď na obě tyto otázky "ano", pak by bylo vhodné zvážit migraci úlohy. Tento přístup by pomohl splnit cíle snížení nákladů a opuštění datacentra.

Pokud je odpověď na kteroukoli otázku "ne", může být vhodné vytvořit plán pro hostování úlohy, dokud ji nebude možné vyřadit. Tento plán by mohl zahrnovat přesunutí prostředků do datacentra s nižšími náklady nebo alternativního datacentra. Tím by se také dosáhlo cílů snížení nákladů a opuštění jednoho datacentra.

Přijetí změn procesu

Vyvážení portfolia vyžaduje další kvalitativní analýzu během fáze přijetí, která pomůže podpořit jednoduchou racionalizaci portfolia.

Na základě dat z tabulky v části zdokumentování obchodních výsledků existuje pravděpodobné riziko, že se portfolio příliš odkloní k modelu realizace se zaměřením na migraci. Pokud byly nejvyšší prioritou zkušenosti zákazníků, bude pravděpodobnější portfolio s velkým důrazem na inovace. Ani jedno není správné nebo špatné, ale příliš velké odklonění v jednom směru má obvykle za následek snížení návratnosti, zbytečné zvýšení složitosti a prodloužení doby realizace související se snahou o přijetí cloudu.

Abyste snížili složitost, měli byste postupovat podle tradičního přístupu k racionalizaci portfolia, ale v iterativním modelu. Následující kroky popisují kvalitativní model takového přístupu:

Tým pro cloudovou strategii udržuje backlog úloh s určenou prioritou, které se mají migrovat.
Tým cloudové strategie a tým přechodu na cloud před dokončením každé verze pořádají schůzku k plánování verze.
V rámci schůzky k plánování verze se týmy dohodnou na prvních 5 až 10 úlohách v backlogu úloh s určenou prioritou.
Mimo schůzku k plánování verze klade tým pro přijetí cloudu vlastníkům aplikací a odborníkům na danou problematiku tyto otázky:
- Dá se tato aplikace nahradit ekvivalentní platformou jako službou (PaaS)?
- Je tato aplikace aplikací třetí strany?
- Byl schválen rozpočet k investování do průběžného vývoje aplikace během příštích 12 měsíců?
- Mohl by další vývoj této aplikace zlepšit zkušenosti zákazníků? Vytvořit konkurenční výhodu? Vést k dalším výnosům pro firmu?
- Přispějí data v rámci této úlohy k inovacím v navazujícím procesu souvisejícím s BI, strojovým učením, IoT nebo souvisejícími technologiemi?
- Je úloha kompatibilní s moderními aplikačními platformami, jako je Azure App Service?
Odpovědi na výše uvedené otázky a jakékoli další požadované kvalitativní analýzy by pak ovlivnily úpravy backlogu s určenou prioritou. Může jít třeba o tyto úpravy:
- Pokud se dá úloha nahradit řešením PaaS, je možné ji z backlogu pro migraci úplně odebrat. Jako úkol by se přidala minimálně dodatečná náležitá péče při rozhodování mezi opětovným hostováním a nahrazením, čímž by se dočasně snížila priorita úlohy z backlogu migrace.
- Pokud úloha prochází (nebo by měla) ve vývoji, může být nejvhodnější pro model refaktoringu, změna architektury a opětovné sestavení. Vzhledem k tomu, že inovace a migrace vyžadují různé technické dovednosti, měly by se aplikace, které jsou v souladu s přístupem refaktoringu, změny architektury a opětovného sestavení, spravovat prostřednictvím backlogu inovací, a ne prostřednictvím backlogu migrace.
- Pokud je úloha součástí inovace podřízeného systému, může být vhodné refaktorovat datovou platformu, ale ponechat vrstvy aplikace jako kandidáta na změnu hostitele. Menší refaktoring datové platformy úlohy se dá často řešit v backlogu pro migraci nebo inovaci. Tento výsledek racionalizace může vést k podrobnějším pracovním položkám v backlogu, ale jinak žádným změnám priorit.
- Pokud úloha není strategická, ale je kompatibilní s moderními platformami pro hostování cloudových aplikací, může být vhodné provést u aplikace menší refaktoring a nasadit ji jako moderní aplikaci. To může přispět k celkovým úsporám díky snížení celkových licenčních požadavků na IaaS a OS migrace do cloudu.
- Pokud je úloha aplikací třetí strany a její data se neplánují používat v rámci inovace podřízeného systému, může být nejlepší ponechat ji v backlogu jako možnost změny hostitele.

Tyto otázky by neměly být rozsahem dokončené kvalitativní analýzy jednotlivých úloh, ale pomáhají vést konverzaci o řešení složitosti nevyváženého portfolia.

Změny procesu migrace

Během migrace můžou mít aktivity vyrovnávání portfolia negativní dopad na rychlost migrace (rychlost, s jakou se prostředky migrují). V následujících pokynech se dozvíte, proč a jak sladit práci, aby nedocházelo k přerušení snahy o migraci.

Racionalizace portfolia vyžaduje různorodé technické snahy. Pro týmy pro příjem cloudu je lákavé sladit tuto rozmanitost portfolia v rámci snah o migraci. Obchodní zúčastněné strany žádají, aby jeden tým pro přijetí cloudu řešil celý backlog pro migraci. To je jen zřídka vhodný přístup, v mnoha případech to může být kontraproduktivní.

Toto různorodé úsilí by mělo být rozděleno mezi dva nebo více týmů přechodu na cloud. Při použití modelu se dvěma týmy jako příkladu způsobu provádění je tým 1 tým migrace a tým 2 je tým pro inovace. V případě většího úsilí by tyto týmy mohly být dále segmentovány, aby řešily další přístupy, jako je úsilí o nahrazení/PaaS nebo menší refaktoring. Následující informace popisují dovednosti a role potřebné k rehostingu, refaktoringu nebo menšímu refaktoringu:

Změna hostitele: Změna hostitele vyžaduje, aby členové týmu implementovali změny zaměřené na infrastrukturu. Obecně se používá nástroj jako Azure Site Recovery k migraci virtuálních počítačů nebo jiných prostředků do Azure. Tato práce je vhodná pro správce datacenter nebo implementátory IT. Pro tuto práci ve velkém měřítku je dobře strukturovaný tým pro migraci do cloudu. Je to nejrychlejší přístup k migraci stávajících prostředků ve většině scénářů.

Refaktoring: Refaktoring vyžaduje, aby členové týmu upravili zdrojový kód, změnili architekturu aplikace nebo přijali nové cloudové služby. Obecně tato snaha využívá vývojářské nástroje jako sada Visual Studio a nástroje kanálu nasazení jako Azure DevOps k opětovnému nasazení modernizovaných aplikací do Azure. Tato práce se dobře hodí pro role vývoje aplikací nebo role vývoje kanálu DevOps. Tým cloudových inovací má nejlepší strukturu, aby tuto práci doručil. Nahrazení stávajících prostředků cloudovými prostředky v tomto přístupu může trvat déle, ale aplikace můžou využívat funkce nativní pro cloud.

Menší refaktoring: Některé aplikace je možné modernizovat pomocí menšího refaktoringu na úrovni dat nebo aplikace. Tato práce vyžaduje, aby členové týmu nasadili data do cloudových datových platforem nebo provedli drobné změny konfigurace v aplikaci. To může vyžadovat omezenou podporu pro odborníky na problematiku dat nebo vývoje aplikací. Tato práce se ale podobá práci, kterou provádějí implementátoři IT při nasazování aplikací třetích stran. Tato práce je vhodná pro tým pro migraci do cloudu nebo tým pro cloudovou strategii. I když tato snaha není zdaleka tak rychlá jako migrace se změnou hostitele, zabere méně času než refaktoring.

Během migrace by se úsilí mělo segmentovat třemi způsoby uvedenými výše a provést příslušný tým v příslušné iteraci. I když byste měli portfolio diverzifikovat, ujistěte se také, že úsilí zůstává velmi soustředěné a oddělené.

Další kroky

Porozumíte tomu, jak můžou rozhodnutí na globálním trhu ovlivnit vaši cestu k transformaci.

Principy globálních trhů