Modernisering av programmer med Power Platform

I dagens raskt utviklende digitale landskap står organisasjoner overfor den konstante utfordringen med å modernisere sine eldre programmer for å holde tritt med skiftende forretningsbehov. Modernisering av programmer er avgjørende for å forbedre driftseffektiviteten, forbedre kundeopplevelsene og holde seg foran konkurrentene. Microsoft Power Platform tilbyr en omfattende pakke med verktøy og teknologier som gir bedrifter mulighet til å transformere og modernisere programmene sine raskt og effektivt.

Dette tekniske dokumentet utforsker fordelene, strategiene og anbefalte fremgangsmåter ved modernisering av programmer med Microsoft Power Platform. Den gir innsikt og veiledning om hvordan lavkodeplattformen Microsoft kan hjelpe deg med å sikre at programmoderniseringsarbeidet lykkes som en del av organisasjonens digitale transformasjon.

Tips

Du kan lagre eller skrive ut dette tekniske dokumentet ved å velge Skriv ut fra nettleseren og deretter velge Lagre som PDF.

Innledning

Eldre applikasjoner gir mange utfordringer for organisasjoner. Disse programmene er ofte bygget på utdaterte teknologistabler og rammeverk, noe som gjør dem vanskelige å integrere med moderne systemer og verktøy. De har ofte skalerbarhet og ytelsesbegrensninger som hindrer en organisasjons evne til å håndtere økende arbeidsbelastninger og kundekrav. Eldre programmer mangler fleksibilitet og smidighet, noe som begrenser deres evne til å tilpasse seg raskt til endrede forretningsbehov og markedsdynamikk. Sikkerhetsproblemer, høye vedlikeholdskostnader, begrensede integreringsmuligheter og risikoen for leverandøravhengighet forsterker utfordringene med eldre programmer ytterligere. For å overvinne dem må organisasjoner modernisere programinfrastrukturen for å dra nytte av ny teknologi.

Funksjonene for lavkodeutvikling i Microsoft Power Platform gjør at du kan bygge og distribuere moderne programmer raskere og mer kostnadseffektivt enn noensinne. Integrer enkelt eksisterende systemer og datakilder for sømløs datautveksling og samarbeid. Legg til kunstig intelligens for å forbedre brukeropplevelser, automatisere prosesser og få verdifull innsikt fra dataene dine. Enten du er en selvlært utvikler som flikker i kantene eller en profesjonell utvikler som jobber med en kompleks tilpasning, kan du drive digital transformasjon intuitivt, raskt og til lavere kostnad enn med tradisjonelle tilnærminger.

Hvorfor Power Platform?

De omfattende verktøyene og teknologiene som utgjør Power Platform, reduserer dramatisk lengden, kostnadene og utviklingskravene til modernisering og digitale transformasjonsprosjekter. Lavkodetilnærmingen reduserer – og kan til og med eliminere – behovet for dyre ressurser for koding, datavitenskap og KI-utvikling. Både selvlærte utviklere og profesjonelle utviklere drar nytte av det. Selvlærte utviklere kan ta en aktiv rolle i moderniseringsprosessen, bygge programmer direkte basert på deres domeneekspertise og redusere avhengigheten av IT-team. Profesjonelle utviklere kan levere selv komplekse løsninger på langt kortere tid, og frigjøre dem til å gå videre til neste prosjekt raskere.

Power Platform-produkter og -konsepter

Hvert produkt i Power Platform-familien har et unikt fokusområde. Organisasjoner kan implementere produktene enkeltvis eller i kombinasjon for å oppfylle deres spesifikke krav. Produktene er sammenkoblet og danner en sømløs helhet, uansett hvordan de kombineres.

Tabellen nedenfor gir en oversikt på høyt nivå over hvert Power Platform-produkt.

Product	Description
Power Apps	Opprett egendefinerte programmer på et intuitivt flytt-og-slipp-lerret. Med mer enn tusen koblinger er interne og eksterne datakilder og tjenester bare noen få klikk unna. Appene kan kjøres i en nettleser, på skrivebordet eller på mobilenheter.
Power Automate	Bygg arbeidsflyter for å automatisere selv komplekse prosesser. Innlem interne og eksterne datakilder og tjenester ved hjelp av innebygde og egendefinerte koblinger. Bruk digital prosessautomatisering (DPA) når programmer har et programmeringsgrensesnitt (API). Bruk robotautomatisering (RPA) til å automatisere gjentakende oppgaver som utføres i en nettleser eller skrivebordsapp. Utløs arbeidsflyter for å kjøre dem når hendelser inntreffer i andre systemer og tjenester, eller planlegg dem for kjøring på et bestemt tidspunkt.
Copilot Studio	Oppretting av samtaleagenter ved å bruke et grafisk grensesnitt uten kode. Du kan distribuere agenter til flere kanaler, inkludert nettsteder, mobilapper og meldingsplattformer som Microsoft Teams. Assistert redigering med kunstig intelligens kan gjøre opprettingen av emner raskere. Generative svar kan finne og presentere informasjon fra flere kilder uten at det kreves oppretting av emner.
Power BI	Dra diagrammer, tabeller og andre visualobjekter til et lerret for enkelt å opprette avanserte rapporter som avdekker innsikt som er låst i dataene. Inkluder automatisert maskinlæring for prediktiv modellering og KI-visualiseringer med nedbrytingstrær for detaljerte drilldowns for årsaksanalyse. Utforsk dataene dine ved å stille spørsmål på naturlig språk i et enkelt spørsmål og svar-format.
Power Pages	Bygg attraktive og datadrevne nettsteder raskt på en sikker, SaaS-lavkodeplattform (plattform som tjeneste) i foretaksklassen. Med omfattende, tilpassbare maler og en flytende visuell opplevelse er det enklere å opprette, være vert for og administrere moderne eksterne forretningsnettsteder.

Power Platform-produktfamilien baserer seg på noen få støttefunksjoner og -konsepter. Tabellen nedenfor beskriver de viktigste du må forstå.

Konsept	Description
Power Fx	Power Fx er et lavkodespråk med åpen kildekode inspirert av Excel-formler. Power Fx er typesikkert, deklarativt og funksjonelt, med imperativ logikk og tilstandsstyring, uttrykt i menneskevennlig tekst, noe som gjør vanlige programmeringsoppgaver enkle både for selvlærte utviklere og profesjonelle utviklere. Det støtter hele spekteret av utviklingsformer, fra kodeløs utvikling for de som aldri har programmert før, til prokodeutvikling for den erfarne eksperten, slik at ulike team kan samarbeide og spare tid og utgifter.
Koblinger	Koblinger er avgjørende for at lavkodebasert og tradisjonell koding skal fungere sammen for å levere moderne apper. Koblinger er en wrapper rundt en API som tillater at Power Apps og Power Automate bruker interne og eksterne datakilder og tjenester. Mer enn tusen forhåndsbygde koblinger er tilgjengelige, og du kan lage dine egne for enhver RESTful API. Koblingsdefinisjonen inneholder de nødvendige metadataene for å gjøre API-en enkel å bruke for lavkodeapper.
Dataverse	Dataverse er et hybrid datalager i skyskala utviklet på Azure-databehandlingstjenester, men det er mer enn en database. Det er den underliggende dataplattformen både for Dynamics 365 og Power Platform, med logikk på serversiden i form av arbeidsflyter og programtillegg, forretningsregler og prosessflyter, en svært sofistikert sikkerhetsmodell og en utvidbar utviklingsplattform med innebygd støtte for apper på flere språk og flere valutaer. Programmer kan raskt konstrueres fra datamodellen, noe som gjør det til en av de raskeste måtene å distribuere en form-over-data-løsning på.
AI Builder	AI Builder gjør det enkelt å bruke kunstig intelligens i Power Apps og Power Automate for å finne innsikt i dataene dine, automatisere prosesser og gjøre appene dine mer produktive. Med AI Builder trenger du ikke kodings- eller datavitenskapsferdigheter for å få tilgang til kraften i kunstig intelligens. Forhåndsbygde, tilpassbare modeller er nøkkelferdige for mange vanlige forretningsscenarioer, og du kan bygge dine egne modeller for å dekke et bestemt forretningsbehov.
Copilot	KI-hjelp for Copilot gjør Power Platform-brukere og -utviklere, både selvlærte og profesjonelle, mer produktive, slik at de kan bruke mer tid på de beste delene av jobbene sine og mindre tid på dagligdagse oppgaver. Beskriv forretningsscenarioet ditt til Copilot i Power Automate, så kan den gjøre om beskrivelsen din til en automatisert arbeidsflyt. Fortell Copilot i Power Apps hva du vil gjøre eller hvilken informasjon du vil se, og den kan bygge en app for dette. Copilot konfigurerer tilkoblinger, oppretter og fyller ut tabeller, genererer skjermer og tilbyr til og med forslag for å gjøre flyten eller appen bedre. Appene dine vil ha kopilotdrevne opplevelser innebygd fra den første skjermen, slik at brukerne kan oppdage innsikt gjennom samtaler.
Miljøer og løsninger	Miljøer er grenser som inneholder og gjør det enklere å administrere og sikre Power Platform-ressurser. De brukes også i administrasjon av applivssyklus, der løsninger utvikles og testes i separate miljøer før de rulles ut til et produksjonsmiljø. Løsninger er pakkede Power Platform-tilpassinger og -utvidelser. En løsning kan inneholde apper, flyter, tabeller, diagrammer, instrumentbord, koblinger og andre komponenter som tilpasningen eller utvidelsen trenger. Løsninger kan utvikles, testes og rulles ut til produksjon i separate miljøer som en del av organisasjonens policy for administrasjon av applivssyklus. Du kan eksportere løsninger for å dele dem med andre brukere eller organisasjoner og importere løsninger fra andre. Løsninger er enten administrerte eller uadministrerte. Uadministrerte løsninger brukes til utvikling og testing. Administrerte løsninger brukes til produksjonsutplassering og distribusjon.

Viktige fordeler med Power Platform for modernisering av apper

Fordelene ved å modernisere programmer ved bruk av Microsoft Power Platform strekker seg utover den opprinnelige forretningsverdien av å ha en løsning som bruker moderne teknologi.

• Lavere kostnader. Organisasjoner kan spare penger på apputvikling og vedlikehold. En bestilt studie av Forrester Consulting fant at organisasjoner som bruker Power Platform, kan oppleve 45 prosent reduksjon i kostnadene til programutvikling og realisere 140 % avkastning på investeringen.

• Utvid ressursutvalget og eliminer flaskehalser. Profesjonelle utviklere, dataforskere og KI-ingeniører er høyt betalte – og etterspurt. Små og mellomstore organisasjoner har ofte ikke luksusen av intern kodingskompetanse, og outsourcing er dyrt. Den lavkodebaserte Power Platform er mer tilgjengelig for et større utvalg av ressurser. Fageksperter og ansatte med ekspertise for forretningsprosesser kan bidra til å akselerere moderniseringsarbeidet, selv om de aldri har skrevet en kodelinje.

• Bygg vognen, ikke hjulet. Tradisjonell programvareutvikling starter friskt hver gang, og finner opp hjulet på nytt med hvert nye prosjekt. Med intuitive, produsentvennlige Power Platform-produkter med lavkode som hjulene dine kan du fokusere på å bygge en bedre vogn – forbedre forretningsprosessene dine – og nyte fordelene av moderniseringsarbeidet raskere.

• Reduser teknisk gjeld. Kostnadene – både økonomisk og i tapte muligheter – ved å oppgradere «raske og skitne» programvareløsninger og vedlikeholde eldre infrastruktur er høye. Power Platform reduserer denne tekniske gjelden ved å gjøre det enklere og billigere å bygge løsninger på riktig måte første gang, forenkle dataintegrering og -styring med en felles datamodell og koblinger, gi en sentralisert plattform for administrasjon av løsninger og støtte kontinuerlig forbedring med analyse og kunstig intelligens.

• Forbedre sikkerheten og sørg for samsvar. Alle Power Platform-produkter inkluderer fullt integrert sikkerhet, innebygd samsvar og styring i foretaksklassen, og de starter med miljøene de kjører i. Administrerte miljøer er en pakke med verktøy som administratorer kan bruke til å administrere Power Platform i stor skala, med mer kontroll og mindre innsats. Du kan blant annet begrense hvem som kan dele hvilke flyter og apper, og med hvem, og bruke policyer til å begrense koblingene utviklere kan bruke. Opprinnelige, fleksible datasikkerhetsmodeller betyr at hver applikasjon ikke trenger å bygge sin egen.

• Moderniser på farten. Jo mer signifikante apper du vil modernisere, jo mindre sannsynlig er det at du ønsker å erstatte alle samtidig. En lavkodebasert tilnærming egner seg godt til å bygge løsninger i håndterbare trinn.

• Integrer eldre apper. Eldre programmer har ofte ikke API-er. RPA-funksjonene i Power Platform kan automatisere klassiske apper og inkludere dem i nye, moderne forretningsprosesser. RPA kan også være nyttig ved trinnvis modernisering av store og komplekse apper.

• Innover uten å bruke mer. Power Platform-funksjonene blir stadig bedre. Apper bygget på plattformen drar nytte av Microsoft-innovasjoner uten at det koster deg mer.

• Øk de ansattes produktivitet på en moderne arbeidsplass. Power Platform er en del av den moderne Microsoft-arbeidsplassen. Programmer som er modernisert på plattformen, kan dra nytte av mulighetene i Microsoft 365, blant annet engasjerende mobilopplevelser og enkelt, intuitivt samarbeid. Banebrytende kunstig intelligens, som for eksempel Copilot, AI Builder og funksjoner som snart blir kunngjort, gjør brukere og utviklere mer produktive med mindre frustrasjon og flatere læringskurver.

Innovasjon for frontlinjearbeideren

Frontlinjearbeidere trenger moderne programmer de kan bruke på en hvilken som helst enhet, uansett hvor de arbeider. De trenger tilgang til innsikt i sanntid for å ta bedre beslutninger raskere. De må samarbeide med kolleger og ledelse for å få alt til å fungere problemfritt. Da American Airlines bestemte seg for å modernisere deler av sin virksomhet, fikk de alt dette og mer.

I partnerskap med Microsoft skapte American Airlines ConnectMe, en Microsoft Teams-app utviklet på Power Apps og Azure. Ved å bruke appen på en hvilken som helst mobil enhet, har frontlinjeteamene viktig informasjon om ankomst, ombordstigning, bagasje og gate lett tilgjengelig i sanntid, noe som effektiviserer bakkeoperasjoner, akselererer flyets svingtider og gjør reisen til en mer behagelig opplevelse for kundene. Lær mer om flyselskapets transformasjon.

Styrking av kunstig intelligens for kunnskapsarbeidere

Kunnskapsarbeidere svømmer i et hav av data – og altfor ofte føler de at de drukner. Nesten alle programmer samler inn data. Få av dem hjelper brukerne med å forstå dataene de samler inn, enn si hente ut innsikt som kan hjelpe arbeidstakere med å gjøre jobben sin bedre. KI-funksjoner kan legges til apper som en del av moderniseringen, ikke bare automatisere datainnsamling og analyse, men også gjøre det enklere for kunnskapsarbeidere å oppdage mønstre og trender. Prediktiv analyse kan bruke modeller for kunstig intelligens til å forutsi fremtidige resultater basert på historiske data med høy nøyaktighet, slik at ledere kan planlegge med trygghet. Moderniserte apper kan inkludere kunstig intelligens for kopilot, som fungerer som en partner for å generere innhold i kontekst – oppsummere intervjuer, utarbeide målrettede markedsførings- og salgsmeldinger og til og med tilby nyttig informasjon i sanntid mens en kundeservicerepresentant eller selger er på telefonen med en kunde.

En trinnvis reise for å modernisere eldre apper

Hvis organisasjonen din er som de fleste andre, har du en økende opphopning av utdaterte programmer som kan dra nytte av modernisering. Eldre programmer bruker vanligvis foreldet teknologi og er bygd på infrastruktur – maskinvare og programvare – som ikke lenger støttes. Ofte er det bare noen få ansatte, vanligvis de som nærmer seg pensjonsalder, som vet hvordan de jobber. Nyansatte vil ikke ha noe med dem å gjøre fordi de ikke kan bruke de moderne verktøyene de er vant til eller ønsker å jobbe med. Å vedlikeholde dem, for ikke å snakke om å oppdatere dem, krever skalering av et fjell av teknisk gjeld som vokser høyere jo mer du klatrer. År, kanskje tiår, med vedlikehold av lappetepper resulterer i en kodebase som ingen tør røre ved – spesielt når store deler av virksomheten er avhengig av den.

Organisasjoner kan ofte ikke enkelt erstatte alle disse programmene samtidig. I stedet legger de ut på en trinnvis moderniseringsreise. En trinnvis tilnærming maksimerer fordelene ved modernisering, samtidig som den reduserer noen av risikoene ved en engangs moderniseringsinnsats.

Alternativer for modernisering av apper

Modernisering betyr ikke alltid å gjenoppbygge en eldre app fra grunnen av. Andre alternativer er å pensjonere den, erstatte den, rehoste den, refaktorere den og rearkitektere den.

Tabellen nedenfor beskriver hvert alternativ, ALM-fasen når det passer best, og drivere som kan påvirke valget.

Slutten på levetiden

Overføring

Modernisering

Trekk tilbake

Replace

Rehosting

Refaktorering

Endre arkitektur

Bygg på nytt

Bekrivelse

Fjern app

Erstatt app med SaaS eller en annen app

Distribuer på nytt som den er til skyen

Optimaliser eksisterende kode

Flytt kode til en ny programarkitektur eller del den opp i mikrotjenester

Skriv om appen fra bunnen av med originalt omfang og spesifikasjoner

Drivere

Ikke lenger nødvendig

Reduser utgifter

Reduser kapitalkostnader

Dra nytte av nyere teknologi

Reduser kapitalkostnader

Gjenopprett datalagring

Rask skyavkastning

Raskere, kortere oppdateringer

Mer bærbar kode

Større skyeffektivitet i ressurser, hastighet, kostnad

Forbedre ytelsen

Reduser teknisk gjeld

Forbedre skalerbarhet, pålitelighet og vedlikehold

Forenkle innføringen av nye skyfunksjoner

Bland teknologistabler

Fremskynd innovasjon

Få fart på utviklingen

Reduser driftsutgifter

Microsoft-teknologi

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

Beholdere

Azure PaaS

Power Platform

Azure PaaS

Serverløse mikrotjenester

Power Platform

Azure PaaS

Serverløse mikrotjenester

Tabellen nedenfor foreslår måter som en lavkodetilnærming kan brukes på hvert av alternativene for appmodernisering.

Alternativ	Description
Rehosting	Rehosting flytter en app som den er, fra et eldre miljø til et nyere. En lavkodetilnærming virker ikke inn direkte, men rehosting kan være det første trinnet før du bruker andre strategier som inkluderer lavkodeløsninger.
Refaktorering eller rearkitektering	Refaktorering justerer koden slik at apper kan få mest mulig nytte av et sky-først-miljø. Ny arkitektur endrer koden betydelig. Det kan omfatte innkapsling av eksisterende logikk ved å flytte den til en API som kan eksponeres for lavkodeløsninger gjennom en kobling.
Erstatt eller bygg på nytt	Når du bytter ut, byttes en app med en annen. Gjenoppbygging gjenskaper en app fra grunnen av. Dette alternativet er vanligvis der en lavkodebasert tilnærming oppnår de beste forretningsresultatene. Start med et program fra Dynamics 365 eller Microsoft AppSource, som kan bidra til å komme godt i gang med modernisering når brukstilfellet samsvarer med en forhåndsbygd funksjon. Organisasjoner kan deretter bruke Power Platform-komponenter til å tilpasse appen etter deres unike behov.

Lavkodetilnærmingen i Power Platform har potensial til å tilby mye mer enn bare et annet utviklingsverktøy. Å gjøre lavkode til en del av den moderne appstrategien kan også danne et grunnlag for å gi ikke-utviklere som fageksperter mulighet til å delta i moderniseringsarbeidet. Organisasjoner har funnet ut at etablering av et Center of Excellence (CoE) rundt Power Platform og bruk av verktøy som CoE-startpakken for å opprette retningslinjer og styring, hjelper brukere med å bygge lavkodeapper og automatiseringer på en vellykket måte, og sikrer at ressurser som API-er og komponenter kan brukes på nytt. Lavkode kan akselerere programutvikling og hjelpe organisasjoner med å trekke ut verdi fra dataene raskere, uavhengig av hvor de befinner seg. Faktisk bestemmer mange organisasjoner seg for å integrere et lavkodebasert tankesett i kulturen.

En veiledning til din moderniseringsreise

Det er lett å bli overveldet når du begynner å tenke på å modernisere eldre apper. En veiledning kan hjelpe deg med å planlegge reisen og holde deg på rett vei underveis. Et godt sted å starte er med disse tre trinnene, og vurderer hver enkelt med en lavkode-tankegang.

1. Planlegging. Tenk nøye gjennom målene dine for å modernisere et eldre program, og definer strategien din for å nå dem. Ha en klar uttalelse av problemet du vil at modernisering skal løse. Dette er tiden for å vurdere appene og miljøene dine med tanke på hva som ikke fungerer, hva som fungerer, men som kan forbedres, og – viktigst av alt – hvilken verdi, for bedriften eller brukerne, som følger av eventuelle endringer. Evaluer hver moderniseringsmulighet for potensialet til å dra nytte av en lavkodetilnærming. Prioriter muligheter som innlemmer lavkodeløsninger. Bruk Cloud Adoption Strategy Evaluator til å bygge en forretningssak for modernisering av programmer.

2. Implementering. Moderniser appene dine ikke bare trinnvis, men iterativt. En iterativ tilnærming gir organisasjoner fleksibilitet til å endre prosjektomfang eller strategi etter behov. Power Platform-lavkodeløsninger kan utvikles og testes raskere enn tradisjonelt utviklede apper, og distribusjon i administrerte miljøer krever bare noen få trinn. Selv om lavkode krever mindre opplæring enn tradisjonell koding, må du sørge for at de ansatte har riktig opplæring i hvordan de skal jobbe som fusjonsteam, som blander lavkodebaserte og tradisjonelle ressurser.

3. Drift. Appmodernisering stopper ikke ved implementering. Med en lavkodebasert skybasert tilnærming kan du bruke skyplattformtjenester og -verktøy til å sikre, styre, administrere og optimalisere appene dine.

Evaluer mulighetene for lavkodeløsninger

Organisasjoner bruker ulike metoder, fra uformell gjennomgang til detaljerte beslutningstrær, for å avgjøre om en lavkodetilnærming er den riktige måten å modernisere en eldre app på. Det viktigste å vurdere er at lavkode ikke er en alt-eller-ingenting-beslutning. Det er vanlig å bygge en del av et program ut av Power Platform-komponenter og deler av det ut av komponenter utviklet ved hjelp av tradisjonelle kodingsteknikker.

For å evaluere et program anbefaler vi at du først finner ut om det fortsatt er nødvendig og nyttig eller bør trekkes tilbake. Hvis du bestemmer deg for at det fortsatt er nødvendig, kan du vurdere om en lavkodeløsning kan erstatte appen som helhet. Hvis hele appen ikke passer for en lavkodeerstatning, kan du vurdere om én eller flere av appens arbeidsbelastninger eller komponenter kan være det. Det kan hende at en lavkodeløsning utvidet med tradisjonelt utviklet kode gir det beste fra to verdener.

Hvis du for eksempel finner ut at et program ikke passer fordi Power Apps mangler en nødvendig kontroll, kan du bruke Power Apps component framework (PCF) og tradisjonell kode til å bygge en egendefinert kontroll. Et annet eksempel er en app som har kompleks logikk. Du kan sentralisere logikken i en API som Power Apps kan få tilgang til, ved hjelp av en egendefinert kobling. I begge disse eksemplene gjorde utvidelsesmuligheter i Power Platform det mulig å bygge mesteparten av appen med lavkodekomponenter, og tette hullene med tradisjonelt utviklet kode.

NSure.com, en rettighetsbeskyttet plattform for kjøp av forsikringer på nettet, tilbyr et eksempel fra den virkelige verden. Selskapets første lansering var avhengig av tradisjonelt utviklede Angular-, Xamarin- og Azure-tjenester. Ved å legge til Power Platform og Dynamics 365, opprettet NSure.com en neste generasjons løsning ved hjelp av både lavkodebaserte og tradisjonelle kodingsteknikker, som følgende diagram illustrerer. Finn ut mer om selskapets reise.

Like viktig som å identifisere lavkodemuligheter er å gjenkjenne når en lavkodetilnærming ikke er den rette. Tabellene nedenfor beskriver brukstilfeller som vanligvis ikke passer for lavkodeløsninger. Organisasjoner står overfor forskjellige utfordringer på frontend og backend, så la oss vurdere dem separat.

Frontscenarioer som ikke passer inn i en lavkodebasert tilnærming

Scenario	Utfordring
Brukerenheten er ikke kompatibel	Power Platform gjenkjenner mobilenheter og spesialiserte enheter, som strekkodeskannere. Enheter som er avhengige av bestemte API-er eller drivere, støttes kanskje ikke, og krever en mer tradisjonell tilnærming.
Stort volum av data på klientsiden	Brukeropplevelsen i noen applikasjoner krever store mengder data, en utfordring for enhver teknologi, ikke bare lavkode. Nedlasting og behandling av så mye data kan stresse back-end-systemer og redusere ytelsen til både appen og enheten den kjører på. Brukere er ikke like produktive når de blir tvunget til å navigere i et hav av data. Før du går over til tradisjonelle kodingsmetoder for å håndtere belastningen, kan du undersøke om riktig filtrering og navigering kan gi en bedre brukeropplevelse.
Komplekse frakoblede krav	Programmer som må fungere på steder der tilkoblingen er dårlig eller ikke-eksisterende, kan være utfordrende å implementere og støtte, enten de bruker lavkode eller tradisjonell kode. Power Apps tilbyr grunnleggende funksjoner for enkle frakoblede scenarioer. En app som for eksempel fanger opp kundeemner under et arrangement og laster dem opp til en markedsføringsdatabase etter hendelsen, fungerer fint. For programmer som krever filer og bilder, ikke-Dataverse-koblinger eller kompleks konfliktløsning, bør du se på tradisjonelle kodeteknikker.

Serverdelscenarioer som ikke passer til en lavkodetilnærming

Scenario	Utfordring
Data med høy hastighet	Import av millioner av rader med data som en del av overføringer og lignende hendelser støttes vanligvis. Arbeidsbelastninger som involverer behandling av millioner av rader med data hver time eller daglig, bør imidlertid evalueres mer. Det er for eksempel ikke fornuftig å samle inn store mengder IoT-telemetri (Tingenes Internett) i Dataverse. I stedet kan Azure-skytjenester brukes til å samle inn og analysere dataene og relevante signaler legges til i Dataverse for å utløse handlinger i programmet. Programmer som involverer et stort antall oppdateringer av Dataverse-data regelmessig, kan trenge hjelp fra tradisjonell kode for å skalere oppdateringene.
Bakgrunnsarbeidsbelastninger med kompleks logikk	Bakgrunnsarbeidsbelastninger som involverer kompleks logikk eller et stort antall API-kall, er kanskje ikke riktig for en lavkodeløsning. I stedet kan logikken sentraliseres i en API som en lavkodeløsning kan kalle.
API-er som bruker ikke-RESTful-protokoller	Power Platform-koblinger støtter bare REST-API-er. Hvis du må koble til en annen type API, for eksempel SOAP eller gRPC, må du levere din egen REST API som kommuniserer med den inkompatible API-en.

Vi anbefaler at du holder deg oppdatert på Power Platform-lanseringsbølger fordi de fortsetter å tette hull i hva du kan gjøre med lavkodeløsninger. Oppretting av et lavkodebasert konseptbevis er en god måte å finne ut om scenarioet passer for deg.

Prioriter lavkodemuligheter

Når du evaluerer programporteføljen din, er det ikke nok å identifisere gode kandidater for lavkodetransformasjon. Teamet ditt må prioritere dem for å maksimere suksessen til moderniseringsarbeidet.

Prioritering bør vurdere følgende faktorer:

• Organisasjonens lavkodebaserte modenhet
• Mulighetens kompleksitet
• Avkastning for organisasjonen, brukerne og IT
• Tid til verdi

Det å være realistisk når det gjelder organisasjonens lavkodefunksjoner kan hjelpe deg med å velge en mulighet som utfordrer teamet ditt til å vokse, men som ikke overvelder dem til å mislykkes. Du trenger ikke å velge det enkleste programmet uten utfordringer. En ideell ville gi noen muligheter til å utforske hvordan man kombinerer tradisjonell kode med lavkodeløsninger.

Programmer med kompleks integrasjon med andre systemer er ofte ikke det beste stedet å starte. Å prøve å takle programmer som er for store eller for komplekse kan føre til frustrasjon og fiasko. Unngå alle som er tvilsomme lavkodekandidater. Lagre dem til etter at teamet ditt har fullført noen vellykkede moderniseringer.

Når du moderniserer en stor, monolittisk app, bør du vurdere om du kan modernisere små deler av den trinnvis. Monolitiske programmer pleide å være vanlige. Nå er mindre rolle- eller oppgavefokuserte apper mer vanlige. De gir mulighet for trinnvis utvikling og forbedringer og skalering av teamene som bygger dem.

De første moderniseringene er viktige fordi de lar organisasjonen se virkningen av lavkodeløsninger. Det er viktig å evaluere fordelene og risikoene for interessentene i en app når du prioriterer muligheter. Å velge et program som ingen bryr seg om eller har liten innvirkning på organisasjonen, vil ikke være den beste demonstrasjonen av fordelene med en lavkodeløsning.

Brukeradopsjon av det moderniserte programmet er viktig. Brukere må føle at det nye lavkodeprogrammet passer sammen med resten av programmene de bruker. En annen risiko for adopsjon er graden av tilpasning de er vant til. Hvis de forventer en svært spesialbygd opplevelse, kan de være mindre tilbøyelige til å ta i bruk en lavkodeløsning som føles mindre personlig.

Organiser og øk kompetansen til teamene dine

Organisasjoner som lykkes med å modernisere eldre apper, tildeler ikke bare et moderniseringsprosjekt til et team av tradisjonelle kodeutviklere og håper de lykkes. Det er viktig å gi teamet kunnskapen og tryggheten i lavkodeutviklingen de trenger for å fullføre moderniseringsarbeidet.

Et team med lavkoderessurser som arbeider sammen med tradisjonelle koderessurser, kalles et fusjonsteam. Fusjonsteam er utformet for å oppmuntre til samarbeid ved å trene begge typer ressurser på integrering av lavkodeløsninger med tradisjonell kode. En løsningsarkitekt fastsetter hvordan løsningen er utformet mellom lavkode og tradisjonell kode.

Selv om det er enkelt å tildele alt arbeidet til tradisjonelle utviklere som standard, er lavkodemoderniseringstiltak gode muligheter til å utvide prosjektteamet. Mange forretningsbrukere er utmerkede lavkoderessurser. De kan akselerere teamets arbeid fordi de allerede forstår forretningsproblemet. De trenger bare å lære å fullføre de typer lavkodearbeid teamet tar på seg og være kjent med testing og ALM-prosedyrer. Det kan bety å lære å bygge apper i Power Apps eller arbeidsflyter i Power Automate. De bør også forstå hva tradisjonelle kodere kan utvikle for å gjøre lavkodeinnsatsen enklere. Dette betyr ikke at de trenger å vite hvordan de skal skrive tradisjonell kode.

Tradisjonelle koderessurser må ha grunnleggende kunnskap om lavkodetilnærminger og hvordan disse skiller seg fra koden de vanligvis skriver. Det viktigste er at de må lære seg utvidelsesmulighetene til lavkodeløsninger. De bør være komfortable med å opprette en testapp eller flyt som bruker kode de skriver, for å sikre at den fungerer, og for å være klare til å støtte lavkoderessurser når de bruker ressursene for utvidelsesmuligheter.

Både lavkodebaserte og tradisjonelle koderessurser må forstå hvor lavkodeløsninger og tradisjonelle kodeløsninger begynner og slutter, og hvor de krysser hverandre.

Samle inn krav

Det kan hende du finner ut at du har apper som er ti år eller eldre og ikke dokumentert. De kan kreve omvendt utvikling eller forretningsbrukerkunnskap for å gjenskape. Det er viktig å huske at selv om en lavkodebasert tilnærming er effektiv, gjør den ikke innsamling av krav og kunnskap om forretningsprosesser raskere eller komplekse krav mindre komplekse. Ofte er det en urealistisk forventning at et team som moderniserer en app, oppnår like mye som et team som bygger en ny app med lavkode. Etabler organisasjonens forventninger med disse utfordringene i tankene.

To tilnærminger kan bidra til å akselerere arbeidet med å få kunnskap om en eldre app. Først utvider du teamet til å omfatte forretningsbrukere med domenekunnskap. For det andre, fokuser på å forstå forretningsprosessen og det ønskede resultatet i stedet for å dokumentere hvordan den er implementert i det gamle systemet. Unntaket til dette er hvis det gamle programmet krever spesialisert logikk som utfører forretningsregler som du må følge.

Unngå å arbeide mot lavkodetilnærminger

Organisasjoner som moderniserer programmer med lavkodeløsninger, gjør ofte den feilen at de utvikler lavkode på samme måte som de utvikler tradisjonell kode. En organisasjon kan for eksempel bruke UX-standarder skrevet for Angular-apper på den første Power Apps-implementeringen. Prosjektgruppen ville bruke unødvendig tid på å prøve å oppfylle standarder som var utformet for Angular framework-funksjoner og ikke forretningsbehov.

Team som er vant til å arbeide med tradisjonell kode, kan prøve å minimere lavkode. I stedet for å bruke Power Apps-kontroller kan teamet for eksempel bygge et program ut av Power Apps Component Framework-kontroller for å unngå å bruke lavkode så mye som mulig. Det er best for team å komme så langt de kan med lavkode til de treffer blokkeringer som ikke kan omgås. Team som lærer å dra nytte av plattformens funksjoner, lykkes bedre med å oppnå maksimale fordeler med lavkode. Lavkode fortsetter å bli bedre i stand til å ta på seg det som pleide å være mulig bare med tradisjonell kode. En vanlig utfordring tidligere var å bli sittende fast fordi lavkode ikke kunne gjenskape noe nødvendig funksjonalitet. Power Platform løser denne utfordringen med utvidelsesalternativer som gjør at programmer som stort sett bruker lavkode, kan innlemme spesialiserte komponenter skrevet i tradisjonell kode når det er nødvendig.

Lavkodebaserte tilnærminger kan spille en viktig rolle i moderniseringsstrategiene dine. De beste resultatene krever en klar redegjørelse for problemet moderniseringsarbeidet er ment å løse, planlegging, bemanning som strekker seg utover standardroller, opplæring og prioritering. Å gjøre nødvendige justeringer av standarder og prosesser om nødvendig hjelper også organisasjoner med å realisere det fulle potensialet til lavkode. Modernisering gjort riktig bør forbedre den totale forretningsverdien av de moderniserte applikasjonene.

Lavkodeplattformer har utviklet seg raskt de siste årene. Selv om de alltid har vært gode til å støtte individuelle produktivitetsscenarier, har det siste fokuset vært på bedriftsfunksjoner. Organisasjoner bygger lavkodeprogrammer som støtter den moderne arbeidsplassen, inkludert hybridarbeid (eksternt og på stedet) og det medfølgende behovet for måter å oppmuntre til samarbeid på. Lavkodebaserte plattformer som Power Platform kan nå skaleres for å håndtere programmer som alle brukere i en organisasjon kan basere seg på, og som kan integreres i bedriftens sikkerhetsmodeller. Ved å koble lavkodefunksjoner til bedriftsinfrastruktur kan du bruke lavkodeteknikker side ved side med tradisjonelle metoder. Lavkode abstraherer mye av kompleksiteten og lar et bredere sett av mennesker delta i å bygge løsninger.

Forstå kostnadsstrukturen for en lavkodetilnærming

Et vanlig spørsmål som organisasjoner stiller når de vurderer en moderniseringsinnsats, er hvor mye vil det koste? Mens en fullstendig diskusjon av lisensiering og kostnadsanalyse er utenfor omfanget av denne artikkelen, kan vi utforske disse emnene på et høyt nivå.

Power Platform-produkter er lisensierte produkter. Du kan lisensiere dem individuelt for å matche dine krav. Du kan konfigurere Azure-fakturering for forbruksbetaling, som tillater bruk uten lisensforpliktelse eller -kjøp på forhånd, og inkluderer noe Power Automate-bruk i appen. Power Automate har også lisensiering per bruker og per flyt for frittstående arbeid. Lisensiering per flyt fungerer bra når du har automatisering som kommer hele organisasjonen til gode. Power Apps-lisenser kan være per bruker eller per app. Power Pages-nettsteder lisensieres per bruker, nettsted eller måned. En tilleggslisens kreves for godkjente nettsteder. Alle lisenser inkluderer bruk av koblinger og Dataverse, med mulighet til å lisensiere flere lagrings- og API-forespørsler for scenarioer med høyt volum.

Alle Power Platform-produkter har volumprising som vanligvis gjelder for modernisering av programmer, og som må evalueres for hver organisasjons unike strategi.

Når du vurderer kostnaden for lavkode sammenlignet med tradisjonell kode, er det viktig å innse at sammenligningen ikke er epler til epler. Med lavkode betaler du for arbeidet for å implementere en unik forretningsprosess i lavkodeproduktet og for at produktlisensen skal bruke den. Generelt inkluderer lisensen flere apper og automatiseringer uten at hver enkelt krever mer kostnad.

Med tradisjonelle kodingstilnærminger betaler du for arbeidskraften for å implementere en unik forretningsprosess i kode, arbeidskraften for å bygge appens infrastruktur og skytjenestene som trengs for å støtte appen.

Alle løsninger, enten de bruker lavkode eller tradisjonell kode, krever kontinuerlig vedlikehold. Lavkodeløsninger krever imidlertid færre ressurser for å gjøre det. De pådrar seg også mindre teknisk gjeld fordi app-infrastrukturen leveres av plattformen.

Sammenlignet med et helt tilpasset program som ikke er bygget på toppen av en lavkodeplattform, har en lavkodeløsning en mer forutsigbar kostnad. Unngå å falle i fellen med å sammenligne lavkodelisensiering med den opprinnelige kostnaden for tradisjonell kodedistribusjon.

En titt på innsiden av Power Platform

Power Platform-komponenter er bygd på de samme Microsoft Azure-skytjenestene som er tilgjengelige hvis du bruker tradisjonelle kodingsmetoder. Integreringen av disse komponentene med hverandre og med sikkerhets-, skalerbarhets- og katastrofegjenopprettingsfunksjoner er gjort for deg.

På innsiden av Dataverse

Dataverse drives av mer enn 25 totaladministrerte Azure-tjenester som funksjoner, belastningsfordeling, kognitive tjenester, Synapse, DevOps, Active Directory og Microsoft Purview. Innebygde funksjoner inkluderer omfattende sikkerhet, kraftig analyse, kunstig intelligens, avansert forretningslogikk og hendelseshåndtering, datamodellering og integrering med Dynamics 365, Microsoft 365, Azure og mer. Alle disse funksjonene er bygd på et polyglot Dataverse-lagringslag, som er basert på Azure SQL DB (for relasjonsdata), Azure Cosmos DB (for NoSQL), Azure Blob Storage (for filer) og Azure Data Lake Storage Gen 2 (for analyse i storskala og langsiktig dataoppbevaring). De er tilgjengelige for gjennomsiktig bruk i Power Platform-lavkodekomponenter og gjennom Dataverse REST-API.

Høy tilgjengelighet og forretningskontinuitet og katastrofeberedskap (BCDR) er viktig for forretningskritiske programmer. Dataverse maksimerer tilgjengeligheten med Azure-pålitelighetstjenester. Replikering av primære og sekundære servere er synkron, med en struktur under som kan oppdage feil og velge en ny primærserver etter korrekthetsprotokoller. Failover med høy tilgjengelighet, som forekommer i et Azure-område, er sømløst og blir sjelden lagt merke til av brukere, og skjer vanligvis i løpet av sekunder. De er garantert å ha null tap av data uavhengig av om strømbruddet er planlagt eller ikke planlagt.

Failover for nødgjenoppretting forekommer på tvers av to Azure-områder. For å sikre raskere failover med minimalt tap av data, opprettholdes en kontinuerlig kopi av nødgjenoppretting ved hjelp av asynkron replikering. Planlagte failovere medfører ingen tap av data, og for produksjonsmiljøer kan de vanligvis fullføres i løpet av sekunder eller noen få minutter.

I tillegg til den tekniske implementeringen av høy tilgjengelighet og BCDR, tester driftsteamet regelmessig sin beredskap til å reagere på ulike typer hendelser.

På innsiden av Power Automate

Power Automate-skyflyter er bygd på toppen av Azure Logic Apps. Power Automate gir abstraksjoner og integrering med andre lavkodekomponenter, som Power Apps, og bruker Logic Apps-kjøretidsmotoren. Utviklere som er kjent med Logic Apps, vil se at Power Automate bruker lignende konsepter, inkludert uttrykksspråket.

På innsiden av Power Apps

Power Apps-kjøretidsmotoren er utviklet på React-rammeverket. Programmer bygges i Power Apps-utformingen, som bruker et dra-og-slipp-grensesnitt for å bygge skjermer. Power Fx-formler implementerer logikk. Koblinger utvider appers tilgang til andre tjenester og logikk og komponenter som tillater gjenbrukbare visuelle utvidelser. Utviklere kan bruke Power Apps Component Framework (PCF) til å opprette egendefinerte kontroller. Mange UI-rammeverk kan brukes sammen med PCF, men Power Apps har innebygd støtte for React.

På innsiden av koblinger

Koblinger bruker Azure API Management til å behandle legitimasjon og tilkoblinger fra hver bruker.

Den samme arkitekturen brukes for alle koblinger, inkludert egendefinerte koblinger som du oppretter for dine egne API-er. Bruken av Azure API Management sikrer et konsekvent grensesnitt for Power Platform-produkter, som Power Apps og Power Automate, med alle koblinger.

Et unntak er Dataverse-koblingen. Den vises i listen over koblinger for apper og flyter, men den er implementert på en annen måte. Når en app eller en flyt bruker Dataverse-data eller -handlinger, foregår samhandlingen direkte gjennom OData API i Dataverse.

Alternativer for utvidbarhet i Power Platform

Utvidbarhet er en nøkkelfunksjon som skiller Microsoft Power Platform fra andre lavkodeplattformer. Et ledende prinsipp for plattformen er ingen klipper – du bør ikke blokkeres fra å oppnå noe ved hjelp av lavkode, selv om det krever tradisjonell kode. Du kan bygge en hel arbeidsbelastning som en del av en større app ved hjelp av tradisjonell kode om nødvendig. Plattformen tilbyr imidlertid mange utvidelsesalternativer som gjør at lavkode og tradisjonell kode kan brukes sammen i samme arbeidsbelastning.

Tabellen nedenfor gir en oversikt på høyt nivå over noen av de vanlige utvidelsesalternativene. Vi refererer til noen av dem igjen senere, når vi diskuterer hvordan du nærmer deg modernisering og mønstre som du kan bruke.

Alternativ	Description
API-er og egendefinerte koblinger	Egendefinerte koblinger for REST-API-ene sentraliserer applogikken og gjør at den kan eksponeres for lavkodekomponenter på en sikker og styrt måte. Du kan bruke denne tilnærmingen i en API-først-strategi for modernisering av programmer. Den egendefinerte koblingen bruker et OpenAPI-dokument til å definere hvordan en lavkodekomponent kan samhandle med REST-API. Du kan for eksempel opprette en API ved hjelp av Azure Functions og publisere den til Azure API Management. Azure API Management kan eksportere en OpenAPI-definisjon for automatisk å opprette den egendefinerte koblingen for bruk i en lavkodeløsning. Denne tilnærmingen kobler klientprogrammer fra API-ene, slik at de kan utvikle seg uavhengig. API-ene administreres sentralt, og legger til et sikkerhetslag ved ikke å eksponere API-en direkte og bruke godkjenningsteknikker som abonnementsnøkler, tokener, klientsertifikater og egendefinerte overskrifter.
Power Apps Component Framework	Power Apps Component Framework er et rammeverk for utvidbarhet for oppretting av egendefinerte visualobjekter for Power Apps og Power Pages. Kodekomponentene opprettes ved hjelp av HTML, JavaScript eller TypeScript. Tenk på kodekomponenter som byggesteiner i brukergrensesnittet som kan brukes på nytt til å bygge én eller flere apper. Komponentene inkluderer et manifest som definerer hvordan en lavkodekomponent kan samhandle med kodekomponenten. Komponentgrensesnittet gjør det mulig for kjøretidsmotoren for hosting å kommunisere vertsbeholderens livssyklushendelser. Dette gjør at kodekomponenten kan gjengi sine visualobjekter ved hjelp av kontekstinformasjon levert av vertsbeholderen. For ideer, bla gjennom fellesskapsgalleriet på https://pcf.gallery.
Virtuelle tabeller	Virtuelle tabeller gjør det enklere å integrere data som ligger i eksterne systemer. De representerer sømløst de eksterne dataene som tabeller i Microsoft Dataverse, uten å replikere dataene og ofte uten behov for tilpasset koding. Dataverse leveres med dataleverandører for OData v4 og Azure Cosmos DB. En leverandør av virtuelle koblinger, som for øyeblikket er i forhåndsversjon, utvider de tilgjengelige dataleverandørene til å inkludere et delsett av Power Platform-koblingene, inkludert SharePoint og SQL Server. For mer avanserte scenarioer kan utviklere opprette egendefinerte dataleverandører. Oppretting av egendefinerte dataleverandører krever dyp kunnskap om både eksterne data og Dataverse. Muligheten til å opprette Dataverse-programtillegg ved å bruke Power Fx for logikken er i forhåndsversjon.
Programtillegg i Dataverse	Et Dataverse-programtillegg er en egendefinert hendelsesbehandling som utføres som svar på en bestemt hendelse. Tenk på programtillegg som lagrede prosedyrer i en databasemotor, men skrevet i .NET. Hendelser oppstår for eksempel under behandling av en Microsoft Dataverse-dataoperasjon eller ved behov for egendefinerte API-hendelser. Programtillegget implementeres som en egendefinert klasse kompilert til en .NET Framework-samling som kan lastes opp og registreres med Dataverse. Ved hjelp av et definert grensesnitt kan programtillegget hente kontekstinformasjon om hendelsen som behandles. Programtillegg kan kjøres som en del av Dataverse-transaksjonen og kan utføre andre dataoperasjoner som er en del av den gjeldende transaksjonen. Programtillegg er beregnet på små arbeidsenheter. Ytelsen deres må optimaliseres slik at de ikke påvirker den generelle ytelsen negativt. Programtillegg kjøres alltid, uavhengig av operasjoner fra brukergrensesnittet eller API-en, noe som gjør dem til en effektiv måte å håndheve forretningslogikk konsekvent på.

Utforske scenarioer med lavkodemoderniseringsarkitektur

Som med de fleste plattformer kan du komponere et uendelig antall arkitekturscenarioer ved hjelp av Power Platform-komponenter og andre Microsoft skytjenester. I denne delen av papiret utforsker vi noen av de vanligste scenarioene og diskuterer noen hensyn du bør huske på når du bruker dem.

Programfunksjoner

Modernisering av brukeropplevelsen kan utgjøre en stor forskjell for brukerne. Power Apps er den primære måten å bygge interne programopplevelser med Power Platform på. Du kan bruke Power Pages for interne webprogrammer, men det er mer vanlig for eksterne programmer.

Power Apps

Arbeidsbelastninger bør utformes slik at brukerne kan fullføre mye av arbeidet uten å bytte app. Når du moderniserer et stort, monolitisk program, kan du dele funksjonaliteten i flere apper. Hvis brukerne derimot må arbeide med flere apper, kan du konsolidere dem i én app som presenterer en enhetlig visning av flere datakilder.

Tabellen nedenfor beskriver de to apptypene du kan bygge med Power Apps, lerretsapper og modelldrevne apper.

Type app	Description
Lerretsapper	Lerretsapper kan tilpasses. De består av én eller flere skjermer som brukerne samhandler med. Du kontrollerer oppsettet for hver skjerm og navigasjonen på tvers av skjermene. Lerretsapper samvirker med data ved hjelp av koblinger. Én enkelt app kan fungere med flere koblinger, noe som gjør den god for integrering på tvers av flere datakilder som en sammensatt app.
Modelldrevne apper	Modelldrevne apper bruker Dataverse som primær datakilde. De består av én eller flere sider, som kan være Dataverse-tabeller eller egendefinerte sider. En Dataverse-tabellside kan drilles ned til en detaljside for visning og redigering. Egendefinerte sider kan inneholde en lerretsappskjerm og data fra koblinger. Modelldrevne apper har en innebygd navigasjonsstruktur som kan tilpasses. Den er konsekvent på tvers av alle modelldrevne apper, noe som bidrar til brukerinnføring.

Diagrammet nedenfor illustrerer en grunnleggende arkitektur for en lerretsapp eller en modelldrevet app, der appen kobler direkte til datakilder.

Hvis du vil minimere direkte tilkoblinger til en datakilde, kan du få appen til å bruke en egendefinert kobling til API-en, som gjør alt nødvendig arbeid i datakilden. Denne fremgangsmåten lar deg kontrollere hvilke operasjoner som eksponeres for lavkodekomponenter, og kan abstrahere kompleksiteten til den underliggende logikken. Diagrammet nedenfor illustrerer denne API-først-tilnærmingen.

Power Apps kan også kjøre Power Automate-skyflyter direkte, som kan returnere resultater til programmet eller kjøre asynkront.

Ved å bruke Power Apps med datarepositoriene eller API-ene dine kan du modernisere brukeropplevelsen samtidig som du minimerer avbrudd i andre deler av en eldre løsning. Denne tilnærmingen kan også gjøre det mulig å koble flere eldre systemer til ett enkelt program, noe som gir brukerne ett enkelt sted å fullføre arbeidet.

Power Pages

Den primære datakilden for Power Pages er Dataverse. Når du legger til sider på et nettsted, lagrer du sidedefinisjonene i Dataverse. Sider kan både presentere Dataverse-data og samle inn data fra brukere for å lagre dem i en Dataverse-tabell.

Du kan konfigurere sider for anonym tilgang eller for godkjent tilgang ved hjelp av Microsoft Entra ID for interne brukere eller identitetsleverandører for eksterne brukere. Når godkjente brukere får tilgang til data, er bare dataene de har tilgang til, tilgjengelige.

Et vanlig bruksområde på et Power Pages-nettsted er å gi eksterne brukere selvbetjent tilgang til en organisatorisk forretningsprosess. Interne brukere kan bruke et Power Apps-program. Følgende diagram illustrerer en slik arkitektur.

Databehandling

Modernisering av programmer krever evaluering av dataene som brukes i den totale løsningen. Moderniserte programmer har flere alternativer for håndtering av data. I mange tilfeller bruker flere programmer det samme datalageret. Det blir vanskelig å overføre dataene til et nytt repositorium som en del av moderniseringen av et av programmene. Et kjerneprinsipp i Power Platform er at data kan brukes der de er eller bringes inn i plattformen, enten i Dataverse eller en datasjø.

Du har følgende alternativer for dataarkitekturen i det moderniserte programmet:

• La dataene være der de er: Bruk koblinger eller API-er med egendefinerte koblinger for å få tilgang til dataene der de er. Når dataene er lokale, kan datagatewayen legge til rette for sikker tilkobling. Bruk virtuelle tabeller til å integrere kompatible eksterne data som en Dataverse-tabell.

• Migrer til Dataverse: Dataverse er et godt alternativ for transaksjonsdata og for å konsolidere flere kilder i ett enkelt oppføringssystem. Data kan tilordnes og overføres fra mange kilder ved hjelp av Power Query og automatiserte flyter. Dataverse støtter også elastiske tabeller, utformet for å ta inn data med høyt volum som er lagret i ustrukturerte eller halvstrukturerte formater.

• Overfør til datasjø: Bruk en datasjø for historiske data, analysedata eller telemetridata. Dataene i sjøen kan brukes til å generere Power BI-analyser eller behandles for å generere KI-drevet innsikt.

Når du evaluerer alternativer for dataarkitekturen til et modernisert program, må du huske på følgende:

• Innvirkning på andre programmer: Selv om overføring til et mer effektivt datalager kan være ideelt for ett program, kan den opprinnelige innvirkningen på andre programmer som bruker dataene, være for høy. Noen organisasjoner vurderer å la dataene ligge i gamle datalagre og opprette nye data i Dataverse, og overføre fra det gamle lageret etter hvert som flere programmer moderniseres.

• Innvirkning på nye programmer: Hvis du lar data ligge i et gammelt datalager, selv om det er enkelt, kan dette påvirke hvor enkelt moderniserte applikasjoner kan bruke dem. Eldre datalagre har kanskje ikke god integrasjon med andre skytjenester, noe som gjør det vanskeligere å innlemme dataene i den nye overordnede arkitekturen.

• Datakonsolidering: Det er vanlig som en del av modernisering av programmer å identifisere data som ikke har tydelig eierskap eller ansvar for å sikre riktig bruk. Ved å konsolidere data i Dataverse kan organisasjoner forbedre styringen av dem og bedre sikre at de brukes riktig.

• Datapersonvern og -sikkerhet: Du bør evaluere personvern og sikkerhet basert på dine nåværende behov og målet for moderniseringsarkitekturen, ikke bare på hvordan det eldre programmet håndterte dem. Skyløsninger har flere alternativer for implementering av personvern- og sikkerhetskontroller. Ofte kan et enkelt datalager forenkle dem. Du må også vurdere hvordan du implementerer enhetlig datasikkerhet i hybride programmer som deler data på tvers av flere repositorier.

• Integrasjonsproblemer. Eldre datalagre mangler kanskje API-ene som er nødvendige for å tillate tilgang uten å overføre dataene eller opprette en API som programmer kan bruke med en egendefinert kobling. Tilkobling fra det gamle datalageret til programmene som bruker det, bør evalueres for å avgjøre om ytelsen er akseptabel.

Du bør bestemme en dataarkitektur for hvert program som skal moderniseres. Et første trinn er å etablere en overordnet visjon for hvordan dataarkitekturene innlemmer Dataverse. Hvis målet er å maksimere verdien av lavkoden, bør du bruke Dataverse når det er mulig. Å ha en visjon i starten kan hjelpe deg med å unngå å spre flere siloer med data.

Eksterne data og Dataverse

Eldre programmer er ofte avhengige av data som befinner seg utenfor organisasjonen og eksisterte lenge før Dataverse. Modernisering av disse programmene trenger ikke å innebære duplisering av dataene i Dataverse. I stedet kan du representere dataene som virtuelle Dataverse-tabeller. Virtuelle tabeller kan delta i relasjoner med andre virtuelle tabeller og med lokale tabeller. De moderniserte prgrammene ser et enhetlig sett med tabeller som ser ut til å eksistere fullstendig i Dataverse.

Virtuelle tabeller implementeres ved hjelp av en dataleverandørarkitektur. Dataverse har en OData-leverandør som kan brukes med OData V4-webtjenester. En dataleverandør for virtuelle koblinger, som for øyeblikket er i forhåndsversjon, tillater bruk av Power Platform-tabellkoblinger som virtuelle tabeller.

Diagrammet nedenfor illustrerer bruken av den virtuelle koblingen.

Utviklere kan også opprette egendefinerte leverandører for andre eksterne datakilder. De må imidlertid forstå og implementere alle Dataverse-tilordninger og driftsstøtte.

Følgende vurderinger kan hjelpe deg med å evaluere bruken av virtuelle tabeller i moderniseringsprosjektene:

• Alle eksterne datakilder må ha en primærnøkkel, og dataleverandøren må presentere den som en GUID til Dataverse. Du kan få plass til ikke-GUID-nøkler med utfylling hvis den polstrede verdien er stabil og unik.
• Datasikkerhet konfigureres på det virtuelle tabellnivået. Sikkerhet på rad- og kolonnenivå er ikke tilgjengelig.
• Ytelsen til virtuelle tabeller avhenger av dataleverandøren, API-en for den eksterne datakilden og tilkoblingen til datakilden. I de fleste tilfeller er tilgang til virtuelle tabeller tregere enn med lokale Dataverse-tabeller.
• Enkelte Dataverse-funksjoner, for eksempel søk, revisjon, diagrammer og instrumentbord og frakoblet tilgang, er ikke tilgjengelige for virtuelle tabeller.
• Bruk av virtuelle tabeller for referansedata kan føre til redusert synkronisering.

Fil og bilder

Når du moderniserer programmer som bruker filer og bilder, er det viktig å vurdere hvor den nye løsningen skal lagre dem. Dataverse har spesialiserte funksjoner for lagring av filer og bilder. Begge disse kan legges til i tabeller som en kolonne, og de lagres i Azure Blob Storage som administreres av Dataverse. Apper kan fungere med dem ved hjelp av Dataverse-koblingen, ingen separat godkjenning eller API kreves.

Bruk av Dataverse for filer og bilder er hensiktsmessig når de har en direkte forbindelse med dataene og flere brukere ikke trenger å samarbeide om dem; for eksempel et bilde av et produkt eller et sted eller den endelige kopien av en juridisk kontrakt. Hvis flere brukere imidlertid må endre den juridiske kontrakten samtidig, vil SharePoint gi bedre samarbeidsmuligheter. Vurder å bruke Azure Blob Storage direkte hvis du trenger å få sikkerheten administrert separat fra Dataverse, eller hvis du trenger å bruke bestemte filspesifikke funksjoner.

Integreringer

Modernisering av programmer inkluderer ofte integrasjoner med interne eller eksterne systemer. Integrasjoner kan grovt kategoriseres som data, program eller prosess.

• Dataintegrering kombinerer data fra ulike kilder for å gi brukeren en enhetlig visning. Det tilbyr en frakoblet tilnærming, men tillater ikke konstruksjon av logikk eller prosesser i sanntid. Ytelsen kan bli bedre fordi alle dataene er lokale.

• Programintegrering kobles til på programlaget og gjøres vanligvis via API-er eller, med lavkodeløsninger, koblinger. Integrering på programnivå gir en definert grense mellom to løsninger, men skaper også en avhengighet i sanntid i mange tilfeller. Denne typen integrering oppretter også en sikkerhetsgrense, der tilgang kan kontrolleres av systemet som leverer API-en.

• Prosessintegrering kobler sammen flere ulike systemer, som alle er en del av en helhetlig forretningsprosess. Denne typen integrasjon er den mest frakoblede, slik at de deltakende systemene kan håndtere hver del av forretningsprosessen. I moderniseringsscenarier kan det være nyttig å partisjonere en del av en prosess for modernisering med lavkode, integrert med andre deler som fortsatt håndteres av et eldre system.

Når du evaluerer hvordan du implementerer integreringer, er det viktig å ikke anta at den gamle tilnærmingen er den beste for programmet du moderniserer. For eksempel, hvis en prosess er i sanntid og synkron, bør du vurdere om du kan gjøre den asynkront. Synkron integrasjon kan være mer skjør i en skyløsning. For eksempel, en Power Automate-lavkodeflyt med riktig feilhåndtering kan orkestrere integreringen. Ikke bare vil denne tilnærmingen forbedre påliteligheten, men det vil også forbedre brukernes produktivitet fordi de ikke lenger trenger å vente på at integrasjonen skal fullføres.

Følgende vurderinger kan hjelpe deg med å evaluere hvordan du fremmer eksisterende integreringer:

• Er integrasjonen fortsatt nødvendig? Det er ikke uvanlig å finne ut at ingen bruker resultatene av integrasjonen lenger, og den kan pensjoneres.

• Er det tilkoblingsutfordringer hvis det moderniserte programmet er i skyen? Utfordringer kan omfatte ventetid og tilgang til en lokal API eller et datalager. I noen tilfeller kan den lokale datagatewayen hjelpe deg med å få tilgang til tjenesten eller data fra skyen. Hvis tilgangen til dataene eller tjenesten er for treg, bør du vurdere om du kan gjøre dataene lokale i den moderniserte appen eller utføre integreringen i bakgrunnen.

Integrering kan også bidra til å tilpasse et modernisert program. Du kan partisjonere én eller flere deler av det gamle programmet for å etterlate eller implementere det i et separat program. Denne fremgangsmåten fungerer bra når brukere med ulike roller bruker ulike deler av det gamle programmet. Du kan implementere én eller flere av rollene ved hjelp av lavkode, og bruke prosessintegrering til å la det eksisterende programmet håndtere de gjenværende delene av prosessen. Ved hjelp av denne tilnærmingen kan du gradvis modernisere de gjenværende delene over tid. Å ha uavhengige deler av prosessen implementert separat kan også legge til rette for en mer smidig måte å rulle ut forbedringer uavhengig av de andre delene av prosessen.

Før du viderefører tilpassede integreringer, bør du evaluere integreringsfunksjonene som er innebygd i Power Apps.

• Microsoft Teams: Power Apps-lerretsapper og Copilot Studio-agenter kan bygges inn i Teams-kanaler. Ved hjelp av Teams-koblingen kan apper og flyter enkelt legge ut og bruke Teams-meldinger. Power Apps-kort kan brukes som mikroapper for å dele handlingsrettet informasjon i en Teams-kanal.

• SharePoint: Modelldrevne Power Apps-apper kan konfigureres for å koble til dokumenter som er lagret i et SharePoint-bibliotek for å gjøre dem tilgjengelige i en Dataverse-rad. Med Microsoft Lister eller en SharePoint-liste kan brukere kjøre Power Automate-flyter i konteksten til et listeelement.

• Power BI: Power BI-innsikt kan vises i sammenheng med en Power Apps-lerretsapp. Du kan bygge inn en modelldrevet app i en Power BI-rapport, slik at brukere kan handle på innsiktene uten å forlate Power BI.

Bruk av Dataverse som primært datalager for det moderniserte programmet gir noen innebygde funksjoner som kan være nyttige for integrering.

• Egendefinerte API-er i Dataverse kan brukes til integrering på innkommende programnivå. Egendefinerte API-er gir en unik operasjon som er knyttet til en liten mengde egendefinert kodelogikk. Et avsendersystem kan for eksempel bruke den egendefinerte API-en RequestNewProject, og den tilknyttede logikken vet hvordan de mottatte dataene skal plasseres i de riktige Dataverse-tabellene. Avsendersystemet vil bli abstrahert fra Dataverse-tabellstrukturen.

• Utgående integrering kan utføres ved hjelp av funksjonene for publisering av hendelser til Dataverse. Dataverse kan konfigureres til å publisere til Azure Service Bus, Azure Event Hubs eller en hvilken som helst Webhook-mottaker. Når for eksempel en ny Dataverse-prosjekttabellrad opprettes, kan den publiseres til en Azure Service Bus-kø. Du kan også publisere mer konseptuelle hendelser som samsvarer med en forretningsprosesshendelse. Du kan for eksempel definere og publisere hendelser når et prosjekt er fullført.

Diagrammet nedenfor illustrerer et eksempel på innkommende og utgående hendelser i et Dataverse-miljø.

Organisasjoner bør også vurdere forhåndsbygde integreringsalternativer som er tilgjengelige fra tredjeparter på Microsoft AppSource. Microsoft har for eksempel en forhåndsbygd løsning for organisasjoner som trenger å integrere SAP med Power Platform. Denne forhåndsbygde løsningen innlemmer apper og flyter og legger til nye funksjoner som forenkler kommunikasjonen mellom organisasjonens SAP-system og Power Platform.

Ernst & Young brukte for eksempel den forhåndsbygde SAP-integrasjonen til raskt å utvikle en løsning for å optimalisere en høyfrekvent global finansprosess. Følgende diagram over selskapets PowerPost-løsning viser hvordan finansbrukere posterer dokumenter til SAP ERP-systemet i hovedboken ved hjelp av Power Platform.

Alternativer for integreringstilkobling

Etter hvert som løsninger flyttes til skyen, kan tilkobling tilbake til lokale ressurser være avgjørende for å sikre at integreringer fortsatt fungerer med det moderniserte programmet. Disse applikasjonene må også kunne integreres med andre tradisjonelle skyressurser som kan ligge i forskjellige nettverksmiljøer. Power Platform støtter de fire primære alternativene for sikker tilkobling: datagatewayer, datagatewayer for virtuelt nettverk, private koblinger og ExpressRoute.

• Med datagatewayer kan lavkodekomponenter fra Power Apps, Power Automate og Power BI tilbakeføres til lokale ressurser for å støtte hybride integrasjonsscenarioer. Gatewayer gir en rask metode for moderniserte lavkodeprogrammer for å få tilgang til datakilder som fortsatt er lokale. Med en gateway kan du koble til lokale data fra kilder som et lokalt filsystem, DB2, Oracle, SAP ERP, SQL Server og SharePoint. Én gateway kan støtte flere brukere og tilgang til flere kilder. Du kan også konfigurere datagatewayer som klynger for å få høy tilgjengelighet.

  Gateway-støtte er integrert i tilkoblingsprosessen for koblinger, noe som gjør det mulig å angi når en gateway kreves, og velge den konfigurerte gatewayen. Når tilkoblingen er konfigurert, kan apper og flyter bruke koblingen akkurat som en uten gateway.

  

• Datagatewayer for virtuelt nettverk tillater Power BI- og Power Platform-dataflyter å koble til datatjenester i et virtuelt Azure-nettverk uten behov for en lokal datagateway på en virtuell maskin i det virtuelle nettverket.

• Azure Private Link og Azure-nettverk for private endepunkter gir apper og flyter sikker tilgang til Power BI . Private endepunkter brukes til å sende datatrafikk privat ved hjelp av Microsofts ryggradsnettverksinfrastruktur i stedet for å gå over internett. Private endepunkter sikrer at trafikk som går inn i organisasjonens Power BI-ressurser, for eksempel rapporter eller arbeidsområder, alltid følger organisasjonens konfigurerte Private Link-nettverksbane.

• Azure ExpressRoute fungerer som en avansert metode for å koble det lokale nettverket til Microsoft Cloud Services ved hjelp av privat tilkobling. Én enkelt ExpressRoute-tilkobling kan få tilgang til flere nettjenester som Power Platform, Dynamics 365, Microsoft 365 og Azure-skytjenester uten å gå via det offentlige Internett. ExpressRoute krever betydelig planlegging og konfigurasjon og innebærer mer kostnad for ExpressRoute-tjenesten og tilkoblingsleverandøren.

Uansett hvilke tilnærminger du bruker for integreringstilkobling, bør du evaluere tilkoblingen for å sikre at den har lav nok ventetid og nok båndbredde til å støtte både integreringene og det moderniserte programmet.

Forretningslogikk

Når du bygger moderne programmer, kan du velge hva du vil implementere forretningslogikk med, og hvor du vil implementere den i programarkitekturen. Uten veiledning ville de fleste organisasjoner ende opp med kaos i forretningslogikk. Å ha gjenbrukbar logikk som sikrer konsistens i implementeringen, kan bidra til å fremskynde moderniseringsarbeidet.

For vårt formål definerer vi forretningslogikk som forskjellig fra brukeropplevelseslogikk. Eksempel: Logikk for å navigere fra skjerm til skjerm basert på inspeksjonsdataverdier er brukeropplevelseslogikk. Logikken du implementerer for å avgjøre om en inspeksjon er fullført, kan omfatte flere betingelsesevalueringer og betraktes som forretningslogikk.

Når du designer en løsning som inneholder lavkode, kan følgende hensyn hjelpe deg med å avgjøre hvor du kan plassere forretningslogikken.

• I Power Apps-programmet: Det enkleste er å plassere forretningslogikk i lavkodeprogrammet, men det gir begrensede alternativer for gjenbruk eller for å håndheve konsekvens på tvers av apper og automatiseringer. Generelt bør du begrense denne tilnærmingen til ikke-driftskritisk, enkel logikk som andre programmer eller automatiseringer ikke trenger å bruke. Lavkodeverktøyet gir ikke en feilsøkingsopplevelse linje for linje. Hvis logikk strekker seg over mer enn én skjerm eller er vanskelig å lese, bør du vurdere andre tilnærminger som vil være mer vedlikeholdbare. Det er ikke uvanlig at noen forretningslogikk dupliseres lokalt i programmet og i skyen. Hvis en bruker for eksempel angir en hotellbestilling, er forretningsregelen at utsjekkingsdatoen ikke kan være før innsjekkingsdatoen. Hvis programmet ikke validerte dette, ville brukeren komme helt til slutten og sende bestillingen bare for å finne den egendefinerte koblingen avvist den. Håndtering av validering lokalt i applikasjonen og i skyen gir en langt bedre brukeropplevelse.

• I en Power Automate-skyflyt: Du kan uttrykke forretningslogikk i handlingene i en flyt, og flyten kan utløses som svar på en hendelse eller en forespørsel som kjøres fra andre apper og flyter. Flyten kan gi en lavkodetilnærming til sentralisering av logikk. Trinn i flyten er uavhengige og er ikke en del av en transaksjon. Flyter kan imidlertid implementere kompensasjon for å håndtere tilbakerulling hvis det oppstår feil. Flyter kan kjøre trinn ved hjelp av tilkoblinger som har tillatelser utover det appbrukeren kanskje kan gjøre, og gir en måte å utvide tillatelser på. Denne fremgangsmåten gjør det også mulig å minimere tillatelsene appbrukeren kan kreve.

• I et Dataverse-programtillegg :Programtillegg kjøres som svar på en dataradhendelse, for eksempel oppretting, oppdatering eller sletting. Denne logikken kjøres hver gang hendelsen inntreffer, uavhengig av hvilken app eller flyt som utførte handlingen, eller om den ble utført direkte fra Dataverse-API-en. Fordelen med denne oppførselen er at den sikrer konsekvens på tvers av alle bruksområder. I tillegg er alle Dataverse-dataendringene fra logikken i programtillegget transaksjonelle og fullføres enten helt eller rulles tilbake helt. Plug-in logikk må være kort og effektiv og ikke prøve å gjennomføre langvarig arbeid. Noen ganger er ikke programtillegg for hendelser den beste tilnærmingen hvis du må lytte til hendelser på flere tabeller for å fullføre en enkelt forretningshendelse, for eksempel Lukk inspeksjon. Du kan for eksempel vurdere en egendefinert Dataverse-API i stedet for å ha programtillegg i flere tabeller. Programtillegg kan utføre logikk med utvidede tillatelser som brukeren vanligvis kanskje ikke har. Denne fremgangsmåten gjør det også mulig å minimere tillatelsene appbrukeren kan kreve. Programtillegg kan distribueres i en Dataverse-løsning sammen med apper og flyter.

• I egendefinerte Dataverse-API-er: Egendefinerte Dataverse-API-er lar deg implementere din egen egendefinerte API-melding som kan kjøre logikk. Du kan for eksempel opprette en egendefinert API for nøye inspeksjon som kalles for å gjøre alt arbeidet for å kontrollere og lukke en inspeksjon. Det ville ikke være hendelsesdrevet, men brukt på forespørsel av appene og flytene som trenger det. I likhet med hendelsesdrevne programtillegg er dataendringene som gjøres i den egendefinerte API-programtillegg, transaksjonsmessige. En egendefinert API er best når den eneste tjenesten den bruker, er Dataverse-API-en for annet dataarbeid. Programtillegg for egendefinerte API-er kan distribueres i en Dataverse-løsning sammen med apper og flyter.

Implementer en kode-API

Du kan implementere API-er i din favorittkjøretid for API-hosting, for eksempel Azure Functions, Azure Container Apps eller en hvilken som helst tjeneste som kan være vert for en REST-API. Disse egendefinerte API-ene kan implementere enhver logikk, og både lavkodebaserte og tradisjonelle kodeprogrammer kan bruke dem. Egendefinerte API-er gir ingen annen transaksjonsstøtte enn det som kan leveres av en API de bruker. En egendefinert API kan for eksempel bruke SQL Server-transaksjonskonstruksjoner hvis den brukte SQL Server. Distribusjon av en kode-API vil være uavhengig av lavkoderessursene som kan bruke den. Du kan bruke Azure API Management til å styre bruken av disse API-ene og gjøre dem mer synlige.

Sikkerhet

Sikkerhet, inkludert autentisering og autorisasjon, er en viktig del av arkitekturen til et modernisert program. Moderne apper er ofte mer utfordrende å sikre enn eldre apper. De inkluderer flere skytjenester, og brukere jobber med dem fra mer forskjellige steder. Koseptuelt er sikkerhet i plattformen der for å sørge for at brukerne kan utføre arbeidet de trenger å gjøre med minst mulig friksjon, samtidig som data og tjenester beskyttes.

Power Platform har en flerlags tilnærming til sikkerhet som du kan bruke til å bygge sikkerhetsarkitekturen. Et kjerneprinsipp for disse funksjonene er at lavkodeløsninger bør integreres med ditt eksisterende sikkerhetsapparat for å minimere virkningen av å introdusere dem.

La oss ta en grundig titt på lagene av sikkerhet som utgjør Power Platform-sikkerhetsmodellen:

• Brukere godkjennes av Microsoft Entra ID, og bruk kan begrenses ved hjelp av policyer for betinget tilgang.
• Lisensiering er den første kontrollporten som gir tilgang til Power Platform-komponenter.
• Muligheten til å opprette apper og arbeidsflyter styres av sikkerhetsroller i miljøkontekstene.
• Brukernes mulighet til å vise og bruke Power Platform-ressurser, styres ved å dele programmet med dem. Ressurser deles direkte med brukeren eller Entra ID-gruppen.
• Miljøer fungerer som sikkerhetsgrenser, som gjør det mulig å implementere ulike sikkerhetsbehov i hvert enkelt miljø.
• Power Automate-flyter og -lerretsapper bruker koblinger. Rettighetene til bestemte tilkoblinger og tilknyttede tjenesterettigheter avgjør tillatelser når apper bruker koblingene.
• Miljøer med en Dataverse-forekomst støtter mer avanserte sikkerhetsmodeller som er spesifikke for kontroll av tilgang til data og tjenester i Dataverse-forekomsten.
• Bruk av koblinger kan begrenses ytterligere i policyer for hindring av tap av data (DLP). Innkommende og utgående begrensninger på tvers av leiere kan også brukes på koblingene.

Det er viktig å merke seg at ved tilgang til datakilder ved hjelp av koblinger gis all den underliggende sikkerheten som datakilden tilbyr, i tillegg til lagene av sikkerhet som er beskrevet. Power Apps og Power Automate gir som standard ikke brukere tilgang til koblingsdatakilden de ikke allerede har. Brukere bør bare ha tilgang til data som de genuint trenger tilgang til.

Når du bruker Dataverse som en del av en løsning, inneholder den en rollebasert sikkerhetsmodell som kan tilpasses mange forretningsscenarioer. Data kan sikres helt ned til en enkelt kolonne på en datarad. Brukere tildeles én eller flere sikkerhetsroller som sammen bestemmer deres generelle rettigheter. Dataverse inneholder byggeblokker for sikkerhetsmodellering, som forretningsenheter og team. Forretningsenheter kan for eksempel brukes til å definere sikkerhetsgrenser for å holde data isolert mellom to ulike grupper med organisasjonsbrukere. Du kan bruke team til å gruppere brukere som trenger lignende tilgang til data. Du kan til og med tildele gruppeeierskap for datarader. Diagrammet nedenfor illustrerer bruk av forretningsenheter til å isolere data for divisjoner i en organisasjon.

Utforming av sikkerhetsmodellen

Skreddersy sikkerhetsmodellen til det moderniserte programmet for programmets generelle arkitektur. Programmer som bruker ett enkelt datalager og ingen koblinger, krever minimalt sikkerhetsdesignarbeid. Etter hvert som programmer bruker flere koblinger og datarepositorier, må sikkerhetsmodelleringen inkludere andre hensyn.

• Brukeridentitet: Hvordan godkjennes brukere, og er dette allerede tilordnet Microsoft Entra ID i scenarioer som kommer fra lokale nettverk? Dette inkluderer tilordning av grupper som er nødvendige for å støtte en programgruppe eller teamtildeling i skydatalagre som Dataverse.

• Koblingsidentitet for tilkobling: Når programmer bruker én eller flere koblinger, hvilken type godkjenning utføres for tilkoblingen, og gir den det kontrollnivået som er nødvendig for å implementere de nødvendige sikkerhetskontrollene? Programmer som bruker en tjenestekontohaver til å koble til, krever for eksempel ikke at brukeren av programmet har direkte tilgang til koblingen, noe som kan være nyttig i enkelte scenarier. Individuelle brukertilkoblinger kan være aktuelle for programmer som trenger å vite hvilken bruker som utførte en operasjon, eller for å begrense svar til bestemte brukere.

• Sikkerhetskonstruksjon av portabilitet: Etter hvert som programmene bruker flere koblinger og datalagre, er det viktig å huske at ikke alle sikkerhetsmekanismer fra én tjeneste kan overføres direkte til en annen. I Dataverse er det for eksempel flere måter en bruker kan få tilgang til en datarad på, inkludert deling av raden med brukeren. Hvis et program knytter et SharePoint-dokumentbibliotek til raden, er sikkerheten som gir tilgang til dokumentbiblioteket, atskilt fra sikkerheten som styrer Dataverse-tilgang. De tilordnes ikke direkte. Moderniserte programmer må ta hensyn til denne typen uoverensstemmelser på tvers av koblingene og datalagrene de bruker.

Kunstig intelligens

I løpet av de siste årene har kunstig intelligens funnet veien inn i programmoderniseringsarbeidet. Ved modernisering av programmer bør organisasjoner vurdere å bruke kunstig intelligens for å gjøre brukerne mer produktive og bedre i stand til å ta informerte beslutninger. Resultatene av å innlemme kunstig intelligens kan også bety bedre kundeopplevelser, noe som positivt påvirker forretningsresultatene.

Inkludert kunstig intelligens pleide å involvere tunge løft i integrering av programlogikk og bygging av spesialopplærte modeller. Med tilgjengeligheten og kraften til store språkmodeller kan programmer nå introdusere nye måter å bruke kunstig intelligens på for å hjelpe brukere med å få svar og utføre oppgaver. Brukere kan bruke ledetekster på naturlig språk til å samhandle med KI-funksjoner i et bredt spekter av assisterende forretningsscenarioer.

Microsoft har introdusert kopiloter i kjerneprodukter og -tjenester for å gjøre tilgangen til avansert KI-teknologi enklere. En Copilot bruker moderne KI-teknikker og store språkmodeller og kan samhandles med av brukere i programmene de bruker hver dag, som Microsoft 365, Windows, Dynamics 365, og Power Platform.

Utvid med programtillegg

Brukere av Copilot-drevne programmer kan be Copilot om hjelp med vanlige oppgaver i programmet. Du kan utvide kopiloter til å inkludere data og oppgaver de ikke allerede kjenner, og som er utenfor omfanget av appen brukeren arbeider med. Microsoft 365 Copilot kan inkludere Power Platform-data som er lagret i Dataverse, slik at brukerne ikke trenger å bytte frem og tilbake mellom programmer. Fra Outlook kan for eksempel en bruker be Copilot om å generere en statusoppdatering for alle mislykkede inspeksjoner som er fullført i dag. Microsoft 365 Copilot arver automatisk det opprinnelige rammeverket for sikkerhet og styring i Dataverse og anvender brukersikkerhet og tillatelser under kjøring.

Koblinger som programtillegg

Power Platform-koblinger er også viktige for Copilot opplevelsen. Koblinger kan kobles til som programtillegg for å utvide Copilot sine funksjoner. For eksempel kan Microsoft 365 Copilot med Power Platform-koblingen for Jira Software gjøre det mulig for en prosjektleder å be om statusen til en Jira-støtteforespørsel og handle basert på svaret, for eksempel å rute den for mer godkjenning eller starte en innkjøpsordre for ny maskinvare. Ved hjelp av programtillegg kan du integrere forretningsprosesser og data med Copilot for å gi brukerne mulighet til å samhandle fra appene de bruker.

Bygg din egen kopilot

Etter hvert som brukerne blir mer vant til å ha KI-hjelp i kopilot i appene sine, forventer de det i alle programmer. Du kan gjøre de moderne programmene mer engasjerende ved å inkludere kopiloter som du oppretter med Copilot-stakken, et rammeverk for KI-utvikling.

Du kan bruke den forhåndsbygde Copilot-kontrollen i Power Apps til å legge til kopiloter i lerretsapper og modelldrevne apper. Ved å konfigurere en visning av en datakilde og litt grunnleggende spørsmålsinformasjon kan du raskt tilby en egen kopilotopplevelse i appen.

Administrasjon av programlivssyklus

En viktig del av enhver moderniseringsinnsats er å etablere en passende prosess for administrasjon av programlivssyklus. Organisasjoner ønsker ofte at innsatsen med lavkode skal passe inn i hvordan de arbeider med ALM for tradisjonell kode. Power Platform inneholder ALM-verktøy, slik at du kan inkludere lavkodeartefakter i eller ved siden av prosessene du vanligvis bruker.

ALM i Power Platform starter med hvordan du bygger lavkoderessurser. Ressurser du bygger, er i konteksten til et Power Platform-miljø. Et miljø kan ha ett Dataverse-datalager. Du kan bruke flere miljøer – vanligvis utvikling, testing og produksjon – til å implementere landingssoner i en ALM-prosess som inkluderer lavkode. Antallet og formålet med miljøer er fleksible, og organisasjoner kan justere dem for å oppfylle individuelle prosjektbehov. En Dataverse-løsning er en beholder for relaterte lavkoderessurser, som forenkler versjonskontroll og transport fra ett miljø til et annet.

Power Platform-pipeliner gir en lavkodebasert tilnærming for å automatisere distribusjoner og implementere kontinuerlig integrering og kontinuerlig levering (CI/CD). Power Platform administrerer prosessen når pipeliner konfigureres. Administratorer kan administrere og styre kanalene sentralt.

Organisasjoner kan også bruke CI/CD-verktøyet de ønsker. Power Platform CLI er et kommandolinjeverktøy som du kan bruke med de fleste CI/CD-automatiseringsverktøy. Power Platform Build Tools inneholder handlinger for GitHub og oppgaver for Azure DevOps, som inneholder alle de vanlige handlingene som kreves for å bygge CI/CD-automatiseringer som inkluderer lavkodeartefakter.

Diagrammet nedenfor illustrerer et eksempel på en gruppe som bygger en inspeksjonsapp. I den indre løkken jobber de i et utviklingsmiljø og lagrer arbeidet sitt i et Git-repositorium. Den ytre løkken består av et testmiljø og et produksjonsmiljø. En build-kanal tar den versjonskontrollerte løsningen, utfører alle nødvendige kontroller og produserer en artefakt i inspeksjonsløsningen. En utgivelseskanalen ruller deretter ut løsningen for testing, der testere kan bekrefte at den er klar for produksjon. Når utgivelseskanalen er godkjent, ruller den løsningen ut til produksjon.

Når du eksporterer en løsning fra Dataverse, eksporteres den som én enkelt komprimert fil. Hvis du vil lagre lavkoderessursene i versjonskontroll, kan du bruke byggverktøyet til å pakke ut løsningsfilen i individuelle komponentfiler. Under byggautomatisering kombinerer byggverktøyene individuelle filer fra versjonskontroll til én enkelt komprimert fil.

Utrulling av en løsning i et miljø som inneholder en tidligere versjon av løsningen, bruker en intelligent oppgraderingsprosess som bare bruker endringer. Denne oppgraderingsprosessen unngår behovet for å differensiere skript eller andre måter å avgjøre hva som må distribueres.

Når det moderniserte programmet inneholder lavkodebaserte og tradisjonelle koderessurser, kan du kombinere dem i én enkelt CI/CD-prosess eller administrere dem uavhengig av hverandre. Med uavhengig administrasjon kan ressurser rulles ut individuelt, og prosjektteam kan oppnå større smidighet. API-en som et lavkodeprogram bruker, kan for eksempel distribueres uavhengig hvis teamet ikke innfører endringer som ødelegger noe.

Overvåking og innsikt

Moderniserte applikasjoner må integreres i driftsmiljøer som gir muligheten til å diagnostisere problemer på tvers av ulike miljøer, fra utvikling til produksjon. Application Insights, en Azure Monitor-utvidelse, samler inn telemetri fra Power Apps og Dataverse. Denne informasjonen hjelper ikke bare med å identifisere og løse problemer, men gir også innsikt i hva brukerne gjør i et program. Du kan bruke denne innsikten til å forbedre appene og prosessene i det moderniserte programmet.

Mens et Power Apps-program er under utvikling, kan utviklere inkludere logikk for å logge egendefinerte hendelser. Når du har koblet det distribuerte programmet til Application Insights, samler utvidelsen automatisk inn grunnleggende telemetri, inkludert mer kontekst fra loggede hendelser, når brukere samhandler med programmet.

Administratorer kan også konfigurere Dataverse-miljøer for å eksportere telemetri til Application Insights. Data som logges, kan inkludere Dataverse-API-kall, kjøring av programtillegg, SDK-operasjoner og unntak. Utviklere som oppretter egendefinert programtilleggslogikk, kan logge flere tilpassede telemetridata direkte til Application Insights.

Bruk av Application Insights i alle programmene dine kan gjøre det enklere å korrelere problemer med flere ressurser. Driftspersonell kan opprette varsler i Azure Monitor for å utløses når et høyt antall unntak oppdages. Regelmessig analyse av dine moderniserte applikasjoner kan identifisere trender som krever mer undersøkelse.

Konklusjon

I dette tekniske dokumentet har vi sett nærmere på fordeler, strategier og anbefalte fremgangsmåter for modernisering av eldre programmer med Microsoft Power Platform. Du har fått innsikt i og veiledning om bruk av lavkodefunksjoner i Power Platform for å sikre et vellykket moderniseringsarbeid som en del av organisasjonens digitale transformasjon.

Eldre applikasjoner gir mange utfordringer for organisasjoner. For å overvinne dem må organisasjoner ta fatt på programmoderniseringsinitiativer for å revitalisere infrastrukturen og dra nytte av moderne teknologi. I dette tekniske dokumentet har du sett hvordan du inntar en lavkodebasert tilnærming til moderniseringsarbeidet, spesielt hvordan funksjonene for lavkodeutvikling i Microsoft Power Platform gjør at du raskt kan bygge og rulle ut moderne programmer.

Lavkode åpner døren for et bredere sett med mennesker enn tradisjonelle kodere. En nøkkelfaktor for organisasjoner som lykkes med en lavkodebasert tilnærming, er å sørge for at personene som er involvert i modernisering av programmer, har opplæring i lavkodeutvikling, enten de er profesjonelle utviklere eller forretningsbrukere. Forretningsbrukere er tettere på forretningsproblemet som skal løses, og de kan bidra med tidsbesparende kompetanse. Tradisjonelle kodeutviklere kan bruke teknikkene og ferdighetene de allerede har, for å bygge utvidelser for å fylle eventuelle lavkodehull. Organisasjoner kan være mest effektive ved å blande forretningsmessige og tekniske ressurser på det vi liker å kalle tverrfaglige grupper.

Dette tekniske dokumentet etablerer grunnlaget for deg. De neste trinnene er dine. Her er noen forslag:

• Bruk noen minutter på å finne ut hva organisasjonen allerede gjør med lavkode. Det kan overraske deg!
• Evaluer mulighetene for modernisering av programmer.
• Identifiser og prioriter en god førstekandidat.
• Bemann et team som moderniserer programmet. For best resultat må du sørge for at det er en tverrfaglig gruppe.
• Sørg for at teamet har den nødvendige opplæringen for å lykkes.
• La teamet modernisere programmet.
• Reflekter over moderniseringsarbeidet. Finjuster og skaler det til andre eldre programmer.

Hver organisasjons reise til programmodernisering er unik. Microsoft-kontoteamet ditt eller Power Platform-partneren din kan hjelpe deg med å planlegge reisen og holde deg på rett kjøl underveis.

Ressurser

• The Total Economic Impact™ of Microsoft Power Platform Premium Capabilities
• ConnectMe-appen til American Airlines skaper en enklere reiseopplevelse for kundene og bedre teknologiske verktøy for teammedlemmer
• Power Fx-repositorium med åpen kildekode på GitHub
• Startpakken for CoE
• Power Platform-innføringsvurdering
• Digital forsikringsselskap automatiserer en kompleks kjøpsprosess ved hjelp av Power Platform
• PCF-galleri
• EY bidrar til å muliggjøre oppføring ved kilden for en global finansprosess med Power Platform, noe som reduserer kundeemnetider med 95 prosent
• Azure Private Link
• Microsoft Azure ExpressRoute
• Power Platform-lanseringsplanlegger
• Veiledning om lisenser for Microsoft Power Platform
• Microsoft skisserer et rammeverk for bygging av KI-apper og -kopiloter, utvider økosystemet for KI-programtillegg