Portfoliohiërarchie

Als u wilt weten hoe een portfolio van workloads, assets en ondersteunende services samenwerken, moet u een portfoliohiërarchie opzetten. 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 bereikgenoemd.

Werkbelasting

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

Normaal gesproken delen een zakelijke belanghebbende en technische leider de verantwoordelijkheid voor de voortdurende ondersteuning van elke workload. In sommige fasen van de levenscyclus van de workload worden deze rollen duidelijk aangegeven. 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 impliciet) complexer en meer gematrixd.

Workloads en hun ondersteunende assets vormen de kern van elk portfolio. De omvang of lagen bepalen hoe deze workloads worden bekeken en in hoeverre ze worden beïnvloed door de matrix van potentiële ondersteunende teams.

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

• Asset: De kleinste eenheid van technische functie die ondersteuning biedt voor een workload of oplossing.
• Workload: de kleinste eenheid 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 gebied. De andere lagen kunnen expliciet worden gedefinieerd als er meer werklasten 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 met de benodigde fundamentele hulpprogramma's of gedeelde loodgieters die nodig zijn om een of meer workloads te ondersteunen. Landingszones zijn zo kritiek in de cloud dat de hele Ready methodologie van het Cloud Adoption Framework zich richt op landingszones. Voor een meer gedetailleerde definitie, zie Wat is een landingszone?
• Fundamentele hulpprogramma's: Deze gedeelde IT-services zijn vereist voor workloads die binnen de technologie- en bedrijfsportfolio werken.
• Platform foundation: Deze organisatieconstructie centraliseert basisoplossingen en zorgt ervoor dat deze besturingselementen worden afgedwongen voor alle landingszones.
• Cloudplatforms: Afhankelijk van de algehele strategie voor het ondersteunen van het volledige portfolio, hebben klanten mogelijk meerdere cloudplatforms met verschillende implementaties van de platformbasis nodig om meerdere regio's, hybride oplossingen of zelfs multicloudoplossingen te beheren.
• Portfolio: Via een technologielens is het portfolio een verzameling workloads, assets en ondersteunende resources die alle cloudplatforms omvatten. Via een bedrijfslens is het portfolio de verzameling projecten, mensen, processen en investeringen die de technologieportfolio ondersteunen en beheren om bedrijfsresultaten te stimuleren. Samen leggen deze twee lenzen het portfolio vast.

Hiërarchieverantwoordelijkheid en richtlijnen

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 voor de ondersteuning van zakelijke beslissingen, technische beslissingen en technische implementatie.

Notitie

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

• Portfolio: Het cloudstrategieteam en het Cloud Center of Excellence (CCoE) gebruiken de Strategy en Plan methodologieën om beslissingen te leiden 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 kaders die consistentie in elke omgeving garanderen 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 vereist is. Het cloudgovernanceteam moet ook op de hoogte worden gebracht van de voortgang van de workload en de acceptatie van assets.
• 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 die landingszones en platformhulpprogramma's. Beide teams gebruiken de methodologie Ready om de implementatie te begeleiden. Beide teams moeten op de hoogte worden gebracht van de voortgang bij de acceptatie van workloads en eventuele wijzigingen in de onderneming of omgeving.
• Workloads: Adoptie vindt plaats op workloadniveau. Cloudacceptatieteams gebruiken de Migrate en Innoveren methodologieën om schaalbare processen tot stand te brengen om de acceptatie te versnellen. Nadat de adoptie is voltooid, wordt het eigendom van workloads waarschijnlijkerwijs overgedragen aan een cloudbeheerteam dat gebruikmaakt van de Beheer-methodologie om het beheer van de operaties te sturen. Beide teams moeten vertrouwd zijn met het Microsoft Azure Well-Architected Framework om gedetailleerde architectuurbeslissingen 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 landingszonefuncties.
• Assets: Assets zijn doorgaans de verantwoordelijkheid van het cloudbewerkingsteam. Dat team gebruikt de basislijn voor beheer in de Beheer methodologie om beslissingen over het beheer van bewerkingen te begeleiden. Azure Advisor en het Azure Well-Architected Framework moeten ook worden gebruikt om gedetailleerde resource- en architectuurwijzigingen aan te brengen die nodig zijn om te voldoen aan de vereisten voor bewerkingen.

Verantwoordelijkheidsvarianten

• enkele 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 worden gecombineerd tot één team.
• Één workload: Sommige bedrijven hebben slechts één workload of een paar workloads nodig in één landingszone en één omgeving. In die gevallen is er weinig behoefte aan een scheiding van taken tussen governance-, platform- en operationele teams.

Veelvoorkomende voorbeelden van workload en verantwoordelijkheid

In de volgende voorbeelden ziet u de portfoliohiërarchie.

COTS-workloads

Van oudsher hebben ondernemingen de voorkeur geven aan softwareoplossingen van commercial-off-the-shelf (COTS) voor het aandrijven van bedrijfsprocessen. Deze oplossingen worden geïnstalleerd, geconfigureerd en vervolgens uitgevoerd. Er is weinig verandering in de oplossingsarchitectuur na de configuratie.

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

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 bieden mogelijk ook een versie van het softwarepakket dat wordt uitgevoerd in hun eigen in de cloud gehoste omgeving, wat een PaaS-alternatief (Platform as a Service) biedt voor de workload.

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

In ontwikkeling met actieve revisies

Wanneer een COTS-oplossing of PaaS-aanbieding niet is afgestemd op de bedrijfsbehoefte of er geen oplossing bestaat, bouwen ondernemingen aangepaste workloads. Normaal gesproken maakt slechts een klein percentage van het IT-portfolio gebruik van deze workloadbenadering. Maar deze workloads leiden meestal tot een onevenredig hoog percentage van de bijdrage van IT aan bedrijfsresultaten, met name resultaten met betrekking tot nieuwe omzetstromen. Deze werkbelastingen zijn meestal goed toe te wijzen aan nieuwe ideeën voor innovatie.

Gezien verschillende bewegingen die zijn geroot in agile methodologieën en DevOps-procedures, geven deze workloads de voorkeur aan een business/DevOps-afstemming op traditionele IT-beheer. Voor deze workloads is er mogelijk al enkele jaren geen overdracht naar het cloudbewerkingsteam. In die gevallen fungeert het ontwikkelteam als de technische eigenaar van de workload.

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

Reparatie/herstel of sunsetontwikkeling

Nadat een aangepaste workload een piek in de volwassenheid heeft bereikt, kan het ontwikkelteam opnieuw worden toegewezen aan andere projecten. In deze gevallen wordt het technische eigendom doorgaans overgestapt op een cloudbewerkingsteam. 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 zal vervangen. Het team kan ook verdergaan omdat de bedrijfskans die wordt ondersteund door de workload wordt uitgefaseerd. In deze zonsondergangscenario's fungeert het cloudbewerkingsteam als de technische eigenaar totdat de workload niet meer nodig is.

In beide scenario's fungeert het cloudbewerkingsteam doorgaans als de technische eigenaar en beslisser op lange termijn. Dat team zal waarschijnlijk toepassingsontwikkelaars inschakelen wanneer operationele wijzigingen aanzienlijke architectuurwijzigingen vereisen.

Bedrijfskritieke workloads

In elk bedrijf zijn een paar werkbelastingen te belangrijk voor het bedrijf om te mislukken. Met deze bedrijfskritieke workloads zijn er meestal operationele en ontwikkelingsverantwoordelijken met verschillende niveaus van verantwoordelijkheid. Deze teams moeten operationele wijzigingen en architectuurwijzigingen afstemmen om onderbrekingen van de productieoplossing te minimaliseren.

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 deze operationele wijzigingen een architectuurwijziging vereisen, worden ze voltooid door het ontwikkelings- of acceptatieteam in een niet-productieomgeving, voordat het operations-team de wijzigingen toepast op de productie.

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

Strategieportfolio-uitlijning

Het is belangrijk om inzicht te krijgen in de strategische doelstellingen van de cloudimplementatie en het portfolio uit te lijnen om die transformatie te ondersteunen. Een aantal veelvoorkomende soorten strategische portfolio-uitlijning helpen de structuur van de portfoliohiërarchie vorm te geven. De volgende secties bevatten voorbeelden van de uitlijning van de portfolio en het effect op de portfoliohiërarchie.

Door innovatie geleide portfolio of door ontwikkeling geleide portfolio

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

Omdat de omgeving aangepaste oplossingen host, kan de DevOps-pijplijn en rapportage op toepassingsniveau de noodzaak voor bewerkingen en governancefuncties vervangen. Deze klanten zullen waarschijnlijk de focus verminderen op activiteiten, governance of andere ondersteunende rollen. Een sterkere nadruk op de verantwoordelijkheden van de cloudimplementatie en cloudautomatiseringsteams is ook gebruikelijk.

Portfolio-afstemming: Het is waarschijnlijk dat het IT-portfolio zich zal concentreren op workloads en de eigenaren daarvan om noodzakelijke architectuurbeslissingen mogelijk te maken. Deze teams zullen waarschijnlijk meer waarde vinden in de Richtlijnen van Het Azure Well-Architected Framework tijdens de implementatie en operationele activiteiten.

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

Operationeel geleid portfolio

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

Portfoliouitlijning: De IT-portfolio wordt afgestemd op de workload, maar deze workloads worden vervolgens afgestemd op operationele eenheden of bedrijfseenheden. Er kan ook een organisatie zijn rond financieringsmodellen, industrie of andere bedrijfssegmentatievereisten.

Grensdefinities: Landingszones groepeert waarschijnlijk toepassingen in toepassings archetypen om vergelijkbare bewerkingen in een vergelijkbare segmentatie te behouden. Omgevingen verwijzen waarschijnlijk naar fysieke constructies zoals datacentrum, natie, regio van de cloudprovider of andere operationele organisatiestandaarden.

Migratiegestuurd portfolio

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

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

nl-NL: Grensdefinities: Landingszones zullen waarschijnlijk toepassingen groeperen in grenzen die overeenkomen met de segmentatie van on-premises systemen. Hoewel dit geen best practice is, komen omgevingen vaak overeen met de naam en landingszones van het on-premises datacenter die netwerksegmentatieprocedures vertegenwoordigen. Het is een betere gewoonte om te voldoen aan segmentatie die nauwer aansluit bij een door operations geleid portfolio.

Door governance geleid portfolio

Afstemming op governance-teams moet zo vroeg mogelijk plaatsvinden. Door governancepraktijken en cloudgovernancetools kunnen portfolio's en milieugrenzen het beste de behoeften van innovatie, operaties en migratie-inspanningen in balans brengen.

portfoliouitlijning: door governance geleide portfolio's bevatten meestal gegevenspunten die details van innovatie en bewerkingen vastleggen, zoals workload, eigenaar van bewerkingen, gegevensclassificatie en operationele kritiek. Deze gegevenspunten maken een goed afgeronde weergave van de portfolio.

Grensdefinities: Grenzen in een door governance geleid portfolio geven de voorkeur aan operaties boven innovatie, terwijl een beheergroepgestuurde hiërarchie overeenkomt met 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 te zorgen voor scheiding van taken en consistente bewerkingen.

Volgende stappen

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