Portfoliohiërarchie

Als u wilt begrijpen hoe een portfolio van workloads, assets en ondersteunende services allemaal samenwerken, moet u een portfoliohiërarchie instellen. Dit artikel bevat duidelijke definities voor de niveaus van uw portfoliohiërarchie, samen met richtlijnen voor teams om aan de verwachtingen voor elk niveau te voldoen. In dit artikel wordt elk niveau van de hiërarchie ook wel een bereik genoemd.

Workloads

Een verzameling technologieën die gedefinieerde bedrijfswaarde levert, wordt een workload genoemd. De verzameling kan toepassingen, servers of virtuele machines, gegevens, apparaten en andere vergelijkbare gegroepeerde assets bevatten. De meeste bedrijven zijn afhankelijk van meerdere workloads om essentiële bedrijfsfuncties te leveren.

Normaal gesproken delen een zakelijke belanghebbende en technische leider de verantwoordelijkheid voor de doorlopende ondersteuning van elke workload. In sommige fasen van de levenscyclus van de workload worden deze rollen duidelijk vermeld. In meer operationele fasen van de levenscyclus van een workload kunnen deze rollen worden overgezet naar een gedeeld operations-beheerteam of cloudbewerkingsteam. Naarmate het aantal workloads toeneemt, worden de rollen (aangegeven of geïmpliceerd) complexer en meer matrix.

Workloads en de bijbehorende ondersteunende assets vormen de kern van elk portfolio. De bereiken of lagen bepalen hoe deze workloads worden weergegeven en in welke mate ze worden beïnvloed door de matrix van potentiële ondersteunende teams.

Hoewel de voorwaarden kunnen variëren, bevatten alle IT-oplossingen assets en workloads:

• Actief: De kleinste technische functie-eenheid die ondersteuning biedt voor een workload of oplossing.
• Werklast: De kleinste eenheid van IT-ondersteuning voor het bedrijf. Een workload is een verzameling infrastructuur, toepassingen en gegevensassets die ondersteuning bieden voor een gemeenschappelijk bedrijfsdoel of de uitvoering van een gemeenschappelijk bedrijfsproces.

Wanneer u uw eerste workload implementeert, zijn de workload en de bijbehorende assets mogelijk het enige gedefinieerde bereik. De andere lagen kunnen expliciet worden gedefinieerd naarmate er meer workloads worden geïmplementeerd.

IT-portfolio

Wanneer bedrijven workloads ondersteunen via matrixbenaderingen of gecentraliseerde benaderingen, bestaat er waarschijnlijk een bredere hiërarchie ter ondersteuning van deze workloads:

• Landingszones: Landingszones bieden workloads de benodigde basishulpprogramma's, of gedeeld sanitair, die nodig zijn om een of meer workloads te ondersteunen. Landingszones zijn zo essentieel in de cloud dat de volledige Ready-methodologie van de Cloud Adoption Framework zich richt op landingszones. Zie Wat is een landingszone? voor een gedetailleerdere definitie.
• Basishulpprogramma's: Deze gedeelde IT-services zijn vereist om workloads te laten werken binnen de technologie- en bedrijfsportfolio.
• Platformbasis: Deze organisatieconstructie centraliseert basisoplossingen en helpt ervoor te zorgen dat deze besturingselementen worden afgedwongen voor alle landingszones.
• Cloudplatforms: Afhankelijk van de algemene strategie voor het ondersteunen van het volledige portfolio, hebben klanten mogelijk meerdere cloudplatforms nodig met afzonderlijke implementaties van de platformbasis om meerdere regio's, hybride oplossingen of zelfs oplossingen voor meerdere clouds te beheren.
• Portfolio: Via een technologische lens bestaat de portfolio uit een verzameling workloads, assets en ondersteunende resources die alle cloudplatforms omvatten. Via een zakelijke lens bestaat de portfolio uit een verzameling projecten, mensen, processen en investeringen die de technologieportfolio ondersteunen en beheren om bedrijfsresultaten te stimuleren. Samen leggen deze twee lenzen het portfolio vast.

Verantwoordelijkheid en richtlijnen voor hiërarchie

Een verantwoordelijk team beheert elke laag van de portfoliohiërarchie. In het volgende diagram ziet u de toewijzing tussen het verantwoordelijke team en de richtlijnen ter ondersteuning van zakelijke beslissingen, technische beslissingen en technische implementatie.

Notitie

De teams die in de volgende lijst worden genoemd, kunnen virtuele teams of individuen zijn. Voor sommige varianten van deze hiërarchie kunnen sommige verantwoordelijke teams worden samengevouwen, zoals later wordt beschreven in de verantwoordelijkheidsvarianten.

• Portfolio: Het cloudstrategieteam en het Cloud Center of Excellence (CCoE) gebruiken de strategie - en planmethoden om beslissingen te nemen die van invloed zijn op de algehele portfolio. Het cloudstrategieteam is verantwoordelijk voor het ondernemingsniveau van de cloudportfoliohiërarchie. Het cloudstrategieteam moet ook worden geïnformeerd over beslissingen over de omgeving, landingszones en workloads met hoge prioriteit.
• Cloudplatforms: Het cloudgovernanceteam is verantwoordelijk voor de disciplines die zorgen voor consistentie in elke omgeving in overeenstemming met de Governance-methodologie . Het cloudgovernanceteam is verantwoordelijk voor governance van alle resources in alle omgevingen. Het cloudgovernanceteam moet worden geraadpleegd over wijzigingen waarvoor mogelijk een uitzondering of wijziging van het beleid is vereist. Het cloudgovernanceteam moet ook op de hoogte worden gesteld van de voortgang van de workload en assetacceptatie.
• Landingszones en cloudbasis: Het cloudplatformteam is verantwoordelijk voor het ontwikkelen van de landingszones en platformhulpprogramma's die ondersteuning bieden voor acceptatie. Het cloudautomatiseringsteam is verantwoordelijk voor het automatiseren van de ontwikkeling en doorlopende ondersteuning voor deze landingszones en platformhulpprogramma's. Beide teams gebruiken de ready-methodologie om de implementatie te begeleiden. Beide teams moeten op de hoogte worden gehouden van de voortgang met de overstap naar workloads en eventuele wijzigingen in de onderneming of omgeving.
• Werkbelasting: Acceptatie vindt plaats op het niveau van de workload. Cloudacceptatieteams gebruiken de methodologieën voor migreren en innoveren om schaalbare processen tot stand te brengen om de acceptatie te versnellen. Nadat de implementatie is voltooid, wordt het eigendom van workloads waarschijnlijk overgedragen aan een team voor cloudbewerkingen dat gebruikmaakt van de beheermethode als leidraad voor operationeel beheer. Beide teams moeten vertrouwd zijn met het Microsoft Azure Well-Architected Framework om gedetailleerde beslissingen over de architectuur te nemen die van invloed zijn op de workloads die ze ondersteunen. Beide teams moeten worden geïnformeerd over wijzigingen in landingszones en -omgevingen. Beide teams kunnen af en toe bijdragen aan functies voor landingszones.
• Activa: Assets zijn doorgaans de verantwoordelijkheid van het team voor cloudbewerkingen. Dat team gebruikt de basislijn voor beheer in de methodologie Beheren om beslissingen voor operationeel beheer te nemen. Het moet ook Gebruikmaken van Azure Advisor en het Azure Well-Architected Framework om gedetailleerde resource- en architectuurwijzigingen aan te brengen die nodig zijn om te voldoen aan de vereisten voor bewerkingen.

Verantwoordelijkheidsvarianten

• Eén omgeving: Wanneer een onderneming slechts één omgeving nodig heeft, is een CCoE doorgaans niet vereist.
• Enkele landingszone: Als een omgeving slechts één landingszone heeft, kunnen de governance- en platformmogelijkheden waarschijnlijk in één team worden gecombineerd.
• Eén workload: Sommige bedrijven hebben slechts één workload of enkele workloads nodig in één landingszone en één omgeving. In dergelijke gevallen is er weinig behoefte aan een scheiding van taken tussen governance-, platform- en operationele teams.

Veelvoorkomende voorbeelden van workloads en verantwoordelijkheden

In de volgende voorbeelden ziet u de portfoliohiërarchie.

COTS-workloads

Traditioneel geven ondernemingen de voorkeur aan commerciële softwareoplossingen (COTS) om bedrijfsprocessen aan te runnen. Deze oplossingen worden geïnstalleerd, geconfigureerd en vervolgens gebruikt. Na de configuratie verandert er weinig in de oplossingsarchitectuur.

In deze scenario's eindigt elke cloudacceptatie van COTS-oplossingen met een overgang naar een team voor cloudbewerkingen. Het team voor cloudbewerkingen wordt vervolgens de technische eigenaar van die software en neemt de verantwoordelijkheid voor het beheren van configuratie, kosten, patchcycli en andere operationele behoeften op zich.

Deze workloads omvatten boekhoudpakketten, logistieke software of branchespecifieke oplossingen. In Microsoft-terminologie worden de leveranciers van deze pakketten onafhankelijke softwareleveranciers (ISV's) genoemd. Veel ISV's bieden een service voor het implementeren en onderhouden van een exemplaar van hun softwarepakket in uw abonnementen. Ze kunnen ook een versie van het softwarepakket aanbieden die wordt uitgevoerd in hun eigen in de cloud gehoste omgeving, met een PaaS-alternatief (Platform as a Service) voor de workload.

Met uitzondering van PaaS-aanbiedingen zijn cloudbewerkingsteams verantwoordelijk voor het garanderen van de basisvereisten voor operationele naleving voor deze workloads. Een cloudbewerkingsteam moet samenwerken met het cloudgovernanceteam om kosten, prestaties en andere architectuurpijlers op elkaar af te stemmen.

In ontwikkeling met actieve revisies

Wanneer een COTS-oplossing of PaaS-aanbieding niet is afgestemd op de bedrijfsbehoefte, of wanneer er geen oplossing bestaat, bouwen ondernemingen op maat ontwikkelde workloads. Normaal gesproken gebruikt slechts een klein percentage van de IT-portfolio deze workloadbenadering. Maar deze workloads hebben de neiging om een onevenredig hoog percentage van de it-bijdrage aan bedrijfsresultaten te genereren, met name resultaten met betrekking tot nieuwe omzetstromen. Deze workloads worden meestal goed toegewezen aan nieuwe innovatieideeën.

Gezien verschillende bewegingen die zijn gebaseerd op flexibele methodologieën en DevOps-procedures, geven deze workloads de voorkeur aan een zakelijke/DevOps-afstemming ten opzichte van traditioneel IT-beheer. Voor deze workloads is er mogelijk een aantal jaren geen overdracht aan het team voor cloudbewerkingen. In die gevallen fungeert het ontwikkelteam als de technische eigenaar van de workload.

Vanwege grote tijd- en kapitaalbeperkingen zijn aangepaste ontwikkelopties vaak beperkt tot hoogwaardige kansen. Typische voorbeelden zijn toepassingsinnovaties, diepgaande gegevensanalyse of bedrijfskritieke bedrijfsfuncties.

Onderbreken/herstellen of onderbroken ontwikkeling

Nadat een aangepaste workload de maximale volwassenheid heeft bereikt, wordt het ontwikkelingsteam mogelijk opnieuw toegewezen aan andere projecten. In deze gevallen gaat het technische eigendom doorgaans over naar een team voor cloudbewerkingen. Wanneer er kleine oplossingen nodig zijn, vraagt het operations-team ontwikkelaars om de fout op te lossen.

In sommige gevallen wordt het ontwikkelteam verplaatst naar een project dat uiteindelijk de huidige workload vervangt. Het team kan ook verdergaan omdat de zakelijke verkoopkans die door de workload wordt ondersteund, geleidelijk wordt beëindigd. In deze scenario's met zonsondergang fungeert het team voor cloudbewerkingen als de technische eigenaar totdat de workload niet meer nodig is.

In beide scenario's fungeert het cloud operations-team doorgaans als de technische eigenaar en beslisser op de lange termijn. Dit team zal waarschijnlijk toepassingsontwikkelaars inschakelen wanneer operationele wijzigingen aanzienlijke wijzigingen in de architectuur vereisen.

Essentiële werkbelastingen

In elk bedrijf zijn een paar workloads te belangrijk voor het bedrijf om ze te laten mislukken. Met deze bedrijfskritieke workloads zijn er meestal eigenaren van bewerkingen en ontwikkeling met verschillende niveaus van verantwoordelijkheid. Deze teams moeten operationele wijzigingen en architectuurwijzigingen afstemmen om onderbrekingen van de productieoplossing tot een minimum te beperken.

Deze scenario's vereisen een sterke focus op scheiding van taken. Het operationele team is over het algemeen verantwoordelijk voor dagelijkse operationele wijzigingen in de productieomgeving. Wanneer voor deze operationele wijzigingen een architectuurwijziging is vereist, worden ze voltooid door het ontwikkelings- of acceptatieteam in een niet-productieomgeving, voordat het operationele team de wijzigingen toepast op productie.

Voorbeelden van bedrijfskritieke workloads met een vereiste scheiding van taken zijn workloads zoals SAP, Oracle of andere ERP-oplossingen (Enterprise Resource Planning), die meerdere bedrijfseenheden in het bedrijf omvatten.

Uitlijning van strategieportfolio

Het is belangrijk om de strategische doelstellingen van de cloudimplementatie te begrijpen en de portfolio op elkaar af te stemmen om die transformatie te ondersteunen. Enkele veelvoorkomende typen strategische portfolio-uitlijning helpen de structuur van de portfoliohiërarchie vorm te geven. De volgende secties bevatten voorbeelden van de portfolio-uitlijning en het effect op de portfoliohiërarchie.

Door innovatie of ontwikkeling geleid portfolio

Sommige bedrijven, met name snel groeiende start-ups, hebben een hoger dan gemiddeld percentage aangepaste ontwikkelingsprojecten. In portfolio's met veel ontwikkeling worden de omgeving, landingszone en workloads vaak gecomprimeerd, dus er kunnen specifieke omgevingen zijn voor specifieke workloads. Het resultaat is een 1:1-verhouding tussen omgeving, landingszone en workload.

Omdat de omgeving als host fungeert voor aangepaste oplossingen, kunnen de DevOps-pijplijn en rapportage op toepassingsniveau de behoefte aan bewerkings- en governancefuncties vervangen. Deze klanten zullen waarschijnlijk minder aandacht besteden aan bewerkingen, governance of andere ondersteunende rollen. Een sterkere nadruk op de verantwoordelijkheden van de teams voor cloudimplementatie en cloudautomatisering is ook gebruikelijk.

Portfolio-uitlijning: Het IT-portfolio zal zich waarschijnlijk richten op workloads en workloadeigenaren om kritieke beslissingen over architectuur te nemen. Deze teams zullen waarschijnlijk meer waarde vinden in de Azure Well-Architected Framework-richtlijnen tijdens de implementatie en operationele activiteiten.

Grensdefinities: De logische grenzen, zelfs op ondernemingsniveau, zijn waarschijnlijk gericht op segmentering van productie- en niet-productieomgevingen. Er kan ook een duidelijke segmentatie zijn tussen producten in het softwareportfolio van het bedrijf. Soms kan er ook segmentatie zijn tussen ontwikkel- en gehoste klantexemplaren.

Door operations geleide portfolio

Multinationale ondernemingen met meer gevestigde IT-operationele teams hebben doorgaans een sterkere focus op governance en bewerkingen dan ontwikkeling. In deze organisaties is een hoger percentage workloads doorgaans afgestemd op de COTS- of break/fix-categorieën, die worden onderhouden door technische eigenaren binnen het cloudbewerkingsteam.

Portfolio-uitlijning: De IT-portfolio wordt op de werkbelasting afgestemd, maar deze workloads worden vervolgens afgestemd op operationele eenheden of bedrijfseenheden. Er kan ook organisatie zijn rond financieringsmodellen, branche of andere vereisten voor bedrijfssegmentatie.

Grensdefinities: Landingszones groeperen toepassingen waarschijnlijk in archetypen van toepassingen om vergelijkbare bewerkingen in een vergelijkbare segmentatie te houden. Omgevingen verwijzen waarschijnlijk naar fysieke constructies, zoals datacentrum, land, cloudproviderregio of andere operationele organisatiestandaarden.

Migratiegestuurd portfolio

Net als bij door operations geleide portfolio's zal een portfolio dat grotendeels is opgebouwd via migratie gebaseerd zijn op specifieke bedrijfsfactoren die hebben geleid tot de migratie van bestaande assets. Normaal gesproken is het datacenter de grootste factor in deze stuurprogramma's.

Portfolio-uitlijning: Het IT-portfolio kan de workload zijn uitgelijnd, maar het is waarschijnlijker dat de assets zijn uitgelijnd. Als er in de geschiedenis van het bedrijf overgangen naar IT-bewerkingen hebben plaatsgevonden, kunnen veel assets voor actief gebruik mogelijk niet eenvoudig worden toegewezen aan een gefinancierde workload. In deze gevallen hebben veel assets mogelijk pas laat in het migratieproces een gedefinieerde workload of de eigenaar van de workload.

Grensdefinities: In landingszones worden toepassingen waarschijnlijk gegroepeerd in grenzen die on-premises segmentatie weerspiegelen. Hoewel dit geen best practice is, komen omgevingen vaak overeen met de naam van het on-premises datacenter en de landingszones die netwerksegmentatieprocedures vertegenwoordigen. Het is een betere gewoonte om te voldoen aan segmentatie die meer overeenkomt met een door operations geleid portfolio.

Door governance geleid portfolio

Afstemming op governanceteams moet zo vroeg mogelijk plaatsvinden. Door middel van governanceprocedures en hulpprogramma's voor cloudgovernance kunnen portfolio's en milieugrenzen de beste balans vinden tussen de behoeften van innovatie, bewerkingen en migratie-inspanningen.

Portfolio-uitlijning: Door governance geleide portfolio's bevatten meestal gegevenspunten die informatie over innovatie en bewerkingen vastleggen, zoals workload, eigenaar van bewerkingen, gegevensclassificatie en operationele kritiek. Deze gegevenspunten zorgen voor een goed afgeronde weergave van het portfolio.

Grensdefinities: Grenzen in een door governance geleide portfolio geven de voorkeur aan bewerkingen boven innovatie, terwijl een door beheergroepen gestuurde hiërarchie wordt gebruikt die is toegewezen aan criteria voor bedrijfseenheden en ontwikkelomgevingen. Op elk niveau van de hiërarchie kan een grens voor cloudgovernance verschillende mate van beleidshandhaving hebben om ontwikkeling en creatieve flexibiliteit mogelijk te maken. Tegelijkertijd kunnen vereisten op productieniveau worden toegepast op productieabonnementen om scheiding van taken en consistente bewerkingen te garanderen.

Volgende stappen

Meer informatie over hoe Azure-producten ondersteuning bieden voor de portfoliohiërarchie.