Algemene operationele modellen voor de cloud controleren en vergelijken

Artikel
12/16/2024

Operationele modellen zijn uniek en specifiek voor het bedrijf dat ze ondersteunen, op basis van hun huidige vereisten en beperkingen. Maar bedrijfsmodellen 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 operationeel model

De volgende afbeelding wijst algemene operationele modellen toe op basis van het complexiteitsbereik, van minst complex (gedecentraliseerd) tot de meest complexe (globale 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 het portfolio dat moet worden beheerd

	Gedecentraliseerde operaties (ops)	Gecentraliseerde operaties	Enterprise-bewerkingen (ops)	Gedistribueerde operaties (ops)
strategische prioriteiten of motivaties	Innovatie	Controle	Democratisering	Integratie
Portfoliobereik	Werkdruk	Landingszone	Cloudplatform	Het volledige portfolio
de workloadomgeving	Hoge complexiteit	Lage complexiteit	Gemiddelde complexiteit	Gemiddelde of variabele complexiteit
landingszone	N.V.T.	Hoge complexiteit	Gemiddelde tot lage complexiteit	Lage complexiteit
Foundationhulpmiddelen	N.V.T	n.v.t. of weinig ondersteuning	Gecentraliseerd en meer ondersteuning	De meeste ondersteuning
cloudinfrastructuur	N.V.T.	N.V.T.	Hybride, provider-specifieke of regionale fundamenten	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 ontwerp van een operationeel model ondersteunt. Gecentraliseerde bewerkingen zijn bijvoorbeeld ontworpen voor enkele landingszones. Maar de beslissing over het operationele model kan operationele risico's voor een organisatie creëren. Operationele risico's zijn het resultaat bij het beheren van een grote complexe portfolio. Deze portfolio's vereisen mogelijk veel landingszones of variabele complexiteit bij het ontwerpen van landingszones.

Belangrijk

Het gebruik van de cloud leidt vaak tot weerspiegeling van het huidige operationele model en kan leiden tot een verschuiving van het ene gemeenschappelijke operationele model naar het andere. Maar cloudimplementatie is niet de enige trigger. Bedrijfsprioriteiten en het bereik van cloudimplementatie kunnen veranderen hoe de portfolio moet worden ondersteund. Er kunnen ook andere verschuivingen zijn in het meest geschikte uitgelijnde operationele model. Wanneer het bestuur of andere leidinggevenden 5 tot 10 jaar bedrijfsplannen 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 leiden 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 het ondersteunen van verschillende functies. Elk algemeen operationeel model wijst echter definitieve verantwoordelijkheid toe voor beslissingsresultaten aan één team of individu. Deze aanpak is van invloed op de manier waarop het operationele model wordt gefinancierd en welk ondersteuningsniveau voor elke functie wordt geboden.

	Gedecentraliseerde operaties	Gecentraliseerde operaties	Bedrijfsoperaties	Gedistribueerde operaties
Zakelijke uitlijning	werklastteam	Centrale cloudstrategie	CCoE	Variabele: een breed cloudstrategieteam vormen?
cloudbewerkingen	workloadteam	Central IT	CCoE	Op basis van portfolioanalyse - zie Business-afstemming en Zakelijke toezeggingen
cloud governance	workloadteam	Central IT -	CCoE	meerdere governancelagen
cloudbeveiliging	werklastteam	Security Operations Center (SOC) / DevSecOps-functie	CCoE + SOC	Gemengd- zie Een beveiligingsstrategie definiëren
cloudautomatisering en DevOps	werkdrukteam	Central IT of n.v.t.	CCoE	Gebaseerd op portfolioanalyse - zie Zakelijke afstemming en Zakelijke verplichtingen

Implementatie van operationele modellen versnellen in Azure

Zoals besproken in Uw operationele model definiëren, biedt elke methodologie van het Cloud Adoption Framework een gestructureerd pad voor het ontwikkelen van uw operationele model. Deze methodologieën kunnen u helpen bij het overwinnen van obstakels die voortvloeien uit hiaten in het gebruik van het cloudbedrijfsmodel.

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

	Gedecentraliseerde operaties	Gecentraliseerde operaties	Ondernemingsbeheer	Gedistribueerde operaties
beginpunt	Azure Well-Architected Framework (WAF)	Azure-landingszones: kleine opties	Azure-landingszones: op ondernemingsniveau van CAF	Zakelijke uitlijning
iteraties	Met een focus op workloads kan het team binnen WAF itereren.	De start-small optie vereist meer iteratie voor elke methodologie, maar kan worden uitgevoerd naarmate de inspanningen voor cloudimplementatie volwassen worden.	Zoals wordt geïllustreerd door de referentie-implementaties, richten toekomstige iteraties zich meestal op kleine configuratietoevoegingen.	Bekijk de implementatieopties voor 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

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 het minst complex van de algemene operationele modellen. In deze vorm van operaties werken alle workloads onafhankelijk door toegewijde workloadteams.

Prioriteiten: uw team meet innovatie over gecentraliseerd beheer of standaardisatie voor meerdere workloads.
Uniek voordeel: Maximaliseer de snelheid van innovatie door workload- en bedrijfsteams volledig in controle te plaatsen over ontwerp, bouw en operaties.
Uniek nadeel: vermindering van standaardisatie over werkbelastingen, schaalvoordelen door gedeelde diensten en gecentraliseerde nalevingsinspanningen voor consistent bestuur.
Risico: deze benadering introduceert risico's bij het beheren van een portfolio met workloads. Workloadteams kunnen speciale teams hebben 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 moeten voldoen aan de nalevingsvereisten van derden.
Richtlijnen: Gedecentraliseerde operaties zijn beperkt tot beslissingen op het niveau van de werklast. Microsoft Azure Well-Architected Framework ondersteunt de beslissingen die binnen dat bereik zijn genomen. De processen en richtlijnen binnen het Cloud Adoption Framework kunnen overhead toevoegen die niet vereist is voor gedecentraliseerde bewerkingen.

Voordelen van gedecentraliseerde bewerkingen

Cost Management-: de kosten van bewerkingen kunnen eenvoudig worden toegewezen aan één bedrijfseenheid. Workloadspecifieke bewerkingen ondersteunen een grotere optimalisatie van werkbelastingen.
Verantwoordelijkheden: deze vorm van bewerkingen is doorgaans zeer afhankelijk van automatisering om overhead te minimaliseren. Verantwoordelijkheden richten zich meestal 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 te standaardiseren van release tot release.
Operationele ondersteuning: beslissingen die van invloed zijn op operaties zijn alleen gericht op de behoeften van die workload en het vereenvoudigen van operationele beslissingen. Leden van de DevOps-community zeggen dat operationele ondersteuning de meest pure vorm van bewerkingen is vanwege het strakkere operationele bereik.
Expertise: DevOps en ontwikkelteams worden het meest ondersteund door deze aanpak en ondervinden de minste weerstand tegen het stimuleren van marktveranderingen.
ontwerp van landingszone: geen specifiek operationeel voordeel.
foundationele hulpprogramma's: geen specifiek operationeel voordeel.
Scheiding van taken: Geen specifiek operationeel voordeel.

Nadelen van gedecentraliseerde bewerkingen

Kostenbeheer: Ondernemingskosten zijn moeilijker te berekenen. Het ontbreken van gecentraliseerde governanceteams maakt het moeilijker om uniforme kostencontroles of optimalisatie 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 ontbreken van ondersteuning is problematisch wanneer deze taken niet zijn geautomatiseerd in codebeoordeling en release-pijplijnen.
Standaardisatie: Standaardisatie in een portfolio met workloads is variabel en inconsistent.
Operations ondersteunt: schaalefficiënties worden vaak gemist tijdens 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 toepassingsontwerp en de configuratie. Raadpleeg microsoft Azure Well-Architected Review en Azure Well-Architected Framework regelmatig om de vereiste expertise te verbeteren.
ontwerp van landingszone: Landingszones zijn niet workloadspecifiek en worden niet meegenomen in deze benadering.
Foundationele hulpprogramma's: weinig (indien aanwezig) basisservices worden 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 die teams. Als u scheiding van taken nodig hebt, moet u mogelijk sterk investeren in DevOps-volwassenheid om met deze benadering te kunnen werken.

Gecentraliseerde bewerkingen

gecentraliseerde bewerkingen

Stabiele statusomgevingen vereisen mogelijk geen focus op de architectuur of afzonderlijke operationele vereisten van de afzonderlijke workloads. Centrale operaties zijn meestal de norm voor technologieomgevingen die voornamelijk bestaan uit workloads met een stabiele toestand. Voorbeelden van stabiele toestandsbewerkingen zijn zaken zoals commercial-off-the-shelf -toepassingen (COTS) of goed gedefinieerde aangepaste toepassingen met een trage releasefrequentie. Als een wijzigingspercentage wordt aangestuurd door regelmatige updates en patches, is de centralisatie van bewerkingen mogelijk een effectieve manier om uw portfolio te beheren.

Prioriteiten: Prioriteiten zijn de centrale controle over innovatie en meten de bestaande operationele processen ten opzichte van de culturele verschuiving naar moderne cloudbewerkingen.
Uniek voordeel: Centralisatie introduceert schaalvoordelen, best-of-breed controles 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: het schalen om te voldoen aan de eisen van een grote portfolio met workloads kan aanzienlijke belasting vormen voor gecentraliseerde teams die operationele beslissingen nemen voor productieworkloads. Als technische assets verwachten dat ze groter zijn dan 1000 VM's, toepassingen of gegevensbronnen, kunt u een bedrijfsmodel overwegen als dit binnen 18-24 maanden valt.
Risico: deze benadering beperkt centralisatie tot een kleiner aantal abonnementen (vaak één productieabonnement). Er is een aanzienlijk risico betrokken bij het later herstructureren in uw cloudtraject, en het kan uw adoptieplannen verstoren. Om te voorkomen dat u opnieuw werkt, kunt u zich richten op segmentatie, omgevingsgrenzen, identiteitshulpprogramma's en andere fundamentele elementen.
Richtlijnen: Implementatieopties voor Azure-landingszones die zijn afgestemd op de ontwikkelingssnelheid 'klein en uitbreiden' maken een goed uitgangspunt. U kunt deze opties gebruiken om de implementatie te versnellen. Maar om succesvol te zijn, moet u duidelijk beleid opstellen om vroege acceptatie-inspanningen binnen acceptabele risicotoleranties te begeleiden. Het sturen en beheren van methodologieën helpt bij het creëren van processen om operaties parallel te laten rijpen. Deze stappen fungeren als fasepoorten die moeten worden voltooid voordat een verhoogd risico wordt toegestaan wanneer operaties rijpen.

Voordelen van gecentraliseerde bewerkingen

Kostenbeheer-: Het centraliseren van gedeelde services voor veel workloads zorgt voor schaalvoordelen en elimineert dubbele taken. Centrale teams kunnen snel kostenreducties implementeren via bedrijfsbrede grootte- en schaaloptimalisaties.
Verantwoordelijkheden: gecentraliseerde expertiseren en standaardiseren kan leiden tot hogere stabiliteit, betere operationele prestaties en minimale storingen in verband met wijzigingen. Deze aanpak vermindert brede druk op vaardigheden voor de teams die zijn gericht op werkbelastingen.
Standaardisatie: over het algemeen zijn standaardisatie en kosten van bewerkingen het laagst met een gecentraliseerd model, omdat er minder gedupliceerde systemen of taken zijn.
Operations ondersteunen: het verminderen van complexiteit en centralisatie van bewerkingen maakt het voor kleinere IT-teams eenvoudiger om bewerkingen te ondersteunen.
Expertise: met het centraliseren van ondersteunende teams kunnen experts op het gebied van beveiliging, risico, governance en activiteiten bedrijfskritieke beslissingen nemen.
ontwerp van landingszone: Centrale IT vermindert de complexiteit door het aantal landingszones en abonnementen te minimaliseren. Ontwerpen voor landingszones bootsen meestal de voorgaande ontwerpen van datacenters na, waardoor de overgangstijd wordt verminderd. Naarmate de acceptatie vordert, kunnen gedeelde bronnen worden verplaatst naar een afzonderlijk abonnement of platformbasis.
Fundamentele hulpprogramma's: Het overbrengen van bestaande datacenterontwerpen naar de cloud leidt tot fundamentele, gedeelde services die on-premises hulpprogramma's en operaties nabootsen. Wanneer on-premises bewerkingen uw primaire operationele model zijn, kan dit een voordeel zijn, maar let op een aantal nadelen. On-premises bewerkingen verminderen de overgangstijd, maakt gebruik van schaalvoordelen en ondersteunt consistente operationele processen tussen on-premises en in de cloud gehoste workloads. Deze aanpak kan de complexiteit en inspanning op korte termijn verminderen en kleinere teams cloudbewerkingen laten ondersteunen met verminderde leercurven.
Scheiding van taken: Scheiding van taken is duidelijk in centrale activiteiten. Centrale IT behoudt 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 niet altijd de workloadarchitecturen om zinvolle optimalisaties op het niveau van de workload te realiseren. Het gebrek aan begrip beperkt de mate van kostenbesparingen die voortkomen uit goed afgestemde werkbelastingoperaties. Het niet volledig begrijpen van de workloadarchitectuur kan invloed hebben op gecentraliseerde kostenoptimalisaties, die van invloed zijn op prestaties, schaal en andere pijlers van een goed ontworpen workload. Voordat u bedrijfsbrede kostenwijzigingen toepast op workloads met een hoog profiel, moet uw centrale IT-team de Microsoft Azure Well-Architected Review begrijpen en voltooien.
Verantwoordelijkheden: het centraliseren van productieondersteuning en -toegang zorgt voor een hoge operationele last voor een paar personen en grotere druk op elk individu. De druk op deze personen leidt ertoe dat zij diepere beoordelingen moeten uitvoeren van de geïmplementeerde workloads, die de naleving van gedetailleerde beveiligingsgovernance- en nalevingsvereisten valideren.
Standaardisatie: De centrale IT-benaderingen maken het moeilijk om standaardisatie te schalen zonder lineaire schaalaanpassing van centraal IT-personeel.
Operations ondersteunen: de grootste nadelen van deze benadering zijn gekoppeld aan aanzienlijke schaal en verschuivingen die innovatie meten.
Expertise: Developer- en DevOps-experts lopen het risico ondergewaardeerd te worden of te veel beperkingen te ervaren in dit type omgeving.
ontwerp van landingszone: datacenterontwerpen 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 segmentatie van de omgeving te herzien en mogelijkheden te bieden voor innovatie. Het ontbreken van segmentatie van landingszones verhoogt het potentiële effect van schending, de complexiteit van governance en naleving, en kan obstakels vormen voor adoptie in het cloudtraject. Zie de sectie risico's hierboven.
Foundational Utilities: Tijdens 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 operationele efficiëntie te verhogen. Het 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 de twee trajecten en beide kunnen innovatie belemmeren.
- optie 1: Teams buiten de centrale IT krijgen beperkte toegang tot ontwikkelomgevingen die productie nabootsen. Deze optie belemmert experimenten.
- optie 2: Teams ontwikkelt en test in niet-ondersteunde omgevingen. Deze optie belemmert implementatieprocessen en vertraagt het testen van de integratie na de implementatie.

Ondernemingsbewerkingen

Bedrijfsactiviteiten

Ondernemingsbewerkingen zijn de voorgestelde doelstatus voor alle cloudbewerkingen. Bedrijfsactiviteiten balanceren de noodzaak van controle en innovatie door beslissingen en verantwoordelijkheden te vereenvoudigen. Centrale IT wordt vervangen door een meer faciliterend cloudcentrum of CCoE-team, dat workloadteams ondersteunt. Het CCoE-team houdt de workloadteams verantwoordelijk voor hun beslissingen, in plaats van hun acties te controleren of te beperken. Workloadteams krijgen meer kracht 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 voorheen bij centrale IT lagen, naar de workloadteams. Om deze verschuiving in prioriteiten te realiseren, worden beslissingen minder afhankelijk van beoordelingsprocessen die door mensen worden uitgevoerd. Deze aanpak ondersteunt geautomatiseerde controle, governance en afdwinging met behulp van cloudeigen hulpprogramma's.
Uniek voordeel: Segmentatie van omgevingen en scheiding van taken zorgt voor evenwicht tussen controle en innovatie. Gecentraliseerde operaties onderhouden workloads waarvoor verhoogde naleving van voorschriften en een stabiele operationele toestand vereist zijn, of die grotere beveiligingsrisico's vertegenwoordigen. Omgekeerd ondersteunt deze aanpak het verminderen van gecentraliseerd beheer van workloads en omgevingen waarvoor meer innovatie nodig is. Grotere portfolio's kunnen moeite hebben met het evenwicht tussen controle en innovatie. Deze flexibiliteit maakt het eenvoudiger om duizenden workloads te schalen, met een vermindering van operationele problemen.
Uniek nadeel: Wat on-premises heeft gewerkt, werkt mogelijk niet goed in bedrijfscloudbewerkingen. 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, vergen tijd en toegewijde inspanningen om te implementeren, te rijpen en te stabiliseren. Architectuurverschuivingen kunnen vereist zijn bij stabiele workloads, terwijl veranderingen in tooling nodig zijn om de culturele, operationele en architecturale verschuivingen te faciliteren en te ondersteunen. Voor deze verschuivingen zijn mogelijk toezeggingen vereist voor een primaire cloudprovider. Adoptie-inspanningen die zijn gedaan voordat deze wijzigingen zijn doorgevoerd, kunnen aanzienlijke herwerking vereisen die verder gaat dan typische herstructureringsinspanningen.
Risico: voor deze aanpak is de toezegging van de executive vereist voor de wijzigingsstrategie. Het vereist ook toezegging van de technische teams om leercurven te overwinnen en de vereiste wijziging te leveren. Samenwerking op lange termijn tussen business-, CCoE- en centrale IT-teams en workloadteams is vereist om langetermijnvoordelen te zien.
Richtlijnen: Opties voor Azure-landingszones worden gedefinieerd als op ondernemingsniveau. Deze opties bieden referentie-implementaties om te laten zien hoe technische wijzigingen leveren met behulp van cloudeigen hulpprogramma's in Azure. De benadering op ondernemingsniveau begeleidt teams door de operationele en culturele verschuivingen die nodig zijn om optimaal te profiteren van deze implementaties. Dezelfde benadering kan de referentiearchitectuur aanpassen om de omgeving zo te configureren dat deze voldoet aan uw acceptatiestrategie en nalevingsbeperkingen. Wanneer u op ondernemingsniveau implementeert, kunnen de governance- en beheermethoden 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

Cost Management-: Centrale teams handelen naar portefeuille-overschrijdende optimalisaties en houden afzonderlijke workloadteams verantwoordelijk voor diepere optimalisatie van werkbelastingen. Teams die zich op werkladingen richten zijn gemachtigd om beslissingen te nemen en worden voorzien van duidelijkheid als deze beslissingen nadelige kosten hebben. Centrale teams en workloadteams delen de verantwoordelijkheid voor kostenbeslissingen op het juiste niveau.
Verantwoordelijkheden: centrale teams gebruiken cloudeigen hulpprogramma's om kaders te definiëren, af te dwingen en te automatiseren. De inspanningen van het workloadteam worden versneld via CCoE-automatisering en -procedures. Workloadteams kunnen innovatie stimuleren en beslissingen nemen binnen die kaders.
Standaardisatie: Centrale kaders en basisdiensten zorgen voor consistentie in alle omgevingen.
Operations-ondersteuning: workloads waarvoor gecentraliseerde ondersteuning voor bewerkingen is vereist, worden gesegmenteerd naar omgevingen met besturingselementen voor stabiele status. Segmentatie en scheiding van taken stellen workloadteams in staat om verantwoordelijkheid te nemen voor operationele ondersteuning in hun eigen toegewezen 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 informeren en versterken workload-teams om gedetailleerdere beslissingen te nemen. Deze beslissingen vergroten het effect van de gecentraliseerde experts zonder dat het personeel op dezelfde schaal met technologie moet worden uitgebreid.
Ontwerp van landingszone: het ontwerp van de landingszone repliceert de behoeften van het portfolio, het creëren van 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. Bij bedrijfsactiviteiten is het ontwerp van landingszones minder complex, waardoor sneller kan worden opgeschaald en de barrières voor selfservice vraag worden verminderd.
Foundational utilities: Foundational Utilities worden gehost in afzonderlijke centraal beheerde abonnementen, ook wel platformbasis genoemd. Centrale hulpmiddelen worden vervolgens naar elke landingszone geleid als nutsvoorzieningen. Door fundamentele hulpprogramma's van de landingszones te scheiden, wordt de consistentie en schaalbesparing gemaximaliseerd. Deze hulpprogramma's maken ook duidelijk onderscheid tussen centraal beheerde verantwoordelijkheden en verantwoordelijkheden op workloadniveau.
Scheiding van taken: Duidelijke scheiding van taken tussen basisvoorzieningen en landingszones is een van de grootste voordelen in de operationele benadering. 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 bedrijfsbewerkingen

Kostenbeheer: Centrale teams zijn afhankelijker van workloadteams om productiewijzigingen aan te brengen binnen landingszones. Deze verschuiving vormt een risico op potentiële budgetoverschrijdingen en langzamere aanpassing van de werkelijke uitgaven. Kostenbeheerprocessen, duidelijke budgetten, geautomatiseerde controles en regelmatige beoordelingen moeten vroeg worden uitgevoerd om kosten verrassingen te voorkomen.
Verantwoordelijkheden: Voor bedrijfsactiviteiten zijn meer culturele en operationele vereisten vereist. Deze vereisten zorgen voor duidelijkheid in verantwoordelijkheden en verantwoording tussen centrale teams en workloadteams.
Traditionele wijzigingsbeheerprocessen, of wijzigingsadviesborden (cabs), behouden mogelijk niet het tempo en de balans die vereist zijn in dit operationele model. Deze processen worden weerspiegeld in het automatiseren van processen en procedures die de overstap naar de cloud veilig schalen.
Gebrek aan toewijding om zich aan verandering te committeren, materialiseert zich eerst in onderhandelingen en de afstemming van verantwoordelijkheden. Het niet kunnen uitlijnen op verschuivingen in verantwoordelijkheid is een indicatie dat centrale IT-operationele modellen mogelijk vereist zijn tijdens de implementatie van de cloud op korte termijn.
Standaardisatie: Gebrek aan investeringen in gecentraliseerde kaders of automatisering, creëren risico's voor standaardisatie, wat moeilijker te overwinnen is door middel van handmatige beoordelingsprocessen. Operationele afhankelijkheden tussen workloads in landingszones en gedeelde services zorgen voor grotere risico's. Deze risico's breiden zich uit van standaardisatie tijdens upgradecycli of toekomstige versies van fundamentele hulpprogramma's. Tijdens revisies van platformfundamenten zijn verbeterde of zelfs geautomatiseerde tests vereist voor alle ondersteunde landingszones en de workloads die zij herbergen.
Operations biedt ondersteuning voor: de basislijn voor bewerkingen die wordt geleverd via automatisering en gecentraliseerde bewerkingen, kan voldoende zijn voor workloads met een lage invloed of lage kritiek. Maar workloadteams, of andere vormen van toegewezen bewerkingen, zijn mogelijk vereist voor complexe of zeer kritieke workloads. Als dat het geval is, kan het een verschuiving in de operationele budgetten veroorzaken, waarbij business units hun bedrijfskosten toewijzen aan die vormen van geavanceerde operaties. Als centrale IT vereist is om de enige verantwoordelijkheid voor de kosten van bewerkingen te behouden, kunnen enterprise-bewerkingen moeilijk te implementeren zijn.
Expertise: Centrale IT-teamleden moeten mogelijk expertise ontwikkelen bij het automatiseren van centrale controles die eerder via handmatige processen zijn geleverd. Deze teams kunnen ook bekwaamheid ontwikkelen voor infrastructure-as-code-benaderingen om de omgeving te definiëren en inzicht te hebben in vertakkingen, samenvoegen en implementatiepijplijnen. Een platformautomatiseringsteam heeft ten minste beslissingsvaardigheden nodig om inzicht te hebben in beslissingen die zijn genomen door cloudcentrum van uitmuntendheid of centrale operationele teams. Workloadteams moeten mogelijk meer kennis ontwikkelen met betrekking tot de besturingselementen en processen die hun beslissingen bepalen.
Ontwerp van landingszone: Ontwerp van 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 begrip kan helpen bij het voorkomen van duplicatie van inspanningen, fouten of conflicten. Als u flexibiliteit wilt creëren, kunt u rekening houden met uitzonderingsprocessen voor uw landingszoneontwerpen.
Fundamentele nutsvoorzieningen: Het centraliseren van fundamentele nutsvoorzieningen kost tijd. Deze hulpprogramma's overwegen uiteindelijk opties en ontwikkelen oplossingen die kunnen worden geschaald om te voldoen aan verschillende acceptatieplannen. Vertragingen in vroege adoptie-inspanningen zijn mogelijk. Vertragingen kunnen op de lange termijn worden verschoven vanwege versnellingen en blokkeringsvermijding later in het proces.
scheiding van taken: een duidelijke scheiding van taken vereist volwassen identiteitsbeheerprocessen. Er is mogelijk meer onderhoud gekoppeld aan de juiste afstemming van gebruikers, groepen en onboarding- en off-boardingactiviteiten. Mogelijk moet u nieuwe processen gebruiken om Just-In-Time-toegang mogelijk te maken via verhoogde bevoegdheden.

Gedistribueerde bewerkingen

gedistribueerde bewerkingen

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

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

prioriteiten: meerdere bestaande operationele modellen integreren.
Overgangsstatus met een focus op het verplaatsen van de hele organisatie naar een van de eerder genoemde operationele modellen.
Operationele benadering op langere termijn wanneer de organisatie te groot of te complex is om uit te lijnen op één operationeel model.
Specifiek voordeel: Integreer algemene elementen van het operationele model van elke bedrijfseenheid. Met deze benadering wordt een voertuig gemaakt om operationele eenheden te groeperen in een hiërarchie waarmee ze hun bewerkingen kunnen ontwikkelen met behulp van consistente herhaalbare processen.
Uniek nadeel: consistentie en standaardisatie voor meerdere operationele modellen is moeilijk te onderhouden gedurende langere perioden. Deze operationele aanpak vereist een grondige kennis van de portfolio en hoe verschillende segmenten van het technologieportfolio werken.
Risico: Gebrek aan toezegging aan 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.
Guidance: Begin met een grondige beoordeling van de portfolio, die gebruikmaakt van de aanpak die wordt beschreven in de business alignment artikelen. Probeer het portfolio te groeperen op het operationeel model van de staat (gedecentraliseerd, gecentraliseerd of onderneming).
Ontwikkel een hiërarchie van beheergroepen 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 gangbare tot meest voorkomende buckets.
Evalueer de afstemming van workloads op operationele modellen om het meest relevante operationele modelcluster te vinden om mee te beginnen. Volg de richtlijnen die zijn toegepast op het operationele model voor alle workloads binnen de hiërarchie van knooppunten en beheergroepen.
Gebruik methodologieën voor governance en beheer om gemeenschappelijk bedrijfsbeleid te vinden, inclusief vereiste operationele beheerprocedures op verschillende punten van de hiërarchie. Algemene Azure-beleidsregels toepassen om het gedeelde bedrijfsbeleid te automatiseren.
Wanneer u Azure-beleid test met verschillende implementaties, probeert u deze hoger te verplaatsen in de hiërarchie van de beheergroep. De beleidsmaatregelen kunnen worden toegepast op veel werkbelastingen, door overeenkomsten en specifieke operationele behoeften te ontdekken.
In de loop van de tijd kan deze benadering u helpen bij het definiëren van een model dat wordt geschaald over verschillende operationele modellen. Deze aanpak kan ook teams samenvoegen via een set algemene beleidsregels en procedures.

Voordelen en nadelen van deze benadering zijn doelbewust leeg. Nadat u de bedrijfsuitlijning van uw portfolio hebt voltooid, raadpleegt u de bovenstaande sectie over het overheersende operationele model voor meer duidelijkheid over 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 operationele modellen

Meer informatie over hoe een landingszone de basisbouwsteen biedt van elke omgeving voor cloudimplementatie.

Wat is een landingszone?

Delen via