Een strategie ontwikkelen voor de tenantomgeving zodat Power Platform op schaal kan worden toegepast
Het traject dat elke organisatie volgt om Microsoft Power Platform in te voeren is uniek. Een strategie voor een tenantomgeving legt de basis om het gebruik op een beheersbare en veilige manier te helpen versnellen.
In dit whitepaper ziet u hoe u uw Power Platform-strategie voor de tenantomgeving kunt afstemmen op de productmogelijkheden en visie. U ontdekt hoe u de nieuwste functies van het platform het beste kunt gebruiken om een strategie te implementeren waarmee uw implementatie van Power Platform op ondernemingsschaal kan worden gerealiseerd.
Notitie
U kunt dit technische document opslaan of afdrukken door in uw browser Afdrukken en vervolgens Opslaan als PDF-bestand te selecteren.
Inleiding
Power Platform stelt organisaties in staat om oplossingen met weinig code te bouwen voor snelle innovatie. Deze oplossingen kunnen gericht zijn op de productiviteit van individuen en kleine teams of kunnen binnen de hele organisatie worden toegepast. Ze kunnen zich ook uitstrekken tot bedrijfsprocessen, inclusief externe klanten en partners. Deze oplossingen worden ondersteund door Power Platform-omgevingen waarin de resources met weinig code worden gebouwd, getest en gebruikt. Naarmate een organisatie de invoering van Power Platform opvoert, is het implementeren van een goede strategie voor de tenantomgeving essentieel om deze beheersbaar en veilig te maken naarmate het aantal omgevingen groeit.
Om de kans op succes verder te vergroten, vindt u in dit artikel uitleg over hoe u de beschikbare functies het beste kunt gebruiken om uw eerste omgevingsstrategie te maken of uw huidige plannen verder te ontwikkelen. Ook schetsen we onze visie op hoe deze functies moeten samenwerken en hoe ze zich zullen ontwikkelen om Power Platform op schaal te kunnen beheren. In deze richtlijnen stellen we vast hoe u nieuwe gebruikers op de juiste manier naar omgevingen en groepsomgevingen kunt leiden om op consistente wijze beheer, beveiligingsregels en andere belangrijke aspecten van een strategie voor een tenantomgeving toe te passen. Ook bieden we gedetailleerde stappen om uw standaardomgeving te beveiligen, wat een cruciale eerste stap is bij de implementatie van een omgevingsstrategie.
Hoewel er veel Perspectieven beschikbaar zijn voor het beheren van Power Platform omgevingen, sluit de aanpak in dit artikel aan bij de nieuwste productrichting van Microsoft en maakt gebruik van huidige functies en geplande verbeteringen op korte termijn. Met deze bijgewerkte richtlijnen kunt u ervoor zorgen dat u alleen de functies en opties van omgeving gebruikt die strategisch zijn voor de manier waarop u omgevingen op schaal wilt beheren. Microsoft
Microsoft's huurder omgeving strategie visie
Veel organisaties beginnen hun Power Platform-beleving met apps en automatiseringen voor persoonlijke productiviteit die zijn gebouwd en draaien in een gedeelde centrale omgeving, de standaardomgeving genoemd. Deze resources gebruiken vaak alleen de basismogelijkheden van Microsoft 365 en niet de volledige mogelijkheden van Power Platform. Naarmate deze eerste acceptatie versnelt, Microsoft krijgt organisaties een opstap naar een omgeving-strategie voor acceptatie van de volledige Power Platform mogelijkheden op ondernemingsniveau. Deze premium beheermogelijkheden worden beschikbaar wanneer gebruikers een premium Power Platform-licentie (Power Apps, Power Automate, Microsoft Copilot Studio en Dynamics 365) hebben. Het looptijdmodel voor invoering van Power Platform kan meer inzichten bieden om organisaties te helpen bij het definiëren van hun roadmap om invoering op ondernemingsniveau te bereiken die verder gaat dan hun omgevingsstrategie. Deze aanpak kan organisaties helpen zich te ontwikkelen van basale persoonlijke productiviteit naar invoering van Power Platform op ondernemingsniveau.
Met de administratieve, governance en beveiligingsfuncties van Power Platform kunnen organisaties Power Platform invoeren en beheren voor bedrijfsproductiviteit en gebruik van zakelijke apps op grote schaal. Het gebruik van beheerde omgevingen activeert een reeks premiummogelijkheden die een grotere zichtbaarheid en controle mogelijk maken en de handmatige inspanningen voor het beheren en beveiligen van omgevingen beperken. Met behulp van deze mogelijkheden kunt u zorgen voor een consistente toepassing van uw governance- en beveiligingsbeleid. Beheerders kunnen met behulp van deze mogelijkheden de overgang maken naar een omgevingsstrategie op ondernemingsniveau. Door minder tijd en energie aan het beheer te besteden, kunt u de algehele totale eigendomskosten (TCO) van het platform verlagen naarmate uw organisatie het gebruik opschaalt.
Een belangrijk element van de transitie naar ondernemingsschaal is het verbeteren van de gedeelde, centrale omgevingsstrategie voor makers, door het hen gemakkelijker te maken om persoonlijke ontwikkelomgevingen te gebruiken. In een gedeelde, centrale omgevingsstrategie bouwen, gebruiken en delen makers apps in de standaardomgeving. Deze strategie kan resulteren in een gebrek aan isolatie en makers die in elkaars vaarwater komen. Stelt u zich eens voor dat iedereen in het bedrijf één enkele, OneDrive-map zou delen voor al hun documenten. In plaats daarvan kunt u omgevingsfuncties gebruiken om makers naar hun eigen, persoonlijke omgeving te leiden waar ze veilig hun apps kunnen bouwen, beschermd tegen makers die aan niet-gerelateerde assets werken, met vereenvoudigd beheer voor beheerders. Collega's kunnen als extra makers aan deze omgevingen worden toegevoegd om samen aan de bouw van oplossingen te werken.
Figuur: Illustratie van een gedeelde, centrale omgeving (links) en een omgeving routeringsstrategie (rechts).
Pas aangemaakte makersomgevingen kunnen automatisch worden toegevoegd aan een groep die regels toepast om ervoor te zorgen dat de omgevingen consistent beheer- en beveiligingsbeleid hebben. Beheerders kunnen uitzonderingen afhandelen door de omgeving van een maker te verplaatsen naar een groep met minder strenge regels.
Resources met weinig code die door de makers zijn gemaakt, vertegenwoordigen de eerste fase in het ALM-traject (levenscyclusbeheer van toepassingen) van een resource. Als onderdeel van deze eerste fase is het belangrijk om elke versie van een resource vast te leggen en deze indien nodig opnieuw te kunnen maken. Wanneer de resource klaar is om te worden gedeeld, kan de maker de continue integratie die aan de ontwikkelomgeving is gekoppeld, gebruiken om deze te een niveau te verhogen naar een productieomgeving, waar gebruikers de resource kunnen gebruiken, geïsoleerd van eventuele voortdurende makersactiviteiten.
U moet waar mogelijk prioriteit geven aan de ingebouwde functies van het platform voor het beheren van omgevingen, in plaats van uw eigen tools te bouwen. Als de ingebouwde functies niet voldoen aan de unieke vereisten van uw organisatie, kunt u hulpprogramma's voor platformbeheer gebruiken om aangepaste tools te maken. U moet alle aangepaste hulpprogramma's beoordelen aan de hand van nieuwe functies zodra deze beschikbaar komen. Door de platform-roadmap van Microsoft in de gaten te houden en uw eigen roadmap bij te houden, kunt u dit gemakkelijker maken.
U moet uw omgevingsstrategie vaststellen met behulp van de aanbevolen omgevingsmogelijkheden die zijn afgestemd op de unieke behoeften van uw organisatie. Beschouw het opstellen van uw omgevingsstrategie niet als een eenmalige activiteit. Deze moet in de loop van de tijd veranderen, waarbij nieuwe omgevingsfuncties worden opgenomen zodra deze beschikbaar komen.
Functies die een omgevingsstrategie op ondernemingsniveau ondersteunen
Omgevingen zijn een bouwsteen voor Power Platform beheer, governance en beveiliging. Een volledig overzicht van de functies valt buiten het bestek van dit artikel. In dit gedeelte worden echter de functies uitgelicht die de implementatie van een omgevingsstrategie op ondernemingsschaal ondersteunen.
Typen omgevingen beschrijft de verschillende toepassingen van omgevingen als onderdeel van uw strategie.
niveau verhogen biedt een reeks premiumfuncties waarmee u omgevingen eenvoudiger op schaal kunt beheren.
Met licenties automatisch claimen wordt het toewijzen van licenties vereenvoudigd doordat gebruikers licenties per gebruiker kunnen claimen wanneer ze deze nodig hebben. Een beheerder hoeft dan niet vooraf te bepalen welke gebruikers licenties nodig hebben. Power Apps
omgeving groepen en regels legt uit hoe u omgevingen als groepen kunt beheren en regels op groepen kunt toepassen om consistente governance-beleidsregels te automatiseren.
Standaardroutering omgeving leidt makers automatisch van het maken van resources in de standaardroutering omgeving naar hun eigen, persoonlijke omgeving.
Microsoft Dataverse biedt verbeterde beveiliging en ALM.
Met Preferred Solutions kunnen makers ervoor zorgen dat alle assets die ze bouwen zich in een Dataverse oplossing bevinden, waardoor ze gemakkelijker naar andere omgevingen kunnen worden gemigreerd.
Pipelines in Power Platform bieden een vereenvoudigd proces voor het promoten van assets van ontwikkelings- naar test- en productieomgevingen, waardoor continue integratie en implementatie (CI/CD) beschikbaar wordt voor alle makers.
Met Catalogus in Power Platform kunnen makers componenten, zoals apps en stromen, en meer geavanceerde startpunten, zoals sjablonen, Delenen.
Typen omgevingen
In de volgende tabel worden de typen omgevingen beschreven die u kunt maken, met hun kenmerken en het beoogde gebruik.
| Type | Kenmerken en toepassingen |
|---|---|
| Default | De omgeving die bij iedere tenant hoort. Veel Microsoft 365-ervaringen gebruiken deze omgeving voor aanpassingen en automatiseringen. Deze omgeving is niet bedoeld voor langdurig of permanent werk buiten de persoonlijke productiviteitsscenario's van Microsoft 365. |
| Productie | Deze omgeving is bedoeld om te worden gebruikt voor permanent werk in een organisatie. Productieomgevingen ondersteunen verlengde retentie van back-ups, van zeven dagen tot maximaal 28 dagen. |
| Sandbox | Deze niet-productieomgevingen ondersteunen omgevingsacties, zoals kopiëren en opnieuw instellen. Sandboxes kunnen het beste worden gebruikt voor test- en ALM-bouwomgevingen. |
| Developer | Deze speciale omgevingen zijn bedoeld als persoonlijke ontwikkelwerkruimtes voor makers, waarbij assets met weinig code worden geïsoleerd van gebruikers en andere makers. Makers kunnen maximaal drie ontwikkelomgevingen hebben. Ze tellen niet mee voor uw tenantcapaciteit. Ontwikkelaarsomgevingen die 90 dagen niet zijn gebruikt, worden automatisch uitgeschakeld en vervolgens uit uw tenant verwijderd als de eigenaar niet op meldingen reageert. Dynamics 365-apps zijn niet beschikbaar in ontwikkelaarsomgevingen. |
| Proefversie | Deze omgevingen zijn bedoeld ter ondersteuning van kortetermijntesten en proofs of concept. Ze zijn beperkt tot één per gebruiker. Proefomgevingen worden na korte tijd automatisch verwijderd uit uw tenant. |
| Microsoft Dataverse for Teams | Deze omgevingen worden automatisch aangemaakt wanneer u een app maakt in Teams of een app installeert vanuit de app-catalogus. Het beveiligingsmodel voor deze omgevingen komt overeen met het team waaraan ze zijn gekoppeld. |
| Ondersteuning | Dit zijn speciale omgevingen die door Microsoft Support zijn gemaakt, zodat technici problemen kunnen oplossen. Deze omgevingen tellen niet mee voor uw tenantcapaciteit. |
Terwijl u een algemene strategie voor de tenantomgeving samenstelt, zijn de verschillende typen relevant om de strategieaanbevelingen te ondersteunen.
Beheerde omgevingen
Omgevingen hebben een basisset van functies en kenmerken, afhankelijk van het omgevingstype. Beheerde omgevingen breiden de basisfuncties uit en bieden een reeks premiummogelijkheden waarmee beheerders Power Platform gemakkelijker op schaal kunnen beheren met meer controle, minder moeite en meer inzichten. Deze mogelijkheden worden ontgrendeld wanneer u een omgeving als beheerd instelt.
In de volgende tabel worden de functies van beheerde omgevingen vermeld die op het moment van schrijven beschikbaar zijn. Er worden vaak nieuwe functies toegevoegd, dus bekijk de documentatie voor de nieuwste lijst. Hoewel alle functies u kunnen helpen bij het ontwikkelen van een omgevingsstrategie, zijn de cursief gedrukte functies relevanter voor de strategie die in dit artikel wordt beschreven.
| Meer zichtbaarheid | Meer controle | Minder moeite |
|---|---|---|
| gebruiksinzichten Beheerderssamenvatting Licentierapporten Gegevensbeleidweergave Gegevens exporteren naar Azure Application Insights Door AI gegenereerde beschrijvingen voor Alle apps |
Delen limieten Gegevensbeleid voor Bureaublad-stromen Oplossingscontrole Maker-welkomstinhoud IP-firewall IP-cookiebinding Door de klant beheerde sleutels Klantenkluis Uitgebreide back-ups |
Eenvoudige activering Power Platform pijpleidingen omgeving-routering omgeving groepen en regels Power Platform adviseur |
Automatisch claimen van licentie
Met autoclaimbeleid worden licenties automatisch toegewezen aan gebruikers wanneer zij deze nodig hebben om bepaalde apps of functies te gebruiken. Power Apps Power Automate Automatisering kan helpen het aantal verbruikte licenties te verminderen en de overhead van het handmatig toewijzen van licenties te vermijden.
Nadat beleid is geconfigureerd, wordt aan elke gebruiker in de organisatie die een individuele Power Apps-licentie nodig heeft, automatisch een licentie verleend onder de volgende voorwaarden:
Als een gebruiker zonder een zelfstandige Power Apps-licentie een app opent waarvoor een premium-licentie nodig is, wijst het systeem automatisch een Power Apps-licentie per gebruiker toe aan de gebruiker.
Als een gebruiker zonder een zelfstandige Power Apps-licentie een app opent in een beheerde omgeving, wijst het systeem automatisch een Power Apps-licentie per gebruiker toe aan de gebruiker.
Op dezelfde manier wordt nadat beleid is geconfigureerd aan elke gebruiker in de organisatie die een individuele Power Automate-licentie nodig heeft, automatisch een licentie verleend onder de volgende voorwaarden:
De gebruiker activeert, bewaart of schakelt een premium cloudstroom in met begeleide RPA (robotgestuurde procesautomatisering).
De gebruiker vraagt een premium-licentie voor Power Automate aan.
We raden u aan automatisch claimen van licenties te configureren als uw omgevingsstrategie beheerde omgevingen omvat. Gebruikers van apps en stromen ondervinden de minste problemen met licentieverlening, en u verbruikt alleen licenties voor gebruikers die actief apps uitvoeren of Power Automate gebruiken.
Omgevingsgroepen en -regels
Naarmate het gebruik van Power Platform in uw tenant toeneemt, neemt ook het aantal omgevingen waarvoor beheer en beheer vereist toe. Met het toenemende aantal omgevingen wordt het steeds uitdagender om ervoor te zorgen dat u consistente instellingen en governancebeleid op de omgevingen hebt toegepast. De functie voor omgevingsgroepen maakt dit makkelijker, doordat u benoemde groepen kunt maken en er omgevingen aan kunt koppelen, zoals het plaatsen van gerelateerde documenten in een bestandsmap.
Houd de volgende overwegingen in gedachten als u nadenkt over het gebruik van omgevingsgroepen:
Een omgeving moet worden beheerd om te kunnen worden opgenomen in een groep.
Een omgeving mag per keer maar in één groep aanwezig zijn.
Een omgeving mag van de ene naar een andere groep worden verplaatst.
Omgevingen in een groep kunnen afkomstig zijn uit meerdere geografische regio's.
Groepen mogen geen andere groepen bevatten.
Om u te helpen consistente instellingen en governance toe te passen, kunnen voor omgevingsgroepen een of meer van de volgende regels worden geconfigureerd en ingeschakeld:
Besturingselementen voor canvas-apps delen
Gebruiksinzichten
Welkomstinhoud voor maker
Oplossingscontrole afdwingen
Retentie van back-ups
Door AI gegenereerde beschrijvingen
Een regel wordt actief wanneer deze wordt gepubliceerd. Actieve regels worden toegepast op alle omgevingen die aan de groep zijn gekoppeld.
Wanneer een groepsregel een instelling beheert, zijn de individuele omgevingsinstellingen vergrendeld. De enige manier om ze te veranderen is door de regel aan te passen. Als de omgeving uit de groep wordt verwijderd, blijven de groepsinstellingen behouden, maar nu kan een omgevingsbeheerder deze wijzigen. Dit is belangrijk voor een omgevingsstrategie omdat het ervoor zorgt dat een omgevingsbeheerder het beleid dat u voor de groep instelt niet kan overschrijven.
Door omgevingsgroepen te gebruiken, kunt u uw omgevingen op logische manieren organiseren, vergelijkbaar met uw organisatiestructuur, productservicehiërarchie of andere raamwerken die we verderop zullen onderzoeken. Het volgende diagram is een conceptueel voorbeeld van hoe de Contoso-organisatie haar omgevingsgroepen zou kunnen organiseren.
Afbeelding: Conceptualisering van een omgeving-strategie voor een Contoso-tenant.
Wanneer u de regels plant die u wilt configureren, bedenk dan wat u op elk niveau van de conceptuele hiërarchie zou kunnen toepassen. Hoewel u de groepshiërarchie nog niet kunt configureren, kunt u een combinatie van naamconventies en configuratie van regels gebruiken om uw conceptuele ontwerp te implementeren. Gegeven de eerder getoonde conceptualisatie voor de Contoso-tenant geeft de volgende illustratie bijvoorbeeld de omgevingsgroepen weer die de organisatie zou kunnen gebruiken om het ontwerp ervan te implementeren.
Figuur: Voorbeeld van het implementeren van de conceptuele omgeving-groepen in de daadwerkelijke tenant
Verderop in dit artikel onderzoeken we meer manieren om omgevingsgroepen te gebruiken als onderdeel van een strategie voor een tenantomgeving.
Routering standaardomgeving
Een belangrijk onderdeel van de omgevingsstrategie die we in dit artikel schetsen, is om makers ervan te weerhouden resources in de standaardomgeving te creëren. De functie voor omgevingsroutering leidt makers om naar hun eigen, persoonlijke ontwikkelomgeving en creëert indien nodig nieuwe ontwikkelaarsomgevingen.
Afbeelding: Een maker wordt automatisch doorgestuurd naar een persoonlijke omgeving in plaats van de standaard Delen bij het bouwen van apps.
De ontwikkelomgevingen die door routering worden gemaakt, worden standaard beheerd. Gebruikers met Developer Plan-licenties zijn beperkt tot het maken en bekijken van resources in de omgeving. Om de resources als gebruiker te kunnen gebruiken, hebben ze een passende licentie nodig.
U kunt omgevingsroutering op zichzelf gebruiken, maar de aanbevolen manier is om deze met omgevingsgroepen te gebruiken. Wanneer u het op deze manier gebruikt, wordt elke gemaakte omgeving gekoppeld aan de groep die u aanwijst voor alle nieuwe ontwikkelaarsomgevingen, zodat deze onmiddellijk onder uw governancebeleid valt.
Makers krijgen automatisch een beveiligingsrol toegewezen, waardoor ze een omgevingsbeheerder van hun ontwikkelaarsomgeving worden. Wanneer de omgeving deel uitmaakt van een omgevingsgroep, kan de maker (als omgevingsbeheerder) de omgevingsinstellingen niet wijzigen, omdat deze worden beheerd door de regels van de omgevingsgroep. Alleen beheerders, die de groepsregels kunnen wijzigen, kunnen wijzigingen aanbrengen.
U kunt op twee manieren nog meer controle opleggen. Ten eerste kunt u het handmatig maken van ontwikkelaarsomgevingen in uw tenantinstellingen niet toestaan. Wanneer deze optie is ingesteld, kunnen makers zelf geen omgevingen maken in de beheerportal. Ze krijgen er ook niet automatisch een omgeving die door het routeringsbeleid wordt aangemaakt. Ten tweede kunt u in het routeringsbeleid een beveiligingsgroep opgeven om te beperken wie automatisch een omgeving kan laten maken.
In eerste instantie ondersteunt omgevingsroutering het routeren van nieuwe en bestaande makers weg van de standaardomgeving wanneer ze make.powerapps.com gebruiken. Na verloop van tijd zullen andere Power Platform-services de functie voor omgevingsroutering ondersteunen.
Microsoft Dataverse
Gegevens die worden gebruikt door toepassingen worden veilig opgeslagen en beheerd door Dataverse. In de context van een omgevingsstrategie gebruikt u de Dataverse-oplossingsfunctie om apps en onderdelen van de ene omgeving naar de andere te transporteren. Makers bouwen hun activa in containers (oplossingen) waarin wordt bijgehouden wat ze bouwen. Oplossingen kunnen eenvoudig naar andere omgevingen worden getransporteerd. Met deze aanpak kunt u ontwikkelaarsomgevingen, waar makers resources bouwen, scheiden van de productieomgevingen waarin ze worden gebruikt. Zowel makers als gebruikers profiteren ervan. Makers kunnen hun resources blijven ontwikkelen en gebruikers worden niet verrast door plotselinge veranderingen. Wanneer makers klaar zijn om hun wijzigingen te publiceren, kunnen ze een verzoek indienen om de bijgewerkte resource door te zetten naar de productieomgeving.
Dataverse-oplossingen zijn het mechanisme voor het implementeren van ALM in Power Platform-producten, zoals Power Apps en Power Automate. Pipelines in Power Platform gebruiken oplossingen voor het automatiseren van CI/CD van activa die makers bouwen. Oplossingen kunnen worden geëxporteerd vanuit Dataverse en opgeslagen in een hulpprogramma voor broncodebeheer zoals Azure DevOps of GitHub. De oplossing in broncodebeheer wordt de bron van de waarheid als u de ontwikkelomgeving opnieuw moet creëren. Als een maker bijvoorbeeld een populaire app heeft gebouwd en vervolgens de ontwikkelaarsomgeving heeft verwijderd, kan een geëxporteerde oplossing die is opgeslagen in broncodebeheer worden gebruikt om een bruikbare ontwikkelomgeving opnieuw te creëren.
Nog een belangrijke overweging bij het creëren van een omgeving met Dataverse, is of er Dynamics 365-toepassingen in de omgeving zullen worden geïmplementeerd. Als deze mogelijkheid er is, moet u Dynamics 365 inschakelen wanneer u de omgeving maakt, anders kunt u Dynamics 365-apps later niet installeren.
Wij raden u aan om Dataverse in te richten in elke omgeving waar makers activa creëren die met andere gebruikers worden gedeeld. Hierdoor zijn de activa makkelijker gereed voor ALM.
Voorkeursoplossingen
Wanneer een maker een Dataverse-activum maakt in een Dataverse-omgeving (en niet vanuit een maatwerkoplossing begint) is het activum gekoppeld aan de standaardoplossing en misschien ook aan de standaard Common Data Service-oplossing. De standaardoplossing wordt gedeeld door alle makers die activa in de omgeving creëren. Er is geen gemakkelijke manier om te bepalen welke maker welke onderdelen heeft gemaakt of welke activa bij welke apps horen. Dit kan het moeilijk maken om een populaire app door te zetten naar een andere omgeving om deze te delen met een groter publiek. U zou alle activa in de standaardoplossing moeten doorzetten, wat geen ideaal scenario is.
Om uw omgevingsstrategie te ondersteunen en deze gebruiksvriendelijker te maken, moeten makers een aangepaste oplossing in hun ontwikkelomgeving creëren en deze vervolgens instellen als de voorkeursoplossing in de omgeving. Makers stellen de voorkeursoplossing in een omgeving in om aan te geven aan welke oplossing een door hen gemaakt activum moet worden gekoppeld. Voorkeursoplossingen kunnen ervoor zorgen dat wanneer makers pipelines gebruiken om hun resources door te zetten naar andere omgevingen de doorgezette oplossing alle vereiste activa bevat. Zie dit als het voorbereiden van de activa zodat ze gereed zijn voor ALM.
Pipelines in Power Platform
Zoals we hebben gezien, is een belangrijk uitgangspunt van een goede omgevingsstrategie het afscheiden van de plaats waar een activum wordt gebouwd van die waar het wordt ingezet en gebruikt. Deze scheiding zorgt ervoor dat gebruikers die een activum proberen te gebruiken, geen downtime ondervinden omdat een maker deze aan het bijwerken is. Hiervoor is het echter nodig dat activa worden doorgezet naar een productieomgeving (idealiter als onderdeel van een Dataverse-oplossing) voordat ze kunnen worden gebruikt.
Dataverse-oplossingen kunnen handmatig tussen omgevingen worden getransporteerd. Met behulp van pipelines kunt u het proces echter automatiseren en beleid instellen om te waarborgen dat wijzigingsbeheer plaatsvindt. Afhankelijk van de omgevingsregels die u instelt in de oplossingscontrole, handhaven pipelines automatisch alle regels voordat de oplossing wordt geïmplementeerd, waardoor verdere implementatiefouten worden voorkomen. Het volgende diagram laat zien hoe met pipelines het doorzetten van een activum van ontwikkeling naar productie kan worden geautomatiseerd.
Afbeelding: Een pijplijn automatiseert het promoten van een activum die is opgeslagen in broncodebeheer, van ontwikkeling, via test, naar productie.
U kunt het aantal omgevingen en processen, zoals goedkeuringen, configureren dat in een pipeline moet worden opgenomen.
Pipelines werken samen met omgevingsgroepen. Ze kunnen vooraf worden geconfigureerd voor ontwikkelomgevingen, zodat makers eenvoudig het proces voor doorzetten kunnen starten door te reageren op een prompt wanneer ze hun activa met andere gebruikers proberen te delen. Als onderdeel van een implementatieaanvraag met behulp van pipelines kunnen makers voorstellen met wie ze hun activa willen delen en wat de vereiste beveiligingsrollen zijn. Een pipeline-beheerder kan de aanvraag vóór implementatie goedkeuren of afwijzen door te controleren op de minste bevoegdheden voor de maker die de aanvraag heeft ingediend.
Pipelines slaan de definities van elke pipeline op in een host omgeving die Power Platform standaard wordt beheerd. Microsoft U kunt echter meerdere hostomgevingen definiëren in uw tenant die u beheert, zodat u aan unieke vereisten kunt voldoen.
Catalogus in Power Platform
Organisaties waarin ontwikkelaars en makers onderdelen bouwen en delen, zoals apps en stromen en sjablonen, die geavanceerdere uitgangspunten zijn, halen doorgaans meer waarde uit Power Platform. Dankzij de Power Platform catalogus kunnen makers hun componenten en sjablonen effectiever in verschillende omgevingen inzetten.
De catalogus wordt in een omgeving geïnstalleerd en kan met de pipelinehost in dezelfde omgeving worden geïnstalleerd. Aan unieke vereisten voor resourcesegmentatie kan ook worden voldoen door meerdere omgevingen te hebben waarin een catalogus is geïnstalleerd.
Functieroutekaart
Terwijl de functies van Microsoft die governance en administratie ondersteunen, verder worden ontwikkeld, kunt u volgen volgen in de Power Platform Releaseplanner . U ontdekt wat er gepland is, wat er in de komende releasewave zit en wat u nu al kunt uitproberen. U kunt zelfs uw eigen releaseplan maken door de items die u wilt volgen op te slaan.
De basis van een omgevingsstrategie op ondernemingsniveau
We hebben onze visie voor een strategie voor een tenantomgeving op ondernemingsniveau besproken, evenals de belangrijkste omgevingskenmerken die deze ondersteunen. Nu bekijken we hoe u die functies samen kunt gebruiken als onderdeel van een omgevingsstrategie. Uw strategie moet gebaseerd zijn op de unieke vereisten van uw organisatie. Laten we dus beginnen met een simpel voorbeeld, voordat we bekijken hoe u een strategie kunt afstemmen op uw behoeften.
In dit voorbeeld wil het management van Contoso medewerkers in staat stellen te profiteren van het Power Platform en hebben ze de volgende vereisten op hoog niveau geïdentificeerd:
Medewerkers moeten geautomatiseerde processen voor goedkeuring van documenten en andere Power Platform-aanpassingen kunnen maken met Microsoft 365.
Medewerkers moeten Power Apps en Power Automate-automatiseringen kunnen bouwen om hun persoonlijke productiviteit te verbeteren.
De makers die aan de Compliance Tracker-app van het bedrijf werken, moeten deze kunnen ontwikkelen en onderhouden.
Ter ondersteuning van deze vereisten heeft het beheer- en governanceteam van Contoso de volgende omgevingstopologie bedacht:
Afbeelding: Voorgestelde omgeving-topologie voor Contoso's Power Platform project op schaal.
Laten we deze omgevingstopologie eens tot in detail bekijken.
De standaardomgeving wordt gebruikt om Microsoft 365-productiviteitsaanpassingen te bouwen. Verliespreventiebeleid en beperkingen op het delen beperken andere soorten activiteiten van makers en plaatsen vangrails rond wat makers in deze omgeving kunnen bouwen.
Alleen beheerders kunnen proef-, sandbox- en productieomgevingen maken. Makers gebruiken een aangepast Microsoft formulier of een ander proces om een nieuwe omgeving aan te vragen. De Microsoft Power Platform Center of Excellence (CoE) Starter Kit bevat een omgevingsaanvraag die kan worden gebruikt.
Er worden vier omgevingsgroepen gemaakt: Ontwikkeling, Gedeelde ontwikkeling, UAT (gebruikersacceptatietesten) en Productie.
Een omgevingsrouteringsbeleid dat is ingesteld voor de groep Ontwikkeling leidt makers weg van de standaardomgeving naar hun eigen ontwikkelaarsomgevingen. Wanneer er nieuwe ontwikkelomgevingen worden gemaakt, worden deze automatisch gekoppeld aan de groep Ontwikkeling en worden de regels daarvan toegepast.
De groep Gedeelde ontwikkeling ondersteunt omgevingen die projecten met meerdere makers bevatten.
De UAT-groep bevat omgevingen die worden gebruikt om resources te testen voordat ze worden doorgezet naar productie.
De groep Productie bevat omgevingen die apps, stromen en andere artefacten hosten voor productiegebruik.
Iets wat in deze voorgestelde topologie ontbreekt, zijn pipelines om doorzetten naar ontwikkel-, test- en productieomgevingen te automatiseren. Laten we ze nu toevoegen.
Afbeelding: Dezelfde omgeving-topologie met pijplijnen die een pijplijnhost omgeving verbinden met ontwikkelings-, test- en productieomgevingen.
In het herziene diagram voor omgevingstopologie hebben we een pipeline-hostomgeving en twee pipelines toegevoegd. Eén pijplijn verplaatst resources van ontwikkel- naar test- en vervolgens naar productieomgevingen. De pipelineregel voor de groep Ontwikkeling wordt aangepast om deze pipeline te gebruiken. De andere pipeline verplaatst resources van de gedeelde ontwikkelomgeving naar testen en vervolgens naar productie. De pipelineregel voor de groep Gedeelde ontwikkeling wordt aangepast om deze pipeline te gebruiken.
Deze eenvoudige omgevingsstrategie biedt een basis waarop u kunt voortbouwen voor andere gebruiksscenario's, die we hierna onderzoeken.
Omgevingsstrategieën voor specifieke scenario's
Hier volgen enkele veelvoorkomende gebruiksscenario's die u mogelijk moet opnemen in de basisstrategie voor tenantomgevingen.
Bepalen welke makers ontwikkelaarsomgevingen mogen maken
Standaard kan iedereen die een Power Platform Premium-licentie, een Developer Plan-licentie of een Power Platform-tenantbeheerdersrol een ontwikkelaarsomgeving maken vanuit de beheerportal.
In de basisomgevingsstrategie zorgt omgevingsroutering ervoor dat makers weggeleid worden van de standaardomgeving naar een nieuwe ontwikkelaarsomgeving die in de aangewezen groep is gemaakt. Makers kunnen echter nog steeds handmatig ontwikkelaarsomgevingen maken die niet in een omgevingsgroep zijn geplaatst en waarop de regels niet worden toegepast.
Als u wilt verfijnen welke makers in aanmerking komen voor omgevingsroutering, geeft u een beveiligingsgroep op in de routeringsconfiguratie. Wanneer een beveiligingsgroep wordt geconfigureerd, worden alleen leden van de beveiligingsgroep gerouteerd. Alle anderen vallen terug naar de standaardomgeving.
Geavanceerde makers meer flexibiliteit bieden
In de basisomgevingsstrategie worden alle nieuwe makeromgevingen doorgestuurd naar een aangewezen ontwikkelaarsomgevingsgroep. Normaal gesproken wordt op deze groep omgevingen een tamelijk beperkende set governanceregels toegepast.
Naarmate makers geavanceerder worden, kunt u hen toegang tot meer mogelijkheden laten aanvragen. In plaats van ze uit de oorspronkelijke omgevingsgroep te verwijderen en de uitzondering handmatig te beheren, kunt u een andere omgevingsgroep gebruiken om deze geavanceerde makers te volgen.
Afbeelding: Voeg meer capabele makers toe aan een omgeving met versoepelde governance-regels.
Ontwikkelaarsomgevingen organiseren per regio of Business Unit
In de huidige implementatie van omgevingsroutering worden alle nieuwe ontwikkelaarsomgevingen in één omgevingsgroep gemaakt. Wat als u de ontwikkelaarsomgevingen van uw makers bijvoorbeeld wilt indelen op regio of Business Unit?
Gebruik routering om makers naar een nieuwe ontwikkelaarsomgeving te leiden die in de aangewezen groep is gemaakt. Vervolgens kunt u deze verplaatsen naar een andere groep die is gebaseerd op regio, organisatie-eenheid of andere criteria, waar u gedetailleerdere governanceregels kunt toepassen.
Afbeelding: Nadat omgeving routing ontwikkelaarsomgevingen in de aangewezen groep heeft aangemaakt, verplaatst u deze naar meer structureel specifieke groepen.
Het verplaatsen van omgevingen is tegenwoordig een handmatige actie. U kunt dit proces echter automatiseren wanneer de Power Platform admin-connector de groepsfunctie in een toekomstige update ondersteunt.
Een app voor zakelijk gebruik ontwikkelen
Een team in uw organisatie ontwikkelt mogelijk een app die door het hele bedrijf gebruikt gaat worden. Het team kan IT-gestuurd zijn of zowel IT- als zakelijke gebruikers omvatten (een zogenaamd fusieteam).
In de eenvoudigste omgevingsstrategie bouwt het projectteam een gedeelde omgeving van het type sandbox of productie. Een type ontwikkelaarsomgeving is niet de beste manier om meerdere makers te ondersteunen die aan een resource samenwerken. De makers moeten echter met elkaar communiceren om botsingen en conflicten in de gedeelde omgeving te voorkomen.
Er zijn geen speciale test- en productieomgevingen vereist. De app kan worden getest en geïmplementeerd in organisatiebrede test- en productieomgevingen waarin meerdere toepassingen worden gehost.
Afbeelding: Twee bedrijfsapps die in speciale omgevingen worden ontwikkeld en vervolgens worden getest en geïmplementeerd in omgevingen die met andere apps worden gedeeld.
In een meer geavanceerde variant heeft elke maker een afzonderlijke ontwikkelaarsomgeving. Dit heeft het voordeel dat het de maker een grotere isolatie biedt, maar kan het combineren van individueel werk in een integratieomgeving ingewikkelder maken. Hoewel afzonderlijk werken nuttig kan zijn voor grotere, geavanceerde teams, kan het onnodige overhead geven aan kleinere teams die beter kunnen samenwerken in een gedeelde ontwikkelomgeving.
Afbeelding: Twee makers die in afzonderlijke ontwikkelomgevingen aan dezelfde app werken, moeten hun werk combineren in een gedeelde integratie omgeving voordat de test- en productiefase begint.
Deze variant omvat gewoonlijk een strategie voor broncodebeheer, waarbij elke ontwikkelomgeving wordt weergegeven als een branch in broncodebeheer die wordt samengevoegd wanneer wijzigingen klaar zijn om te worden doorgezet. Het is belangrijk om rekening te houden met hoe de toepassing zal worden onderhouden na de eerste release.
Versie 1.0 van de app kan bijvoorbeeld in productie zijn terwijl het team doorgaat met het bouwen van versie 2.0. Uw omgevingsstrategie moet het oplossen van een probleem in versie 1.0 ondersteunen, terwijl de ontwikkeling van versie 2.0 gaande is.
Afbeelding: Versie 1.0 moet worden gepatcht, getest en geïmplementeerd, terwijl versie 2.0 wordt ontwikkeld, getest en geïmplementeerd.
Omgevingsgroepen bieden meerdere benaderingen voor het omgaan met dit bedrijfsapp-scenario. Dit kan bijvoorbeeld één app-groep zijn, maar het kan ook gaan om van afzonderlijke groepen voor elke fase van de ontwikkeling. In de sectie met best practices bekijken we hoe we de opties kunnen evalueren.
Het gebruik van ontwikkelaarsomgevingen tot een minimum beperken
Individuele ontwikkelaarsomgevingen zijn de aanbevolen manier om makers een werkruimte te bieden om oplossingen met weinig code te bouwen. Ze bieden het hoogste niveau aan isolatie van andere makers. Maar als uw organisatie het aantal ontwikkelaarsomgevingen wil minimaliseren, zijn meerdere gedeelde omgevingen beter dan het aanmoedigen van makers om activa in de standaardomgeving te bouwen.
In dit scenario beperkt u het maken van ontwikkelaarsomgevingen en maakt u gedeelde ontwikkelomgevingen van het type productie. U kunt deze gedeelde omgevingen indelen op organisatiestructuur, regio of andere criteria. Een omgevingsgroep zou ze kunnen beperken om ervoor te zorgen dat er consistente governanceregels worden toegepast. Geef makers toestemming om activa met weinig code te maken in de omgeving die aan hen is toegewezen.
Beveiliging als onderdeel van uw omgevingsstrategie
Omgevingen zijn een belangrijk onderdeel van veilig gebruik van Power Platform. Ze vertegenwoordigen beveiligingsgrenzen binnen uw tenant die helpen bij het beschermen van apps en gegevens. Het is belangrijk om als onderdeel van uw omgevingsstrategie te bekijken wat de invloed van uw beveiligingsvereisten is op het aantal en doel van de omgevingen in uw tenant.
Met omgevingen kunt u meerdere beveiligingsgrenzen binnen uw tenant creëren om apps en gegevens te beschermen. De bescherming die de omgeving biedt, kan worden aangepast om aan de noodzakelijke beveiligingsbescherming te voldoen door een configureerbare set beveiligingsfuncties toe te passen op de omgeving. Een gedetailleerde bespreking van afzonderlijke beveiligingskenmerken van de omgeving valt buiten het bestek van dit artikel. In deze sectie bieden we echter aanbevelingen voor hoe u beveiliging als onderdeel van de strategie van uw tenantomgeving kunt zien.
Beveiliging op tenantniveau
De meeste beveiligingsinstellingen die van invloed zijn op omgevingen, worden voor elke omgeving afzonderlijk geconfigureerd. U kunt echter enkele wijzigingen aanbrengen op tenantniveau ter ondersteuning van uw omgevingsstrategie.
- Overweeg het uitschakelen van de functie Delen met iedereen in Power Platform. Alleen beheerders kunnen een activum met iedereen delen.
- Overweeg om integratie met Exchange te beveiligen.
- Pas isolatie tussen tenants toe om het risico op gegevensexfiltratie tussen tenants te minimaliseren.
- Beperk het maken van netto nieuwe productieomgevingen tot beheerders. Het beperken van het aanmaken van omgeving is gunstig voor het behoud van de controle in het algemeen: zowel om onopgemerkt capaciteitsverbruik te voorkomen als om het aantal te beheren omgevingen te beperken. Als gebruikers omgevingen moeten aanvragen bij centrale IT, is het gemakkelijker om te zien waaraan mensen werken als beheerders optreden als poortwachter.
De standaardomgeving beveiligen
De standaardomgeving speelt een rol bij het ondersteunen van Microsoft 365-productiviteitsaanpassingen. Als onderdeel van de aanbevolen omgevingsstrategie kunt u het gebruik ervan echter het best tot een minimum beperken. In plaats daarvan zouden makers hun eigen geïsoleerde omgevingen moeten inbouwen. Hoewel u de toegang tot de standaardomgeving niet kunt blokkeren, kunt u wel minimaliseren wat daarin kan worden gedaan.
Gebruik eerst omgevingsroutering om makers naar hun eigen werkruimte te leiden om activa met weinig code te bouwen.
Bekijk wie beheerderstoegang heeft tot de standaardomgeving en beperk deze tot rollen voor wie dit nodig is.
Overweeg de naam van de standaardomgeving te wijzigen in iets wat meer beschrijvend is, zoals Persoonlijke productiviteit.
Stel een DLP-beleid (preventie van gegevensverlies) op voor de standaardomgeving dat nieuwe connectoren blokkeert en makers beperkt tot het gebruik van alleen eenvoudige, niet-blokkeerbare connectoren. Verplaats alle connectors die niet kunnen worden geblokkeerd naar de bedrijfsgegevensgroep. Verplaats alle blokkeerbare connectors naar de geblokkeerde gegevensgroep.
Maak een regel om alle URL-patronen te blokkeren die door aangepaste connectoren worden gebruikt.
Het beveiligen van de standaardomgeving moet een prioriteit zijn. Doe dit samen met beveiliging op tenantniveau als onderdeel van de eerste stap bij het implementeren van uw omgevingsstrategie. Zijn deze niet geïmplementeerd, dan hebben makers meer mogelijkheden om activa toe te voegen aan de standaardinstellingen. Zijn deze vastgelegd in combinatie met omgevingsroutering, dan worden makers aangemoedigd om hun eigen omgeving te gebruiken.
Andere omgevingen beveiligen
Als u een doorsnee organisatie bent, dan beschikt u naast de standaardomgeving over meerdere andere omgevingen. Het beveiligingsniveau dat voor elk vereist is, kan variëren op basis van de apps en gegevens die erin zijn opgenomen. Ontwikkelaarsomgevingen hebben doorgaans minder strenge regels dan productieomgevingen. Sommige productieomgevingen vereisen de best mogelijke beveiliging.
Als onderdeel van het vaststellen van uw omgevingsstrategie bepaalt u gemeenschappelijke beveiligingsniveaus voor uw omgevingen en de functies waarmee elk niveau wordt beveiligd, zoals in het onderstaande voorbeeld.
Afbeelding: Een voorbeeld van drie niveaus van omgeving-beveiliging en de beveiligingsfuncties die van toepassing zijn op omgevingen in elk niveau.
Neem de beveiligingsniveaus die u identificeert op in uw groepsstrategie en gebruik waar mogelijk regels om de beveiligingsfuncties in uw omgevingen in te schakelen. In dit voorbeeld beperkt een regel het delen in alle omgevingen die zijn aangemerkt als normale of gemiddelde beveiliging.
Omgevingen afstemmen op uw strategie ter preventie van gegevensverlies
Gegevensbeleid is een ander belangrijk onderdeel van een algehele governance-inzet voor het beheer van de services die worden gebruikt door resources met weinig code in een omgeving. Omgevingsgroepen hebben geen regel voor het toepassen van DLP-beleid op een omgeving. U kunt uw DLP-strategie echter afstemmen op uw omgevingsgroepen. U kunt bijvoorbeeld DLP-beleid maken met dezelfde of een vergelijkbare naam als een omgevingsgroep en dit toepassen op omgevingen in die groep.
Lees meer over het opzetten van een DLP-strategie.
Afbeelding: In dit voorbeeld hebben omgevingen in de Personal Dev-groep volgen een DLP-beleid dat alle niet-Microsoft connectoren blokkeert.
Een omgevingsstrategie op maat maken voor uw organisatie
In eerdere secties hebben we onze visie beschreven op hoe organisaties omgevingen op schaal kunnen beheren. We hebben essentiële eigenschappen bekeken, hoe deze bijdragen aan een omgevingsstrategie en hoe een basis-omgevingstopologie die deze gebruikt, eruit zou kunnen zien. We hebben voorbeelden gegeven van hoe op die basis kan worden voortgebouwd om aan veelvoorkomende scenario's tegemoet te komen. Omdat elke organisatie uniek is, is de volgende stap dat u een omgevingsstrategie op maat maakt die voldoet aan de behoeften van uw organisatie.
Begin waar u staat
Of uw organisatie nog niet bekend is met Power Platform of het al jaren gebruikt, de eerste stap is het evalueren van uw situatie. Beoordeel, op hoog niveau, wat uw standaardomgeving bevat, welke andere omgevingen u hebt en waarvoor ze worden gebruikt. Vaak wordt een omgevingsstrategie uitgevoerd als onderdeel van een algemene inzet om governance op te zetten voor Power Platform in een organisatie. Als dat het geval is, hebt u wellicht al een deel van de governance-visie vastgelegd die nodig is om een strategie op maat te maken voor uw organisatie.
Informatie over de organisatie waarmee u bekend moet zijn, omvat:
Wat is de visie op hoe Power Platform zal worden gebruikt in de organisatie?
Wie in de organisatie gaat activa met weinig code bouwen?
U moet een aantal belangrijke beslissingen nemen:
Hoe krijgen makers nieuwe omgevingen?
Gaat u uw omgevingen groeperen, en zo ja, hoe?
Welke beveiligingsniveaus zijn vereist voor verschillende omgevingen en hoe worden omgevingen geclassificeerd?
Hoe bepaalt u of een app, automatisering of Copilot gebruik gaat maken van een bestaande of een nieuwe omgeving?
Zijn er hiaten tussen de basisfuncties van het platform en uw vereisten waarvoor een aangepast governanceproces nodig is?
Hoe gaat u om met bestaande activa in de standaardomgeving?
Hebt u een DLP-beleidsstrategie voor tenants en omgevingen, en zo ja, hoe sluit deze aan bij de omgevingsstrategie die u aan het maken bent?
Mogelijk kunt u ook wat inspiratie halen uit de cloud-werkmodellen die deel uitmaken van het Cloud Adoption Framework voor Azure.
Gaten dichten opvullen met behulp van het platform
U zult bijna altijd eisen tegenkomen waaraan de ingebouwde mogelijkheden van het platform niet voldoen. Houd bij het evalueren van deze gaten rekening met de volgende mogelijke uitkomsten van uw evaluatie:
Het gat is acceptabel.
Het gat kan worden gedicht met de Power Platform Center of Excellence Starter Kit.
Het gat kan worden gedicht met behulp van de mogelijkheden van het platform, zoals API's, connectoren en apps op maat of automatiseringen.
Het gat kan worden gedicht met behulp van een tool of app van derden.
CoE Starter Kit
De Power Platform Center of Excellence Starter Kit is een verzameling onderdelen en tools die zijn ontworpen om uw organisatie te helpen bij het invoeren van Power Platform en het ondersteunen van het gebruik ervan. Een belangrijk aspect van de starterkit is de mogelijkheid om gegevens te verzamelen over platformgebruik in uw omgevingen, wat nuttig kan zijn bij het ontwikkelen en evolueren van uw omgevingsstrategie.
Het Power BI-dashboard Omgevingen biedt bijvoorbeeld een overzicht waarmee u inzicht krijgt in welke omgevingen er in uw tenant bestaan, wie deze heeft gemaakt en welke activa ze bevatten.
Afbeelding: Het dashboard Omgevingen in Power BI.
De kit bevat uitgangspunten of inspiratie, zoals een proces dat makers kunnen gebruiken voor het aanvragen van nieuwe omgevingen en wijzigingen in het DLP-beleid voor hun omgevingen.
Figuur: Stroomdiagram dat een omgeving-beheerproces in de CoE Starter Kit illustreert.
Programmeerbaarheid en uitbreidbaarheid van platforms
Een van de mooie dingen van een platform met weinig code is dat je het kunt gebruiken om apps, automatiseringen, portals en copilots te bouwen om je te helpen bij het beheer ervan. U hebt ook toegang tot tools op een lager niveau die kunnen worden gebruikt om gaten te dichten ter ondersteuning van uw omgevingsstrategie.
U kunt de volgende connectoren gebruiken om apps en stromen te bouwen:
U kunt de Power Platform-opdrachtregelinterface (CLI) gebruiken om automatiseringen te ontwikkelen waarmee u de levenscyclus van de omgeving en andere taken met betrekking tot DevOps-praktijken kunt beheren.
Met PowerShell-cmdlets voor Power Platform-makers en -beheerders kunt u veel bewakings- en beheertaken automatiseren.
De Power Platform DLP SDK kan u helpen bij het beheren van het beleid ter preventie van gegevensverlies voor uw tenant en omgeving.
Best practice-aanbevelingen
In dit deel van het artikel bouwen we voort op de aanbevelingen in de basis- en scenariospecifieke secties.
Nieuwe omgevingen
Als onderdeel van het ontwikkelen van uw strategie, moet u nadenken over wanneer u omgevingen creëert ter ondersteuning van een workload. In de evaluatie moet een balans vinden tussen de voordelen van isolatie die een omgeving biedt (het is bijvoorbeeld nuttig om bepaalde omgevingen beter af te sluiten dan andere vanuit beveiligingsoogpunt) en de nadelen, zoals dat isolatie wrijving veroorzaakt voor gebruikers die gegevens proberen te delen tussen apps.
Wanneer u beoordeelt of een app of een automatisering in een eigen omgeving thuishoort, beoordeelt u de verschillende fasen van de levenscyclus van de app afzonderlijk. Tijdens de ontwikkeling is isolatie van andere apps belangrijk. Wanneer meerdere apps in één omgeving worden ontwikkeld, loopt u het risico dat er afhankelijkheden tussen apps ontstaan.
Als algemene aanbeveling moeten ontwikkelomgevingen, indien mogelijk, voor één doel dienen, wegwerpbaar zijn en gemakkelijk opnieuw kunnen worden gecreëerd.
Het testen van meerdere apps in dezelfde omgeving is zinvol als ze samen in productie draaien. Als u niet test met de apps die in productie zullen worden uitgevoerd, loopt u het risico dat compatibiliteitsproblemen onopgemerkt blijven.
Houd bij het evalueren van de productieomgeving voor een app rekening met de volgende overwegingen:
Is de app compatibel met bestaande apps in de omgeving? Twee apps die beide de Dataverse-contacttabel gebruiken voor verschillende doeleinden zijn bijvoorbeeld mogelijk niet compatibel. Zijn de apps compatibel vanuit het oogpunt van DLP-beleid?
Zijn er speciale nalevings- of wettelijke vereisten voor de scheiding van gegevens? Is het omwille van de gevoeligheid van de gegevens nodig om deze te isoleren? Is er een vereiste dat gegevens niet mogen worden opgenomen met andere gegevens?
Zijn de gegevens zeer vertrouwelijk of gevoelig? Zou exfiltratie tot financiële of reputatieschade voor de organisatie kunnen leiden? Het isoleren in een aparte omgeving kan meer controle over de beveiliging mogelijk maken.
Heeft de app gegevens van andere apps nodig en moet deze daarmee worden gecombineerd? Twee apps die beide uw klanttabel gebruiken, moeten bijvoorbeeld samen worden gehost. Het scheiden ervan zou overtollige gegevenskopieën creëren en problemen veroorzaken bij het onderhouden van de gegevens.
Is er regionale gegevenslocatie nodig voor de gegevens? In sommige scenario's kan dezelfde app of automatisering worden geïmplementeerd in regionale omgevingen om de juiste gegevensisolatie en locatie te garanderen.
Bevinden de meeste gebruikers zich in dezelfde regio als de omgeving? Als de omgeving zich in EMEA bevindt, maar de meeste gebruikers van de app in de VS wonen, levert het delen van een omgeving mogelijk niet de beste prestaties.
Zijn er nieuwe beheerders nodig of zijn de bestaande beheerders voldoende? Als er voor de nieuwe app meer beheerders nodig zijn, zijn deze dan compatibel met de bestaande beheerders, omdat ze allemaal beheerdersrechten hebben voor alle apps in de omgeving?
Wat is de levensverwachting van de app? Als de app of automatisering tijdelijk of van korte duur is, is het wellicht geen goed idee om deze in een omgeving met meer permanente apps te installeren.
Zullen gebruikers moeite hebben om meerdere omgevingen voor verschillende apps te gebruiken? Dit kan van invloed zijn op van alles, van het vinden van een app op hun mobiele apparaat tot selfservice rapportage waarbij gegevens uit meerdere omgevingen moeten worden gehaald.
Capaciteit
Elke omgeving (behalve proef- en ontwikkelaarsomgevingen) verbruikt 1 GB bij de inrichting in eerste instantie. Capaciteit wordt gedeeld binnen de tenant en moet daarom worden toegewezen aan degenen die deze nodig hebben.
Bespaar capaciteit door:
- Gedeelde test- en productieomgevingen te beheren. Machtigingen in test- en productieomgevingen moeten, in tegenstelling tot gedeelde ontwikkelomgevingen, worden beperkt tot gebruikerstoegang voor testdoeleinden.
- Automatiseer het opschonen van tijdelijke ontwikkelomgevingen en moedig het gebruik van proefomgevingen aan voor testen of proof-of-concept werk.
Omgevingsgroepen
Omgevingsgroepen zijn flexibel en bieden u de mogelijkheid om verschillende gebruiksscenario's aan te passen die uniek zijn voor uw organisatie. Hier volgen enkele manieren waarop u het groeperen van omgevingen kunt overwegen als onderdeel van uw omgevingsstrategie:
Per service of onderdeel; bijvoorbeeld een ServiceNow-servicestructuur
Ontwikkeling, testen en productie
Afdelingen, bedrijfsgroepen of kostenplaatsen
Op projecten
Op locatie, als de meeste omgevingen op een locatie vergelijkbare governancebehoeften hebben. Dit kan ook helpen bij het voldoen aan vergelijkbare regionale regelgeving en wettelijke naleving
Afbeelding: omgeving-groepen voor twee verschillende afdelingen hebben verschillende regels.
Omgevingen en groepen benoemen
Overweeg als onderdeel van uw strategie welke naam omgevingen en groepen krijgen.
Omgevingsnamen zijn zichtbaar voor beheerders, makers en gebruikers. Normaal gesproken gebruiken alleen beheerders omgevingsgroepen, maar makers kunnen deze tegenkomen als ze bevoegdheden hebben om omgevingen te maken.
Ontwikkelaarsomgevingen die automatisch worden gemaakt, volgen het patroon <gebruikersnaam>'s omgeving; bijvoorbeeld 'Avery Howards omgeving'. Omgevingsgroepen krijgen niet automatisch een naam.
Namen van omgevingen en omgevingsgroepen hoeven niet uniek te zijn. Om verwarring te voorkomen, is het echter een best practice om dubbele namen te vermijden.
Namen mogen maximaal 100 tekens lang zijn. Kortere namen zijn gemakkelijker in gebruik.
Zorg voor een consistente naamconventie.
Consistente namen helpen beheerders te weten wat het doel van de groep is en welke omgevingen deze beheert, en kunnen automatisering en rapportage vereenvoudigen.
Het is gebruikelijk om de levenscyclusfase op te nemen in de naam van een omgeving; bijvoorbeeld Contoso Dev, Contoso Test, Contoso Prod. Het doel is om omgevingen met dezelfde inhoud, maar met verschillende doeleinden, duidelijk van elkaar te onderscheiden.
Een andere veel voorkomend gebruik is om de afdeling of Business Unit in de naam op te nemen wanneer de omgeving aan die groep gebruikers is toegewezen.
U kunt bijvoorbeeld besluiten dat alle namen van omgevingen of omgevingsgroepen het volgende patroon moeten volgen: <levenscyclusfase>-<regio><Business Unit>-<doel> (Prod-VS-Finance-Payroll).
Houd de namen kort, betekenisvol en beschrijvend.
Denk na over hoe uw groepen in de loop van de tijd zullen evolueren en groeien, en zorg ervoor dat uw naamconventie aan deze veranderende behoeften kan voldoen.
Neem geen vertrouwelijke gegevens op in namen. Deze kunnen zichtbaar zijn voor iedereen die toegang heeft tot het beheercentrum.
Activa in de standaardomgeving
Uw omgevingsstrategie moet het gebruik van persoonlijke ontwikkelomgevingen aanmoedigen (of afdwingen) om wat er in de standaardomgeving wordt gecreëerd te beperken. U moet echter kijken naar wat makers al hebben gemaakt in de standaardomgeving en evalueren hoe u met elke gebruikssituatie moet omgaan. Is het gepast om het activum in de standaardomgeving te behouden of moet dit naar een andere omgeving worden gemigreerd?
Een belangrijk onderdeel van het uitvoeren van deze opschoningsinspanningen is het identificeren van toepassingen die door de hele organisatie heen worden gebruikt en die een eigen beschermde ontwikkelomgeving moeten hebben die gescheiden is van de productieomgeving.
De volgende tabel bevat voorbeelden van gebruiksscenario's en migratieacties. Uiteindelijk moet uw organisatie haar eigen gebruiksscenario's en risicofactoren identificeren in relatie tot het behouden van activa in de standaardomgeving. Lees meer over wanneer u activa moet verplaatsen van de standaardinstelling omgeving.
| Standaard omgeving | Migratie actie |
|---|---|
| Microsoft 365 persoonlijke productiviteit | In de standaardomgeving blijven. |
| Activa met één maker die onlangs zijn gebruikt, maar niet zijn gedeeld | Verplaatsen naar de eigen ontwikkelaarsomgeving van de eigenaar. |
| Activa met één maker die onlangs zijn gebruikt en zijn gedeeld | Verplaatsen naar de eigen ontwikkelaarsomgeving van de eigenaar en uitvoeren vanuit een gedeelde productieomgeving. |
| Activa met meerdere makers die onlangs zijn gebruikt en zijn gedeeld | Verplaatsen naar een gedeelde ontwikkelaarsomgeving en uitvoeren vanuit een gedeelde productieomgeving. |
| Activa die niet onlangs zijn gebruikt | De eigenaar inlichten en overbrengen naar quarantaine indien er geen reactie is. |
Activa in Dataverse for Teams-omgevingen
Microsoft Dataverse for Teams stelt gebruikers in staat om aangepaste apps, bots en stromen te bouwen in Microsoft Teams met behulp van Power Apps, Microsoft Copilot Studio en Power Automate. Wanneer een teameigenaar deze mogelijkheid aan zijn team toevoegt, wordt een Microsoft Power Platform-omgeving met een Dataverse for Teams-database gemaakt en aan hun team gekoppeld. Leer hoe u governancebeleid kunt opstellen om Microsoft Dataverse for Teams omgevingen te beheren.
Omgeving strategie intern bij Microsoft
Microsoft beschouwt zichzelf als "Customer Zero" omdat het bedrijf intern automatisering en efficiëntie onder zijn werknemers wil stimuleren. Power Platform De volgende getallen geven u een idee beeld van de schaal van het gebruik binnen de Microsoft interne tenant.
50.000-60.000 actieve makers elke maand
Meer dan 250.000 toepassingen en meer dan 300.000 stromen
Meer dan 20.000 omgevingen
Microsoft stapt over van de eerdere omgeving-strategie naar een strategie die gebruikmaakt van de nieuwste governancefuncties, waaronder Beheerde omgevingen, omgeving-groepen en -regels. Power Platform
Als onderdeel van de verbeterde strategie zijn er plannen om scenario's te groeperen op basis van ontwikkelingstype, organisatorisch eigenaarschap en risiconiveau. Microsoft Omdat er in het hele bedrijf zoveel wordt gebouwd, is het te moeilijk om op elk mogelijk scenario te concentreren en het voor elke gebruikssituatie aan te passen. Er gebeurt te veel en het moet worden geautomatiseerd en zoveel mogelijk kant-en-klare besturingselementen gebruiken.
Microsoft structureert zijn omgevingen in drie bredere categorieën die zeven use cases bestrijken, die verschillende niveaus van risico en controle weerspiegelen: persoonlijke productiviteit, samenwerking in teamverband en bedrijfsontwikkeling. Power Platform
Persoonlijke productiviteit – Dit is voor iemand die gewoon een app of flow voor zichzelf wil bouwen. Ze werken bijvoorbeeld niet samen met anderen. Deze gebruikers worden doorgestuurd naar persoonlijke ontwikkelomgevingen, die vergrendeld zijn. Deze omgevingen maken gebruik van de functies van de beheerde omgeving, waaronder het beperken van delen en het beheren van andere dingen die u in de omgevingen kunt doen. De connectoren en de beschikbare acties zijn in deze groep omgevingen sterk beperkt. Deze omgevingen zijn het minst riskant. Door het gebruik van vergrendelde, persoonlijke omgevingen kunnen gebruikers het strengere nalevingsproces vermijden als ze enkel persoonlijke productiviteitsapps en -stromen bouwen.
Samenwerking in teams – Dit is bedoeld voor gebruikers die tools, automatisering en processen voor hun team bouwen. Voor dit scenario Microsoft wordt het gebruik van Dataverse for Teams omgevingen aanbevolen. Levenscyclus, toegangsbeheer en labelen van gegevens worden beheerd op Microsoft 365-groepsniveau, zodat we geen tijd hoeven te besteden aan het beheer van deze gebruikers vanuit een Power Platform-governance-oogpunt. Dit gebruiksniveau is de volgende stap in het risicospectrum.
Bedrijfsontwikkeling/productieniveau, gebruikt door alle werknemers – Dit zijn mensen die tools of oplossingen bouwen die breder binnen het bedrijf worden gebruikt. In deze omgevingen kunnen de meest gevoelige gegevens worden opgeslagen, krachtigere connectoren worden gebruikt en meer governance vereisen. Dit wordt als het grootste risico beschouwd en de meeste energie wordt besteed aan governance. ALM is vereist, omdat preproductiewerk plaatsvindt in sandboxomgevingen en binnen productieomgevingen alleen beheerde oplossingen zijn toegestaan. Deze omgevingen moeten worden gekoppeld aan ServiceTree, dat terugkerende beveiligings- en privacybeoordelingen afdwingt. De omgevingsgroepsregels worden aangepast op basis van ServiceTree-metagegevens en signalen. Er worden veel omgevingsgroepen en -regels gebruikt om deze omgevingen te beheren en controleren.
MicrosoftDe governance-strategie van is niet statisch. Deze is veranderbaar en verandert om zich aan nieuwe uitdagingen aan te passen en nieuwe Power Platform-functies te integreren.
De strategie voor uw tenantomgeving doorontwikkelen
In dit artikel hebben we beschreven hoe u een strategie voor een tenantomgeving op ondernemingsniveau kunt opzetten. De strategie kan met uw bedrijf meegroeien, ongeacht waar u aan het traject begint. Organisaties van elke omvang kunnen profiteren van de strategie die wij presenteren. Voor organisaties die al op grotere schaal werken zijn de voordelen echter groter.
Het ontwikkelen van een strategie voor een tenantomgeving is geen eenmalige activiteit. Het is een reis. U moet uw strategie in de loop van de tijd doorontwikkelen naarmate uw behoeften veranderen. Uw strategie moet zich ook aanpassen om nieuwe mogelijkheden van het platform te gebruiken en nieuwe uitdagingen aan te pakken.
Zoals bij alle reizen komen verschillende organisaties onderweg op verschillende punten samen, maar ze hebben allemaal dezelfde bestemming in gedachten. Wat volgt zijn mogelijke instappunten die representeren waar uw organisatie nu staat.
Begin
Uw organisatie staat aan het begin van het invoeringstraject voor Power Platform. Dit wordt vaak een greenfield genoemd. U begint uw reis op de beste plek, omdat u zich geen zorgen hoeft te maken over bestaande omgevingen of de impact die nieuw beleid kan hebben op de manier waarop mensen in uw organisatie Power Platform gebruiken. Dit is het beste moment om een omgevingsstrategie op ondernemingsniveau te implementeren die is afgestemd op productfuncties en best practices.
Verken de belangrijkste omgevingsfuncties en -strategieën die in dit artikel worden beschreven. Neem de tijd om inzicht te krijgen in de belangrijkste thema's en de overwegingen en beslissingen die u nodig hebt om een strategie voor een tenantomgeving te ontwerpen en implementeren die het beste bij uw vereisten past.
Nu een solide basis leggen is essentieel om te voorkomen dat u in een uit de hand gelopen situatie terechtkomt die later kan ontstaan als u begint zonder een bepaalde strategie. Maak plannen voor een snelle versnelling van uw gebruik van Power Platform, maar vermijd de verleiding om uw omgevingsstrategie te uitgebreid te maken door deze ingewikkelder te maken dan nodig is. Vergeet niet dat dit een reis is en dat u uw strategie kunt blijven ontwikkelen naarmate uw behoeften veranderen.
Align
Uw organisatie heeft en voert een omgevingsstrategie uit die moet worden aangepast om deze af te stemmen op de nieuwe Power Platform-functies en best practices. Dit wordt vaak een brownfield genoemd. In tegenstelling tot organisaties die net zijn begonnen, moet u rekening houden met de impact op uw organisatie als u uw omgevingsstrategie wijzigt.
Verken de belangrijkste omgevingsfuncties en -strategieën die in dit artikel worden beschreven en beoordeel wat er nodig is om uw strategie beter af te stemmen. Meestal zijn alleen incrementele aanpassingen nodig. Plan indien mogelijk de implementatie van wijzigingen om de impact op uw gebruikers te minimaliseren.
De volgende suggesties zijn veelvoorkomende incrementele wijzigingen die u kunt implementeren:
Om uw afstemming te starten zonder bestaande omgevingen te beïnvloeden, maakt u een omgevingsgroep die nieuwe ontwikkelaarsomgevingen bevat en stelt u regels op voor de manier waarop u deze wilt beheren. Schakel omgevingsroutering in om ervoor te zorgen dat alle nieuwe ontwikkelaarsomgevingen in de aangewezen groep worden gemaakt.
Evalueer uw groeperingsstrategie en creëer, indien nodig, groepen om uw bestaande omgevingen te ondersteunen. Stel regels op voor die groepen die aansluiten bij bestaande beperkingen en uitzonderingen. Verplaats bestaande omgevingen naar die groepen.
Identificeer algemeen populaire toepassingen die zijn gebouwd en worden gebruikt in de standaardomgeving. Gebruik pipelines om ze te publiceren naar een productieomgeving waar gebruikers in uw organisatie ze kunnen uitvoeren. Werk vervolgens aan het migreren van de ontwikkeling van die apps naar een individuele ontwikkelaarsomgeving of een speciale ontwikkelomgeving.
Maak een plan om activa in de standaardomgeving die niet worden gebruikt te identificeren, in quarantaine te plaatsen en te verwijderen.
Verbeteren
De omgevingsstrategie die u uitvoert is al in lijn met de nieuwste functies en best practices, maar uw organisatie wil meer besturingselementen of functies toevoegen.
Communiceer de omgevingsstrategie naar uw organisatie
De implementatie van de strategie voor uw tenantomgeving verloopt beter als uw Power Platform-gebruikers begrijpen wat u probeert te realiseren en erachter staan. Als u uw strategie simpelweg zonder enige communicatie inzet, zien gebruikers de wijzigingen als beperkingen en zoeken ze naar manieren om deze te omzeilen.
Als onderdeel van het ontwikkelen of doorontwikkelen van uw strategie, beslist u hoe u gebruikers informeert over de belangrijkste elementen van de strategie die van invloed zijn op hun gebruik van Power Platform. Ze hoeven niet alle technische details van uw strategie te kennen, enkel de essentiële zaken die ervoor zorgen dat ze productief blijven, zoals:
Het doel van de standaardomgeving
Waar ze nieuwe activa met weinig code moeten bouwen
Hoe ze hun persoonlijke ontwikkelaarsomgeving moeten gebruiken
Hoe ze aangepaste omgevingen kunnen aanvragen voor specifieke Business Units of projecten
Algemeen beleid voor connectorgebruik en hoe ze meer connectorbevoegdheden kunt aanvragen voor hun omgevingen
Hoe ze wat ze bouwen met anderen kunnen delen
De verantwoordelijkheden van een maker, bijvoorbeeld:
Houd de tenant schoon. Verwijder omgevingen, apps en stromen als ze niet meer nodig zijn. Gebruik testomgevingen als u experimenteert.
Deel verstandig. Pas op voor het te veel delen van uw omgevingen, apps, stromen en gedeelde verbindingen.
Bescherm organisatiegegevens. Vermijd het verplaatsen van zeer vertrouwelijke of vertrouwelijke gegevensbronnen nooit naar niet-beveiligde of externe opslag.
Deel wanneer uw strategie verandert welke invloed de veranderingen hebben voor uw gebruikers, zodat ze weten wat ze anders moeten doen
Begin goed door de welkomstinhoud voor makers in te schakelen in de omgevingsgroep waar nieuwe makers worden toegevoegd.
Afbeelding: Gebruik de welkomstinhoud om nieuwe makers te helpen succesvol te zijn.
Een andere effectieve manier om met uw gebruikers te communiceren, is het opzetten van een interne Power Platform-hub. De hub kan een plek zijn waar mensen kunnen samenwerken aan projecten, ideeën kunnen delen en nieuwe manieren kunnen ontdekken om technologie toe te passen om meer te bereiken. De hub kan de plek zijn waar u meer gedetailleerde informatie deelt over uw omgevingsstrategie die relevant is voor uw gebruikers. Leer hoe u een interne Power Platform hub maakt.
Conclusie
In dit artikel hebben we functies bekeken die zijn ontworpen om uw organisatie te helpen Power Platform-omgevingen op ondernemingsschaal te beheren en deze op te nemen in de strategie voor uw tenantomgeving.
Naarmate uw organisatie de invoering van Power Platform en het gebruik ervan versnelt, kan de behoefte aan omgevingen snel veranderen. U hebt een flexibele aanpak nodig die ervoor zorgt dat uw omgevingsstrategie gelijke tred houdt met veranderingen en blijft voldoen aan de evoluerende governancevereisten van uw organisatie.
Een belangrijke succesfactor voor een tenantomgeving is communicatie met uw makers en gebruikers om draagvlak te creëren. Zorg ervoor dat de mensen die toepassingen met weinig code en automatiseringen bouwen, weten hoe ze de omgevingsstrategie van uw organisatie moeten volgen en waar ze hun activa met weinig code moeten bouwen.
Het traject dat elke organisatie volgt om Power Platform in te voeren is uniek. We hebben u enkele ideeën aangereikt om te zorgen dat u een vliegende start kunt maken. Uw Microsoft accountteam of Power Platform partner kan u helpen een meer op maat gemaakte tenant omgeving-strategie voor uw organisatie te creëren.