Moln rationalisering

Moln rationalisering är processen att utvärdera tillgångar för att avgöra det bästa sättet att migrera eller modernisera varje tillgång i molnet. Mer information om rationaliseringsprocessen finns i Vad är en digital egendom.

Rationaliseringskontext

De fem R:na för rationalisering som anges i den här artikeln är ett bra sätt att märka upp ett potentiellt framtida tillstånd för alla arbetsbelastningar som betraktas som molnkandidater. Placera den här etiketteringsprocessen i rätt kontext innan du försöker rationalisera en miljö. Granska följande myter för att tillhandahålla den kontexten:

Myt: Det är lätt att fatta rationaliseringsbeslut tidigt i processen

God rationalisering kräver djup kunskap om arbetsbelastningen och tillhörande tillgångar, till exempel program, infrastruktur och data. Viktigast av allt är att bra rationaliseringsbeslut tar tid. Vi rekommenderar att du använder en inkrementell rationaliseringsprocess.

Myt: Molnimplementering måste vänta på att alla arbetsbelastningar rationaliseras

När en hel IT-portfölj eller till och med ett enda datacenter rationaliseras kan det fördröja förverkligandet av affärsvärdet med månader eller till och med år. Undvik fullständig rationalisering när det är möjligt. Använd i stället Power of 10-metoden för att släppa planeringen för att fatta kloka beslut om de kommande 10 arbetsbelastningarna som är planerade för molnimplementering.

Myt: Affärsmotivering måste vänta på att alla arbetsbelastningar rationaliseras

Om du vill utveckla en affärsmotivering för en molnimplementering måste du göra några grundläggande antaganden på portföljnivå. När motivationer är anpassade till innovation, förutsätter omartitektur. Om de är anpassade till migrering antar du att du byter värd. Dessa antaganden kan påskynda affärsmotiveringsprocessen. Under utvärderingsfasen av varje arbetsbelastnings implementeringscykel utmanas antagandena och budgetarna förfinas.

Granska nu följande fem R:er för rationalisering för att bekanta dig med den långsiktiga processen. När du utvecklar din molnimplementeringsplan väljer du det alternativ som bäst passar dina motiveringar, affärsresultat och aktuella tillståndsmiljöer. Målet med rationalisering av digital egendom är att ange en baslinje, inte att rationalisera varje arbetsbelastning.

Rationalisering – fem punkter

Följande fem R:er för rationalisering beskriver de vanligaste alternativen för rationalisering.

Ange ny värd

Ett nytt värdbyte kallas även lift and shift-migrering och flyttar en aktuell tillståndstillgång till den valda molnleverantören med minimal ändring av den övergripande arkitekturen.

Vanliga drivrutiner kan vara att:

• Minska kapitalkostnaden.
• Frigör datacenterutrymme.
• Uppnå snabb avkastning på investeringar i molnet.

Kvantitativa analysfaktorer är:

• VM-storlek, inklusive CPU, minne och lagring.
• Beroenden, till exempel nätverkstrafik.
• Tillgångskompatibilitet.

Kvalitativa analysfaktorer är:

• Tolerans för förändring.
• Affärsprioriteringar.
• Kritiska affärshändelser.
• Processberoenden.

Omstrukturera

PaaS-alternativ (Plattform som en tjänst) kan minska de driftskostnader som är associerade med många program. Det är en bra idé att omstrukturera ett program något så att det passar en PaaS-baserad modell.

Refaktorisering avser även programutvecklingsprocessen för refaktoriseringskod för att göra det möjligt för ett program att leverera nya affärsmöjligheter.

Vanliga drivrutiner kan vara:

• Snabbare och kortare uppdateringar.
• Kodportabilitet.
• Större molneffektivitet för att hjälpa till med resurser, hastighet, kostnad och hanterade åtgärder.

Kvantitativa analysfaktorer är:

• Programtillgångens storlek, till exempel CPU, minne och lagring.
• Beroenden, till exempel nätverkstrafik.
• Användartrafik, till exempel sidvisningar, tid på sidan och inläsningstider.
• Utvecklingsplattformar som språk, dataplattformar och mellannivåtjänster.
• Databas som innehåller CPU, minne, lagring och version.

Kvalitativa analysfaktorer är:

• Fortsatta investeringar i verksamheten.
• Burst-alternativ eller tidslinjer.
• Affärsprocessberoenden.

Arkitekturomarbetning

Vissa åldrande program är inte kompatibla med molnleverantörer. Den här inkompatibiliteten beror på de arkitektoniska beslut som fattades när programmet skapades. I dessa fall kan programmet behöva arkitekturomarbetas före omvandlingen.

I andra fall kan program som är molnkompatibla, men inte molnbaserade, skapa kostnadseffektivitet och driftseffektivitet genom att arkitekturera om lösningen till ett molnbaserat program.

Vanliga drivrutiner kan vara:

• Programskala och flexibilitet.
• Enklare införande av nya molnfunktioner.
• Blandning av teknikstackar.

Kvantitativa analysfaktorer är:

• Programtillgångens storlek, till exempel CPU, minne och lagring.
• Beroenden, till exempel nätverkstrafik.
• Användartrafik, till exempel sidvisningar, tid på sidan och inläsningstider.
• Utvecklingsplattformar som språk, dataplattformar och mellannivåtjänster.
• Databas som innehåller CPU, minne, lagring och version.

Kvalitativa analysfaktorer är:

• Att växa affärsinvesteringar.
• Driftskostnader.
• Potentiella feedbackslingor och DevOps-investeringar.

Återskapa

I vissa scenarier kan deltat som måste övervinnas för att föra ett program framåt vara för stort för att motivera ytterligare investeringar. Det här problemet gäller särskilt för program som tidigare uppfyllde behoven i ett företag men som nu inte stöds med de aktuella affärsprocesserna. Lös problemet genom att skapa en ny kodbas som överensstämmer med en molnbaserad metod.

Vanliga drivrutiner kan vara att:

• Påskynda innovationen.
• Skapa program snabbare.
• Minska driftskostnaderna.

Kvantitativa analysfaktorer är:

• Programtillgångens storlek, till exempel CPU, minne och lagring.
• Beroenden, till exempel nätverkstrafik.
• Användartrafik, till exempel sidvisningar, tid på sidan och inläsningstider.
• Utvecklingsplattformar som språk, dataplattformar och mellannivåtjänster.
• Databas som innehåller CPU, minne, lagring och version.

Kvalitativa analysfaktorer är:

• Minska slutanvändarnas nöjdhet.
• Affärsprocesser som begränsas av funktioner.
• Potentiella kostnads-, erfarenhets- eller intäktsvinster.

Ersätt

Lösningar implementeras vanligtvis med den bästa tekniken och metoden som är tillgänglig vid den tidpunkten. Ibland kan saaS-program (programvara som en tjänst) tillhandahålla alla nödvändiga funktioner för det värdbaserade programmet. I dessa scenarier kan en arbetsbelastning schemaläggas för framtida ersättning, vilket tar bort den från omvandlingsarbetet.

Vanliga drivrutiner kan vara att:

• Standardisera kring bästa praxis för branschen.
• Påskynda införandet av affärsprocessdrivna metoder.
• Omallokera utvecklingsinvesteringar i program som skapar konkurrensdi differentiering eller fördelar.

Kvantitativa analysfaktorer är:

• Allmänna minskningar av driftskostnader.
• VM-storlek, inklusive CPU, minne och lagring.
• Beroenden, till exempel nätverkstrafik.
• Tillgångar som ska dras tillbaka.
• Databas som innehåller CPU, minne, lagring och version.

Kvalitativa analysfaktorer är:

• Kostnadsnyttoanalys av den aktuella arkitekturen jämfört med en SaaS-lösning.
• Affärsprocesskartor.
• Datascheman.
• Anpassade eller automatiserade processer.

Nästa steg

Du kan använda dessa fem R:er för rationalisering på en digital egendom som hjälper dig att fatta rationaliseringsbeslut om det framtida tillståndet för varje program.

Vad är en digital egendom