Programmodernisering med Power Platform

I dagens hurtigt udviklende digitale landskab står organisationer over for den konstante udfordring at modernisere deres ældre applikationer for at holde trit med skiftende forretningsbehov. Applikationsmodernisering er afgørende for at forbedre driftseffektiviteten, forbedre kundeoplevelsen og holde sig foran konkurrenterne. Microsoft Power Platform indeholder en omfattende pakke af værktøjer og teknologier, der giver virksomheder mulighed for at transformere og modernisere deres applikationer hurtigt og effektivt.

I dette whitepaper gennemgås fordelene, strategierne og den bedste praksis ved at moderne programmer med Microsoft Power Platform. Den giver indsigt i og vejledning i, hvordan Microsoft-platformen med lav kode kan hjælpe dig med at sikre, at dine programmer moderniseres som en del af din organisations digitale transformation.

Tip

Du kan gemme eller udskrive denne whitepaper ved at vælge Udskriv i din browser og derefter vælge Gem som PDF.

Introduktion

Legacy-programmer giver mange udfordringer for organisationer. Disse applikationer er ofte bygget på forældede teknologistakke og rammer, hvilket gør dem vanskelige at integrere med moderne systemer og værktøjer. De har ofte begrænsninger for skalerbarhed og ydeevne, der hindrer en organisations evne til at håndtere stigende arbejdsbelastninger og kundekrav. Ældre programmer mangler fleksibilitet og agilitet, hvilket begrænser deres evne til hurtigt at tilpasse sig skiftende forretningsbehov og markedsdynamik. Sikkerhedssårbarheder, høje vedligeholdelsesomkostninger, begrænsede integrationsmuligheder og risikoen for leverandørafhængighed forværrer yderligere udfordringerne ved ældre programmer. For at overvinde dem skal organisationer modernisere deres applikationsinfrastruktur for at drage fordel af nye teknologier.

Funktionerne til udvikling af lave koder i Microsoft Power Platform gør det muligt at oprette og installere moderne programmer hurtigere og mere omkostningseffektivt end nogensinde før. Integrer nemt dine eksisterende systemer og datakilder for problemfri dataudveksling og samarbejde. Tilføj kunstig intelligens for at forbedre brugeroplevelsen, automatisere processer og få værdifuld indsigt fra dine data. Uanset om du er en borgerudvikler, der roder rundt i kanterne, eller en professionel udvikler, der arbejder på en kompleks tilpasning, kan du drive digital transformation intuitivt, hurtigt og til lavere omkostninger end med traditionelle tilgange.

Hvorfor Power Platform?

De omfattende værktøjer og teknologier, der udgør Power Platform dramatisk, sænker længden, omkostningerne og udviklingskravene til moderniserings- og digitale transformationsprojekter. Dens fremgangsmåde med lav kode reducerer – og kan endda eliminere – behovet for dyr kodning, datavidenskab og AI-tekniske ressourcer. Det gavner både selvlærte udviklere og professionelle udviklere. Selvlærte udviklere kan tage en aktiv rolle i moderniseringsprocessen, bygge programmer direkte baseret på deres domæneekspertise og reducere deres afhængighed af it-teams. Professionelle udviklere kan levere selv komplekse løsninger på langt kortere tid, hvilket frigør dem til at gå videre til det næste projekt hurtigere.

Power Platform-produkter og tjenester

Hvert produkt i Power Platform familien har et unikt fokusområde. Organisationer kan implementere produkterne individuelt eller i kombination for at opfylde deres specifikke krav. Produkterne er indbyrdes forbundne og danner en sømløs helhed, uanset hvordan de kombineres.

Følgende tabel indeholder en overordnet oversigt over hvert Power Platform produkt.

Product	Description
Power Apps	Opret brugerdefinerede programmer på et intuitivt lærred med træk og slip. Med mere end tusind connectorer er interne og eksterne datakilder og tjenester kun nogle få klik væk. Dine apps kan køre i en browser, på skrivebordet eller på mobilenheder.
Power Automate	Opbyg arbejdsprocesser for at automatisere selv komplekse processer. Inkorporer interne og eksterne datakilder og tjenester ved hjælp af indbyggede og brugerdefinerede connectorer. Brug digital procesautomatisering (DPA), når programmer har en API (Application Programming Interface). Brug procesautomatisering med robotteknologi (RPA) til at automatisere gentagne opgaver, der udføres i en browser eller skrivebordsapp. Udløser arbejdsprocesser til at køre, når der indtræffer hændelser i andre systemer og tjenester, eller de planlægges til at køre på et bestemt tidspunkt.
Copilot Studio	Oprettelse af samtaleagenter ved at bruge en kodefri grafisk grænseflade. Du kan udrulle agenter på flere kanaler, herunder websteder, mobilapps og meddelelsesplatforme som f.eks. Microsoft Teams. AI-assisteret oprettelse kan gøre oprettelsen af emner hurtigere. Generative svar kan finde og præsentere oplysninger fra flere kilder uden at kræve oprettelse af emner.
Power BI	Træk diagrammer, tabeller og andre visuelle elementer til et lærred for nemt at oprette avancerede rapporter, der afslører indsigt, der er låst inde i dine data. Inkluder automatiseret maskinel indlæring til prædiktiv modellering og AI-visualiseringer med opdelingstræer til detaljerede detailudledninger i forbindelse med analyse af rodårsag. Udforsk dine data ved at stille spørgsmål på naturlige sprog i et enkelt Q&A-format.
Power Pages	Opbyg hurtigt attraktive, datadrevne websteder på en sikker low-code-SaaS-platform i virksomhedsklassen (Software as a Service). Med omfattende, tilpasselige skabeloner og en flydende visuel oplevelse er det nemmere at oprette, hoste og administrere moderne eksterne forretningswebsteder.

Produktfamilien Power Platform er afhængig af nogle få understøttende funktioner og koncepter. Følgende tabel beskriver de vigtigste, der skal forstås.

Begreb	Description
Power Fx	Power Fx er et open source-sprog med lav kode, der er inspireret af Excel-formler. Typesikkert, beskrivende og funktionelt, med bydende logik og tilstandsstyring, alt sammen udtrykt i menneskevenlig tekst, Power Fx gør almindelige programmeringsopgaver nemme for både selvlærte udviklere og professionelle udviklere. Det understøtter det fulde spektrum af udvikling fra ingen kode for dem, der aldrig har programmeret før, til "professionel kode" for den rutinerede professionelle, der tilpasser forskellige teams, så de kan samarbejde og spare tid og udgifter.
Connectorer	Connectorer er vigtige for, at lav kode og traditionel kodning kan arbejde sammen og levere moderne apps. Connectorer er en indpakning omkring et API, der tillader Power Apps og Power Automate at bruge interne og eksterne datakilder og tjenester. Mere end tusind forudbyggede connectorer er tilgængelige, og du kan oprette dine egne til enhver RESTful API. Connectordefinitionen indeholder de metadata, der er nødvendige for at gøre API'en nem for apps med lav kode at forbruge.
Dataverse	Dataverse er et hybriddatalager i skyskala, der er bygget på Azure Datastyring tjenester – men det er mere end en database. Det er den underliggende dataplatform for både Dynamics 365 og Power Platform med logik på serversiden i form af arbejdsprocesser og plug-ins, forretningsregler og procesforløb, en meget avanceret sikkerhedsmodel og en udvidelig udviklingsplatform med indbygget understøttelse af apps på flere sprog og flere valutaer. Programmer kan hurtigt konstrueres ud fra datamodellen, hvilket gør det til en af de hurtigste måder at implementere en form-over-data-løsning på.
AI Builder	AI Builder gør det nemt at bruge kunstig intelligens i Power Apps og Power Automate at finde indsigt i dine data, automatisere processer og gøre dine apps mere produktive. Med AI Builder behøver du ikke kodnings- eller datafærdigheder for at få adgang til AI-funktionalitet. Færdigbyggede modeller, der kan tilpasses, er nøglefærdige til mange almindelige forretningsscenarier, og du kan bygge dine egne modeller for at opfylde et bestemt forretningsbehov.
Copilot	Copilot AI-assistance gør Power Platform brugere og udviklere, borgere eller professionelle, mere produktive, så de kan bruge mere tid på de bedste dele af deres job og mindre tid på trivielle opgaver. Beskriv dit forretningsscenarie til Copilot i Power Automate, og det kan gøre din beskrivelse til en automatiseret arbejdsgang. Fortæl Copilot i Power Apps, hvad du vil gøre, eller hvilke oplysninger du vil se, og den kan oprette en app til det. Copilot konfigurerer forbindelser, opretter og udfylder tabeller, genererer skærmbilleder og kommer endda med forslag til, hvordan du kan gøre dit flow eller din app bedre. Dine apps får copilot-drevne oplevelser indbygget fra det første skærmbillede – så dine brugere kan få indsigt gennem samtale.
Miljøer og løsninger	Miljøer er grænser, der indeholder og gør det nemmere at administrere og sikre Power Platform ressourcer. De bruges også i ALM (Application Lifecycle Management), hvor løsninger udvikles og testes i separate miljøer, før de installeres i et produktionsmiljø. Løsninger er pakketilpasninger af Power Platform og udvidelser. En løsning kan omfatte apps, flows, tabeller, diagrammer, dashboards, connectorer og andre komponenter, som tilpasningen eller udvidelsen har brug for. Løsninger kan udvikles, testes og udrulles til produktion i separate miljøer som en del af en organisations ALM-politik. Du kan eksportere løsninger for at dele dem med andre brugere eller organisationer og importere løsninger fra andre. Løsninger er enten administreret eller ikke-administreret. Ikke-administrerede løsninger bruges til udvikling og test. Administrerede løsninger bruges til produktion, udrulning og distribution.

De vigtigste fordele ved Power Platform til appmodernisering

Fordelene ved at modernisere programmer ved hjælp af Microsoft Power Platform strækker sig ud over den oprindelige forretningsværdi ved at have en løsning, der bruger moderne teknologier.

• Lavere omkostninger. Organisationer kan spare penge på appudvikling og vedligeholdelse. En bestilt undersøgelse foretaget af Forrester Consulting viste, at organisationer, der bruger Power Platform, kan se et fald på 45 procent i applikationsudviklingsomkostninger og realisere et afkast på 140 % af deres investering.

• Udvid ressourcepuljen, og fjern flaskehalse. Professionelle udviklere, dataforskere og AI-ingeniører er højt betalte – og meget efterspurgte. Små og mellemstore organisationer har ofte ikke den luksus at have intern kodningsekspertise, og outsourcing er dyrt. Low-code Power Platform er mere tilgængelig af en større pulje af ressourcer. Fageksperter og medarbejdere med ekspertise inden for forretningsprocesser kan hjælpe med at fremskynde moderniseringsindsatsen, selvom de aldrig har skrevet en kodelinje.

• Byg vognen, ikke hjulet. Traditionel softwareudvikling starter på en frisk hver gang og genopfinder hjulet med hvert nyt projekt. Med intuitive, producentvenlige Power Platform produkter med lav kode som hjul kan du fokusere på at bygge en bedre indkøbskurv – forbedre dine forretningsprocesser – og hurtigere nyde fordelene ved din moderniseringsindsats.

• Reducer teknisk gæld. Omkostningerne - både økonomisk og i tabte muligheder - ved at opgradere "hurtige og beskidte" softwareløsninger og vedligeholde ældre infrastruktur er høje. Power Platform reducerer denne tekniske gæld ved at gøre det nemmere og billigere at bygge løsninger rigtigt første gang, forenkle dataintegration og styring med en fælles datamodel og connectorer, levere en centraliseret platform til administration af løsninger og understøtte løbende forbedringer med analyser og AI.

• Forbedringer af sikkerhed og overholdelse af angivne standarder Alle Power Platform-produkter inkluderer fuldt integreret sikkerhed i virksomhedsklassen, overholdelse af angivne standarder og styring som standard, startende med de miljøer, de kører i. Administrerede miljøer er en værktøjspakke, der gør det muligt for administratorer at administrere Power Platform i stor skala med mere kontrol og mindre indsats. Du kan blandt andet begrænse, hvem der kan dele hvilke flow og apps og med hvem, og bruge politikker til at begrænse de connectorer, udviklere kan bruge. Oprindelige, fleksible datasikkerhedsmodeller betyder, at hvert program ikke behøver at bygge sit eget.

• Modernisere efter forbrug. Jo vigtigere apps er, at du vil modernisere, jo mindre sandsynligt er det, at du vil erstatte dem alle på én gang. En fremgangsmåde med lav kode egner sig godt til at bygge løsninger i overskuelige trin.

• Integrer ældre apps. Ældre programmer har ofte ikke API'er. Power Platforms RPA-funktioner kan automatisere klassiske apps og inkludere dem i dine nye moderne forretningsprocesser. RPA kan også være nyttigt til trinvis modernisering af store og komplekse apps.

• Skab innovation uden at bruge flere penge. Power Platform-funktionerne bliver stadig bedre. Apps, der er bygget på platformen, drager fordel af Microsoft innovationer uden flere omkostninger for dig.

• Øg medarbejdernes produktivitet på en moderne arbejdsplads. Power Platform er en del af den moderne Microsoft-arbejdsplads. Programmer, der er moderniseret på platformen, kan drage fordel af Microsoft 365-mulighederne, herunder engagerende mobiloplevelser og let, intuitivt samarbejde. Banebrydende AI som Copilot, AI Builder og funktioner, der snart vil blive annonceret, gør brugere og udviklere mere produktive med mindre frustration og lavere indlæringskurver.

Innovations til frontlinjemedarbejderen

Frontlinjemedarbejdere har brug for moderne programmer, de kan bruge på enhver enhed, uanset hvor de arbejder. De har brug for adgang til indsigt i realtid for at kunne træffe bedre beslutninger hurtigere. De er nødt til at samarbejde med kolleger og ledelse for at holde alt fungere problemfrit. Da American Airlines besluttede at modernisere aspekter af sine operationer, fik de alt det og mere.

I samarbejde med Microsoft skabte American Airlines ConnectMe, en Microsoft Teams-app bygget på Power Apps og Azure. Ved hjælp af appen på enhver mobilenhed har frontlinjeteams vigtige ankomst-, boarding-, bagage- og gateoplysninger lige ved hånden i realtid, hvilket strømliner operationer på jorden, fremskynder flyets vendetider og gør rejsen til en mere behagelig oplevelse for kunderne. Få mere at vide om flyselskabets transformation.

AI-styrkelse for vidensarbejdere

Vidensarbejdere svømmer i et hav af data – og alt for ofte føler de, at de er ved at drukne. Næsten alle applikationer indsamler data. Få af dem hjælper brugerne med at forstå de data, de indsamler, endsige fremhæve indsigt, der kan hjælpe medarbejderne med at udføre deres job bedre. AI-funktioner kan føjes til apps som en del af moderniseringen, ikke kun automatisering af dataindsamling og -analyse, men også gør det lettere for vidensarbejderne at spotte mønstre og tendenser. Prædiktiv analyse kan bruge AI-modeller til at forudsige fremtidige resultater baseret på historiske data med høj nøjagtighed, så ledere kan planlægge med tillid. Moderniserede apps kan omfatte copilot AI, der fungerer som en partner til at generere indhold i kontekst - opsummere interviews, udarbejde målrettede marketing- og salgsmeddelelser og endda tilbyde nyttige oplysninger i realtid, mens en kundeservicemedarbejder eller sælger taler i telefon med en kunde.

En trinvis rejse til modernisering af ældre apps

Hvis din organisation er som de fleste, har du en voksende pukkel af forældede applikationer, der ville drage fordel af modernisering. Ældre programmer bruger typisk forældet teknologi og er bygget på infrastruktur – hardware og software – der ikke længere understøttes. Ofte er det kun få medarbejdere, som regel dem, der nærmer sig pensionsalderen, der ved, hvordan de arbejder. Nye medarbejdere vil ikke have noget med dem at gøre, fordi de ikke kan bruge de moderne værktøjer, de er vant til eller ønsker at arbejde med. Vedligeholdelse af dem, endsige opdatering af dem, kræver skalering af et bjerg af teknisk gæld, der vokser højere, jo mere du klatrer. År, måske årtier, med patchwork-vedligeholdelse resulterer i en kodebase, som ingen tør røre ved - især når store dele af virksomheden er afhængig af den.

Organisationer kan ofte ikke nemt erstatte disse programmer på én gang. I stedet begiver de sig ud på en trinvis moderniseringsrejse. En trinvis tilgang maksimerer fordelene ved modernisering, samtidig med at den mindsker nogle af risiciene ved en engangsmoderniseringsindsats.

Indstillinger for modernisering af apps

Modernisering betyder ikke altid, at en ældre app skal genopbygges fra bunden. Andre muligheder er at trække det tilbage, erstatte det, genhoste det, omstrukturere det og genarkitektere det.

I følgende tabel beskrives hver indstilling, ALM-fasen, når det er mest hensigtsmæssigt, og drivere, der kan påvirke valget af indstillingen.

Sluttidspunkt

Overførsel

-modernisering

Lad udgå

Replace

Rehost

Omstrukturer

Omdefiner

Genopbyg

Beskrivelse

Remove-app

Erstat app med SaaS eller en anden app

Udrul igen, som det er, i cloudmiljøet

Optimer eksisterende kode

Skift kode til en ny programarkitektur, eller bryd den op i mikrotjenester

Omskriv appen fra bunden med originalt omfang og specifikationer

-drivere

Ikke længere nødvendigt

Reducer udgifterne

Reducer kapitaludgifter

Udnyt nyere teknologier

Reducer kapitaludgifter

Gendan datalager

Hurtig ROI i skyen

Hurtigere og kortere opdateringer

Mere bærbar kode

Større cloudeffektivitet i ressourcer, hastighed og omkostninger

Forbedre ydeevnen

Reducer teknisk gæld

Forbedre skalerbarhed, pålidelighed og vedligeholdelse

Gøre det nemmere at indføre nye cloudfunktioner

Bland teknologistakke

Accelerer innovation

Sæt fart på udviklingen

Reducer driftsudgifter

Microsoft-teknologi

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

Objektbeholdere

Azure PaaS

Power Platform

Azure PaaS

Serveruafhængige mikrotjenester

Power Platform

Azure PaaS

Serveruafhængige mikrotjenester

I følgende tabel foreslås måder, hvorpå der kan anvendes en fremgangsmåde med lav kode for hver af indstillingerne for appmodernisering.

Mulighed	Description
Rehost	Gen-hostning flytter en app, som den er, fra et ældre miljø til et nyere. En fremgangsmåde med lav kode gælder ikke direkte, men genhosting kan være det første trin, før der anvendes andre strategier, som omfatter løsninger med lav kode.
Refaktorisering eller omstrukturering	Refactoring justerer koden, så apps kan få mest muligt ud af et cloud-first-miljø. Rearchitecting ændrer koden betydeligt. Det kan omfatte indkapsling af eksisterende logik ved at flytte den til en API, der kan vises for low-code løsninger via en connector.
Udskift eller genopbyg	Når du udskifter, byttes en app med en anden. Genopbygning genskaber en app fra bunden. Denne indstilling er normalt der, hvor en fremgangsmåde med lav kode giver de bedste forretningsresultater. Starte med et program fra Dynamics 365 eller Microsoft AppSource kan hjælpe med at komme hurtigt i gang med modernisering, når use case matcher en foruddefineret funktion. Organisationer kan derefter bruge Power Platform komponenter til at tilpasse appen til deres unikke behov.

Power Platform har en fremgangsmåde med lav kode potentiale til at tilbyde meget mere end blot endnu et udviklingsværktøj. Hvis du gør lav kode til en del af din moderne appstrategi, kan det også skabe et fundament for at give ikke-udviklere, f.eks. fageksperter, mulighed for at deltage i din moderniseringsindsats. Organisationer har fundet ud af, at oprettelse af et Center of Excellence (CoE) omkring Power Platform og brug af værktøjer som CoE-startpakken til at oprette retningslinjer og styring hjælper brugerne med at opbygge apps og automatiseringer med lav kode med succes og sikrer, at aktiver som API'er og komponenter kan genbruges. Lav kode kan fremskynde programudvikling og hjælpe organisationer med at udtrække værdi fra deres data hurtigere, uanset hvor de er placeret. Faktisk beslutter mange organisationer at integrere en low-code-tankegang i deres kultur.

En guide til din moderniseringsrejse

Det er nemt at blive overvældet, når du begynder at tænke på at modernisere ældre apps. En guide kan hjælpe dig med at planlægge din rejse og holde dig på den rigtige vej undervejs. Et godt sted at starte er med disse tre trin, hvor man overvejer hvert trin med en low-code tankegang.

1. Planlægning. Tænk nøje over dine mål for modernisering af et ældre program, og definer din strategi for at nå dem. Hav en klar erklæring om det problem, du vil have modernisering til at løse. Det er nu, du skal vurdere dine apps og miljøer med henblik på, hvad der ikke fungerer, hvad der fungerer, men som kan forbedres, og – vigtigst af alt – hvilken værdi eventuelle ændringer resulterer for virksomheden eller brugerne. Evaluer hver enkelt moderniseringsmulighed for dens potentiale til at drage fordel af en fremgangsmåde med lav kode. Prioriter muligheder, der inkorporerer løsninger med lav kode. Brug Cloud Adoption Strategy Evaluator til at opbygge en business case til app modernisering.

2. Implementering. Moderniser dine apps ikke kun trinvist, men også iterativt. En iterativ tilgang giver organisationer fleksibilitet til at ændre deres projektomfang eller strategi efter behov. Power Platform-løsninger med lav kode kan udvikles og testes hurtigere end traditionelt udviklede apps, og udrulning i administrerede miljøer kræver blot nogle få trin. Selvom lav kode kræver mindre opkvalificering end traditionel kodning, skal du sørge for, at dine medarbejdere er tilstrækkeligt uddannet i, hvordan de arbejder som fusionsteams, der blander lav kode og traditionelle ressourcer.

3. Drift. Appmodernisering stopper ikke ved implementeringen. Med en cloudplatform-tilgang med lav kode og cloud-først kan du bruge cloudplatformstjenester og -værktøjer til at sikre, styre, administrere og optimere dine apps.

Evaluer muligheder for løsninger med lav kode

Organisationer bruger forskellige metoder, lige fra uformel gennemgang til detaljerede beslutningstræer, til at afgøre, om en fremgangsmåde med lav kode er den rigtige måde at modernisere en ældre app på. Det vigtigste at overveje er, at lav kode ikke er en alt-eller-intet-beslutning. Det er almindeligt at bygge en del af en applikation ud af Power Platform komponenter og en del af den ud af komponenter, der er udviklet ved hjælp af traditionelle kodningsteknikker.

Hvis du vil evaluere en applikation, anbefaler vi, at du først finder ud af, om den stadig er nødvendig og nyttig, eller om den skal trækkes tilbage. Hvis du beslutter, at det stadig er nødvendigt, skal du vurdere, om en løsning med lav kode kan erstatte appen som helhed. Hvis hele appen ikke egner sig godt til en erstatning med lav kode, skal du vurdere, om en eller flere af appens arbejdsbelastninger eller komponenter kan være det. Du kan opleve, at en løsning med lav kode, der udvides med traditionelt udviklet kode, giver det bedste fra begge verdener.

Hvis du f.eks. finder ud af, at et program ikke passer godt, fordi Power Apps mangler et påkrævet kontrolelement, kan du bruge Power Apps component framework (PCF) og traditionel kode til at oprette et brugerdefineret kontrolelement. Et andet eksempel er en app med kompleks logik. Du kan centralisere logikken i en API, hvor Power Apps kan få adgang til ved hjælp af en brugerdefineret connector. I begge disse eksempler gjorde Power Platform udvidelsesmulighederne det muligt at bygge det meste af appen med komponenter med lav kode, hvilket gjorde det muligt at bygge bro over hullerne med traditionelt udviklet kode.

NSure.com, en proprietær online forsikringsshoppingplatform, tilbyder et eksempel fra den virkelige verden. Virksomhedens oprindelige lancering var afhængig af traditionelt udviklede Angular-, Xamarin- og Azure-tjenester. Ved at tilføje Power Platform og Dynamics 365, skabte NSure.com en næste generations løsning ved hjælp af både lav kode og traditionelle kodningsteknikker, som følgende diagram illustrerer. Få mere at vide om firmaets transformation.

Det er lige så vigtigt som at identificere muligheder med lav kode at erkende, når en fremgangsmåde med lav kode ikke er den rigtige. I følgende tabeller beskrives de use cases, der normalt ikke egner sig godt til løsninger med lav kode. Organisationer står over for forskellige udfordringer i frontend og backend, så lad os overveje dem separat.

Front-end-scenarier, der ikke passer til en fremgangsmåde med lav kode

Scenarie	Udfordring
Brugerenheden er ikke kompatibel	Power Platform genkender mobile enheder og specialiserede enheder som stregkodescannere. Enheder, der er afhængige af specifikke API'er eller drivere, understøttes muligvis ikke og kræver en mere traditionel tilgang.
Stor mængde data på klientsiden	Brugeroplevelsen i nogle applikationer kræver store mængder data, en udfordring for enhver teknologi, ikke kun lav kode. Download og behandling af så mange data kan stresse backend-systemer og forringe ydeevnen for både appen og den enhed, den kører på. Brugere er ikke så produktive, når de er tvunget til at navigere i et hav af data. Før du vender dig til traditionelle kodningsmetoder til håndtering af belastningen, skal du undersøge, om korrekt filtrering og navigation kan give en bedre brugeroplevelse.
Komplekse offlinekrav	Programmer, der skal fungere på steder, hvor forbindelsen er dårlig eller ikke-eksisterende, kan være en udfordring at implementere og understøtte, uanset om de bruger kode med lidt eller traditionel kode. Power Apps tilbyder grundlæggende funktioner til enkle offlinescenarier. En app, der registrerer kundeemner under et arrangement og overfører dem til en marketingdatabase efter arrangementet, fungerer f.eks. fint. I forbindelse med programmer, der kræver filer og billeder, ikke-Dataverse-connectorer eller kompleks konfliktløsning, bør du anvende traditionelle kodeteknikker.

Back-end-scenarier, der ikke passer til en fremgangsmåde med lav kode

Scenarie	Udfordring
Data med høj hastighed	Import af millioner af rækker med data som en del af overførsler og lignende hændelser understøttes som regel. Arbejdsbelastninger, der omfatter behandling af millioner af rækker data hver time eller dagligt, bør være underlagt yderligere evaluering. Det ville f.eks. ikke give mening at indsamle store mængder IoT-telemetri (Internet of Things) i Dataverse. I stedet kan Azure cloud-tjenester bruges til at indsamle og analysere data og relevante signaler, der kan tilføjes til Dataverse for at udløse handlinger i applikationen. Programmer, der involverer en stor mængde opdateringer til Dataverse-data regelmæssigt, kan kræve hjælp fra traditionel kode for at skalere opdateringerne.
Baggrundsarbejdsbelastninger med kompleks logik	Arbejdsbelastninger i baggrunden, der involverer kompleks logik eller en stor mængde API-kald, er muligvis ikke de rigtige til en løsning med lav kode. Logikken kan i stedet centraliseres i en API, som en løsning med lav kode kan kalde.
API'er, der bruger ikke-RESTful-protokoller	Power Platform Connectorer understøtter kun REST API'er. Hvis du har brug for at oprette forbindelse til en anden stil-API, f.eks. SOAP eller gRPC, skal du angive din egen REST API, der kommunikerer med den, der er inkompatibel.

Vi anbefaler, at du holder dig ajour med Power Platform udgivelsesbølger, da de bliver ved med at lukke huller i, hvad du kan gøre med løsninger med lav kode. Hvis du opretter et proof-of-concept med lav kode, kan du finde ud af, om dit scenarie passer godt.

Prioriter lavkode-salgsmuligheder

Når du evaluerer din programportefølje, er det ikke nok at identificere gode kandidater til transformation med lav kode. Dit team skal prioritere dem for at maksimere succesen af din moderniseringsindsats.

Prioritering bør overveje følgende faktorer:

• Din organisations modenhed med lav-kode
• Kompleksiteten af mulighederne
• ROI for organisationen, brugerne og it-afdelingen
• Hurtigere værdinytte

Hvis du er realistisk omkring organisationens muligheder med lav-kode, kan det hjælpe dig med at vælge en mulighed, der udfordrer dit team til at vokse, men som ikke overvælder dem til at mislykkes. Du behøver ikke vælge den mest ligetil applikation uden udfordringer. En ideel løsning ville give nogle muligheder for at undersøge, hvordan man kombinerer traditionel kode med løsninger med lav kode.

Applikationer med kompleks integration med andre systemer er ofte ikke det bedste sted at starte. Forsøg på at tackle applikationer, der er for store eller for komplekse, kan føre til frustration og fiasko. Undgå dem, der er tvivlsomme lav-kode kandidater. Gem dem, til dit team har gennemført et par vellykkede moderniseringer.

Når du moderniserer en stor, monolitisk app, skal du overveje, om du kan modernisere små dele af den trinvist. Monolitiske applikationer plejede at være almindelige. Nu er mindre rolle- eller opgavefokuserede apps mere almindelige. De giver mulighed for trinvis udvikling og forbedringer og skalering af de teams, der bygger dem.

De første par moderniseringer er vigtige, fordi de giver organisationen mulighed for at se effekten af løsninger med lav kode. Det er vigtigt at evaluere fordele og risici for en apps interessenter, når du prioriterer muligheder. At vælge et program, som ingen interesserer sig for, eller som har en lav indvirkning på organisationen, vil ikke være den bedste demonstration af fordelene ved en løsning med lav kode.

Brugernes accept af den moderniserede applikation er vigtig. Brugere skal føle, at deres nye low-code-applikation passer sammen med resten af de applikationer, de bruger. En anden risiko ved adoption er graden af tilpasning, de er vant til. Hvis de forventer en meget skræddersyet oplevelse, er de måske mindre tilbøjelige til at anvende en løsning med lav kode, der føles mindre personlig.

Organiser og opkvalificer dine teams

Organisationer, der har succes med at modernisere deres ældre apps, tildeler ikke blot et moderniseringsprojekt til et team af traditionelle kodeudviklere og håber, at de lykkes. Det er vigtigt at give dit team den viden og tillid til udvikling med lav kode, der er nødvendig for at fuldføre en moderniseringsindsats.

Et team af ressourcer med lav kode, der arbejder side om side med traditionelle koderessourcer, kaldes et fusionsteam. Fusionsteams er designet til at tilskynde til samarbejde ved at træne begge typer ressourcer i at integrere løsninger med lav kode med traditionel kode. En løsningsarkitekt fastlægger, hvordan løsningen er opbygget mellem lav kode og traditionel kode.

Selvom det er nemt som standard at tildele alt arbejdet til traditionelle udviklere, er moderniseringstiltag med lav kode en god mulighed for at udvide projektteamet. Mange forretningsbrugere er fremragende ressourcer inden for lav kode. De kan fremskynde teamets arbejde, fordi de allerede forstår forretningsproblemet. De skal bare lære, hvordan de udfører de typer arbejde med lav kode, som teamet påtager sig, og være fortrolige med test- og ALM-procedurer. Det kan betyde, at du skal lære at bygge apps i Power Apps eller arbejdsprocesser i Power Automate. De bør også forstå, hvad traditionelle programmører kan udvikle for at gøre deres indsats med lav kode lettere. Dette betyder ikke, at de skal vide, hvordan man skriver traditionel kode.

Traditionelle koderessourcer skal have et grundlæggende kendskab til fremgangsmåder med lav kode, og hvordan disse adskiller sig fra den kode, de typisk skriver. Det vigtigste er, at de skal lære udvidelsesmulighederne for løsninger med lav kode. De skal være trygge ved at oprette en testapp eller et testflow, der bruger kode, de skriver, for at sikre, at den fungerer, og for at være klar til at understøtte ressourcer med lav kode ved forbrug af deres udvidelsesaktiver.

Både ressourcer med lav kode og traditionelle koderessourcer skal forstå, hvor løsninger med lav kode og traditionelle kodeløsninger starter og slutter, og hvor de krydser hinanden.

Samle krav

Du kan opleve, at du har apps, der er et årti eller ældre og ikke er dokumenteret. De kan kræve reverse engineering eller forretningsbrugerkendskab for at genskabe. Det er vigtigt at huske, at selvom en fremgangsmåde med lav kode er effektiv, gør den ikke indsamling af krav og viden om forretningsprocesser hurtigere eller gør komplekse krav mindre komplekse. Der er ofte en urealistisk forventning om, at et team, der moderniserer en app, opnår lige så meget som et team, der bygger en ny app med low-code. Fastlæg din organisations forventninger med disse udfordringer i tankerne.

To fremgangsmåder kan hjælpe dig med at få hurtigere viden om en ældre app. Først skal du udvide teamet til at omfatte forretningsbrugere med domænekendskab. For det andet skal du fokusere på at forstå forretningsprocessen og dens ønskede resultat i stedet for at dokumentere, hvordan den implementeres i det ældre system. Undtagelsen herfra er, hvis det ældre program kræver specialiseret logik, der udfører forretningsregler, som du skal følge.

Undgå at arbejde med lav-kode-tilgange

Organisationer, der er nye til at modernisere programmer med lav-kode-løsninger, begår ofte den fejl at udvikle lav-kode på samme måde, som de udvikler traditionel kode. En organisation kan f.eks. anvende UX-standarder, der er skrevet til Angular-apps, til den første Power Apps implementering. Projektteamet ville bruge unødvendig tid på at forsøge at opfylde standarder, der var designet til Angular-rammefunktioner og ikke forretningsbehov.

Teams, der er vant til at arbejde med traditionel kode, kan forsøge at minimere low-code. I stedet for at bruge Power Apps kontrolelementer kan teamet f.eks. bygge et program ud fra Power Apps component framework-kontrolelementer for så vidt muligt at undgå at bruge low-code. Det er bedst for teams at komme så langt som muligt med low-code, indtil de rammer blokeringer, der ikke kan løses. Teams, der lærer at udnytte platformens muligheder, har større succes med at opnå de maksimale fordele ved lav kode. Lav kode fortsætter med at blive mere i stand til at påtage sig, hvad der tidligere kun var muligt med traditionel kode. En almindelig udfordring tidligere var at sidde fast, fordi lav kode ikke kunne replikere nogle nødvendige funktioner. Power Platform løser denne udfordring med udvidelsesmuligheder, der gør det muligt for programmer med lav kode at inkorporere specialiserede komponenter, der er skrevet i traditionel kode, når det er nødvendigt.

Tilgange med lav kode kan spille en vigtig rolle i dine moderniseringsstrategier. De bedste resultater kræver en klar redegørelse for det problem, moderniseringsindsatsen er beregnet til at løse, planlægning, bemanding, der når ud over standardroller, træning og prioritering. Hvis det er nødvendigt, hjælper det også organisationer med at realisere det fulde potentiale ved lav kode. Modernisering udført rigtigt bør forbedre den samlede forretningsværdi af de moderniserede applikationer.

Platforme med lav kode har udviklet sig hurtigt i de senere år. Mens de altid har været gode til at understøtte individuelle produktivitetsscenarier, har det seneste fokus været på virksomhedsfunktioner. Organisationer udvikler programmer med lav kode, der understøtter den moderne arbejdsplads, herunder hybridarbejde (fjernarbejde og onsite) og det medfølgende behov for måder at tilskynde til samarbejde på. Platforme med lav kode som f.eks. Power Platform kan nu skaleres til at håndtere programmer, som alle brugere i en organisation kan stole på, og som kan integreres i virksomhedens sikkerhedsmodeller. Ved at knytte funktioner med lav kode til virksomhedens infrastruktur kan du bruge teknikker med lav kode side om side med traditionelle metoder. Lav kode abstraherer meget af kompleksiteten og giver et bredere sæt personer mulighed for at deltage i udviklingen af løsninger.

Forstå omkostningsstrukturen ved en fremgangsmåde med lav kode

Et almindeligt spørgsmål, som organisationer stiller, når de overvejer en moderniseringsindsats, er, hvor meget det vil koste? Mens en komplet diskussion af licenser og omkostningsanalyse ligger uden for rammerne af dette papir, kan vi udforske disse emner på et højt niveau.

Power Platform Produkter er licenserede produkter. Du kan licensere dem individuelt, så de passer til dine krav. Du kan konfigurere Azure fakturering for pay-as-you-go, som tillader brug uden en forudgående licensforpligtelse eller køb og inkluderer noget brug i appen Power Automate. Power Automate har også licenser pr. bruger og pr. flow til enkeltstående arbejde. Licenser pr. flow fungerer godt, når du har automatisering, der gavner hele organisationen. Power Apps licenser kan være pr. bruger eller pr. app. Power Pages-websteder licenseres pr. bruger, websted eller måned. Der kræves en ekstra licens til godkendte websteder. Alle licenser inkluderer brug af connectorer og Dataverse med mulighed for at licensere flere lager- og API-anmodninger til scenarier med store volumener.

Alle Power Platform produkter har volumenpriser, der normalt gælder for applikationsmoderniseringsindsatser og skal evalueres for hver organisations unikke strategi.

Når du evaluerer omkostningerne ved lav kode sammenlignet med traditionel kode, er det vigtigt at indse, at sammenligningen ikke er lige for lige. Med lav kode betaler du for arbejdet med at implementere en unik forretningsproces i produktet med lav kode og for produktlicensen til at bruge det. Generelt inkluderer licensen flere apps og automatiseringer, uden at hver enkelt kræver flere omkostninger.

Med traditionelle kodningsmetoder betaler du for arbejdet med at implementere en unik forretningsproces i kode, arbejdet med at opbygge appens infrastruktur og de skytjenester, der er nødvendige for at understøtte appen.

Alle løsninger, uanset om der er lav kode eller traditionel kode, kræver løbende vedligeholdelse. Løsninger med lav kode kræver dog færre ressourcer til at gøre det. De pådrager sig også mindre teknisk gæld, fordi appinfrastrukturen leveres af platformen.

Sammenlignet med en fuldt brugerdefineret applikation, der ikke er bygget oven på en platform med lav kode, har en løsning med lav kode en mere forudsigelig pris. Undgå at falde i fælden med at sammenligne licenser til lav kode-løsninger med de oprindelige omkostninger ved traditionel kodeudrulning.

Et kig indenfor Power Platform

Power Platform-komponenter er bygget på de samme Microsoft Azure skytjenester, som er tilgængelige, hvis du bruger traditionelle kodningsmetoder. Integrationen af disse komponenter med hinanden og med funktioner til sikkerhed, skalerbarhed og it-katastrofeberedskab er gjort for dig.

Indenfor Dataverse

Dataverse drives af mere end 25 fuldt administrerede Azure-tjenester som Functions, Load Balancer, Cognitive Services, Synapse, DevOps, Active Directory og Microsoft Purview. De indbyggede funktioner omfatter omfattende sikkerhed, effektive analyser, AI, avanceret forretningslogik og hændelseshåndtering, datamodellering og integration med Dynamics 365, Microsoft 365, Azure og meget mere. Alle disse funktioner er bygget på et polyglot lagerlag Dataverse , der er baseret på Azure SQL DB (til relationsdata), Azure Cosmos DB (til NoSQL), Azure Blob Storage (til filer) og Azure Data Lake Storage Gen 2 (til omfattende analyse og langvarig dataopbevaring). De er tilgængelige til gennemsigtig brug i komponenter med Power Platform lav kode og via Dataverse REST API.

Høj tilgængelighed og forretningskontinuiteten samt katastrofeberedskab (BCDR) er vigtigt for dine forretningskritiske applikationer. Dataverse maksimerer tilgængeligheden med Azure pålidelighedstjenester. Replikering af primære og sekundære servere er synkron med en struktur nedenunder, der kan registrere fejl og vælge en ny primær server efter korrekthedsprotokoller. Failovers med høj tilgængelighed, som opstår i et Azure område, er problemfri og bemærkes sjældent af brugerne, typisk på få sekunder. De har garanteret nul datatab, uanset om afbrydelsen er planlagt eller uplanlagt.

It-katastrofeberedskabs-failovers forekommer på tværs af to Azure regioner. For at sikre hurtigere failover med minimalt datatab vedligeholdes en kontinuerlig kopi af it-katastrofeberedskab ved hjælp af asynkron replikering. Planlagte failovers medfører intet datatab, og i produktionsmiljøer kan de normalt gennemføres på få sekunder eller få minutter.

Ud over den tekniske implementering af høj tilgængelighed og BCDR tester driftsteamet regelmæssigt sin parathed til at reagere på forskellige typer begivenheder.

Indenfor Power Automate

Power Automate cloudflows bygget oven på Azure Logic Apps. Power Automate indeholder abstraktioner og integration med andre komponenter med lav kode, f.eks. Power Apps og bruger kørselsprogrammet Logic Apps. Udviklere, der er fortrolige med Logic Apps, vil finde, at Power Automate bruger lignende begreber, herunder udtrykssproget.

Indenfor Power Apps

Runtime-motoren Power Apps er bygget på React-rammeverket. Applikationer er bygget i designeren Power Apps, som bruger en træk-og-slip-grænseflade til at opbygge skærme. Power Fx-formler implementerer logik. Connectorer udvider apps' adgang til andre tjenester og logik og komponenter, der gør det muligt at genbruge visuelle udvidelser. Udviklere kan bruge Power Apps Component framework (PCF) til at oprette brugerdefinerede kontrolelementer. Mens mange UI-rammer kan bruges sammen med PCF, er Power Apps-funktioner indbygget i understøttelse af React.

Indenfor connectorer

Connectorer bruger Azure API Management til at administrere legitimationsoplysningerne og forbindelserne fra de enkelte brugere.

Den samme arkitektur bruges til alle connectorer, herunder brugerdefinerede connectorer, som du opretter til dine egne API'er. Brugen af Azure API Management sikrer en ensartet grænseflade for Power Platform produkter som Power Apps og Power Automate med alle connectorer.

En undtagelse er connectoren Dataverse. Det vises på listen over connectorer til apps og flows, men det implementeres anderledes. Når en app eller et flow bruger Dataverse data eller handlinger, er interaktionen direkte via Dataverse OData-API'en.

Power Platform Indstillinger for udvidelse

Udvidelsesmuligheder er en nøglefunktion,der adskiller Microsoft Power Platform fra andre platforme med lav kode. Et ledende princip for platformen er "ingen afgrunde" - du bør ikke blokeres fra at udføre noget ved hjælp af lav kode, selvom det kræver traditionel kode. Du kan oprette en hel arbejdsbelastning som en del af en større app ved hjælp af traditionel kode, hvis det er nødvendigt. Platformen indeholder dog mange udvidelsesmuligheder, der gør det muligt at bruge lav kode og traditionel kode sammen i den samme arbejdsbelastning.

Følgende tabel indeholder en overordnet oversigt over nogle af de almindelige udvidelsesmuligheder. Vi henviser til nogle af dem igen senere, når vi diskuterer, hvordan man nærmer sig modernisering og mønstre, som du kan anvende.

Mulighed	Description
API'er og brugerdefinerede connectorer	Brugerdefinerede connectorer til dine REST API'er centraliserer applogikken og gør det muligt at vise den for komponenter med lav kode på en sikker og styret måde. Du kan bruge denne fremgangsmåde i en API-first-strategi til programmodernisering. Den brugerdefinerede connector bruger et OpenAPI dokument til at definere, hvordan en komponent med lav kode kan interagere med REST API'en. Du kan f.eks. oprette en API ved hjælp af Azure Functions og publicere den til Azure API Management. Azure API Management kan eksportere en OpenAPI definition for automatisk at oprette den brugerdefinerede connector til brug i en løsning med lav kode. Denne fremgangsmåde afkobler klientprogrammer fra API'erne, så de kan udvikles uafhængigt. API'erne administreres centralt, hvilket tilføjer et lag af sikkerhed ved ikke at eksponere API'en direkte og ved hjælp af godkendelsesteknikker som abonnementsnøgler, tokens, klientcertifikater og brugerdefinerede overskrifter.
Power Apps Component framework	Power Apps Component framework er en udvidelsesstruktur til oprettelse af brugerdefinerede visualiseringer til Power Apps og Power Pages. Kodekomponenterne oprettes ved hjælp af HTML, JavaScript eller TypeScript. Tænk på kodekomponenter som byggesten til brugergrænsefladen, der kan genbruges til at bygge en eller flere apps. Komponenterne indeholder et manifest, der definerer, hvordan en komponent med lav kode kan interagere med kodekomponenten. Komponentgrænsefladen gør det muligt for værtskørselsprogrammet at kommunikere værtscontainerens livscyklushændelser. Dette gør det muligt for kodekomponenten at gengive sine visualiseringer ved hjælp af kontekstoplysninger, der leveres af værtscontaineren. Hvis du vil have idéer, kan du gennemse communitygalleriet på https://pcf.gallery.
Virtuelle tabeller	Virtuelle tabeller gør det nemmere at integrere data, der findes i eksterne systemer. De repræsenterer problemfrit de eksterne data som tabeller i Microsoft Dataverse uden at replikere dataene og ofte uden behov for brugerdefineret kodning. Dataverse leveres med dataprovidere til OData v4 og Azure Cosmos DB. En virtuel connector-provider, der i øjeblikket er i prøveversion, udvider de tilgængelige dataprovidere til at omfatte et undersæt af Power Platform connectorerne, herunder SharePoint og SQL Server. I mere avancerede scenarier kan udviklere oprette brugerdefinerede dataprovidere. Oprettelse af brugerdefinerede dataprovidere kræver dyb viden om både de eksterne data og Dataverse. Muligheden for at oprette Dataverse plug-ins ved hjælp af Power Fx til logikken findes som prøveversion.
Dataverse-plug-ins	En Dataverse plug-in er en brugerdefineret hændelseshandler, der udføres som svar på en bestemt hændelse. Tænk på plug-ins som lagrede procedurer i en databasemotor, men skrevet i .NET. Hændelser opstår f.eks. under behandling af en Microsoft Dataverse datahandling eller efter behov for brugerdefinerede API-hændelser. Plug-in'et implementeres som en brugerdefineret klasse, der er kompileret i en .NET Framework-assembly, der kan uploades og registreres med Dataverse. Ved hjælp af en defineret grænseflade kan plug-in'en hente kontekstoplysninger om den hændelse, der behandles. Plug-ins kan køre som en del af transaktionen Dataverse og kan udføre andre datahandlinger, der er en del af den aktuelle transaktion. Plug-ins er beregnet til små arbejdsenheder. Deres ydeevne skal optimeres, så de ikke påvirker den samlede ydeevne negativt. Plug-ins udføres altid, uanset handlinger fra brugergrænsefladen eller API'en, hvilket gør dem til en effektiv måde at håndhæve forretningslogik konsekvent på.

Undersøgelse af scenarier for moderniseringsarkitektur med lav kode

Som med de fleste platforme kan du oprette et uendeligt antal arkitekturscenarier ved hjælp af Power Platform komponenter og andre Microsoft skytjenester. I dette afsnit af artiklen undersøger vi nogle af de mere almindelige scenarier og diskuterer nogle overvejelser, du bør huske på, når du bruger dem.

Applikationsoplevelser

Modernisering af brugeroplevelsen kan gøre en stor forskel for brugerne. Power Apps er den primære måde at opbygge interne programoplevelser med Power Platform. Du kan bruge Power Pages til interne webapplikationer, men det er mere almindeligt for eksterne applikationer.

Power Apps

Arbejdsbelastninger bør designes, så brugerne kan udføre meget af deres arbejde uden at skifte apps. Når du moderniserer en stor, monolitisk applikation, kan du opdele dets funktionalitet i flere apps. Hvis brugerne derimod har brug for at arbejde med flere apps, kan du konsolidere dem i en enkelt app, der giver en samlet visning af deres flere datakilder.

I følgende tabel beskrives de to typer apps, du kan bygge med Power Apps, lærredapps og modelbaserede apps.

Type af ap	Description
Lærredapps	Lærredapps kan tilpasses meget. De består af et eller flere skærmbilleder, som brugerne interagerer med. Du styrer layoutet af hvert skærmbillede og navigationen på tværs af skærmbilleder. Lærredapps arbejder med data ved hjælp af connectorer. En enkelt app kan arbejde med flere connectorer, hvilket gør den velegnet til integration på tværs af flere datakilder som en sammensat app.
Modelbaserede apps	Modelbaserede apps bruger Dataverse som den primære datakilde. De består af en eller flere sider, som kan være Dataverse tabeller eller brugerdefinerede sider. En Dataverse tabelside kan bore sig ned til en detaljeside til visning og redigering. Brugerdefinerede sider kan indeholde en skærm i lærredappen og data fra connectorer. Modelbaserede apps har en indbygget navigationsstruktur, der kan tilpasses. Det er ensartet på tværs af alle modelbaserede apps, hvilket hjælper med brugernes adoption.

Følgende diagram illustrerer en grundlæggende arkitektur for en lærredapp eller en modelbaseret app, hvor appen opretter direkte forbindelse til datakilder.

Hvis du vil minimere de direkte forbindelser til en datakilde, kan du få appen til at bruge en brugerdefineret connector til API'en, som udfører det nødvendige arbejde i datakilden. Denne fremgangsmåde giver dig mulighed for at styre, hvilke handlinger der vises for komponenter med lav kode, og du kan abstrahere kompleksiteten af den underliggende logik. Følgende diagram illustrerer denne API-først-tilgang.

Power Apps kan også køre Power Automate cloudflows direkte, der kan returnere resultater til programmet eller køre asynkront.

Når du bruger Power Apps sammen med dine datalagre eller API'er, kan du modernisere brugeroplevelsen, samtidig med at du minimerer afbrydelser af andre dele af en ældre løsning. Denne fremgangsmåde kan også give dig mulighed for at forbinde flere ældre systemer til et enkelt program, så brugerne får ét samlet sted, hvor de kan udføre deres arbejde.

Power Pages

Den primære datakilde til Power Pages er Dataverse. Når du føjer sider til et websted, gemmer du sidedefinitionerne i Dataverse. Sider kan både præsentere Dataverse data og indsamle data fra brugere, der skal gemmes i en Dataverse tabel.

Du kan konfigurere sider til anonym adgang eller til godkendt adgang ved hjælp af Microsoft Entra id for interne brugere eller identitetsudbydere for eksterne brugere. Når godkendte brugere får adgang til data, er det kun de data, de har tilladelse til at få adgang til, der er tilgængelige.

En almindelig anvendelse af et Power Pages websted giver eksterne brugere selvbetjeningsadgang til en forretningsproces i organisationen. Interne brugere kan bruge et Power Apps program. Følgende diagram illustrerer en sådan arkitektur.

Dataadministration

Programmodernisering kræver evaluering af de data, der bruges i den samlede løsning. Moderniserede programmer har flere muligheder for håndtering af data. I mange tilfælde bruger flere applikationer det samme datalager. Det bliver vanskeligt at migrere dataene til et nyt lager som en del af moderniseringen af en af applikationerne. Et kerneprincip Power Platform er, at data kan bruges, hvor de er, eller bringes ind på platformen i enten Dataverse eller en datasø.

Du har følgende indstillinger for dataarkitekturen i det moderniserede program:

• Lad dataene blive siddende: Brug connectorer eller API'er med brugerdefinerede connectorer til at få adgang til dataene, hvor de er placeret. Når dataene er i det lokale miljø, kan datagatewayen muliggøre sikker forbindelse. Brug virtuelle tabeller til at integrere kompatible eksterne data som en Dataverse tabel.

• Overfør til Dataverse: Dataverse er en god mulighed til transaktionsdata og til konsolidering af flere kilder i et enkelt postsystem. Data kan tilknyttes og overføres fra mange kilder ved hjælp af Power Query automatiserede flows. Dataverse understøtter også elastiske tabeller, der er udviklet til indtagelse af store mængder data, som er gemt i ustrukturerede eller semistrukturerede formater.

• Overfør til datasø: Brug en datasø til historiske, analytiske eller telemetriske data. Dataene i søen kan bruges til at generere Power BI analyser eller behandles for at generere AI-drevet indsigt.

Når du evaluerer indstillinger for dataarkitekturen i et moderniseret program, skal du være opmærksom på følgende:

• Indvirkning på andre programmer: Selvom migrering til et mere effektivt datalager kan være ideel til ét program, kan den første påvirkning af andre programmer, der bruger dataene, være for høj. Nogle organisationer overvejer at lade dataene blive i gamle datalagre og oprette nye data i Dataverse forbindelse med migrering fra det gamle lager, efterhånden som flere programmer moderniseres.

• Indvirkning på nye programmer: Hvis du efterlader data i et gammelt datalager, kan det være nemt, men det kan have en negativ indvirkning på, hvor nemt moderniserede programmer kan bruge dem. Ældre datalagre har muligvis ikke god integration med andre skytjenester, hvilket gør det sværere at inkorporere dataene i den nye overordnede arkitektur.

• Datakonsolidering: Som led i programmodernisering er det almindeligt at identificere data, der ikke har et klart ejerskab eller ansvar for at sikre, at de bruges korrekt. Ved at konsolidere deres data i Dataverse kan organisationer forbedre deres styring af dem og bedre sikre, at de bruges korrekt.

• Databeskyttelse og sikkerhed: Du bør evaluere privatliv og sikkerhed baseret på dine nuværende behov og målrette moderniseringsarkitekturen, ikke kun på, hvordan det ældre program håndterede dem. Cloudløsninger har flere muligheder for at implementere privatlivs- og sikkerhedskontroller. Ofte kan et enkelt datalager forenkle dem. Du skal også overveje, hvordan du implementerer samlet datasikkerhed i hybridprogrammer, der opdeler data på tværs af flere lagre.

• Integrationsudsteder. Ældre datalagre mangler muligvis de API'er, der er nødvendige for at give adgang uden enten at overføre dataene eller oprette en API, som programmer kan bruge med en brugerdefineret connector. Forbindelsen fra det gamle datalager til de programmer, der bruger det, skal evalueres for at afgøre, om ydeevnen er acceptabel.

Du skal bestemme en dataarkitektur for hvert program, der skal moderniseres. Et første skridt er at etablere en overordnet vision for, hvordan dine dataarkitekturer inkorporerer Dataverse. Hvis målet er at maksimere værdien af lav-kode, skal du bruge Dataverse, når det er muligt. At have en vision i starten kan hjælpe dig med at undgå at sprede flere siloer af data.

Eksterne data og Dataverse

Ældre programmer er ofte afhængige af data, der findes uden for organisationen, og som fandtes længe før Dataverse. Modernisering af disse applikationer behøver ikke at involvere duplikering af dataene i Dataverse. Du kan i stedet repræsentere dataene som virtuelle Dataverse-tabeller. Virtuelle tabeller kan deltage i relationer med andre virtuelle tabeller og med lokale tabeller. De moderniserede programmer ser et samlet sæt tabeller, der ser ud til at eksistere helt i Dataverse.

Virtuelle tabeller implementeres ved hjælp af en dataproviderarkitektur. Dataverse indeholder en OData-provider, der kan bruges sammen med OData V4-webtjenester. En dataprovider til virtuelle connectorer, der i øjeblikket findes som prøveversion, gør det muligt at bruge tabelconnectorer Power Platform som virtuelle tabeller.

Følgende diagram illustrerer brugen af den virtuelle connector.

Udviklere kan også oprette brugerdefinerede providere til andre eksterne datakilder. De skal dog forstå og implementere alle Dataverse-tilknytninger og driftsstøtte.

Følgende overvejelser kan hjælpe dig med at evaluere brugen af virtuelle tabeller i dine moderniseringsprojekter:

• Alle eksterne datakilder skal have en primær nøgle, og dataprovideren skal præsentere den som et GUID til Dataverse. Du kan rumme ikke-GUID-taster med udfyldning, hvis den udfyldte værdi er stabil og unik.
• Datasikkerhed konfigureres på virtuelt tabelniveau. Sikkerhed på række- og kolonneniveau er ikke tilgængelig.
• Virtuelle tabellers ydeevne afhænger af dataprovideren, den eksterne datakilde-API og forbindelsen til datakilden. I de fleste tilfælde er adgangen til virtuelle tabeller langsommere end med lokale Dataverse-tabeller.
• Visse Dataverse funktioner som søgning, overvågning, diagrammer og dashboards samt offlineadgang er ikke tilgængelige for virtuelle tabeller.
• Brug af virtuelle tabeller som referencedata kan resultere i reduceret synkronisering.

Fil og billeder

Når du moderniserer programmer, der bruger filer og billeder, er det vigtigt at overveje, hvor de skal gemmes i den nye løsning. Dataverse har specialiserede funktioner til lagring af filer og billeder. Begge kan føjes til tabeller som en kolonne og gemmes i Azure Blob Storage, der administreres af Dataverse. Apps kan arbejde med dem ved hjælp af Dataverse connectoren, og der kræves ingen separat godkendelse eller API.

Brug Dataverse til filer og billeder er passende, når de har en direkte forbindelse til dataene, og flere brugere ikke behøver at samarbejde om dem, f.eks. et foto af et produkt eller en placering eller den endelige kopi af en juridisk kontrakt. Men hvis flere brugere har brug for at ændre den juridiske kontrakt samtidigt, vil SharePoint brug give større samarbejdsmuligheder. Overvej at bruge Azure Blob Storage direkte, hvis sikkerheden skal administreres separat fra Dataverse, eller hvis du skal bruge visse filspecifikke funktioner.

Integrationer

Modernisering af applikationer inkluderer ofte integrationer med interne eller eksterne systemer. Integrationer kan bredt kategoriseres som data, applikation eller proces.

• Dataintegration kombinerer data fra forskellige kilder for at give brugeren et samlet overblik. Det tilbyder en afkoblet tilgang, men tillader ikke konstruktion af logik eller processer i realtid. Ydeevnen kan være bedre, fordi alle data er lokale.

• Programintegration opretter forbindelse på programlaget og udføres normalt via API'er eller, med løsninger med lav kode, connectorer. Integration på programniveau giver en defineret grænse mellem to løsninger, men skaber også i mange tilfælde en afhængighed i realtid. Denne type integration opretter også en sikkerhedsgrænse, hvor adgangen kan styres af det system, der leverer API'en.

• Procesintegration forbinder flere forskellige systemer, som hver især er en del af en overordnet forretningsproces. Denne type integration er den mest afkoblede, så de deltagende systemer kan håndtere hver del af forretningsprocessen. I moderniseringsscenarier kan det være nyttigt at partitionere en del af en moderniseringsproces med lav kode, integreret med andre dele, der stadig håndteres af et ældre system.

Når du evaluerer, hvordan du implementerer integrationer, er det vigtigt ikke at antage, at den gamle tilgang er den bedste til den applikation, du moderniserer. For eksempel, hvis en proces f.eks. er synkron i realtid, skal du overveje, om du kan gøre den asynkront. Synkron integration kan være mere skrøbelig i en cloud-løsning. Et lav-kode Power Automate-flow og korrekt fejlhåndtering kan f.eks. orkestrere integrationen. Denne tilgang vil ikke kun forbedre pålideligheden, men den vil også forbedre brugernes produktivitet, fordi de ikke længere behøver at vente på, at integrationen er fuldført.

Følgende overvejelser kan hjælpe dig med at evaluere, hvordan du kan fremrykke eksisterende integrationer:

• Er integrationen stadig nødvendig? Det er ikke ualmindeligt at finde ud af, at ingen bruger resultaterne af integrationen længere, og den kan udgå.

• Er der forbindelsesudfordringer, hvis det moderniserede program er i skyen? Udfordringerne kan omfatte ventetid og adgang til et API eller datalager i det lokale miljø. I visse tilfælde kan din datagateway i det lokale miljø hjælpe med at få adgang til tjenesten eller data fra cloudmiljøet. Hvis adgangen til dataene eller tjenesten er for langsom, skal du overveje, om du kan gøre dataene lokale for den moderniserede app eller udføre integrationen i baggrunden.

Integration kan også hjælpe med at tilpasse størrelsen på et moderniseret program. Du kan partitionere en eller flere dele af det ældre program for at efterlade eller implementere i et separat program. Denne fremgangsmåde vil fungere godt, når brugere af forskellige roller bruger forskellige dele af det ældre program. Du kan implementere en eller flere af rollerne ved hjælp af lav kode og bruge procesintegration til at lade det eksisterende program håndtere de resterende dele af processen. Ved hjælp af denne fremgangsmåde kan du gradvist modernisere de resterende dele over tid. At have uafhængige dele af processen implementeret separat kan også lette en mere fleksibel måde at udrulle forbedringer uafhængigt af de andre dele af processen.

Før du viderefører brugerdefinerede integrationer, skal du evaluere de indbyggede Power Apps integrationsfunktioner.

• Microsoft Teams: Power Apps lærredapps og Copilot Studio agenter kan integreres i Teams-kanaler. Ved hjælp af Teams-connectoren kan apps og flows nemt sende og forbruge Teams-meddelelser. Power Apps-kort kan bruges som mikroapps til at dele handlingsrettede oplysninger i en Teams-kanal.

• SharePoint: Power Apps-modelbaserede apps kan konfigureres til at oprette forbindelse til dokumenter, der er gemt i et SharePoint bibliotek, for at gøre dem tilgængelige på en Dataverse-række. Med Microsoft-lister eller en SharePoint liste kan brugere køre Power Automate flows i konteksten for et listeelement.

• Power BI: Power BI-Indsigt kan vises i konteksten af en Power Apps lærredapp. Du kan integrere en modeldrevet app i en Power BI rapport, så brugerne kan reagere på indsigten uden at forlade Power BI.

Hvis du bruger Dataverse som det primære datalager for det moderniserede program, får du nogle få indbyggede funktioner, der kan være nyttige til integration.

• Dataverse-brugerdefinerede API'er kan bruges til indgående integration på programniveau. Brugerdefinerede API'er giver en entydig handling, der er knyttet til en lille mængde brugerdefineret kodelogik. Et afsendelsessystem kan f.eks. bruge den brugerdefinerede RequestNewProject API, og den tilknyttede logik ved, hvordan de modtagne data placeres i de relevante Dataverse tabeller. Afsendelsessystemet ville blive udtrukket fra Dataverse tabelstrukturen.

• Udgående integration kan udføres ved hjælp af funktionerne til publiceringshændelser i Dataverse. Dataverse kan konfigureres til at udgive til Azure Service Bus, Azure Event Hubs eller en hvilken som helst webhook-modtager. Når der f.eks. oprettes en ny Dataverse projekttabelrække, kan den publiceres til en Azure Service Bus-kø. Du kan også publicere flere konceptuelle hændelser, der svarer til en forretningsproceshændelse. Du kan f.eks. definere og publicere hændelser, når et projekt er fuldført.

Følgende diagram illustrerer et eksempel på indgående og udgående hændelser i et Dataverse miljø.

Organisationer bør også overveje forudbyggede integrationsmuligheder, der er tilgængelige fra tredjeparter på Microsoft AppSource. Microsoft har f.eks. en foruddefineret løsning til organisationer, der skal integrere SAP med Power Platform. Denne forudbyggede løsning indeholder apps og flows og tilføjer flere nye funktioner, der gør det nemmere at kommunikere mellem organisationens SAP-systemet og Power Platform.

For eksempel brugte Ernst & Young den forudbyggede SAP-integration til hurtigt at udvikle en løsning til optimering af en højfrekvent global finansieringsproces. Følgende diagram over virksomhedens PowerPost-løsning viser, hvordan økonomibrugere bogfører dokumenter til sit General Ledger SAP ERP-system ved hjælp af Power Platform.

Indstillinger for integrationsforbindelse

Efterhånden som løsninger flyttes til cloudmiljøet, kan det være vigtigt at oprette forbindelse tilbage til ressourcer i det lokale miljø for at sikre, at integrationer stadig fungerer sammen med det moderniserede program. Disse programmer skal også kunne integreres med andre traditionelle cloudressourcer, der kan være placeret i forskellige netværksmiljøer. Power Platform understøtter de fire primære indstillinger for sikker forbindelse: datagateways, virtuelle netværksdatagateways, private links og ExpressRoute.

• Data gateways giver mulighed for low-code-komponenter fra Power Apps, Power Automate og Power BI at gå tilbage til ressourcer i det lokale miljø for at understøtte hybride integrationsscenarier. Gateways gør det hurtigt for moderniserede programmer med lav kode at få adgang til datakilder, der stadig findes i det lokale miljø. Med en gateway kan du oprette forbindelse til data i det lokale miljø fra kilder som et lokalt filsystem, DB2, Oracle, SAP ERP, SQL Server og SharePoint. Én gateway kan understøtte flere brugere og adgang til flere kilder. Du kan også konfigurere datagateways som klynger for at sikre høj tilgængelighed.

  Understøttelse af gateway er integreret i forbindelsesprocessen for connectorer, hvilket gør det muligt at angive, hvornår en gateway er påkrævet, og vælge den konfigurerede gateway. Når forbindelsen er konfigureret, kan apps og flows bruge connectoren på samme måde som en uden en gateway.

  

• Med virtuelle netværksdatagateways kan Power BI og Power Platform-dataflows forbindes med datatjenester i et Azure-virtuelt netværk uden behov for en datagateway i det lokale miljø på en virtuel maskine inden i det virtuelle netværk.

• Azure Private Link og Azure netværk med private slutpunkter gør det muligt for apps og flows at få sikker adgang til Power BI. Private slutpunkter bruges til at sende datatrafik privat ved hjælp af Microsoft's backbone-netværksinfrastruktur i stedet for at gå på tværs af internettet. Private slutpunkter sikrer, at trafik, der går ind i organisationens Power BI ressourcer, f.eks. rapporter eller arbejdsområder, altid følger organisationens konfigurerede sti til Private Link-netværk.

• Azure ExpressRoute giver opdateret metode til at oprette forbindelse det lokale miljø netværk til Microsoft cloud services ved hjælp af private forbindelser. En enkelt ExpressRoute-forbindelse kan få adgang til flere onlinetjenester som Power Platform, Dynamics 365 Microsoft 365 og Azure cloudtjenester uden at gå via det offentlige internet. ExpressRoute kræver omfattende planlægning og konfiguration og medfører flere omkostninger for ExpressRoute-tjenesten og forbindelsesudbyderen.

Uanset hvilke tilgange du bruger til integrationsforbindelse, skal du evaluere din forbindelse for at sikre, at den har lav nok ventetid og nok båndbredde til at understøtte både dine integrationer og det moderniserede program.

Forretningslogik

Når du bygger moderne programmer, kan du vælge, hvad du vil implementere forretningslogik med, og hvor du vil implementere den i programarkitekturen. Uden vejledning ville de fleste organisationer ende med kaos i forretningslogikken. Hvis du har genanvendelig logik, der sikrer ensartethed i implementeringen, kan det hjælpe med at fremskynde moderniseringsindsatsen.

Til vores formål definerer vi forretningslogik som værende forskellig fra brugeroplevelseslogik. Logik til at navigere fra skærm til skærm baseret på værdier for inspektionsdata er f.eks. brugeroplevelseslogik. Den logik, du implementerer for at afgøre, om en inspektion er fuldført, kan omfatte flere betingelsesevalueringer og vil blive betragtet som forretningslogik.

Når du udformer en løsning, der indeholder lav kode, kan følgende overvejelser hjælpe dig med at beslutte, hvor du kan placere forretningslogikken.

• I programmet Power Apps: Placering af forretningslogik i programmet med lav kode er den enkleste fremgangsmåde, men den giver begrænsede muligheder for genbrug eller for at gennemtvinge ensartethed på tværs af apps og automatiseringer. Generelt bør du begrænse denne fremgangsmåde til ikke-missionskritisk, enkel logik, som andre programmer eller automatiseringer ikke behøver at bruge. Værktøjer med lav kode giver ikke en fejlfindingsoplevelse linje for linje. Hvis logik strækker sig over mere end ét skærmbillede eller er svært at læse, bør du overveje andre fremgangsmåder, der er mere vedligeholdelige. Det er ikke ualmindeligt, at forretningslogik duplikeres lokalt i programmet og i skyen. Hvis en bruger f.eks. angiver en hotelreservation, er forretningsreglen, at udtjekningsdatoen ikke må ligge før indtjekningsdatoen. Hvis programmet ikke validerede dette, ville brugeren komme hele vejen til slutningen og sende reservationen kun for at finde ud af, at den brugerdefinerede connector afviste den. Håndtering af validering lokalt i applikationen og i skyen giver en langt bedre brugeroplevelse.

• I et Power Automate cloudflow: Du kan udtrykke forretningslogik i handlingerne i et flow, og flowet kan udløses som svar på en hændelse eller en anmodning om kørsel efter behov fra andre apps og flows. Flowet kan give en tilgang med lav kode til centralisering af logik. Trin i flowet er uafhængige og er ikke en del af en transaktion. Flows kan dog implementere kompensation for at håndtere tilbageførsel i tilfælde af fejl. Flow kan køre trin ved hjælp af forbindelser, der har tilladelser ud over, hvad appbrugeren muligvis kan gøre, hvilket giver mulighed for at hæve tilladelser. Denne fremgangsmåde gør det også muligt at minimere de tilladelser, som appbrugeren kan kræve.

• I en Dataverse plug-in: Plug-ins kører som svar på en datarækkehændelse, f.eks. oprettelse, opdatering eller sletning. Denne logik kører, når hændelsen indtræffer, uanset hvilken app eller hvilket flow der har udført handlingen, eller om den er udført direkte fra Dataverse API. Fordelen ved denne funktionsmåde er, at den sikrer ensartethed på tværs af alle anvendelser. Derudover er alle Dataverse dataændringer fra plug-in-logikken transaktionsmæssige og enten fuldføres helt eller rulles helt tilbage. Plug-in-logik skal være kort og effektiv og ikke forsøge at implementere langvarigt arbejde. Nogle gange er plug-ins til hændelser ikke den bedste fremgangsmåde, hvis du skal lytte til hændelser på flere tabeller for at gennemføre en enkelt virksomhedshændelse som f.eks. Luk inspektion. Du kan f.eks. overveje en Dataverse brugerdefineret API i stedet for at have plug-ins på flere tabeller. Plug-ins kan udføre logik med udvidede tilladelser, som brugeren måske ikke normalt har. Denne fremgangsmåde gør det også muligt at minimere de tilladelser, som appbrugeren kan kræve. Plug-ins kan udrulles i en Dataverse løsning sammen med apps og flows.

• I Dataverse brugerdefinerede API'er: Med Dataverse brugerdefinerede API'er kan du implementere din egen brugerdefinerede API-meddelelse, der kan køre logik. Du kan f.eks. oprette en brugerdefineret API til Luk inspektion, der kaldes for at udføre alt arbejdet med at kontrollere og lukke en inspektion. Det ville ikke være hændelsesdrevet, men ville blive brugt efter behov af de apps og flows, der har brug for det. På samme måde som hændelsesbaserede plug-ins er de dataændringer, der foretages i det brugerdefinerede API-plug-in, transaktionsbaserede. En brugerdefineret API er bedst, når den eneste tjeneste, den bruger, er Dataverse API til andet dataarbejde. Plug-ins til brugerdefinerede API'er kan udrulles i en Dataverse løsning sammen med apps og flows.

Implementere en kode-API

Du kan implementere API'er i din foretrukne API-hostingkørsel, f.eks. Azure Functions, Azure Container Apps eller enhver tjeneste, der kan huse en REST API. Disse brugerdefinerede API'er kan implementere enhver logik, og både programmer med lav kode og traditionelle kodeprogrammer kan bruge dem. Brugerdefinerede API'er yder ikke anden transaktionssupport end den, der kan leveres af en API, de bruger. En brugerdefineret API kan f.eks. bruge SQL Server-transaktionskonstruktioner, hvis den bruger SQL Server. Udrulning af en kode-API vil være uafhængig af de ressourcer med lav kode, der kan bruge den. Du kan bruge Azure API Management til at styre brugen af disse API'er og gøre dem mere synlige.

Sikkerhed

Sikkerhed, herunder godkendelse og autorisation, er en væsentlig del af arkitekturen i en moderniseret applikation. Moderne programmer er ofte mere udfordrende at sikre end ældre apps. De inkluderer flere skytjenester, og brugerne arbejder med dem fra mere forskellige placeringer. Sikkerheden i platformen har til opgave at sikre, at brugerne kan udføre deres arbejde med færrest mulige udfordringer, samtidig med at data og tjenester stadig beskyttes.

Power Platform har en tilgang til sikkerhed i flere lag, som du kan bruge til at opbygge din sikkerhedsarkitektur. Et centralt princip i disse funktioner er, at løsninger med lav kode skal integreres med dit eksisterende sikkerhedsapparat for at minimere virkningen af at introducere dem.

Det følgende er en overordnet illustration af, hvordan de flere sikkerhedslag udgør sikkerhedsmodellen for Power Platform:

• Brugere godkendes af Microsoft Entra ID, og brugen kan begrænses ved hjælp af politikker for betinget adgang.
• Licenser er den første kontrolport, der giver adgang til Power Platform-komponenter.
• Muligheden for at oprette programmer og arbejdsprocesser styres af sikkerhedsroller i konteksten af miljøer.
• En brugers mulighed for at se og bruge Power Platform-ressourcer styres ved at dele programmet med brugeren. Ressourcer deles direkte med brugeren eller Entra ID-gruppen.
• Miljøer fungerer som sikkerhedsgrænser, der gør det muligt at implementere forskellige sikkerhedsforanstaltninger i de enkelte miljøer.
• Power Automate-flows og lærredapps bruger connectorer. De specifikke forbindelseslegitimationsoplysninger og tilknyttede tjenesteberettigelser bestemmer tilladelser, når apps bruger connectorerne.
• Miljøer med en Dataverse-forekomst tilføjer understøttelse af mere avancerede sikkerhedsmodeller, der er specifikke for at styre adgangen til data og tjenester i den pågældende Dataverse-forekomst.
• Brugen af connectorer kan yderligere begrænses ved politikker for forebyggelse af datatab (DLP). Indgående og udgående begrænsninger på tværs af lejeren kan også anvendes på connectorerne.

Det er vigtigt at bemærke, at når du har adgang til datakilder via connectorer, er al den underliggende sikkerhed, som datakilden giver, en tilføjelse til de sikkerhedslag, der er beskrevet ovenfor. Power Apps og Power Automate giver som standard ikke brugerne adgang til den connector-datakilde, de ikke allerede har. Brugere skal kun have adgang til data, som de rent faktisk skal have adgang til.

Når du bruger Dataverse som en del af en løsning, indeholder den en rollebaseret sikkerhedsmodel, der kan tilpasses mange forretningsscenarier. Data kan sikres hele vejen ned til en enkelt kolonne i en datarække. Brugere tildeles en eller flere sikkerhedsroller, der tilsammen bestemmer deres overordnede rettigheder. Dataverse indeholder byggesten til sikkerhedsmodellering, f.eks. afdelinger og teams. Afdelinger kan f.eks. bruges til at definere sikkerhedsgrænser for at holde data isoleret mellem to forskellige grupper af organisationsbrugere. Du kan bruge teams til at gruppere brugere, der har brug for lignende adgang til data. Du kan endda tildele gruppeejerskab af datarækker. Følgende diagram illustrerer brugen af forretningsenheder til at isolere data for divisioner i en organisation.

Design af sikkerhedsmodel

Skræddersy sikkerhedsmodellen for den moderniserede applikation til applikationens overordnede arkitektur. Applikationer, der bruger et enkelt datalager og ingen connectorer, kræver minimalt sikkerhedsdesignarbejde. Efterhånden som programmer bruger flere connectorer og datalagre, skal sikkerhedsmodelleringen omfatte andre overvejelser.

• Brugeridentitet: Hvordan godkender brugere, og er den allerede knyttet til Microsoft Entra id i scenarier, der kommer fra det lokale miljø? Dette omfatter tilknytning af grupper, der er nødvendige for at understøtte programgruppe- eller teamtildeling i clouddatalagre, f.eks. Dataverse.

• Identitet for connectorforbindelse: Hvilken type godkendelse udføres for forbindelsen, når programmer bruger en eller flere connectorer, og giver den det kontrolniveau, der er nødvendigt for at implementere de nødvendige sikkerhedskontroller? Programmer, der bruger en tjenesteprincipal til at oprette forbindelse, kræver f.eks. ikke, at brugeren af programmet har direkte adgang til connectoren, hvilket kan være nyttigt i nogle scenarier. Individuelle brugerforbindelser kan være velegnede til programmer, der har brug for at vide, hvilken bruger der har udført en handling, eller for at give svar til bestemte brugere.

• Portabilitet for sikkerhedskonstruktioner: Efterhånden som dine programmer bruger flere connectorer og datalagre, er det vigtigt at huske, at ikke alle sikkerhedskonstruktioner af ét overføres direkte til et andet. Der er f.eks. flere måder, en bruger kan få adgang til en datarække i Dataverse, herunder at dele rækken med brugeren. Hvis et program knytter et SharePoint dokumentbibliotek til rækken, er den sikkerhed, der giver adgang til dokumentbiblioteket, adskilt fra den sikkerhed, der styrer Dataverse adgangen. De overføres ikke direkte. Moderniserede programmer skal tage højde for disse typer uoverensstemmelser på tværs af de connectorer og datalagre, de bruger.

Kunstig intelligens

I løbet af de sidste par år har AI fundet vej ind i applikationsmoderniseringsindsatsen. Når organisationer moderniserer applikationer, bør de overveje at bruge kunstig intelligens til at hjælpe med at gøre brugerne mere produktive og bedre i stand til at træffe informerede beslutninger. Resultaterne af indføring af AI kan også resultere i bedre kundeoplevelser, der positivt påvirker forretningsresultaterne.

Inkludering af AI plejede at involvere stort arbejde i integrationen af applikationslogik og opbygning af specialtrænede modeller. Med tilgængeligheden og styrken ved store sprogmodeller kan programmer nu introducere nye måder at bruge kunstig intelligens på for at hjælpe brugerne med at få svar og udføre opgaver. Brugere kan bruge naturlige sprogprompter til at interagere med AI-funktioner i en lang række forretningsscenarier med hjælpemidler.

Microsoft har introduceret Copilots i kerneprodukter og -tjenester for at gøre det lettere at få adgang til avanceret AI-teknologi. En Copilot bruger moderne AI-teknikker og store sprogmodeller og kan interageres med af brugere i de applikationer, de bruger hver dag, som Microsoft 365, Windows, Dynamics 365 og Power Platform.

Udvid med plug-ins

Brugere af Copilot-drevne programmer kan bede Copilot om hjælp til almindelige opgaver i programmet. Du kan udvide Copilots til at omfatte data og opgaver, de ikke allerede kender, og som ligger uden for rammerne af den app, brugeren arbejder med. Microsoft 365 Copilot kan inkorporere Power Platform data, der er gemt i Dataverse, så brugerne ikke behøver at skifte frem og tilbage mellem applikationer. Fra Outlook kan en bruger f.eks. bede Copilot om at generere en statusopdatering for alle mislykkede inspektioner, der er fuldført i dag. Microsoft 365 Copilot arver automatisk den oprindelige sikkerheds- og styringsstruktur for Dataverse og anvender brugersikkerhed og tilladelser under kørsel.

Connectorer som plug-ins

Power Platform-connectorer er også vigtige for Copilot-oplevelsen. Connectorer kan tilsluttes som plug-ins for at udvide Copilots muligheder. F.eks. kan Copilot med connectoren Microsoft 365 til Jira Software Power Platform gøre det muligt for en projektleder at anmode om status for en Jira-supportanmodning og handle på baggrund af svaret, såsom at sende det til yderligere godkendelse eller starte en indkøbsordre for ny hardware. Ved hjælp af plug-ins kan du integrere dine forretningsprocesser og data med Copilot for at give brugerne mulighed for at interagere fra de apps, de bruger.

Byg din egen copilot

Efterhånden som brugerne bliver mere vant til at have copilot AI-hjælp i deres apps, forventer de det i alle applikationer. Du kan gøre dine moderne programmer mere engagerende ved at inkludere copiloter, som du opretter med Copilot stack, en AI-udviklingsstruktur.

Du kan bruge det forudbyggede Copilot-kontrolelement i Power Apps til at føje copilots til dine lærredapps og modelbaserede apps. Hvis du konfigurerer en visning af en datakilde og nogle grundlæggende promptoplysninger, kan du hurtigt give din egen copilot oplevelse i appen.

Administration af programlivscyklus

En vigtig del af enhver moderniseringsindsats er at etablere en passende proces til administration af applikationens livscyklus. Organisationer ønsker ofte, at deres indsats med lav kode passer ind i, hvordan de arbejder med traditionel kode-ALM. Power Platform indeholder ALM-værktøjer, så du kan medtage artefakter med lav kode i eller sammen med de processer, du normalt bruger.

ALM i Power Platform starter med, hvordan du opbygger dine ressourcer med lav kode. De ressourcer, du opretter, er i konteksten af et Power Platform miljø. Et miljø kan have ét Dataverse-datalager. Du kan bruge flere miljøer – typisk udvikling, test og produktion – til at implementere landingszoner i en ALM-proces, der omfatter low-code. Antallet af og formålet med miljøer er fleksible, og organisationer kan tilpasse dem til individuelle projektbehov. En Dataverse løsning er en objektbeholder til relaterede ressourcer med low-code, hvilket letter versionskontrol og transport fra ét miljø til et andet.

Power Platform-pipelines giver en tilgang med low-code til automatisering af udrulninger og implementering af løbende integration og levering (CI/CD). Power Platform styrer processen, når pipelines er konfigureret. Administratorer kan administrere og styre pipelines centralt.

Organisationer kan også bruge CI/CD-værktøjer efter eget valg. Power Platform CLI er et kommandolinjeværktøj, som du kan bruge sammen med de fleste CI/CD-automatiseringsværktøjer. Power Platform Build Tools indeholder handlinger til GitHub og opgaver til, der indeholder alle de almindelige handlinger, der kræves for Azure DevOps at bygge CI/CD-automatiseringer, der indeholder artefakter med lav kode.

Følgende diagram illustrerer et eksempel på et team, der bygger en inspektionsapp. I deres indre løkke arbejder de i et udviklermiljø og gemmer deres arbejde i et Git-lager. Den ydre løkke består af et testmiljø og et produktionsmiljø. En build-pipeline tager den versionsstyrede løsning, udfører de nødvendige kontroller og opretter en artefakt af typen Inspektionsløsning. En frigivelsespipeline udruller derefter løsningen til test, hvor testere kan bekræfte, at den er klar til produktion. Når løsningen er godkendt, udruller den den til produktion.

Når du eksporterer en løsning fra Dataverse, eksporteres den som en enkelt komprimeret fil. Hvis du vil gemme ressourcerne med lav kode i versionsstyring, kan du bruge byggeværktøjet til at pakke løsningsfilen ud i individuelle komponentfiler. Under buildautomatisering kombinerer byggeværktøjerne individuelle filer fra versionskontrol til en enkelt komprimeret fil.

Udrulning af en løsning i et miljø, der indeholder en tidligere version af løsningen, bruger en intelligent opgraderingsproces, der kun anvender ændringer. Med denne opgraderingsproces undgår du behovet for forskellige scripts eller andre måder at bestemme, hvad der skal installeres.

Når det moderniserede program indeholder ressourcer med lav kode og traditionel kode, kan du kombinere dem i en enkelt CI/CD-proces eller administrere dem uafhængigt. Med uafhængig administration kan ressourcer implementeres individuelt, og projektteams kan opnå større fleksibilitet. Den API, som et program med lav kode bruger, kan f.eks. udrulles uafhængigt, hvis teamet ikke introducerer ændringer, der bryder funktionaliteten.

Overvågning og indsigt

Moderniserede programmer skal integreres i driftsmiljøer, der giver mulighed for at diagnosticere problemer på tværs af forskellige miljøer, fra udvikling til produktion. Application Insights, en Azure Monitor-udvidelse indsamler telemetri fra Power Apps og Dataverse. Disse oplysninger hjælper ikke kun med at identificere og løse problemer, men giver også indsigt i, hvad brugerne gør i et program. Du kan bruge denne indsigt til at forbedre apps og processer i dit moderniserede program.

Mens et Power Apps program er under udvikling, kan udviklere inkludere logik til at logføre brugerdefinerede hændelser. Når du har tilsluttet det installerede program Application Insights, indsamler udvidelsen automatisk grundlæggende telemetri, herunder mere kontekst fra logførte hændelser, når brugerne interagerer med programmet.

Administratorer kan også konfigurere Dataverse-miljøer, til hvilke telemetri skal eksporteres til Application Insights. Data, der logføres, kan omfatte Dataverse API-kald, plug-in-kørsel, SDK-handlinger og undtagelser. Udviklere, der opretter brugerdefineret plug-in-logik, kan logge flere brugerdefinerede telemetridata direkte på Application Insights.

At bruge Application Insights på tværs af dine programmer kan gøre det nemmere at korrelere problemer med flere ressourcer. Driftsmedarbejdere kan oprette alarmer i Azure Monitor, der udløses, når der registreres et stort antal undtagelser. Regelmæssig analyse af dine moderniserede applikationer kan identificere tendenser, der kræver mere undersøgelse.

Konklusion

Dette whitepaper udforsker fordelene, strategierne og bedste praksis ved at modernisere ældre programmer med Microsoft Power Platform. Du har fået indsigt i og vejledning i at anvende Power Platform's lav kode funktioner for at sikre, at moderniseringsindsatsen som en del af din organisations digitale transformation lykkes.

Legacy-programmer giver mange udfordringer for organisationer. For at overvinde dem skal organisationer gå i gang med applikationsmoderniseringsinitiativer for at genoplive deres infrastruktur og drage fordel af moderne teknologier. I dette whitepaper så du, hvordan du kan bruge en low-code-tilgang i moderniseringsarbejdet – nærmere bestemt hvordan udviklingsfunktionerne Microsoft Power Platform med lav kode giver dig mulighed for hurtigt at bygge og udrulle moderne programmer.

Lav kode åbner døren for et bredere sæt mennesker end traditionelle kodere. En vigtig faktor for organisationer, der har succes med en fremgangsmåde med lav kode, er at sikre, at de personer, der er involveret i modernisering af programmer, har oplæring i udvikling med lav kode, uanset om de er professionelle udviklere eller forretningsbrugere. Erhvervsbrugere er tættere på det forretningsproblem, der løses, og kan bidrage med tidsbesparende ekspertise. Traditionelle kodeudviklere kan anvende de teknikker og færdigheder, de allerede har, til at bygge udvidelser for at udfylde eventuelle huller med lav kode. Organisationer kan være mest effektive ved at blande forretningsmæssige og tekniske ressourcer på det, vi kalder "fusionsteams".

Dette whitepaper danner grundlaget for dig. De næste trin er dine. Her er nogle forslag:

• Brug et par minutter på at finde ud af, hvad din organisation allerede gør med low-code. Det kan overraske dig!
• Evaluer dine muligheder for applikationsmodernisering.
• Identificer og prioriter en god første kandidat.
• Bemand et team, der moderniserer applikationen. For at få de bedste resultater skal du sørge for, at det er et fusionsteam.
• Sørg for, at teamet har den nødvendige træning for at få succes.
• Tillad teamet at modernisere applikationen.
• Reflektere over moderniseringsindsatsen. Finjuster og skaler det til andre ældre applikationer.

Enhver organisations rejse til applikationsmodernisering er unik. Dit Microsoft kontoteam eller din Power Platform-partner kan hjælpe dig med at planlægge din rejse og holde dig på rette vej undervejs.

Ressourcer

• Den samlede økonomiske konsekvenser™ af Microsoft Power Platform Premium Capabilities
• American Airlines ConnectMe-app skaber en mere problemfri rejseoplevelse for kunderne og bedre teknologiværktøjer til teammedlemmer
• Power Fx open source-repositorium på GitHub
• CoE-startpakke
• Power Platform-indføringsvurdering
• Digitalt forsikringsagentur automatiserer en kompleks indkøbsproces ved hjælp af Power Platform
• PCF-galleri
• EY hjælper med at gøre det muligt at indtastning ved kilden for en global finansproces ved at Power Platform reducerer gennemløbstiderne med 95 procent
• Azure Private Link
• Microsoft Azure ExpressRoute
• Power Platform-udgivelsesplanlægger
• Vejledning om licenser til Microsoft Power Platform
• Microsoft skitserer rammer for opbygning af AI-apps og copilots; udvider AI-plugin-økosystem