Balansera portföljen

  • Artikel

Molnimplementering är en portföljhanteringsinsats som är smart förklädd till teknisk implementering. Precis som i alla portföljhanteringsövninger är det viktigt att balansera portföljen. På strategisk nivå innebär detta att balansera migrering, innovation och experimentering för att få ut det mesta möjliga av molnet. När molnimplementeringsarbetet lutar sig för långt i en riktning hittar komplexiteten sin väg in i implementeringsarbetet. Den här artikeln vägleder läsaren genom metoder för att uppnå balans i portföljen.

Allmän omfångsutökning

Att balansera portföljen är strategiskt. Därför är den metod som används i den här artikeln lika strategisk. För att grunda strategin i datadrivna beslut förutsätter den här artikeln att läsaren har utvärderat den befintliga digitala egendomen eller har påbörjat den processen. Målet med den här metoden är att underlätta utvärdering av arbetsbelastningar för att säkerställa korrekt balans mellan portföljen via kvalitativa frågor och portföljförfining.

Dokumentera affärsresultat

Innan du balanserar portföljen är det viktigt att dokumentera och dela affärsresultaten som driver arbetet med molnmigrering. Följande tabell kan hjälpa dig att dokumentera och dela önskade affärsresultat. Det är viktigt att notera att de flesta företag arbetar mot flera resultat samtidigt. Vikten av den här övningen är att klargöra de resultat som är närmast relaterade till arbetet med molnmigrering:

Resultat Mätt enligt Mål Tidsram Prioritet för det här arbetet
Minska IT-kostnaderna Datacenterbudget Minska med 2 MILJONER USD 12 månader Nr 1
Datacenteravslut Avsluta från datacenter 2 datacenter 6 månader Nr 2
Öka affärsflexibiliteten Minska tiden till marknaden Minska distributionstiden med sex månader 2 år Nr 3
Förbättra kundupplevelsen Kundnöjdhet (CSAT) 10 % förbättring 12 månader Nr 4

Viktigt

Tabellen ovan är ett fiktivt exempel och ska inte användas för att välja prioriteringar. I många fall kan den här tabellen betraktas som ett antimönster genom att lägga kostnadsbesparingar över kundupplevelser.

Tabellen ovan kan korrekt representera prioriteringarna för molnstrategiteamet och molnimplementeringsteamet. På grund av kortsiktiga begränsningar lägger det här teamet starkare betoning på minskning av IT-kostnader och prioriterar en datacenterutgång som ett medel för att uppnå önskade minskningar av IT-kostnader. Genom att dokumentera de konkurrerande prioriteringarna i den här tabellen är det dock möjligt att hjälpa molnstrategiteamet att identifiera möjligheter att bättre anpassa implementeringen av den övergripande portföljstrategin.

Flytta snabbt samtidigt som balansen upprätthålls

Vägledningen om inkrementell rationalisering av den digitala egendomen föreslår en metod där rationalisering börjar med en obalanserad position. Molnstrategiteamet bör utvärdera alla arbetsbelastningar med avseende på kompatibilitet med en metod för värdbyte. En sådan metod föreslås eftersom den tillåter snabb utvärdering av en komplex digital egendom baserat på kvantitativa data. Ett sådant första antagande gör att molnimplementeringsteamet kan börja arbeta snabbt, vilket minskar tiden till affärsresultat. Enligt vad som anges i den artikeln ger kvalitativa frågor dock den nödvändiga balansen i portföljen. I den här artikeln dokumenteras processen för att skapa den utlovade balansen.

Betydelsen av beslut om upphörande och tillbakadragning

Tabellen i avsnittet Dokumentera affärsresultat ovan saknar ett viktigt resultat som skulle stödja det främsta målet: att minska IT-kostnader. När minskning av IT-kostnader överhuvudtaget förekommer i listan över affärsresultat är det viktigt att överväga möjligheten med upphörande eller tillbakadragning av arbetsbelastningar. I vissa scenarier kan kostnadsbesparingar komma från att inte migrera arbetsbelastningar som inte motiverar en kortsiktig investering. Vissa kunder har rapporterat kostnadsbesparingar över 20 % av de totala kostnadsminskningarna genom att dra tillbaka underutnyttjade arbetsbelastningar.

Molnstrategiteamet och molnimplementeringsteamet uppmuntras att ställa följande frågor om varje arbetsbelastning under utvärderings- och migreringsfaserna för att balansera portföljen, vilket bättre återspeglar beslut om nedtid och tillbakagång:

  • Har arbetsbelastningen använts av slutanvändare under de senaste sex månaderna?
  • Är slutanvändartrafiken konsekvent eller växande?
  • Kommer den här arbetsbelastningen att behövas av verksamheten 12 månader från nu?

Om svaret på någon av dessa frågor är "nej" kan arbetsbelastningen vara en kandidat för pensionering. Om pensionspotentialen bekräftas med programägaren kanske det inte är meningsfullt att migrera arbetsbelastningen. Detta leder i sin tur till några kvalificeringsfrågor:

  • Kan en plan för tillbakadragning eller upphörande skapas för den här arbetsbelastningen?
  • Kan den här arbetsbelastningen dras tillbaka före datacenterutgången?

Om svaret på båda dessa frågor är "ja" är det klokt att överväga att inte migrera arbetsbelastningen. Den här metoden hjälper till att uppfylla målen med kostnadsbesparingar och datacenterutgång.

Om svaret på någon av frågorna är "nej" kan det vara klokt att upprätta en plan för att hantera arbetsbelastningen tills den kan dras tillbaka. Den här planen kan omfatta flyttning av tillgångar till ett datacenter med lägre kostnader eller ett alternativt datacenter, vilket även skulle uppfylla målen med kostnadsbesparingar och datacenterutgång.

Anta processändringar

För att balansera portföljen krävs ytterligare kvalitativ analys under implementeringsfasen, vilket bidrar till enkel portföljrationalisering.

Baserat på data från tabellen i avsnittet Dokumentera affärsresultat ovan finns det en sannolik risk för att portföljen inriktar sig för mycket på en migreringsfokuserad genomförandemodell. Om kundupplevelsen vore den främsta prioriteten skulle en innovationsinriktad portfölj vara mer trolig. Ingen av dessa är rätt eller fel, men om fokuset riktas för starkt åt ett håll avtar ofta nyttan, onödig komplexitet införs och genomförandetiden vid arbete med molnimplementering ökar.

För att minska komplexiteten bör du följa en traditionell metod för portfölj rationalisering, men i en iterativ modell. Följande steg beskriver en kvalitativ modell för en sådan metod:

  • Molnstrategiteamet har en prioriterad lista över kvarvarande uppgifter för arbetsbelastningar som ska migreras.
  • Teamen för molnstrategi och molnimplementering håller ett möte om lanseringsplanering före slutförandet av varje lansering.
  • I mötet om lanseringsplanering kommer teamen överens om de 5 till 10 främsta arbetsbelastningarna i den prioriterade listan över kvarvarande uppgifter.
  • Utanför mötet om lanseringsplanering ställer molnimplementeringsteamet följande frågor till programägarna och ämnesexperterna:
    • Skulle det här programmet kunna ersättas med en PaaS-motsvarighet (Platform as a Service)?
    • Är det här programmet ett program från tredje part?
    • Har budgeten godkänts för investering i pågående utveckling av programmet under de kommande 12 månaderna?
    • Skulle ytterligare utveckling av programmet förbättra kundupplevelsen? Skulle det skapa en konkurrenskraftig differentiering? Skulle det öka verksamhetens intäkter?
    • Kommer data i den här arbetsbelastningen att bidra till en underordnad innovation relaterad till BI, maskininlärning, IoT eller relaterade tekniker?
    • Är arbetsbelastningen kompatibel med moderna programplattformar såsom Azure App Service?
  • Svaren på ovanstående frågor och annan nödvändig kvalitativ analys påverkar justeringarna av den prioriterade listan över kvarvarande uppgifter. Dessa justeringar kan omfatta följande:
    • Om en arbetsbelastning kan ersättas med en PaaS-lösning kan den tas bort från migreringslistan helt. Som minst läggs ytterligare due diligence för att bestämma mellan värdbyte och ersättning som en uppgift, vilket tillfälligt minskar den arbetsbelastningens prioritet från kvarvarande migreringsuppgifter.
    • Om en arbetsbelastning (eller bör vara) genomgår utvecklingsutveckling kan den bäst passa in i en refaktor-rearchitect-rebuild-modell. Eftersom innovation och migrering kräver olika tekniska färdigheter bör program som är anpassade till en refaktor-rearchitect-rebuild-metod hanteras via en kvarvarande innovationslogg i stället för en kvarvarande migreringslogg.
    • Om en arbetsbelastning ingår i senare innovation kan det vara bäst att refaktorisera dataplattformen men lämna kvar programlagren som en kandidat för värdbyte. Mindre refaktorisering av en arbetsbelastnings dataplattform kan ofta utföras i en lista med kvarvarande uppgifter för migrering eller innovation. Detta rationaliseringsresultat kan leda till mer detaljerade arbetsobjekt i listan med kvarvarande uppgifter, men skulle i övrigt inte ändra några prioriteter.
    • Om en arbetsbelastning inte är strategisk men är kompatibel med moderna, molnbaserade programvärdplattformar kan det vara klokt att utföra mindre refaktorisering på programmet för att distribuera det som ett modernt program. Detta kan bidra till övergripande besparingar genom att molnmigreringens allmänna krav för IaaS- och operativsystemlicensiering minskas.
    • Om en arbetsbelastning är ett program från tredje part, och den arbetsbelastningens data inte planeras för användning i senare innovation, kan det vara bäst att låta den vara kvar som ett alternativ för värdbyte i listan över kvarvarande uppgifter.

De här frågorna bör inte vara omfattningen av den kvalitativa analys som slutförs för varje arbetsbelastning, men de hjälper till att vägleda en konversation om att hantera komplexiteten i en obalanserad portfölj.

Ändringar i migreringsprocessen

Under migreringen kan portföljbalanseringsaktiviteter ha en negativ inverkan på migreringshastigheten (den hastighet med vilken tillgångar migreras). Följande riktlinjer går närmare in på varför och hur arbete bör anpassas så att störningar i migreringsarbetet undviks.

Portföljrationalisering kräver tekniskt arbete av olika slag. Det är lockande för molnimplementeringsteam att matcha den portföljvariationen i migreringsarbetet. Affärsintressenter kan uppmana ett enda molnimplementeringsteam att hantera hela migreringslistan. Detta är sällan en lämplig metod, och i många fall kan den vara direkt kontraproduktiv.

Dessa olika insatser bör segmenteras mellan två eller flera molnimplementeringsteam. Med hjälp av en tvåteamsmodell som exempel på körning är team 1 migreringsteamet och team 2 är innovationsteamet. För större insatser kan dessa team segmenteras ytterligare för att hantera andra metoder som ersättning/PaaS-arbete eller mindre refaktorisering. Följande beskriver de färdigheter och roller som krävs för att ändra värd, refaktorisering eller mindre refaktorisering:

Värd för: Värdbyte kräver att teammedlemmar implementerar infrastrukturfokuserade ändringar. Normalt används ett verktyg såsom Azure Site Recovery för att migrera virtuella datorer eller andra tillgångar till Azure. Detta arbete är väl lämpat för datacenteradministratörer eller IT-implementatörer. Molnmigreringsteamet har en lämplig struktur för att leverera detta arbete i stor skala. Det här är den snabbaste metoden för att migrera befintliga tillgångar i de flesta scenarier.

Refaktorisering: Refaktorisering kräver att teammedlemmar ändrar källkoden, ändrar arkitekturen för ett program eller implementerar nya molntjänster. För sådant arbete används oftast utvecklingsverktyg såsom Visual Studio och distributionspipelineverktyg som Azure DevOps för att omdistribuera moderniserade program till Azure. Detta arbete är väl lämpat för programutvecklingsroller eller DevOps-pipelineutvecklingsroller. Molninnovationsteamet är bäst strukturerat för att leverera det här arbetet. Det kan ta längre tid att ersätta befintliga tillgångar med molntillgångar i den här metoden, men programmen kan dra nytta av molnbaserade funktioner.

Mindre refaktorisering: Vissa program kan moderniseras med mindre refaktorisering på data- eller programnivå. Detta arbete kräver att teammedlemmar distribuerar data till molnbaserade dataplattformar eller gör mindre konfigurationsändringar i programmet. Detta kan kräva visst stöd från ämnesexperter inom data- eller programutveckling. Det här arbetet liknar dock det arbete som utförs av IT-implementorer vid distribution av program från tredje part. Detta arbete kan enkelt anpassas till teamet för molnmigrering eller molnstrategi. Detta arbete är inte alls lika snabbt som en migrering med värdbyte, men det tar ändå mindre tid att genomföra än arbete med refaktorisering.

Under migreringen bör arbetet segmenteras på de tre sätt som anges ovan och köras av lämpligt team i lämplig iteration. Du bör diversifiera portföljen, men se också till att arbetet förblir mycket fokuserat och åtskilt.

Nästa steg

Förstå hur globala marknadsbeslut kan påverka din omvandlingsresa.

Förstå globala marknader