Het portfolio in balans brengen

Cloudacceptatie is een inspanning voor portfoliobeheer, slim vermomd als technische implementatie. Net als bij elke andere oefening in portfoliobeheer is het essentieel om de portfolio in balans te brengen. Op strategisch niveau betekent dit een uitgebalanceerde migratie, innovatie en experimenten, om optimaal te profiteren van de cloud. Wanneer de cloudimplementatie te ver in één richting afbuigt, vindt de complexiteit plaats in de implementatie-inspanningen. In dit artikel maakt de lezer kennis met benaderingen voor een uitgebalanceerd portfolio.

Uitbreiding van algemeen bereik

Het balanceren van de portefeuille is strategisch van aard. Als zodanig is de benadering die in dit artikel wordt gebruikt evenzeer strategisch. Om de strategie te baseren op gegevensgestuurde beslissingen, wordt in dit artikel ervan uitgegaan dat de lezer de bestaande digitale activa heeft geëvalueerd of dat proces is gestart. Het doel van deze aanpak is om te helpen bij het evalueren van workloads om te zorgen voor een juist evenwicht tussen het portfolio, door middel van kwalitatieve vragen en verfijning van het portfolio.

Bedrijfsresultaten documenteren

Voordat u het portfolio in balans houdt, is het belangrijk om de bedrijfsresultaten te documenteren en te delen die de cloudmigratie stimuleren. De volgende tabel kan u helpen bij het documenteren en delen van de gewenste bedrijfsresultaten. Het is belangrijk te weten dat de meeste bedrijven meerdere resultaten per keer trachten te bereiken. Het belang van deze oefening is om de resultaten te verduidelijken die het meest direct verband houden met de cloudmigratie-inspanning:

Resultaat	Gemeten door	Doel	Tijdsbestek	Prioriteit voor deze inspanning
It-kosten verlagen	Datacenterbudget	Verminderen met $ 2 miljoen USD	12 maanden	#1
Datacenter afsluiten	Sluit datacentra af	2 datacenters	6 maanden	#2
Flexibiliteit van bedrijf verhogen	Marktintroductietijd verbeteren	Implementatietijd verkorten met zes maanden	Twee jaar	#3
De klantervaring verbeteren	Klanttevredenheid (CSAT)	10% verbetering	12 maanden	#4

Belangrijk

De bovenstaande tabel is een fictief voorbeeld en mag niet worden gebruikt om prioriteiten in te stellen. In veel gevallen kan deze tabel worden beschouwd als antipatroon door kostenbesparingen boven klantervaringen te plaatsen.

De bovenstaande tabel kan de prioriteiten van het cloudstrategieteam en het cloudacceptatieteam nauwkeurig weergeven. Door beperkingen op korte termijn legt dit team meer nadruk op verlaging van IT-kosten en het prioriteren van het afsluiten van een datacenter als een middel om de gewenste IT-kostenverlagingen te verkrijgen. Door de concurrerende prioriteiten in deze tabel te documenteren, is het cloudacceptatieteam echter beter in staat om het cloudstrategieteam te helpen bij het identificeren van mogelijkheden om de implementatie van de overkoepelende portfoliostrategie beter uit te lijnen.

Snel handelen en toch het evenwicht bewaren

De richtlijnen met betrekking tot incrementele rationalisering van het digitaal onroerend goed stellen een benadering voor waarbij de rationalisering begint met een onevenwichtige positie. Het cloudstrategieteam moet elke workload met een rehost-benadering evalueren op compatibiliteit. Een dergelijke benadering wordt voorgesteld omdat deze een snelle evaluatie van complex digitaal onroerend goed op basis van kwantitatieve gegevens mogelijk maakt. Dankzij een dergelijke eerste aanname kan het cloudacceptatieteam snel aan de slag en sneller bedrijfsresultaten behalen. Zoals vermeld in dat artikel, bieden kwalitatieve vragen echter het vereiste evenwicht in het portfolio. In dit artikel wordt het proces voor het maken van het toegezegde evenwicht gedocumenteerd.

Belang van verval- en buitengebruikstellingsbeslissingen

In de tabel in de sectie Bedrijfsresultaten documenteren hierboven ontbreekt een belangrijk resultaat dat de belangrijkste doelstelling van het verlagen van IT-kosten zou ondersteunen. Als de verlaging van IT-kosten ergens in de lijst met bedrijfsresultaten voorkomen, is het belangrijk dat er rekening wordt gehouden met de mogelijkheid om workloads te laten vervallen of buiten gebruik te stellen. In sommige scenario's kunnen kostenbesparingen het gevolg zijn van het niet migreren van workloads die geen investering op korte termijn rechtvaardigen. Sommige klanten hebben een kostenbesparing van meer dan 20% van de totale kosten gerapporteerd door onderbenutte workloads buiten gebruik te stellen.

Het cloudstrategieteam en het cloudacceptatieteam worden aangemoedigd om de volgende vragen van elke workload te stellen tijdens de evaluatie- en migratiefasen om de portfolio in balans te houden en beslissingen over buiten gebruik te stellen:

• Is de workload in de afgelopen zes maanden gebruikt door eindgebruikers?
• Is het verkeer van eindgebruikers consistent of groeit het?
• Zal het bedrijf deze workload de komende 12 maanden vanaf nu nodig hebben?

Als het antwoord op een van deze vragen 'nee' is, kan de workload een kandidaat voor pensionering zijn. Als het buitengebruikstellingspotentieel wordt bevestigd door de eigenaar van de toepassing, is het mogelijk niet zinvol om de workload te migreren. Dit geeft aanleiding tot een aantal kwalificatievragen:

• Kan er buitengebruikstellingsplan of een vervalplan voor deze workload worden gemaakt?
• Kan deze workload buiten gebruik worden gesteld voordat het datacenter wordt afgesloten?

Als het antwoord op beide vragen 'ja' is, is het verstandig om de workload niet te migreren. Deze aanpak helpt bij het bereiken van de doelstellingen van het verlagen van de kosten en het afsluiten van het datacenter.

Als het antwoord op een van de vragen 'nee' is, kan het verstandig zijn om een plan op te stellen voor het hosten van de workload totdat deze buiten gebruik kan worden gesteld. Dit plan kan bijvoorbeeld bestaan uit het verplaatsen van de assets naar een goedkoper of ander datacenter, waardoor de doelstellingen van het verlagen van de kosten en het verlaten van één datacenter ook worden gerealiseerd.

Proceswijzigingen aannemen

Voor het in balans brengen van de portfolio is aanvullende kwalitatieve analyse vereist tijdens de fase Adopt, die helpt bij het stimuleren van eenvoudige portfoliorationalisatie.

Op basis van de gegevens uit de tabel in de sectie Bedrijfsresultaten documenteren hierboven, bestaat het risico dat het portfolio te veel overhelt naar een migratiegericht uitvoeringsmodel. Als de ervaring van de klant de hoogste prioriteit had, zou een portfolio met veel innovatie waarschijnlijker zijn. Geen van beide is goed of fout, maar te veel overhellen naar één kant leidt in het algemeen tot afnemende resultaten, grotere complexiteit en een langere uitvoeringstijd ten aanzien van cloudacceptatie-inspanningen.

Als u de complexiteit wilt verminderen, moet u een traditionele benadering van portfoliorationalisatie volgen, maar in een iteratief model. De volgende stappen beschrijven een kwaliteitsmodel voor een dergelijke benadering:

• Het cloudstrategieteam houdt een geprioriteerde lijst bij van workloads die nog moeten worden gemigreerd.
• Het cloudstrategieteam en het cloudacceptatieteam houden een bijeenkomst over releaseplanning voordat elke release is voltooid.
• Tijdens deze bijeenkomst stellen de teams een top 5 tot 10 op van workloads in de geprioriteerde achterstandslijst.
• Buiten deze bijeenkomst stelt het cloudacceptatieteam de volgende vragen van toepassingseigenaren en experts:
  • Kan deze toepassing worden vervangen door een gelijkwaardig PaaS (platform als een service)?
  • Is deze toepassing een toepassing van derden?
  • Is er een budget goedgekeurd om de komende 12 maanden te investeren in de voortdurende ontwikkeling van de toepassing?
  • Zal aanvullende ontwikkeling van deze toepassing de ervaring van de klant verbeteren? Een competitief onderscheid maken? Meer omzet voor het bedrijf?
  • Zullen de gegevens in deze workload bijdragen aan een downstream-innovatie met betrekking tot BI, machine learning, IoT of gerelateerde technologieën?
  • Is de workload compatibel met moderne toepassingsplatforms zoals Azure App Service?
• De antwoorden op bovenstaande vragen en alle andere vereiste kwalitatieve analysen hebben vervolgens invloed op aanpassingen aan de geprioriteerde achterstandslijst. Deze aanpassingen kunnen zijn:
  • Als een workload kan worden vervangen door een PaaS-oplossing, kan deze mogelijk volledig worden verwijderd uit de migratieachterstand. Er wordt minimaal extra due diligence toegevoegd om te beslissen tussen opnieuw hosten en vervangen als een taak, waardoor de prioriteit van die workload tijdelijk wordt verminderd ten opzichte van de migratieachterstand.
  • Als een workload een ontwikkelingsverbetering ondergaat (of zou moeten zijn), past deze mogelijk het beste in een model voor herstructureren/herbouwen. Omdat innovatie en migratie andere technische vaardigheden vereisen, moeten toepassingen die zijn afgestemd op een herstructurerings-rearchitect-rebuild-aanpak, worden beheerd via een innovatieachterstand in plaats van een migratieachterstand.
  • Als een workload deel uitmaakt van een downstream-innovatie, kan het zinvol zijn om het gegevensplatform te herstructureren, maar de toepassingslagen te behouden als een kandidaat voor rehosting. Kleine herstructurering van het gegevensplatform van een workload kan vaak worden opgelost in een migratie- of innovatieachterstand. Dit rationaliseringsresultaat kan leiden tot gedetailleerdere werkitems in de achterstand, maar niet tot gewijzigde prioriteiten.
  • Als een workload niet strategisch is, maar compatibel is met moderne, cloudgebaseerde platformen voor het hosten van toepassingen, kan het verstandig zijn om kleine herstructureringen uit te voeren op de toepassing om deze als een moderne toepassing te implementeren. Dit kan bijdragen tot algemene besparingen door de algemene IaaS- en OS-licentievereisten van de cloudmigratie te verminderen.
  • Als een workload een toepassing van derden is en de gegevens van die workload niet zijn gepland voor gebruik in een downstream-innovatie, is het wellicht beter om deze als een optie voor opnieuw hosten in de achterstand te laten staan.

Deze vragen mogen niet de omvang zijn van de kwalitatieve analyse die voor elke workload is voltooid, maar ze helpen een gesprek te voeren over het aanpakken van de complexiteit van een onevenwichtige portfolio.

Wijzigingen in het migratieproces

Tijdens de migratie kunnen portfolioverdelingsactiviteiten een negatieve invloed hebben op de migratiesnelheid (de snelheid waarmee assets worden gemigreerd). De volgende richtlijnen hebben betrekking op waarom en hoe werk moet worden uitgelijnd om onderbrekingen van de migratie-inspanning te vermijden.

Voor de rationalisering van het portfolio is diversiteit van technische inspanningen vereist. Cloudacceptatieteams hebben de neiging om die portfoliodiversiteit in migratie-inspanningen te bekijken. Zakelijke belanghebbenden vragen één cloudacceptatieteam om de volledige migratieachterstand aan te pakken. Dit is zelden een aanbevolen benadering, en werkt in veel gevallen zelfs averechts.

Deze uiteenlopende inspanningen moeten worden gesegmenteerd over twee of meer teams voor cloudimplementatie. Als u een model met twee teams gebruikt als voorbeeld van de uitvoeringsmodus, is team 1 het migratieteam en team 2 het innovatieteam. Voor grotere inspanningen kunnen deze teams verder worden gesegmenteerd om andere benaderingen aan te pakken, zoals vervangings-/PaaS-inspanningen of kleine herstructureringen. Hieronder vindt u een overzicht van de vaardigheden en rollen die nodig zijn voor het opnieuw hosten, herstructureren of kleine herstructurering:

Opnieuw hosten: Opnieuw hosten vereist dat teamleden infrastructuurgerichte wijzigingen implementeren. In het algemeen gebruikt u een hulpprogramma als Azure Site Recovery om VM's of andere assets naar Azure te migreren. Dit werk kan goed worden uitgelijnd met datacenterbeheerders of IT-implementeerders. Het cloudmigratieteam is goed gestructureerd om dit werk op grote schaal te leveren. Dit is in de meeste scenario's de snelste manier om bestaande assets te migreren.

Refactor: Herstructurering vereist dat teamleden de broncode wijzigen, de architectuur van een toepassing wijzigen of nieuwe cloudservices gebruiken. In het algemeen worden voor deze inspanningen ontwikkelhulpprogramma's als Visual Studio en hulpprogramma's voor implementatiepijplijnen, zoals Azure DevOps, gebruikt om gemoderniseerde toepassingen opnieuw te implementeren naar Azure. Dit werk is geschikt voor toepassingsontwikkelingsrollen of DevOps-pijplijnontwikkelingsrollen. Het cloudinnovatieteam is het best gestructureerd om dit werk te leveren. Het kan bij deze benadering langer duren om bestaande assets te vervangen door cloudassets, maar de toepassingen kunnen profiteren van cloudeigen functies.

Kleine herstructurering: Sommige toepassingen kunnen worden gemoderniseerd met een kleine herstructurering op gegevens- of toepassingsniveau. Voor dit werk moeten teamleden gegevens implementeren op cloud-gebaseerde gegevensplatforms of kleine configuratiewijzigingen aanbrengen in de toepassing. In dit geval is mogelijk beperkte ondersteuning van deskundigen van het ontwerp vereist voor gegevens- of toepassingsontwikkeling. Dit werk is echter vergelijkbaar met het werk dat it-implementors uitvoeren bij het implementeren van toepassingen van derden. Dit werk kan eenvoudig worden uitgelijnd met het cloudmigratieteam of het cloudstrategieteam. Hoewel deze inspanning zeker niet zo snel is als een migratie met rehosting, neemt de uitvoering ervan minder tijd in beslag dan herstructureringsinspanningen.

Tijdens de migratie moeten de inspanningen worden gesegmenteerd op de drie hierboven vermelde manieren en worden uitgevoerd door het juiste team in de juiste iteratie. Hoewel u de portefeuille moet diversifiëren, moet u er ook voor zorgen dat de inspanningen zeer gefocust en gescheiden blijven.

Volgende stappen

Krijg inzicht in hoe wereldwijde marktbeslissingen van invloed kunnen zijn op uw transformatietraject.

Inzicht in wereldwijde markten