Conflicterende prioriteiten balanceren
Het succes van elke digitale transformatie wordt bepaald door het vermogen van belanghebbenden om concurrerende prioriteiten te verdelen.
Net als bij andere digitale transformaties biedt cloudimplementatie concurrerende prioriteiten gedurende de hele levenscyclus van de acceptatie. En net als bij andere vormen van transformatie heeft de mogelijkheid om deze prioriteiten te verdelen een aanzienlijk effect op de realisatie van bedrijfswaarde. Voor het verdelen van deze concurrerende prioriteiten zijn open en soms moeilijke gesprekken tussen belanghebbenden en soms met individuele inzenders vereist.
In dit artikel worden enkele van de concurrerende prioriteiten beschreven die vaak worden besproken tijdens de implementatie van elke methodologie. Het kan u helpen deze discussies voor te bereiden wanneer u uw strategie voor cloudimplementatie ontwikkelt.
De volgende secties zijn afgestemd op de stroom in het voorgaande levenscyclusdiagram voor cloudimplementatie. Het is echter belangrijk om te erkennen dat cloudimplementatie een iteratief proces is, niet een opeenvolgend proces en dat deze concurrerende prioriteiten op verschillende punten opnieuw kunnen optreden tijdens uw overstap naar de cloud.
Het algemene thema van de benadering van het Cloud Adoption Framework
Monolithische oplossingen en geavanceerde planning zijn beide gebaseerd op een reeks veronderstellingen die na verloop van tijd onnauwkeurig kunnen blijken te zijn. De overstap naar de cloud is vaak een nieuwe ervaring voor een bedrijf en de technische teams. Net als bij de meeste nieuwe ervaringen is het waarschijnlijk dat initiële veronderstellingen onjuist worden bewezen.
Het volgen van bewezen agile principes van vertraagde technische beslissingen is de voorkeursbenadering voor de meeste richtlijnen binnen dit kader. Deze aanpak volgt een consistent patroon: stel een algemene eindstatus in, ga snel naar de eerste implementatie, test en valideer veronderstellingen en herstructureer vroeg om foutieve veronderstellingen aan te pakken. Dit type groeimentaliteit maximaliseert het leren en minimaliseert het risico op bedrijfswaarde, maar het vereist enige comfort met dubbelzinnigheid.
Dubbelzinnigheid kan soms eng of gevaarlijker zijn dan valse veronderstellingen. Hoewel dit framework prioriteit geeft aan het leren en aanpakken van dubbelzinnigheid tijdens de implementatie, moeten veel situaties het team prioriteit geven aan benaderingen op basis van analyses of veronderstellingen. De volgende secties bevatten ten minste één voorbeeld van een uitgebreid bereik om aan te geven wanneer een tweede diepere iteratie waardevol kan zijn.
Balans tijdens de strategiefase
Het belangrijkste doel van de strategiemethodologie is het ontwikkelen van afstemming tussen belanghebbenden. Nadat deze is gedefinieerd, bepaalt de uitgelijnde strategische positie het gedrag in elk van de methodologieën om ervoor te zorgen dat technische beslissingen overeenkomen met de gewenste bedrijfsresultaten. Het bevorderen van afstemming tussen belanghebbenden creëert een gemeenschappelijke set concurrerende prioriteiten: diepte van rechtvaardiging versus tijd tot bedrijfsimpact.
Concurrerende prioriteiten:
Diepte van rechtvaardiging: belanghebbenden willen vaak een diepgaande financiële analyse en volledige zakelijke rechtvaardiging voordat ze vertrouwd zijn met het afstemmen op een strategische richting. Helaas kan dit analyseniveau een langere periode vereisen om gegevensverzameling en -analyse mogelijk te maken.
Tijd tot bedrijfsimpact: omgekeerd zijn belanghebbenden vaak verantwoordelijk voor het leveren van bedrijfsresultaten binnen gedefinieerde tijdsbestekken. Tijdrovende analyse en evaluatie kunnen deze resultaten in gevaar brengen voordat het technische werk zelfs begint.
Minimumbereik: Het vinden van het juiste saldo vereist dat belanghebbenden vroeg in het proces discussies voeren. De strategiemethodologie stelt voor om het bereik van de uitlijning tijdens deze vroege inspanning te beperken. In de voorgestelde benadering richten belanghebbenden zich op het uitlijnen van een set kernmotivaties, meetbare resultaten en een zakelijke rechtvaardiging op hoog niveau. Belanghebbenden moeten dan snel enkele initiële projecten of piloten doorvoeren om de vereiste leermogelijkheden te stimuleren.
Voorbeeld van uitgebreid bereik: Als de initiële bedrijfsanalyse aangeeft dat het bedrijf een hoog risico heeft dat negatieve gevolgen heeft voor het bedrijf, moeten belanghebbenden mogelijk vertragen en voorzichtiger een diepere analyse evalueren tijdens zakelijke redenen.
Balans tijdens de planningsfase
Net als tijdens de strategiefase is er behoefte tijdens de planningsfase om de diepte van de initiële planning te verdelen ten opzichte van vertraagde technische beslissingen.
Concurrerende prioriteiten:
De diepte van de initiële planning voor technische implementatie in de cloud is vaak gebaseerd op veel veronderstellingen. Vooral wanneer er sprake is van hiaten in de vaardigheden van het team, lijdt de omgeving aan detectie-hiaten of hebben de workloads geen duidelijk gedefinieerde statussen voor de architectuur. Al deze veronderstellingen komen vaak voor in gedetailleerde plannen voor cloudimplementatie. Experimenten, piloten en kwalitatieve analyses zijn vereist om deze veronderstellingen te verifiëren of te verbeteren.
Vertraagde technische beslissingen zijn gebaseerd op de veronderstelling dat hoe later een technische beslissing wordt genomen, hoe nauwkeuriger het is. Door de principes van agile productplanning te volgen, kunnen technische beslissingen worden vertraagd, zodat ze op het juiste moment kunnen plaatsvinden, op basis van voldoende informatie. Deze aanpak resulteert echter in meer dubbelzinnigheid in het eerste plan.
Minimumbereik: We raden flexibele productontwikkelingsmethoden aan om promptacties binnen beheerbare plannen te stimuleren. De planmethodologie beveelt de volgende stappen aan om dit evenwicht te bereiken:
- Inventariseer de volledige digitale activa met behulp van geautomatiseerde detectiehulpprogramma's, maar gebruik incrementele rationalisatie om de komende 1 tot 3 maanden werk te plannen.
- Zorg ervoor dat de juiste organisatie-uitlijning snel kan worden verplaatst.
- Maak een gereedheidsplan voor vaardigheden voor het toegewezen team. Gebruik de sjabloon strategie en plan om snel een initiële achterstand te implementeren.
Voorbeeld van uitgebreid bereik: De levering van een cloudacceptatieplan kan soms een reactie zijn op een tijdgevoelige of high-impact bedrijfsgebeurtenis. Wanneer succes vereist dat een groot aantal activa gedurende een bepaalde periode wordt verplaatst, worden de voorgaande stappen vaak gevolgd door een diepere planningsinspanning. De sleutel tot succes in deze scenario's is om genoeg te plannen om aan de slag te gaan en vervolgens later te plannen voor de volledige betrokkenheid. Deze aanpak vermindert de kans dat planning bedrijfsresultaten blokkeert.
Balans tijdens de gereedheidsfase
Wanneer teams zich voorbereiden op hun eerste stappen in de overstap naar de cloud, zijn er vaak concurrerende prioriteiten tussen de implementatie en langdurige bewerkingen. Het team kan moeite hebben met het evenwicht tussen goed geschikt zijn om de taak bij de hand te leveren en goed te worden beheerd. Deze strijd is nodig in traditionele IT-omgevingen, waarbij het ontwikkelen van een platform fysieke activa en overnamecycli vereist. Wanneer het hele IT-platform echter in code is gedefinieerd, verminderen traditionele ontwikkelingstactieken, zoals herstructureren, de noodzaak om vanaf het begin goed te worden beheerd.
Concurrerende prioriteiten:
Langdurige bewerkingen: organisaties worden vaak geblokkeerd door de wens om een cloudomgeving te hebben die voldoet aan functiepariteit met huidige operationele beheer-, governance- en beveiligingssystemen. In één studie had meer dan 90 procent van de organisaties ondersteuning nodig om achter die mindset te komen. Deze blokkering kan maanden vertraging creëren, vertragen of de impact van het bedrijf voorkomen.
Tijd tot ingebruikname: cloudhulpprogramma's zoals Azure Policy, continue integratie en continue levering (CI/CD) zoals infrastructuur als code (IaC) en beheergroepen kunnen het proces van herstructurering in het IT-platform vereenvoudigen. Bovendien bieden vooraf gedefinieerde landingszones aanbevelingen om de implementatie te versnellen naar een omgeving die al voldoet aan veel vereisten voor functiepariteit. Deze hulpprogramma's bieden mogelijkheden om de tijd tot de markt te versnellen met minimaal effect op langdurige activiteiten.
Minimumbereik: De methodologie Gereed beschrijft een direct pad van snelle acceptatie tot langdurige bewerkingen. Deze benadering begint met een eenvoudige inleiding tot de hulpprogramma's die u kunt gebruiken om uw omgeving te herstructureren. De hulpprogramma's houden rekening met uw vereisten en begeleiden u bij een selectie van vooraf gedefinieerde landingszones, elk geleverd met IaC-modellen. Vervolgens kunt u de code herstructureren tijdens de overstap naar de cloud om bewerkingen, beveiliging en beheer te verbeteren.
Voorbeeld van uitgebreid bereik: Voor teams waarvan het acceptatieplan een tussentijdse doelstelling (binnen 24 maanden) aanroept om meer dan 1000 assets (toepassingen, infrastructuur of gegevensassets) in de cloud te hosten, raden we een krachtigere weergave van landingszones aan. In deze situaties moet u rekening houden met de methodologieën Voor governance en beheer tijdens uw eerste gesprekken in de landingszone. Deze diepere overweging voegt echter vaak weken of maanden toe aan een plan voor cloudimplementatie. Om het effect op bedrijfsresultaten te minimaliseren, moet het acceptatieteam werkelijke workloads in de cloud testen en tegelijkertijd een meer volwassen landingszone en centrale architectuuroplossing maken.
Balans tijdens de migratiefase
Tijdens de migratie gaan implementatieteams er meestal van uit dat workloads opnieuw worden gehost in de cloud in hun huidige configuratie. Deze veronderstelling concurreert met een vooruitziend plan om elke workload opnieuw te ontwerpen om beter te profiteren van cloudmogelijkheden. De twee weergaven sluiten elkaar niet wederzijds uit en kunnen gratis zijn wanneer u ze beheert met behulp van een gemeenschappelijk proces.
Concurrerende prioriteiten:
Opnieuw hosten: organisaties maken migratie vaak gelijk aan een lift-and-shift-benadering die alle assets repliceert naar de cloud in hun huidige configuratie. Deze aanpak leidt tot weinig afwijking binnen de IT-portfolio. Het is ook de snelste manier om assets in een bestaand datacenter buiten gebruik te stellen.
Opnieuw ontwerpen: door de architectuur van elke workload te moderniseren, wordt de waarde van cloudimplementatie voor kosten, prestaties en bewerkingen gemaximaliseerd. Deze benadering is echter langzamer en vereist vaak toegang tot de broncode van elke toepassing.
Minimumbereik: Gebruik tijdens de planning in een vroeg stadium de optie voor opnieuw hosten voor planning, met een duidelijk begrip dat deze keuze is gebaseerd op een eerste bedrijfsveronderstelling en geen technische beslissing is. In de migratiemethodologie vraagt het cloudacceptatieteam deze aanname voor elke gemigreerde workload uit. Deze methodologie volgt de benadering evalueren/migreren/promoten voor elke workload of groep workloads om een migratiefactory te maken. Tijdens de evaluatiefase evalueert het acceptatieteam de technische fit en architectuur van elke workload. Deze evaluatie-inspanning resulteert zelden in een pure lift-and-shift-benadering, omdat veel van de onderdelen in de architectuur meestal worden geselecteerd voor herstructurering en modernisering.
Voorbeeld van uitgebreid bereik: Voor bedrijfskritieke of zeer gevoelige workloads, zoals mainframe- of multitier-microservicestoepassingen, kan een grondigere evaluatie van de workload vereist zijn tijdens de evaluatiefase. In deze situaties waarin u opnieuw ontwerpt, moet u de Azure Well-Architected Review en het Azure Well-Architected Framework gebruiken om de workloadvereisten tijdens de evaluatie te verfijnen.
Balans tijdens de innovatiefase
Echte klantgerichte innovatie creëert vaak conflicterende prioriteiten tussen de noodzaak om een geplande functieset te leveren en een ontwikkelingsproces voor klant-empathie te implementeren.
Concurrerende prioriteiten:
Focus op functies: initiële plannen voor innovatie bouwen voort op de bestaande digitale activa en cloudmogelijkheden om een set functies te leveren die voldoen aan de behoeften van een klant. Het is eenvoudig om het plan toe te staan om de technische implementatie te stimuleren, wat leidt tot een op functies gerichte ontwikkelingsinspanningen. Deze aanpak leidt vaak tot tijdelijke tevredenheid van belanghebbenden, maar vermindert de kans op innovatie die invloed heeft op het gedrag van klanten.
Empathie van de klant: initiële plannen vormen een belangrijk onderdeel van de bedrijfszijde van de ontwikkeling en moeten worden opgenomen in regelmatige rapportage. Leren, meten en bouwen met empathie van klanten is echter een nauwkeurigere maat voor succes in een innovatie-inspanning. Het focussen op klanten over functies leidt waarschijnlijk tot klanttevredenheid en zakelijke impact op de korte en lange termijn.
Minimumbereik: De innovatiemethodologie illustreert hoe u strategie en plannen integreert via consensus over bedrijfswaarde. De handleiding introduceert vervolgens cloudeigen hulpprogramma's waarmee elke discipline van innovatie en best practices voor implementatie kan worden versneld. Ten slotte toont de sectie procesverbeteringen benaderingen voor het bouwen van empathie voor klanten, terwijl plannen en strategieën in het cloudacceptatietraject worden gerespecteerd. Deze aanpak richt zich op het leveren van innovatie met zo weinig mogelijk technologie.
Voorbeeld van uitgebreid bereik: Een innovatie is soms afhankelijk van bedrijfskritieke of zeer gevoelige workloads. Wanneer de klant een interne gebruiker is, kan de ontwikkelingsinspanning zowel bedrijfskritiek als zeer gevoelig zijn tijdens de vroegste iteraties. In deze scenario's moeten acceptatieteams de Azure Well-Architected Review en het Azure Well-Architected Framework gebruiken om vroeg in het proces een geavanceerd architectuurontwerp te evalueren.
Balans tijdens de governancefase
De praktijk van cloudgovernance is een evenwicht tussen twee concurrerende prioriteiten: snelheid en flexibiliteit versus een goed beheerde omgeving. Het cloudgovernanceteam is gericht op het evalueren en minimaliseren van risico's voor het bedrijf via uniforme controles en het minimaliseren van wijzigingen. Het acceptatieteam richt zich op het stimuleren van bedrijfsresultaten, waarvoor nieuwe risico's nodig zijn en inherent veranderingen ontstaan.
Concurrerende prioriteiten:
- Goed beheerd: Elk besturingselement dat is ontworpen om risico's te minimaliseren, blokkeert een bepaald aspect van de ontwerpopties voor wijzigingen of limieten. Controle is essentieel voor een goed beheerde omgeving. Wanneer besturingselementen echter in isolatie zijn ontworpen en geïmplementeerd, kunnen ze net zo schadelijk zijn als de risico's die ze zijn bedoeld om te voorkomen.
- Snelheid en flexibiliteit: Snelheid en flexibiliteit zijn fundamentele zakelijke vereisten in de digitale economie. Beide vereisen de mogelijkheid om verandering te stimuleren met minimale obstakels voor innovatie of acceptatie. Maar wanneer verandering wordt aangestuurd zonder governance, genereert het nieuwe risico's die het bedrijf op onverwachte manieren kunnen schaden.
Minimumbereik: De Governance-methodologie stelt voor dat governance en acceptatie nooit afzonderlijk moeten plaatsvinden. Deze methodologie begint met een goed begrip van de governancedisciplines en een gesprek over bedrijfsrisico's, beleid en proces. Als actieve deelnemer in de cloudimplementatie kan het governanceteam een minimale set waarborgen implementeren om de tastbare risico's binnen het cloudacceptatieplan aan te pakken. Na verloop van tijd kan het governanceteam deze waarborgen herstructureren en uitbreiden om aan nieuwe risico's te voldoen. Deze aanpak maximaliseert het leren en innoveren en minimaliseert risico's.
Voorbeeld van uitgebreid bereik: Wanneer het bedrijfsrisico hoog is, met name vroeg in de acceptatie, moet het cloudgovernanceteam mogelijk de uitbreiding van governance-implementaties versnellen. U kunt dezelfde richtlijnen en oefeningen gebruiken om dit hogere governanceniveau toe te voegen, maar mogelijk moet u sneller gaan. In sommige scenario's is mogelijk zelfs een geavanceerde governancestatus vereist tijdens het ontwikkelen van de eerste landingszones.
Balans tijdens de beheerfase
Het IT-bedrijfsmodel voor operationeel beheer is de afgelopen tien jaar voortdurend verder ontwikkeld. Naarmate hardwareonderhoud verder gaat van de kernwaardepropositie van IT, is de weergave over operations management verschoven. Naarmate DE IT zich richt op het leveren van bedrijfswaarde, worden teams voor operations-beheer conflicteren door de noodzaak om no-ops en low-ops te verdelen ten opzichte van brede investeringen.
Concurrerende prioriteiten:
Brede investeringen: investeren in het vermijden van storingen, snel herstel en bewaking in de hele omgeving is de traditionele benadering van operationeel beheer. Deze benadering kan duur zijn en soms dupliceren de ondersteunende producten van de cloudleverancier.
No-ops en low-ops: gebruik cloudeigen bewerkingsprogramma's om terugkerende en terugkerende taken te minimaliseren die eerder door uw werknemers werden geleverd. Door deze operationele afhankelijkheden te verminderen, kunnen werknemers waarde op andere manieren stimuleren. In isolatie kan deze benadering echter leiden tot ondersteuning voor subparbewerkingen.
Minimumbereik: De methodologie Beheren stelt voor om een cloudeigen no-ops-basislijn te maken. Als u erkent dat de no-ops-basislijn niet aan alle bedrijfsbehoeften voldoet, moet u samenwerken met het bedrijf om toezeggingen te definiëren en investeringen beter af te stemmen. Vouw de basislijn uit om te voldoen aan algemene behoeften voor alle workloads. Schakel vervolgens platformteams of specifieke workloadteams in om goed beheerde oplossingen binnen een goed beheerde omgeving te onderhouden.
Voorbeeld van uitgebreid bereik: In de meeste omgevingen rechtvaardigt de bedrijfswaarde van een klein percentage workloads diepe investeringen in bewerkingen van IT. Voor deze workloads kan het IT-team de Azure Well-Architected Review en het Azure Well-Architected Framework gebruiken om diepere bewerkingen te begeleiden.
Balans tijdens de organisatiefase
De concurrerende prioriteiten die in dit artikel worden beschreven, weerspiegelen het streven van IT om te voldoen aan zakelijke vereisten voor snelheid en flexibiliteit. Dezelfde verschuiving wordt weergegeven in wijzigingen in organigrammen of virtuele teamstructuren om betere ondersteuning te bieden voor bedrijfsresultaten. Aangezien IT-leiders nadenken over teamstructuren, worden er vaak twee concurrerende prioriteiten aangepakt: gecentraliseerd beheer versus gedelegeerd beheer.
Concurrerende prioriteiten:
Gecentraliseerd beheer: Dit operationele model richt zich op de centralisatie van alle besturingselementen die nodig zijn om strikt beleid af te dwingen. In dit model fungeert IT als een obstakel voor innovatie, snelheid en flexibiliteit. IT kan echter een hogere mate van stabiliteit, naleving en beveiliging garanderen.
Gedelegeerd beheer: In dit gedistribueerde operationele model wordt ervan uitgegaan dat elk DevOps-team of bedrijfstoepassingsteam een eigen set besturingselementen levert op basis van de oplossingen die nodig zijn om te voldoen aan bedrijfsdoelstellingen. In dit model biedt IT richtlijnen om teams te helpen risico's te voorkomen, maar het aantal afgedwongen technische beperkingen waar mogelijk te minimaliseren.
Minimumbereik: De meeste organisaties doorlopen een natuurlijke reeks evoluties in de loop van de tijd. De methodologie Organiseren bevat een overzicht van de meest voorkomende reeks evoluties. We raden teams aan om over te stappen op een CCoE-structuur (Cloud Center of Excellence) om gedelegeerde controlemethoden te bieden.
Voorbeeld van uitgebreid bereik: Veel situaties activeren een behoefte aan gecentraliseerd beheer. Nalevingsvereisten van derden en tijdelijke blootstelling aan beveiliging zijn twee voorbeelden van triggers voor gecentraliseerd beheer. In deze situaties is het vaak nodig om het beperken van beleid en strikte, vaste controles vast te stellen. Om innovatie en acceptatie mogelijk te maken, raden we centrale IT-teams echter aan om deze controles te leveren op basis van de kritiek en gevoeligheid van elke workload. Het bieden van omgevingen met minder controle, maar een beperkt bereik of risicoprofiel maakt flexibiliteit mogelijk, zelfs wanneer controle vereist is.
Volgende stappen
Leer hoe u migratie, innovatie en experimenten kunt verdelen om de waarde van uw cloudmigratie-inspanningen te maximaliseren.