Algemene operationele modellen voor de cloud controleren en vergelijken

Artikel
03/22/2023

Operationele modellen zijn uniek en specifiek voor het bedrijf dat ze ondersteunen, op basis van hun huidige vereisten en beperkingen. Maar operationele modellen zijn geen sneeuwvlokken. Er zijn verschillende algemene patronen in operationele modellen van klanten; in dit artikel worden de vier meest voorkomende patronen beschreven.

Vergelijking van operationele modellen

In de volgende afbeelding worden algemene operationele modellen toegewezen op basis van het bereik van complexiteit, van minst complex (gedecentraliseerd) tot de meest complexe (wereldwijde bewerkingen). In de volgende tabellen worden dezelfde operationele modellen vergeleken op basis van de relatieve waarde van enkele andere kenmerken.

Diagram met de mate van complexiteit van het operationele model.

Prioriteiten of bereik

Een cloudbedrijfsmodel wordt voornamelijk aangestuurd door twee factoren:

Strategische prioriteiten of motivaties
Bereik van de portfolio die moet worden beheerd

	Gedecentraliseerde bewerkingen (ops)	Gecentraliseerde bewerkingen (ops)	Enterprise-bewerkingen (ops)	Gedistribueerde bewerkingen (ops)
Strategische prioriteiten of motivaties	Innovatie	Controle	Democratisering	Integratie
Portfoliobereik	Workload	Landingszone	Cloudplatform	Volledig portfolio
Workloadomgeving	Hoge complexiteit	Lage complexiteit	Gemiddelde complexiteit	Gemiddelde of variabele complexiteit
Landingszone	N.v.t.	Hoge complexiteit	Gemiddelde tot lage complexiteit	Lage complexiteit
Basishulpprogramma's	N.v.t.	N.a.w. of weinig ondersteuning	Gecentraliseerde en meer ondersteuning	De meeste ondersteuning
Cloudfundament	N.v.t.	N.v.t.	Hybride, providerspecifieke of regionale basis	Gedistribueerd en gesynchroniseerd

Strategische prioriteiten of motivaties: elk operationeel model levert de typische strategische motivaties voor cloudimplementatie. Maar sommige operationele modellen vereenvoudigen specifieke motivaties.
Portfoliobereik: Het portfoliobereik identificeert het grootste bereik dat een specifiek operationeel modelontwerp ondersteunt. Gecentraliseerde bewerkingen zijn bijvoorbeeld ontworpen voor enkele landingszones. Maar de beslissing over het operationele model kan operationele risico's voor een organisatie met zich meebrengen. Operationele risico's ontstaan bij het beheren van een groot complex portfolio. Deze portfolio's vereisen mogelijk veel landingszones of variabele complexiteit in het ontwerp van landingszones.

Belangrijk

Het overstappen op de cloud activeert vaak reflectie op het huidige operationele model en kan leiden tot een verschuiving van het ene algemene operationele model naar het andere. Maar cloudacceptatie is niet de enige trigger. Bedrijfsprioriteiten en het bereik van cloudacceptatie kunnen de ondersteuning van het portfolio veranderen. Er kunnen ook andere verschuivingen zijn in het meest geschikte operationele model. Wanneer de directie of andere managementteams bedrijfsplannen van 5 tot 10 jaar ontwikkelen, bevatten deze plannen vaak een vereiste (expliciet of impliciet) om het operationele model aan te passen. Operationele modellen zijn een goede referentie voor het sturen van beslissingen. Deze modellen kunnen veranderen of moeten worden aangepast om te voldoen aan uw vereisten en beperkingen.

Verantwoordelijkheidsuitlijning

Veel teams en personen zijn verantwoordelijk voor de ondersteuning van verschillende functies. Maar elk algemeen operationeel model wijst de uiteindelijke verantwoordelijkheid voor beslissingsresultaten toe aan één team of persoon. Deze benadering is van invloed op hoe het operationele model wordt gefinancierd en welk ondersteuningsniveau voor elke functie wordt geboden.

	Gedecentraliseerde ops	Gecentraliseerde bewerkingen	Enterprise-ops	Gedistribueerde ops
Bedrijfsafstemming	Workloadteam	Centrale cloudstrategie	CCoE	Variabele: een breed cloudstrategieteam vormen?
Cloudbewerkingen	Workloadteam	Centrale IT	CCoE	Op basis van portfolioanalyse - zie Bedrijfsuitlijning en bedrijfstoezeggingen
Cloudgovernance	Workloadteam	Centrale IT	CCoE	Meerdere governancelagen
Cloudbeveiliging	Workloadteam	Security Operations Center (SOC)	CCoE + SOC	Gemengd- zie Een beveiligingsstrategie definiëren
Cloudautomatisering en DevOps	Workloadteam	Centrale IT of N/B	CCoE	Op basis van portfolioanalyse - zie Bedrijfsuitlijning en bedrijfstoezeggingen

Implementatie van operationele modellen versnellen in Azure

Zoals besproken in Uw operationele model definiëren, biedt elke methodologie van de Cloud Adoption Framework een gestructureerd pad voor het ontwikkelen van uw operationele model. Deze methodologieën kunnen u helpen om obstakels te overwinnen die het gevolg zijn van hiaten in de overstap naar het cloudbedrijfsmodel.

De volgende tabel bevat een overzicht van manieren om de implementatie van uw operationele model te versnellen.

	Gedecentraliseerde ops	Gecentraliseerde bewerkingen	Enterprise-ops	Gedistribueerde ops
Uitgangspunt	Azure Well-Architected Framework (WAF)	Azure-landingszones: opties voor kleine start	Azure-landingszones: CAF enterprise-scale	Bedrijfsafstemming
Iteraties	Een focus op workloads kan het team herhalen binnen WAF.	De start-small-optie vereist meer iteratie voor elke methodologie, maar kan worden uitgevoerd naarmate de cloudimplementatie zich verder ontwikkelen.	Zoals wordt geïllustreerd door de referentie-implementaties, richten toekomstige iteraties zich meestal op kleine configuratie-toevoegingen.	Bekijk de implementatieopties voor de Azure-landingszone om te beginnen met de optie die het beste voldoet aan uw basislijn voor bewerkingen. Volg het iteratiepad dat is gedefinieerd in de ontwerpprincipes van die optie.

Gedecentraliseerde bewerkingen

Bewerkingen zijn altijd complex. Als u het bereik van uw bewerkingen beperkt tot één workload of een kleine verzameling workloads, bepaalt u de complexiteit. Gedecentraliseerde bewerkingen zijn de minst complexe van de algemene operationele modellen. In deze vorm van bewerkingen worden alle workloads onafhankelijk uitgevoerd door toegewezen workloadteams.

Prioriteiten: Uw team meet innovatie ten opzichte van gecentraliseerd beheer of standaardisatie voor meerdere workloads.
Uniek voordeel: maximaliseer de snelheid van innovatie door workload- en bedrijfsteams volledige controle te bieden over ontwerp, build en bewerkingen.
Uniek nadeel: vermindering van standaardisatie voor meerdere workloads, schaalvoordelen via gedeelde services en consistente gecentraliseerde nalevingsinspanningen voor governance.
Risico: Deze benadering brengt risico's met zich mee bij het beheren van een portfolio met workloads. Workloadteams hebben mogelijk gespecialiseerde teams die zijn toegewezen aan centrale IT-functies. Dit operationele model wordt door sommige organisaties beschouwd als een optie met een hoog risico, met name bedrijven die nalevingsvereisten van derden moeten volgen.
Richtlijnen: Gedecentraliseerde bewerkingen zijn beperkt tot beslissingen op workloadniveau. Microsoft Azure Well-Architected Framework ondersteunt de beslissingen die binnen dat bereik worden genomen. De processen en richtlijnen binnen de Cloud Adoption Framework kunnen overhead toevoegen die niet is vereist voor gedecentraliseerde bewerkingen.

Voordelen van gedecentraliseerde bewerkingen

Kostenbeheer: Kosten van bewerkingen kunnen eenvoudig worden toegewezen aan één bedrijfseenheid. Workloadspecifieke bewerkingen ondersteunen een grotere optimalisatie van workloads.
Verantwoordelijkheden: deze vorm van bewerkingen is doorgaans sterk afhankelijk van automatisering om overhead te minimaliseren. Verantwoordelijkheden zijn meestal gericht op DevOps en pijplijnen voor releasebeheer. Dit type bewerkingen ondersteunt snellere implementaties en kortere feedbackcycli tijdens de ontwikkeling.
Standaardisatie: gebruik een broncode- en implementatiepijplijn om de omgeving van release tot release te standaardiseren.
Ondersteuning voor bewerkingen: beslissingen die van invloed zijn op bewerkingen, hebben alleen betrekking op de behoeften van die workload en het vereenvoudigen van beslissingen over bewerkingen. Leden van de DevOps-community zeggen dat ondersteuning voor bewerkingen de zuiverste vorm van bewerkingen is vanwege het kleinere operationele bereik.
Expertise: DevOps en ontwikkelteams worden het meest ondersteund door deze aanpak en ondervinden de minste weerstand tegen marktveranderingen.
Ontwerp van landingszone: geen specifiek operationeel voordeel.
Basishulpprogramma's: geen specifiek operationeel voordeel.
Scheiding van taken: geen specifiek operationeel voordeel.

Nadelen van gedecentraliseerde bewerkingen

Kostenbeheer: Enterprise-kosten zijn moeilijker te berekenen. Het ontbreken van gecentraliseerde governanceteams maakt het moeilijker om uniforme kostencontroles of optimalisaties te implementeren. Op schaal kan dit model kostbaar zijn, omdat elke workload mogelijk duplicatie heeft in geïmplementeerde assets en personeelstoewijzingen.
Verantwoordelijkheden: Gebrek aan gecentraliseerde ondersteuning betekent dat het workloadteam volledig verantwoordelijk is voor governance, beveiliging, bewerkingen en wijzigingsbeheer. Het gebrek aan ondersteuning is problematisch wanneer deze taken niet zijn geautomatiseerd in codebeoordelings- en releasepijplijnen.
Standaardisatie: Standaardisatie voor een portfolio van workloads is variabel en inconsistent.
Ondersteuning voor bewerkingen: Schaalefficiëntie wordt vaak gemist bij het maken van best practices voor meerdere workloads.
Expertise: teamleden hebben een grotere verantwoordelijkheid om verstandige en ethische beslissingen te nemen over governance, beveiliging, bewerkingen en wijzigingsbeheer binnen het ontwerp en de configuratie van de toepassing. Raadpleeg regelmatig de Microsoft Azure Well-Architected Review en Azure Well-Architected Framework om de vereiste expertise te verbeteren.
Ontwerp van landingszone: Landingszones zijn niet workloadspecifiek en worden niet meegenomen in deze benadering.
Basishulpprogramma's: er worden weinig (indien aanwezig) basisservices gedeeld tussen workloads, waardoor de schaalefficiëntie wordt verminderd.
Scheiding van taken: Hogere vereisten voor DevOps en ontwikkelteams verhogen het gebruik van verhoogde bevoegdheden van deze teams. Als u scheiding van taken nodig hebt, moet u mogelijk veel investeren in DevOps-volwassenheid om met deze aanpak te kunnen werken.

Gecentraliseerde bewerkingen

Voor stabiele statusomgevingen is mogelijk geen focus vereist op de architectuur of afzonderlijke operationele vereisten van de afzonderlijke workloads. Centrale bewerkingen zijn meestal de norm voor technologische omgevingen die voornamelijk bestaan uit workloads met een stabiele status. Voorbeelden van stabiele statusbewerkingen zijn zaken zoals commerciële standaardtoepassingen (COTS) of bekende aangepaste toepassingen met een trage releasefrequentie. Als een snelheid van wijzigingen wordt aangedreven door regelmatige updates en patches, kan de centralisatie van bewerkingen een effectieve manier zijn om uw portfolio te beheren.

Prioriteiten: Prioriteiten zijn de centrale controle over innovatie en meten de bestaande operationele processen over de culturele verschuiving naar moderne cloudbewerkingen.
Uniek voordeel: Centralisatie introduceert schaalvoordelen, de beste besturingselementen en gestandaardiseerde bewerkingen, en werkt het beste met de cloudomgeving. Deze omgevingen hebben specifieke configuraties nodig om cloudbewerkingen te integreren in bestaande bewerkingen en processen. Centralisatie is het voordeligst met een portfolio van een paar honderd workloads met een bescheiden architectuurcomplexiteit en nalevingsvereisten.
Uniek nadeel: Schalen om te voldoen aan de vereisten van een groot portfolio met workloads kan een aanzienlijke belasting vormen voor gecentraliseerde teams die operationele beslissingen nemen voor productieworkloads. Als technische assets meer dan 1000 VM's, toepassingen of gegevensbronnen verwachten te schalen, kunt u een bedrijfsmodel overwegen als dit binnen 18-24 maanden duurt.
Risico: deze benadering beperkt centralisatie tot een kleiner aantal abonnementen (vaak één productieabonnement). Er is een aanzienlijk risico betrokken bij het herstructureren later in uw cloudtraject en kan uw ingebruiknameplannen verstoren. Als u opnieuw werk wilt voorkomen, kunt u zich richten op segmentatie, omgevingsgrenzen, identiteitshulpprogramma's en andere basiselementen.
Richtlijnen: Implementatieopties voor Azure-landingszones die zijn afgestemd op de ontwikkelsnelheid 'klein beginnen en uitbreiden' vormen een goed uitgangspunt. U kunt deze opties gebruiken om de acceptatie te versnellen. Maar om succesvol te zijn, moet u duidelijk beleid opstellen om vroege acceptatie-inspanningen binnen acceptabele risicotoleranties te begeleiden. Methodologieën beheren en beheren helpt bij het maken van processen om bewerkingen parallel te ontwikkelen. Het volgen van deze stappen fungeert als fasepoorten die moeten worden voltooid voordat een verhoogd risico wordt toegestaan naarmate de bewerkingen volwassen worden.

Voordelen van gecentraliseerde bewerkingen

Kostenbeheer: het centraliseren van gedeelde services in veel workloads zorgt voor schaalvoordelen en elimineert dubbele taken. Centrale teams kunnen snel kostenreducties implementeren via optimalisaties voor de grootte en schaal van de hele onderneming.
Verantwoordelijkheden: Gecentraliseerde expertise en standaardisatie kan leiden tot een hogere stabiliteit, betere operationele prestaties en minimale storingen in verband met wijzigingen. Deze aanpak vermindert de druk op brede vaardigheden op de teams die zijn gericht op werkbelasting.
Standaardisatie: Over het algemeen zijn standaardisatie en kosten van bewerkingen het laagst bij een gecentraliseerd model, omdat er minder dubbele systemen of taken zijn.
Ondersteuning voor bewerkingen: door de complexiteit te verminderen en bewerkingen te centraliseren, kunnen kleinere IT-teams gemakkelijker bewerkingen ondersteunen.
Expertise: Door ondersteunende teams te centraliseren, kunnen experts op het gebied van beveiliging, risico, governance en bewerkingen bedrijfskritieke beslissingen nemen.
Ontwerp van landingszones: Centrale IT vermindert de complexiteit door het aantal landingszones en abonnementen te minimaliseren. Ontwerpen voor landingszones bootsen meestal de voorgaande datacenterontwerpen na, waardoor de overgangstijd wordt verkort. Naarmate de overstap vordert, kunnen gedeelde resources worden verplaatst naar een afzonderlijk abonnement of platformfundament.
Basishulpprogramma's: U draagt bestaande datacenterontwerpen over in de cloud en resulteert in fundamentele, gedeelde services die on-premises hulpprogramma's en bewerkingen nabootsen. Wanneer on-premises bewerkingen uw primaire operationele model zijn, kan dit een voordeel zijn, maar pas op voor enkele nadelen. On-premises bewerkingen verkorten de overgangstijd, profiteren van schaalvoordelen en ondersteunen consistente operationele processen tussen on-premises en in de cloud gehoste workloads. Deze aanpak kan de complexiteit en inspanning op de korte termijn verminderen en kleinere teams cloudbewerkingen laten ondersteunen met beperkte leercurven.
Scheiding van taken: Scheiding van taken is duidelijk in centrale operaties. De centrale IT-afdeling houdt de controle over de productieomgevingen en vermindert de noodzaak van verhoogde machtigingen van andere teams. Deze aanpak vermindert schendingen door het aantal accounts met verhoogde bevoegdheden te beperken.

Nadelen van gecentraliseerde bewerkingen

Kostenbeheer: Centrale teams begrijpen workloadarchitecturen niet altijd om impactvolle optimalisaties op workloadniveau te produceren. Dit gebrek aan begrip beperkt de hoeveelheid kostenbesparingen die worden gegenereerd door goed afgestemde workloadbewerkingen. Het niet volledig begrijpen van de workloadarchitectuur kan van invloed zijn op gecentraliseerde kostenoptimalisaties, die van invloed zijn op prestaties, schaal en andere pijlers van een goed ontworpen workload. Voordat u bedrijfsbrede kostenwijzigingen toepast op belangrijke workloads, moet uw centrale IT-team de Microsoft Azure Well-Architected Review begrijpen en voltooien.
Verantwoordelijkheden: Het centraliseren van productieondersteuning en -toegang brengt een hoge operationele last met zich mee voor een paar mensen en een grotere druk op elk individu. De druk die op deze personen wordt uitgeoefend, zorgt ervoor dat de geïmplementeerde workloads grondiger moeten worden gecontroleerd, waardoor de naleving van gedetailleerde vereisten voor beveiligingsgovernance en naleving wordt gevalideerd.
Standaardisatie: centrale IT-benaderingen maken het moeilijk om standaardisatie te schalen zonder lineair schalen van centrale IT-medewerkers.
Ondersteuning voor bewerkingen: De grootste nadelen van deze aanpak zijn gekoppeld aan aanzienlijke schaalaanpassingen en verschuivingen die innovatie meten.
Expertise: Ontwikkelaars en DevOps-experts lopen het risico te worden ondergewaardeerd of te beperkt in dit type omgeving.
Ontwerp van landingszone: Ontwerpen van datacenters zijn gebaseerd op de beperkingen van voorgaande benaderingen, die niet altijd relevant zijn voor de cloud. Als u deze aanpak volgt, vermindert u de mogelijkheden om de segmentering van de omgeving opnieuw te bekijken en mogelijkheden te creëren voor innovatie. Het ontbreken van segmentering van landingszones verhoogt het potentiële effect van inbreuk, complexiteit van governance en naleving van naleving, en kan leiden tot obstakels voor acceptatie in het cloudtraject. Zie de sectie met risico's hierboven.
Basishulpprogramma's: Tijdens de digitale transformatie kan de cloud het primaire operationele model worden. Centrale hulpprogramma's, die zijn gebouwd voor on-premises bewerkingen, verminderen de mogelijkheden om bewerkingen te moderniseren en de operationele efficiëntie te verhogen. Kiezen om bewerkingen niet vroeg in het acceptatieproces te moderniseren, is ook een optie. Modernisering kan worden bereikt door een platformbasisabonnement te maken in het cloudacceptatietraject. Deze inspanning kan complex, kostbaar en tijdrovend zijn zonder geavanceerde planning.
Scheiding van taken: centrale operaties volgen over het algemeen een van twee paden en beide kunnen innovatie belemmeren.
- Optie 1: Teams buiten de centrale IT krijgen beperkte toegang tot ontwikkelomgevingen die productie nabootsen. Deze optie belemmert het experimenteren.
- Optie 2: Teams ontwikkelt en test in niet-ondersteunde omgevingen. Deze optie belemmert implementatieprocessen en vertraagt het testen van integratie na implementatie.

Enterprise-bewerkingen

Bedrijfsbewerkingen zijn de voorgestelde doelstatus voor alle cloudbewerkingen. Bedrijfsactiviteiten zorgen voor een evenwicht tussen de behoefte aan controle en innovatie door het vereenvoudigen van beslissingen en verantwoordelijkheden. Centrale IT wordt vervangen door een meer faciliterend cloudcentrum of CCoE-team, dat workloadteams ondersteunt. Het CCoE-team houdt workloadteams verantwoordelijk voor beslissingen, in plaats van hun acties te controleren of te beperken. Workloadteams krijgen meer macht en meer verantwoordelijkheid om innovatie te stimuleren, binnen goed gedefinieerde kaders.

Prioriteiten: Prioriteiten zijn de democratisering van technische beslissingen. Democratisering van technische beslissingen verschuift de verantwoordelijkheden die eerder door de centrale IT werden gehouden naar workloadteams. Om deze verschuiving in prioriteiten te realiseren, worden beslissingen minder afhankelijk van door de mens uitgevoerde beoordelingsprocessen. Deze benadering ondersteunt geautomatiseerde controle, governance en afdwinging, met behulp van cloudeigen hulpprogramma's.
Uniek voordeel: segmentatie van omgevingen en scheiding van taken zorgen voor een balans tussen controle en innovatie. Gecentraliseerde bewerkingen onderhouden workloads waarvoor verhoogde naleving en stabiele statusbewerkingen zijn vereist, of die grotere beveiligingsrisico's vormen. Omgekeerd ondersteunt deze aanpak het verminderen van gecentraliseerd beheer van workloads en omgevingen die meer innovatie vereisen. Grotere portefeuilles kunnen moeite hebben met de balans tussen controle en innovatie. Deze flexibiliteit maakt het eenvoudiger om duizenden workloads te schalen met minder operationele problemen.
Uniek nadeel: wat on-premises werkte, werkt mogelijk niet goed in zakelijke cloudbewerkingen. Deze benadering van bewerkingen vereist wijzigingen op veel fronten. Culturele verschuivingen in controle en verantwoordelijkheid zijn vaak de grootste uitdaging. Operationele verschuivingen die de culturele verschuivingen volgen, kosten tijd en inspanningen om te implementeren, te ontwikkelen en te stabiliseren. Architectonische verschuivingen kunnen vereist zijn in stabiele workloads, terwijl verschuivingen van hulpprogramma's nodig zijn om de culturele, operationele en architecturale verschuivingen mogelijk te maken en te ondersteunen. Voor deze verschuivingen moeten mogelijk toezeggingen worden gedaan aan een primaire cloudprovider. Voordat deze wijzigingen zijn doorgevoerd, kunnen er aanzienlijke aanpassingen nodig zijn die verder gaan dan normale herstructureringsinspanningen.
Risico: Deze aanpak vereist dat het management zich inzet voor de wijzigingsstrategie. Het vereist ook inzet van de technische teams om leercurven te overwinnen en de vereiste verandering te leveren. Langdurige samenwerking tussen bedrijfs-, CCoE- en centrale IT- en workloadteams is vereist om voordelen op de lange termijn te zien.
Richtlijnen: Opties voor Azure-landingszones worden gedefinieerd als enterprise-scale. Deze opties bieden referentie-implementaties om te laten zien hoe technische wijzigingen worden uitgevoerd met behulp van cloudeigen hulpprogramma's in Azure. De aanpak op ondernemingsniveau begeleidt teams door de operationele en culturele verschuivingen die nodig zijn om optimaal te profiteren van deze implementaties. Met dezelfde aanpak kan de referentiearchitectuur worden aangepast om de omgeving te configureren om te voldoen aan uw acceptatiestrategie en nalevingsbeperkingen. Wanneer u op ondernemingsniveau implementeert, kunnen de methodologieën beheren en beheren helpen bij het definiëren van processen. Met deze processen kunt u de mogelijkheden voor naleving en bewerkingen uitbreiden om te voldoen aan uw operationele behoeften.

Voordelen van bedrijfsactiviteiten

Kostenbeheer: Centrale teams handelen in op optimalisaties voor meerdere portfolio's en houden afzonderlijke workloadteams verantwoordelijk voor een diepere optimalisatie van workloads. Workloadgerichte teams kunnen beslissingen nemen en duidelijkheid bieden wanneer deze beslissingen een negatief kosteneffect hebben. Centrale teams en workloadteams delen de verantwoordelijkheid voor kostenbeslissingen op het juiste niveau.
Verantwoordelijkheden: Centrale teams gebruiken cloudhulpprogramma's om kaders te definiëren, af te dwingen en te automatiseren. De inspanningen van het workloadteam worden versneld door CCoE-automatisering en -procedures. Workloadteams kunnen innovatie stimuleren en beslissingen nemen binnen deze kaders.
Standaardisatie: gecentraliseerde kaders en basisservices zorgen voor consistentie in alle omgevingen.
Ondersteuning voor bewerkingen: workloads waarvoor ondersteuning voor gecentraliseerde bewerkingen is vereist, worden gesegmenteerd naar omgevingen met besturingselementen voor stabiele status. Segmentering en scheiding van taken stellen workloadteams in staat om verantwoordelijkheid te nemen voor operationele ondersteuning in hun eigen specifieke omgevingen. Geautomatiseerde cloudeigen hulpprogramma's zorgen voor een minimale basislijn voor bewerkingen voor alle omgevingen met gecentraliseerde operationele ondersteuning.
Expertise: Het centraliseren van kernservices, zoals beveiliging, risico, governance en bewerkingen, zorgt voor de juiste centrale expertise. Duidelijke processen en kaders leiden workloadteams op en stellen ze in staat om gedetailleerdere beslissingen te nemen. Deze beslissingen vergroten het effect van de gecentraliseerde experts zonder dat ze personeel lineair hoeven te schalen met technologieschaal.
Ontwerp van landingszone: Het ontwerp van de landingszone repliceert de behoeften van het portfolio en creëert duidelijke grenzen voor beveiliging, governance en verantwoordelijkheid. Deze grenzen zijn vereist voor het uitvoeren van workloads in de cloud. Segmentatieprocedures lijken waarschijnlijk niet op de beperkingen die zijn gemaakt door voorgaande datacenterontwerpen. In enterprise-bewerkingen is het ontwerp van landingszones minder complex, waardoor de schaal sneller kan worden geschaald en de vraag naar selfservice minder wordt belemmerd.
Basishulpprogramma's: Basishulpprogramma's worden gehost in afzonderlijke centraal beheerde abonnementen, ook wel de platformbasis genoemd. Centrale hulpprogramma's worden vervolgens als nutsservices doorgesluisd naar elke landingszone. Het scheiden van basishulpprogramma's van de landingszones maximaliseert consistentie en schaalbesparing. Deze hulpprogramma's maken ook een duidelijk onderscheid tussen centraal beheerde verantwoordelijkheden en verantwoordelijkheden op workloadniveau.
Scheiding van taken: Een duidelijke scheiding van taken tussen basishulpprogramma's en landingszones is een van de grootste voordelen in de benadering van bewerkingen. Cloudeigen hulpprogramma's en processen ondersteunen toegang en een juiste balans tussen gecentraliseerde teams en workloadteams. Deze benadering is gebaseerd op de vereisten van afzonderlijke landingszones en workloads die worden gehost in landingszonesegmenten.

Nadelen van enterprise-bewerkingen

Kostenbeheer: Centrale teams zijn meer afhankelijk van workloadteams om productiewijzigingen aan te brengen in landingszones. Deze verschuiving brengt een risico met zich mee voor mogelijke budgetoverschrijdingen en een tragere rechtse grootte van de werkelijke uitgaven. Kostenbeheersingsprocessen, duidelijke budgetten, geautomatiseerde controles en regelmatige beoordelingen moeten vroeg aanwezig zijn om kostenverrassingen te voorkomen.
Verantwoordelijkheden: Enterprise-bewerkingen vereisen hogere culturele en operationele vereisten. Deze vereisten zorgen voor duidelijkheid in verantwoordelijkheden en verantwoordelijkheden tussen centrale teams en workloadteams.
Traditionele processen voor wijzigingsbeheer of wijzigingsadviesborden (cabs) houden mogelijk niet het tempo en de balans bij die nodig zijn in dit operationele model. Deze processen worden weerspiegeld in het automatiseren van processen en procedures waarmee cloudimplementatie veilig kan worden geschaald.
Het gebrek aan betrokkenheid bij verandering komt in de eerste plaats tot uiting in de onderhandelingen en afstemming van verantwoordelijkheden. Het niet kunnen afstemmen op verschuivingen in verantwoordelijkheid is een indicatie dat centrale IT-operationele modellen nodig kunnen zijn tijdens de kortetermijningebruikname van de cloud.
Standaardisatie: Gebrek aan investeringen in gecentraliseerde kaders, of automatisering, brengt risico's met zich mee voor standaardisatie, wat moeilijker te overwinnen is met handmatige beoordelingsprocessen. Operationele afhankelijkheden tussen workloads in landingszones en gedeelde services creëren grotere risico's. Deze risico's strekken zich uit van standaardisatie tijdens upgradecycli of toekomstige versies van basishulpprogramma's. Tijdens revisies van de platformbasis zijn verbeterde of zelfs geautomatiseerde tests vereist van alle ondersteunde landingszones en de workloads die ze hosten.
Ondersteuning voor bewerkingen: de basislijn voor bewerkingen die via automatisering en gecentraliseerde bewerkingen worden geleverd, kan voldoende zijn voor workloads met een laag effect of lage kritiek. Maar workloadteams of andere vormen van toegewezen bewerkingen kunnen vereist zijn voor complexe of zeer kritieke workloads. Als dat het zo is, kan dit een verschuiving in operationele budgetten creëren, waardoor bedrijfseenheden operationele kosten moeten geven aan deze vormen van geavanceerde bewerkingen. Als de centrale IT de enige verantwoordelijkheid moet houden voor de kosten van bewerkingen, kunnen bedrijfsactiviteiten moeilijk te implementeren zijn.
Expertise: de leden van het centrale IT-team kunnen vereist zijn om expertise te ontwikkelen in het automatiseren van centrale besturingselementen die eerder via handmatige processen zijn geleverd. Deze teams kunnen ook vaardigheden ontwikkelen voor infrastructure-as-code-benaderingen voor het definiëren van de omgeving en inzicht in vertakkingen, samenvoeging en implementatiepijplijnen. Een platformautomatiseringsteam kan ten minste besluitvormingsvaardigheden nodig hebben om inzicht te hebben in beslissingen die worden genomen door cloudcentrum-top- of centrale operationele teams. Workloadteams moeten mogelijk meer kennis ontwikkelen met betrekking tot de besturingselementen en processen die hun beslissingen bepalen.
Ontwerp van landingszone: het ontwerp van de landingszone is afhankelijk van fundamentele hulpprogramma's. Workloadteams moeten begrijpen wat er in het ontwerp staat en wat verboden is om op te nemen. Dit inzicht kan helpen bij het voorkomen van dubbele inspanningen, fouten of conflicten. Om flexibiliteit te creëren, kunt u rekening houden met uitzonderingsprocessen voor uw landingszoneontwerpen.
Basishulpprogramma's: het centraliseren van basishulpprogramma's kost tijd. Deze hulpprogramma's overwegen uiteindelijk opties en ontwikkelen oplossingen die kunnen worden geschaald om te voldoen aan verschillende acceptatieplannen. Vertragingen bij de vroege implementatie zijn mogelijk. Vertragingen kunnen op de lange termijn worden verschoven als gevolg van versnellingen en het vermijden van blokkeringen later in het proces.
Scheiding van taken: Voor een duidelijke scheiding van taken zijn volwassen identiteitsbeheerprocessen vereist. Er kan meer onderhoud zijn gekoppeld aan de juiste afstemming van gebruikers, groepen en onboarding- en offboarding-activiteiten. Mogelijk moet u nieuwe processen gebruiken om Just-In-Time-toegang via verhoogde bevoegdheden mogelijk te maken.

Gedistribueerde bewerkingen

Het bestaande operationele model is mogelijk te ingeworteld voor de hele organisatie om over te schakelen naar een nieuw operationeel model. Voor andere kunnen globale bewerkingen en verschillende nalevingsvereisten verhinderen dat specifieke bedrijfseenheden een wijziging aanbrengen. In dit geval is mogelijk een benadering voor distributiebewerkingen vereist. Deze aanpak is veruit de meest complexe, omdat hiervoor een of meer van de eerder genoemde operationele modellen moeten worden geïntegreerd.

Hoewel het sterk wordt afgeraden, is deze bewerkingsbenadering mogelijk vereist voor sommige organisaties. De aanpak heeft voornamelijk betrekking op organisaties met een losse verzameling van verschillende bedrijfsonderdelen, een diverse basis van klantsegmenten of regionale activiteiten.

Prioriteiten: integreer meerdere bestaande operationele modellen.
Overgangsstatus met de focus op het verplaatsen van de hele organisatie naar een van de eerder genoemde operationele modellen.
Operationele benadering op de langere termijn wanneer de organisatie te groot of te complex is om uit te lijnen met één operationeel model.
Uniek voordeel: integreer algemene elementen van het operationele model uit elke bedrijfseenheid. Met deze benadering wordt een voertuig gemaakt om operationele eenheden te groeperen in een hiërarchie die hen helpt bewerkingen te ontwikkelen met behulp van consistente herhaalbare processen.
Uniek nadeel: consistentie en standaardisatie voor meerdere operationele modellen is moeilijk te onderhouden voor langere perioden. Deze operationele aanpak vereist een grondige kennis van het portfolio en de manier waarop verschillende segmenten van de technologieportfolio werken.
Risico: een gebrek aan betrokkenheid bij een primair operationeel model kan leiden tot verwarring tussen teams. Gebruik dit operationele model als er geen manier is om uit te lijnen op één operationeel model.
Richtlijnen: Begin met een grondige beoordeling van het portfolio, waarbij gebruik wordt gemaakt van de aanpak die wordt beschreven in de artikelen over bedrijfsuitlijning . Probeer de portfolio te groeperen op basis van het statusmodel (gedecentraliseerd, gecentraliseerd of onderneming).
Een beheergroephiërarchie ontwikkelen die de groeperingen van het operationele model weerspiegelt. Deze rangschikking omvat andere organisatiepatronen voor regio, bedrijfseenheid of andere criteria die de workloadclusters toewijzen van minst voorkomende naar meest voorkomende buckets.
Evalueer de uitlijning van workloads met operationele modellen om het meest relevante cluster met operationele modellen te vinden om mee te beginnen. Volg de richtlijnen die zijn toegewezen aan het operationele model voor alle workloads in de knooppunt- en beheergroephiërarchie.
Gebruik governance- en beheermethoden om algemene bedrijfsbeleidsregels te vinden, inclusief vereiste operationele beheerprocedures op verschillende punten van de hiërarchie. Pas algemene Azure-beleidsregels toe om het gedeelde bedrijfsbeleid te automatiseren.
Wanneer u Azure-beleid test met verschillende implementaties, probeert u deze hoger te plaatsen in de beheergroephiërarchie. Het beleid kan worden toegepast op veel werkbelastingen, die mogelijk gemeenschappelijke kenmerken en verschillende bewerkingsbehoeften vinden.
Na verloop van tijd kan deze aanpak u helpen bij het definiëren van een model dat kan worden geschaald tussen verschillende operationele modellen. Deze aanpak kan ook teams samenvoegen via een reeks gemeenschappelijke beleidsregels en procedures.

De voor- en nadelen van deze aanpak zijn doelbewust leeg. Nadat u de bedrijfsuitlijning van uw portfolio hebt voltooid, raadpleegt u de sectie over het overheersende operationele model hierboven voor meer duidelijkheid over de voor- en nadelen.

Volgende stappen

Meer informatie over de terminologie die is gekoppeld aan operationele modellen. De terminologie helpt u te begrijpen hoe een operationeel model past in het grotere thema van bedrijfsplanning.

Terminologie van het operationele model

Lees hoe landingszones de elementaire bouwstenen vormen voor een omgeving voor cloudimplementatie.

Wat is een landingszone?