Balansera konkurrerande prioriteringar

Framgången för en digital omvandling bestäms av affärs- och teknikintressenternas förmåga att balansera konkurrerande prioriteringar.

Precis som andra digitala omvandlingar exponerar molnimplementeringen konkurrerande prioriteringar under hela implementeringslivscykeln. Och precis som med andra former av omvandling har förmågan att balansera dessa prioriteringar en betydande effekt på förverkligande av affärsvärde. Att balansera dessa konkurrerande prioriteringar kräver öppna och ibland svåra samtal mellan intressenter, och ibland med enskilda deltagare.

I den här artikeln beskrivs några av de konkurrerande prioriteringar som ofta diskuteras under genomförandet av varje metod. Det kan hjälpa dig att förbereda dig för dessa diskussioner när du utvecklar din strategi för molnimplementering.

Följande avsnitt överensstämmer med flödet i föregående livscykeldiagram för molnimplementering. Det är dock viktigt att känna igen att molnimplementering är en iterativ process, inte en sekventiell process, och att dessa konkurrerande prioriteringar kan komma tillbaka vid olika tidpunkter under molnimplementeringsresan.

Det allmänna temat för Cloud Adoption Framework-metoden

Monolitiska lösningar och avancerad planering bygger båda på en rad antaganden som kan visa sig vara felaktiga över tid. Att implementera molnet är ofta en ny upplevelse för ett företag och dess tekniska team. Precis som med de flesta nya upplevelser finns det en viss sannolikhet att de inledande antagandena kommer att bevisas vara felaktiga.

Att följa beprövade agila principer för fördröjda tekniska beslut är den föredragna metoden för de flesta riktlinjer inom detta ramverk. Den här metoden följer ett konsekvent mönster: upprätta ett allmänt sluttillstånd, gå snabbt till inledande implementering, testa och validera antaganden och omstrukturera tidigt för att åtgärda felaktiga antaganden. Den här typen av tillväxttänk maximerar inlärningen och minimerar risken för affärsvärde, men det kräver viss komfort med tvetydighet.

Tvetydighet kan ibland vara läskigare, eller farligare, än falska antaganden. Även om det här ramverket prioriterar inlärning och åtgärdar tvetydighet under implementeringen, kräver många situationer att teamet prioriterar analysbaserade eller antagandebaserade metoder. Följande avsnitt innehåller minst ett "utökat omfångsexempel" som illustrerar när en andra djupare iteration kan vara värdefull.

Balansera under strategifasen

Huvudsyftet med strategimetoden är att utveckla anpassningen mellan intressenterna. När den har definierats styr den justerade strategiska positionen beteendet i var och en av metoderna för att säkerställa att tekniska beslut överensstämmer med önskade affärsresultat. Genom att främja anpassningen mellan intressenterna skapas en gemensam uppsättning konkurrerande prioriteringar: en djup motivering jämfört med tid för affärspåverkan.

Konkurrerande prioriteringar:

• Motiveringsdjup: Intressenter vill ofta ha en djup ekonomisk analys och fullständig affärsmotivering innan de är bekväma med att anpassa sig till en strategisk riktning. Tyvärr kan den analysnivån kräva en längre tidsperiod för att möjliggöra datainsamling och analys.

• Tid till affärspåverkan: Omvänt hålls intressenter ofta ansvariga för att leverera affärsresultat inom definierade tidsramar. Tidskrävande analys och utvärdering kan äventyra dessa resultat innan det tekniska arbetet ens börjar.

Minsta omfång: För att hitta rätt balans krävs diskussioner med intressenter tidigt i processen. Strategimetoden föreslår att man begränsar anpassningens omfattning under denna tidiga insats. I den föreslagna metoden fokuserar intressenterna på att anpassa sig till en uppsättning grundläggande motivationer, mätbara resultat och en högnivåaffärsmotivering. Intressenter bör sedan snabbt engagera sig i några inledande projekt eller piloter för att driva de utbildningsmöjligheter som krävs.

Exempel på utökat omfång: Om den inledande affärsanalysen indikerar en hög risk för negativ påverkan på verksamheten kan intressenter behöva sakta ner och mer försiktigt utvärdera en djupare analys under affärsmotiveringen.

Balansera under planeringsfasen

Precis som under strategifasen finns det ett behov under planeringsfasen att balansera djupet i den inledande planeringen jämfört med fördröjda tekniska beslut.

Konkurrerande prioriteringar:

• Djup i den inledande planeringen för teknisk implementering i molnet baseras ofta på många antaganden. Särskilt när det finns kunskapsluckor i teamet drabbas miljön av identifieringsluckor eller om arbetsbelastningarna inte har tydligt definierade arkitektursluttillstånd. Alla dessa antaganden är vanliga i detaljerade molnimplementeringsplaner. Experimentering, piloter och kvalitativ analys krävs för att verifiera eller förbättra dessa antaganden.

• Fördröjda tekniska beslut baseras på antagandet att ju senare ett tekniskt beslut fattas, desto mer exakt är det. Genom att följa principerna för flexibel produktplanering kan du fördröja tekniska beslut, så att de kan ske vid rätt tidpunkt, baserat på tillräcklig information. Den här metoden resulterar dock i mer tvetydighet i den ursprungliga planen.

Minsta omfång: Vi föreslår flexibla produktutvecklingsmetoder för att driva snabbåtgärder inom hanterbara planer. Planmetoden rekommenderar följande steg för att uppnå den här balansen:

1. Inventera den fullständiga digitala egendomen med hjälp av automatiserade identifieringsverktyg, men använd inkrementell rationalisering för att planera så långt som de kommande 1 till 3 månadernas arbete.
2. Se till att organisationen justeras så att den går snabbt.
3. Skapa en kompetensberedskapsplan för det tilldelade teamet. Använd strategi- och planmallen för att snabbt distribuera en inledande kvarvarande information.

Exempel på utökat omfång: Leveransen av en molnimplementeringsplan kan ibland vara ett svar på en tidskänslig eller omfattande affärshändelse. När framgång kräver förflyttning av ett stort antal tillgångar under en fast tidsperiod följs de föregående stegen ofta av en djupare planering. Nyckeln till framgång i dessa scenarier är att planera tillräckligt för att komma igång och sedan planera för det fullständiga engagemanget senare. Den här metoden minskar sannolikheten för att planering blockerar affärsresultat.

Balansera under beredskapsfasen

När teamen förbereder sig för sina första steg i molnimplementeringen finns det ofta konkurrerande prioriteringar mellan tid till implementering och långsiktiga åtgärder. Teamet kan kämpa med balansen mellan att vara väl lämpad att leverera på uppgiften till hands och att vara väl hanterad. Denna kamp är nödvändig i traditionella IT-miljöer, där det krävs fysiska tillgångar och förvärvscykler för att utveckla en plattform. Men när hela IT-plattformen definieras i kod minskar traditionella utvecklingstaktiker, till exempel refaktorisering, behovet av att hanteras väl från början.

Konkurrerande prioriteringar:

• Långsiktiga åtgärder: Organisationer blockeras ofta av viljan att ha en molnmiljö som uppfyller funktionsparitet med nuvarande driftshantering, styrning och säkerhetssystem. I en studie behövde mer än 90 procent av organisationerna stöd för att komma förbi det tänkesättet. Den här blockeraren kan skapa månader av fördröjning, sakta ned eller förhindra påverkan på verksamheten.

• Tid till implementering: Molnbaserade verktyg som Azure Policy, ci/CD-metoder (kontinuerlig integrering och kontinuerlig leverans), till exempel infrastruktur som kod (IaC) och hanteringsgrupper, kan förenkla processen för refaktorisering på IT-plattformen. Dessutom ger fördefinierade landningszoner rekommendationer för att påskynda distributionen mot en miljö som redan uppfyller många krav på funktionsparitet. Dessa verktyg ger möjligheter att påskynda tiden till marknaden med minimal effekt på den långsiktiga verksamheten.

Minsta omfattning: Metoden Klar beskriver en direkt väg från snabb implementering till långsiktiga åtgärder. Den här metoden börjar med en grundläggande introduktion till de verktyg som du kan använda för att omstrukturera din miljö. Verktygen tar hänsyn till dina krav och vägleder dig till ett urval av fördefinierade landningszoner, som var och en levereras med IaC-modeller. Du kan sedan omstrukturera koden under molnimplementeringen för att förbättra åtgärder, säkerhet och hantering.

Utökat omfångsexempel: För team vars implementeringsplan kräver ett halvtidsmål (inom 24 månader) som värd för mer än 1 000 tillgångar (program, infrastruktur eller datatillgångar) i molnet rekommenderar vi en mer robust vy över landningszoner. I dessa situationer bör du överväga metoderna För styrning och hantering under dina inledande konversationer i landningszonen. Det här djupare övervägandet lägger dock ofta till veckor eller månader i en molnimplementeringsplan. För att minimera effekten på affärsresultaten bör implementeringsteamet testa faktiska arbetsbelastningar i molnet samtidigt som de skapar en mer mogen landningszon och en lösning för central arkitektur.

Balansera under migreringsfasen

Under migreringen förutsätter implementeringsteam vanligtvis att arbetsbelastningar kommer att byta värd i molnet i sin aktuella konfiguration. Det här antagandet konkurrerar med en framåtblickande plan för att omarbeta varje arbetsbelastning för att bättre dra nytta av molnfunktionerna. De två vyerna är inte ömsesidigt uteslutande och kan vara kostnadsfria när du hanterar dem med hjälp av en gemensam process.

Konkurrerande prioriteringar:

• Rehost: Organisationer likställer ofta migrering med en lift-and-shift-metod som replikerar alla tillgångar till molnet i den aktuella konfigurationen. Den här metoden resulterar i en liten avvikelse i IT-portföljen. Det är också det snabbaste sättet att dra tillbaka tillgångar i ett befintligt datacenter.

• Ombyggnad: Modernisering av arkitekturen för varje arbetsbelastning maximerar värdet av molnimplementering för kostnader, prestanda och åtgärder. Den här metoden är dock långsammare och kräver ofta åtkomst till varje programs källkod.

Minsta omfång: Under planeringen i ett tidigt skede använder du alternativet rehost för planering, med en tydlig förståelse för att det här valet baseras på ett inledande affärsantagande och inte är ett tekniskt beslut. I migreringsmetodiken utmanar molnimplementeringsteamet sedan det här antagandet för varje migrerad arbetsbelastning. Den här metoden följer metoden för att utvärdera/migrera/höja upp för varje arbetsbelastning eller grupp av arbetsbelastningar för att skapa en migreringsfabrik. Under utvärderingsfasen utvärderar implementeringsteamet den tekniska anpassningen och arkitekturen för varje arbetsbelastning. Den utvärderingsinsatsen resulterar sällan i en ren lift-and-shift-metod eftersom många av komponenterna i arkitekturen tenderar att väljas för refaktorisering och modernisering.

Utökat omfångsexempel: För verksamhetskritiska eller högkänsliga arbetsbelastningar, till exempel stordatorprogram eller mikrotjänstprogram med flera nivåer, kan en mer grundlig utvärdering av arbetsbelastningen krävas under utvärderingsfasen. I dessa lägen bör du använda Azure Well-Architected Review och Azure Well-Architected Framework för att förfina arbetsbelastningskraven under utvärderingen.

Balans under innovationsfasen

Sann kundinriktad innovation skapar ofta motstridiga prioriteringar mellan behovet av att leverera på en planerad funktionsuppsättning och implementera en utvecklingsprocess med kund empati.

Konkurrerande prioriteringar:

• Funktionsfokus: Initiala planer för innovation bygger på befintliga funktioner för digital egendom och moln för att leverera en uppsättning funktioner som uppfyller kundernas behov. Det är enkelt att låta planen driva teknisk implementering, vilket leder till en funktionsfokuserad utveckling. Den här metoden leder ofta till tillfällig intressentnöjdhet men minskar sannolikheten för att driva innovation som påverkar kundernas beteende.

• Kund empati: Initiala planer är en viktig del av affärssidan av utveckling och bör ingå i regelbunden rapportering. Men att lära sig, mäta och bygga med kundens empati som mål är ett mer exakt mått på framgång i en innovationsinsats. Att fokusera på kunder framför funktioner är mer sannolikt att resultera i kortsiktig och långsiktig kundnöjdhet och affärspåverkan.

Minsta omfattning: Innovationsmetodiken illustrerar hur du integrerar strategi och planer med hjälp av affärsvärdeskonsensus. Guiden introducerar sedan molnbaserade verktyg som kan påskynda varje område för innovation och bästa praxis för implementering. Slutligen visar avsnittet om processförbättringar metoder för att skapa kund empati samtidigt som planer och strategier respekteras under hela molnimplementeringsresan. Den här metoden fokuserar på att leverera innovation med så lite teknik som möjligt.

Exempel på utökat omfång: En innovation är ibland beroende av verksamhetskritiska eller högkänsliga arbetsbelastningar. När kunden är en intern användare kan utvecklingsinsatsen vara både verksamhetskritisk och hög känslighet under de tidigaste iterationerna. I dessa scenarier bör implementeringsteamen använda Azure Well-Architected Review och Azure Well-Architected Framework för att utvärdera avancerad arkitekturdesign tidigt i processen.

Balans under styrningsfasen

Molnstyrning är en balans mellan två konkurrerande prioriteringar: hastighet och flexibilitet jämfört med en väl styrd miljö. Molnstyrningsteamet fokuserar på att utvärdera och minimera risker för verksamheten genom enhetliga kontroller och minimera förändringar. Implementeringsteamet fokuserar på att driva affärsresultat, vilket kräver nya risker och skapar förändring.

Konkurrerande prioriteringar:

• Väl styrd: Varje kontroll som är utformad för att minimera risker blockerar någon aspekt av designalternativ för ändringar eller begränsningar. Kontroll är avgörande för en väl styrd miljö. Men när kontroller utformas och distribueras isolerat kan de vara lika skadliga som de risker som de är avsedda att förhindra.
• Hastighet och flexibilitet: Hastighet och flexibilitet är grundläggande affärskrav i den digitala ekonomin. Båda kräver möjligheten att driva förändring med minimala blockerare för innovation eller implementering. Men när förändring drivs utan styrning genererar den nya risker som kan skada verksamheten på oväntade sätt.

Minsta omfång: Styrningsmetodiken tyder på att varken styrning eller implementering någonsin bör ske isolerat. Den här metoden börjar med en förståelse för styrningsområden och en konversation om affärsrisker, principer och processer. Som aktiv deltagare under molnimplementeringen kan styrningsteamet implementera en minsta uppsättning skyddsåtgärder för att hantera de konkreta riskerna i molnimplementeringsplanen. Med tiden kan styrningsteamet omstrukturera och utöka dessa skydd för att möta nya risker. Den här metoden maximerar inlärning och innovation samtidigt som risken minimeras.

Exempel på utökat omfång: När affärsrisken är hög, särskilt tidigt i implementeringen, kan molnstyrningsteamet behöva påskynda expansionen av styrningsimplementeringar. Du kan använda samma vägledning och övningar för att lägga till den här högre styrningsnivån, men du kan behöva gå snabbare. I vissa scenarier kan ett avancerat styrningstillstånd till och med krävas när du utvecklar de första landningszonerna.

Balansera under hanteringsfasen

IT-affärsmodellen för driftshantering har utvecklats kontinuerligt under det senaste decenniet. I takt med att maskinvaruunderhållet går längre från IT:s grundläggande värdeförslag har vyn för driftshantering ändrats. I takt med att IT ökar fokus på att leverera affärsvärde står driftshanteringsteamen i konflikt med behovet av att balansera no-ops och low-ops jämfört med breda investeringar.

Konkurrerande prioriteringar:

• Breda investeringar: Att investera lika mycket i undvikande av avbrott, snabb återhämtning och övervakning i hela miljön är den traditionella metoden för driftshantering. Den här metoden kan vara dyr och duplicerar ibland de stödjande produkter som tillhandahålls av molnleverantören.

• No-ops och low-ops: Använd molnbaserade åtgärdsverktyg för att minimera repetitiva och återkommande uppgifter som tidigare levererades av dina anställda. Att minska dessa driftberoenden gör att anställda kan driva värde på andra sätt. Isolerat kan dock den här metoden leda till stöd för underpar-åtgärder.

Minsta omfång: Metoden Hantera föreslår att en molnbaserad baslinje utan ops upprättas. Att erkänna att no-ops-baslinjen inte uppfyller alla affärsbehov, arbeta med verksamheten för att definiera åtaganden och bättre anpassa investeringarna. Expandera baslinjen för att uppfylla vanliga behov för alla arbetsbelastningar. Gör sedan det möjligt för plattformsteam eller specifika arbetsbelastningsteam att underhålla välhanterade lösningar i en välhanterad miljö.

Exempel på utökat omfång: I de flesta miljöer motiverar affärsvärdet för en liten andel arbetsbelastningar djupa investeringar i åtgärder från IT. För dessa arbetsbelastningar kanske IT-teamet vill använda Azure Well-Architected Review och Azure Well-Architected Framework för att vägleda djupare åtgärder.

Balansera under organisationsfasen

De konkurrerande prioriteringarna som beskrivs i den här artikeln återspeglar IT:s strävan att uppfylla företagets krav på snabbhet och flexibilitet. Samma skifte visas i ändringar i organisationsscheman eller virtuella teamstrukturer för att ge bättre stöd för affärsresultat. När IT-ledarna reflekterar över teamstrukturer behandlas ofta två konkurrerande prioriteringar: centraliserad kontroll jämfört med delegerad kontroll.

Konkurrerande prioriteringar:

• Centraliserad kontroll: Den här driftsmodellen fokuserar på centraliseringen av alla kontroller som krävs för att tillämpa strikta principer. I den här modellen fungerar IT som en blockerare för innovation, snabbhet och flexibilitet. IT kan dock säkerställa en högre grad av stabilitet, efterlevnad och säkerhet.

• Delegerad kontroll: I den här distribuerade driftsmodellen förutsätts det att varje DevOps-team eller affärsprogramteam tillhandahåller sin egen uppsättning kontroller, baserat på de lösningar som krävs för att uppfylla affärsmålen. I den här modellen tillhandahåller IT-avdelningen riktlinjer för att hjälpa team att undvika risker, men minimerar antalet framtvingade tekniska begränsningar när det är möjligt.

Minsta omfång: De flesta organisationer genomgår en naturlig uppsättning utvecklingar över tid. Metoden Organisera beskriver de vanligaste evolutionsserierna. Vi rekommenderar att teamen försöker gå mot en CCoE-struktur (Cloud Center of Excellence) för att leverera delegerade kontrollmetoder.

Exempel på utökat omfång: Många situationer utlöser ett behov av centraliserad kontroll. Efterlevnadskrav från tredje part och tillfällig säkerhetsexponering är två exempel på utlösare för centraliserad kontroll. I dessa situationer finns det ofta ett behov av att upprätta begränsande principer och strikta, fasta kontroller. Men för att göra det möjligt för innovation och implementering att fortsätta uppmuntrar vi centrala IT-team att leverera dessa kontroller baserat på varje arbetsbelastnings allvarlighetsgrad och känslighet. Att ge miljöer mindre kontroll men en reducerad omfångs- eller riskprofil ger flexibilitet även när kontroll krävs.

Nästa steg

Lär dig att balansera migrering, innovation och experimentering för att maximera värdet för dina molnmigreringsinsatser.

Balansera portföljen