Dette er det andre innlegget i en firedelt serie som beskriver hvordan NatWest Group, en stor finansinstitusjon, samarbeidet med AWS profesjonelle tjenester å bygge en ny plattform for maskinlæringsoperasjoner (MLOps). I dette innlegget deler vi hvordan NatWest Group brukte AWS for å muliggjøre selvbetjent distribusjon av deres standardiserte, sikre og kompatible MLOps-plattform ved å bruke AWS servicekatalog og Amazon SageMaker. Dette har ført til en reduksjon i tiden det tar å klargjøre nye miljøer fra dager til bare noen få timer.
Vi tror at beslutningstakere kan dra nytte av dette innholdet. CTOer, CDAOer, senior dataforskere og senior skyingeniører kan følge dette mønsteret for å tilby innovative løsninger for datavitenskaps- og ingeniørteamene deres.
Les hele serien:
|
Teknologi hos NatWest Group
NatWest Group er en relasjonsbank for en digital verden som tilbyr finansielle tjenester til mer enn 19 millioner kunder over hele Storbritannia. Konsernet har en mangfoldig teknologiportefølje, der løsninger på forretningsutfordringer ofte leveres med skreddersydde design og med lange tidslinjer.
Nylig vedtok NatWest Group en sky-først-strategi, som har gjort det mulig for selskapet å bruke administrerte tjenester til å levere on-demand data- og lagringsressurser. Dette grepet har ført til en forbedring i den generelle stabiliteten, skalerbarheten og ytelsen til forretningsløsninger, samtidig som kostnadene er redusert og leveringshastigheten akselerert. I tillegg, ved å flytte til skyen kan NatWest Group forenkle teknologistabelen sin ved å håndheve et sett med konsistente, repeterbare og forhåndsgodkjente løsningsdesign for å møte regulatoriske krav og operere på en kontrollert måte.
Utfordringer
Pilotstadiene for å ta i bruk en sky-først-tilnærming involverte flere eksperimenterings- og evalueringsfaser med bruk av et bredt utvalg av analytiske tjenester på AWS. De første gjentakelsene av NatWest Groups skyplattform for datavitenskapelige arbeidsbelastninger møtte utfordringer med å klargjøre konsistente, sikre og kompatible skymiljøer. Prosessen med å skape nye miljøer tok fra noen få dager til uker eller måneder. En avhengighet av sentrale plattformteam for å bygge, klargjøre, sikre, distribuere og administrere infrastruktur og datakilder gjorde det vanskelig å ombord nye team for å jobbe i skyen.
På grunn av ulikheten i infrastrukturkonfigurasjon på tvers av AWS-kontoer, måtte team som bestemte seg for å migrere arbeidsmengdene sine til skyen, gjennom en omfattende samsvarsprosess. Hver infrastrukturkomponent måtte analyseres separat, noe som økte tidslinjene for sikkerhetsrevisjon.
Å komme i gang med utvikling i AWS innebar å lese et sett med dokumentasjonsveiledninger skrevet av plattformteam. De første trinnene for oppsett av miljø inkluderte administrasjon av offentlige og private nøkler for autentisering, konfigurering av tilkoblinger til eksterne tjenester ved å bruke AWS kommandolinjegrensesnitt (AWS CLI) eller SDK fra lokale utviklingsmiljøer, og kjører tilpassede skript for å koble lokale IDE-er til skytjenester. Tekniske utfordringer gjorde det ofte vanskelig å komme ombord på nye teammedlemmer. Etter at utviklingsmiljøene ble konfigurert, var ruten for å slippe programvare i produksjon like kompleks og lang.
Som beskrevet i del 1 av denne serien, samlet det felles prosjektteamet inn store mengder tilbakemeldinger om brukeropplevelse og krav fra team på tvers av NatWest Group før de bygget den nye datavitenskapen og MLOps-plattformen. Et vanlig tema i denne tilbakemeldingen var behovet for automatisering og standardisering som en forløper for rask og effektiv prosjektleveranse på AWS. Den nye plattformen bruker AWS-administrerte tjenester for å optimalisere kostnadene, kutte ned på plattformkonfigurasjonsarbeidet og redusere karbonavtrykket fra å kjøre unødvendig store datajobber. Standardisering er innebygd i hjertet av plattformen, med forhåndsgodkjente, fullt konfigurerte, sikre, kompatible og gjenbrukbare infrastrukturkomponenter som kan deles mellom data- og analyseteam.
Hvorfor SageMaker Studio?
Laget valgte Amazon SageMaker Studio som hovedverktøy for å bygge og distribuere ML-rørledninger. Studio tilbyr et enkelt nettbasert grensesnitt som gir brukere full tilgang, kontroll og synlighet i hvert trinn som kreves for å bygge, trene og distribuere modeller. Modenheten til Studio IDE (integrert utviklingsmiljø) for modellutvikling, metadatasporing, artefaktadministrasjon og distribusjon var blant funksjonene som appellerte sterkt til NatWest Group-teamet.
Dataforskere ved NatWest Group jobber med SageMaker-notatbøker inne i Studio under de innledende stadiene av modellutvikling for å utføre dataanalyse, datakrangel og funksjonsutvikling. Etter at brukerne er fornøyd med resultatene av dette innledende arbeidet, konverteres koden enkelt til komponerbare funksjoner for datatransformasjon, modelltrening, inferens, logging og enhetstester slik at den er i produksjonsklar tilstand.
Senere stadier av modellutviklingens livssyklus involverer bruk av Amazon SageMaker-rørledninger, som kan inspiseres og overvåkes visuelt i Studio. Rørledninger visualiseres i en DAG (Directed Acyclic Graph) som fargekoder trinn basert på tilstanden mens rørledningen kjører. I tillegg en oppsummering av Amazon CloudWatch-logger vises ved siden av DAG for å lette feilsøkingen av feilslåtte trinn. Dataforskere får en kodemal som består av alle de grunnleggende trinnene i en SageMaker-pipeline. Dette gir et standardisert rammeverk (konsistent på tvers av alle brukere av plattformen for å lette samarbeid og kunnskapsdeling) der utviklere kan legge til den skreddersydde logikken og applikasjonskoden som er spesiell for forretningsutfordringen de løser.
Utviklere kjører pipelines i Studio IDE for å sikre at kodeendringene deres integreres riktig med andre pipeline-trinn. Etter at kodeendringer er gjennomgått og godkjent, bygges disse rørledningene og kjøres automatisk basert på en hovedutløser for Git-depotet. Under modelltrening lagres og spores modellevalueringsberegninger i SageMaker Experiments, som kan brukes til hyperparameterinnstilling. Etter at en modell er trent opp, lagres modellartefakten i SageMaker modellregister, sammen med metadata relatert til modellbeholdere, data brukt under trening, modellfunksjoner og modellkode. Modellregisteret spiller en nøkkelrolle i modelldistribusjonsprosessen fordi det pakker all modellinformasjon og muliggjør automatisering av modellpromotering til produksjonsmiljøer.
MLOps-ingeniører distribuerer administrert SageMaker batch-transformeringsjobber, som skaleres for å møte kravene til arbeidsbelastning. Både offline batch-inferensjobber og online-modeller servert via et endepunkt bruker SageMakers administrerte inferensfunksjonalitet. Dette er til fordel for både plattform- og forretningsapplikasjonsteam fordi plattformingeniører ikke lenger bruker tid på å konfigurere infrastrukturkomponenter for modellslutninger, og forretningsapplikasjonsteam skriver ikke tilleggskode for å sette opp og samhandle med dataforekomster.
Hvorfor AWS Service Catalogue?
Teamet valgte AWS Service Catalog for å bygge en katalog med sikre, kompatible og forhåndsgodkjente infrastrukturmaler. Infrastrukturkomponentene i et AWS Service Catalog-produkt er forhåndskonfigurert for å møte NatWest Groups sikkerhetskrav. Rolletilgangsadministrasjon, ressurspolicyer, nettverkskonfigurasjon og sentrale kontrollpolicyer er konfigurert for hver ressurs pakket i et AWS Service Catalog-produkt. Produktene er versjonert og delt med applikasjonsteam ved å følge en standardprosess som gjør det mulig for datavitenskap og ingeniørteam å betjene og distribuere infrastruktur umiddelbart etter å ha fått tilgang til AWS-kontoene deres.
Plattformutviklingsteam kan enkelt utvikle AWS Service Catalog-produkter over tid for å muliggjøre implementering av nye funksjoner basert på forretningskrav. Iterative endringer i produkter gjøres ved hjelp av AWS Service Catalog-produktversjon. Når en ny produktversjon er utgitt, slår plattformteamet sammen kodeendringer til Git-hovedgrenen og øker versjonen av AWS Service Catalog-produktet. Det er en viss grad av autonomi og fleksibilitet ved å oppdatere infrastrukturen fordi forretningsapplikasjonskontoer kan bruke tidligere versjoner av produkter før de migrerer til den nyeste versjonen.
Løsningsoversikt
Følgende arkitekturdiagram på høyt nivå viser hvordan en typisk brukertilfelle for forretningsapplikasjoner distribueres på AWS. De følgende delene går i mer detalj angående kontoarkitekturen, hvordan infrastrukturen distribueres, brukertilgangsadministrasjon og hvordan ulike AWS-tjenester brukes til å bygge ML-løsninger.
Som vist i arkitekturdiagrammet følger kontoene en nav- og eikemodell. En delt plattformkonto fungerer som en hub-konto, der ressursene som kreves av bedriftsapplikasjonsteamets (talte) kontoer er vert for plattformteamet. Disse ressursene inkluderer følgende:
- Et bibliotek med sikre, standardiserte infrastrukturprodukter som brukes for selvbetjente infrastrukturutrulleringer, vert av AWS Service Catalog
- Docker-bilder, lagret i Amazon Elastic Container Registry (Amazon ECR), som brukes under kjøringen av SageMaker-rørledningstrinn og modellslutning
- AWS CodeArtifact repositories, som er vert for forhåndsgodkjente Python-pakker
Disse ressursene deles automatisk med taltekontoer via AWS Service Catalog-porteføljedeling og -importfunksjon, og AWS identitets- og tilgangsadministrasjon (IAM) tillitsretningslinjer for både Amazon ECR og CodeArtifact.
Hvert forretningsapplikasjonsteam får tildelt tre AWS-kontoer i NatWest Groups infrastrukturmiljø: utvikling, pre-produksjon og produksjon. Miljønavnene refererer til kontoens tiltenkte rolle i livssyklusen for utvikling av datavitenskap. Utviklingskontoen brukes til å utføre dataanalyse og krangel, skrive modell- og modellpipelinekode, trene modeller og utløse modelldistribusjoner til pre-produksjons- og produksjonsmiljøer via SageMaker Studio. Førproduksjonskontoen speiler oppsettet av produksjonskontoen og brukes til å teste modelldistribusjoner og batchtransformasjonsjobber før de slippes ut i produksjon. Produksjonskontoen er vert for modeller og kjører arbeidsbelastninger for produksjonsslutning.
Brukeradministrasjon
NatWest Group har strenge styringsprosesser for å håndheve separasjon av brukerroller. Fem separate IAM-roller er opprettet for hver brukerpersona.
Plattformteamet bruker følgende roller:
- Plattformstøtteingeniør – Denne rollen inneholder tillatelser for business-as-usual-oppgaver og en skrivebeskyttet visning av resten av miljøet for overvåking og feilsøking av plattformen.
- Plattformfikseringsingeniør – Denne rollen er opprettet med økte tillatelser. Den brukes hvis det er problemer med plattformen som krever manuell intervensjon. Denne rollen påtas kun på en godkjent, tidsbegrenset måte.
Utviklingsteamene for forretningsapplikasjoner har tre forskjellige roller:
- Teknisk ledelse – Denne rollen er tildelt applikasjonsteamlederen, ofte en senior dataforsker. Denne brukeren har tillatelse til å distribuere og administrere AWS Service Catalog-produkter, utløse utgivelser i produksjon og gjennomgå statusen til miljøet, som f.eks. AWS CodePipeline statuser og logger. Denne rollen har ikke tillatelse til å godkjenne en modell i SageMaker-modellregisteret.
- Utvikler – Denne rollen er tildelt alle teammedlemmer som jobber med SageMaker Studio, som inkluderer ingeniører, dataforskere og ofte teamlederen. Denne rollen har tillatelser til å åpne Studio, skrive kode og kjøre og distribuere SageMaker-pipelines. I likhet med den tekniske lederen har ikke denne rollen tillatelse til å godkjenne en modell i modellregisteret.
- Modellgodkjenner – Denne rollen har begrensede tillatelser knyttet til å se, godkjenne og avvise modeller i modellregisteret. Årsaken til denne separasjonen er å hindre brukere som kan bygge og trene modeller fra å godkjenne og slippe sine egne modeller inn i eskalerte miljøer.
Det opprettes separate Studio-brukerprofiler for utviklere og modellgodkjennere. Løsningen bruker en kombinasjon av IAM-policyerklæringer og SageMaker-brukerprofiltagger, slik at brukere kun har tillatelse til å åpne en brukerprofil som samsvarer med brukertypen deres. Dette sikrer at brukeren blir tildelt riktig SageMaker execution IAM-rolle (og dermed tillatelser) når de åpner Studio IDE.
Selvbetjente distribusjoner med AWS Service Catalog
Sluttbrukere bruker AWS Service Catalog for å distribuere datavitenskapelige infrastrukturprodukter, for eksempel følgende:
- Et studiomiljø
- Studio brukerprofiler
- Modeller for distribusjonsrørledninger
- Opplæringsrørledninger
- Inferensrørledninger
- Et system for overvåking og varsling
Sluttbrukere distribuerer disse produktene direkte gjennom AWS Service Catalog UI, noe som betyr at det er mindre avhengighet av sentrale plattformteam for å klargjøre miljøer. Dette har betydelig redusert tiden det tar for brukere å få tilgang til nye skymiljøer, fra flere dager ned til bare noen få timer, noe som til slutt har ført til en betydelig forbedring i tid-til-verdi. Bruken av et felles sett med AWS Service Catalog-produkter støtter konsistens i prosjekter på tvers av bedriften og senker barrieren for samarbeid og gjenbruk.
Fordi all datavitenskapelig infrastruktur nå er distribuert via en sentralt utviklet katalog over infrastrukturprodukter, er det tatt hensyn til å bygge hvert av disse produktene med sikkerhet i tankene. Tjenester er konfigurert til å kommunisere innenfor Amazon Virtual Private Cloud (Amazon VPC) slik at trafikk ikke går gjennom det offentlige internett. Data er kryptert under overføring og i hvile ved bruk AWS nøkkelstyringstjeneste (AWS KMS)-taster. IAM-roller er også satt opp for å følge prinsippet om minste privilegium.
Til slutt, med AWS Service Catalog, er det enkelt for plattformteamet å kontinuerlig slippe nye produkter og tjenester etter hvert som de blir tilgjengelige eller kreves av bedriftsapplikasjonsteam. Disse kan ta form av nye infrastrukturprodukter, for eksempel å gi sluttbrukere mulighet til å distribuere sine egne Amazon EMR klynger, eller oppdateringer til eksisterende infrastrukturprodukter. Fordi AWS Service Catalog støtter produktversjon og bruker AWS skyformasjon bak kulissene kan oppgraderinger på stedet brukes når nye versjoner av eksisterende produkter utgis. Dette lar plattformteamene fokusere på å bygge og forbedre produkter, i stedet for å utvikle komplekse oppgraderingsprosesser.
Integrasjon med NatWests eksisterende IaC-programvare
AWS Service Catalog brukes til selvbetjent datavitenskapelig infrastruktur. I tillegg brukes NatWests standard infrastruktur som kode (IaC) verktøy, Terraform, til å bygge infrastruktur i AWS-kontoene. Terraform brukes av plattformteam under den første kontooppsettprosessen for å distribuere nødvendige infrastrukturressurser som VPCer, sikkerhetsgrupper, AWS systemansvarlig parametere, KMS-nøkler og standard sikkerhetskontroller. Infrastruktur i hub-kontoen, slik som AWS Service Catalog-porteføljer og ressursene som brukes til å bygge Docker-bilder, er også definert ved hjelp av Terraform. Imidlertid er selve AWS Service Catalog-produktene bygget ved hjelp av standard CloudFormation-maler.
Forbedre utviklerproduktivitet og kodekvalitet med SageMaker-prosjekter
SageMaker-prosjekter gi utviklere og dataforskere tilgang til hurtigstartprosjekter uten å forlate SageMaker Studio. Disse hurtigstartprosjektene lar deg distribuere flere infrastrukturressurser samtidig med bare noen få klikk. Disse inkluderer et Git-depot som inneholder en standardisert prosjektmal for den valgte modelltypen, Amazon enkel lagringstjeneste (Amazon S3) bøtter for lagring av data, serialiserte modeller og artefakter, og modelltrening og inferens CodePipeline-rørledninger.
Innføringen av standardiserte kodebasearkitekturer og verktøy gjør det nå enkelt for datavitere og ingeniører å flytte mellom prosjekter og sikre at kodekvaliteten forblir høy. For eksempel er beste praksis for programvareutvikling som linting og formateringssjekker (kjøres både som automatiserte kontroller og pre-commit hooks), enhetstester og dekningsrapporter nå automatisert som en del av opplæringspipelines, og gir standardisering på tvers av alle prosjekter. Dette har forbedret vedlikeholdsevnen til ML-prosjekter og vil gjøre det enklere å flytte disse prosjektene i produksjon.
Automatisering av modellimplementeringer
Modelltreningsprosessen er orkestrert ved hjelp av SageMaker Pipelines. Etter at modellene har blitt opplært, lagres de i SageMaker modellregister. Brukere som er tildelt rollen som modellgodkjenner, kan åpne modellregisteret og finne informasjon knyttet til opplæringsprosessen, for eksempel når modellen ble trent, hyperparameterverdier og evalueringsberegninger. Denne informasjonen hjelper brukeren med å bestemme om en modell skal godkjennes eller avvises. Å avvise en modell forhindrer modellen fra å bli distribuert i et eskalert miljø, mens godkjenning av en modell utløser en modellpromoteringspipeline via CodePipeline som automatisk kopierer modellen til AWS-kontoen før produksjon, klar for testing av arbeidsbelastning. Etter at teamet har bekreftet at modellen fungerer korrekt i pre-produksjon, godkjennes et manuelt trinn i samme pipeline og modellen kopieres automatisk over til produksjonskontoen, klar for produksjonsslutningsarbeidsbelastninger.
Resultater
Et av hovedmålene med dette samarbeidsprosjektet mellom NatWest og AWS var å redusere tiden det tar å klargjøre og distribuere datavitenskapelige skymiljøer og ML-modeller i produksjon. Dette er oppnådd – NatWest kan nå levere nye, skalerbare og sikre AWS-miljøer i løpet av få timer, sammenlignet med dager eller til og med uker. Dataforskere og ingeniører har nå myndighet til å distribuere og administrere datavitenskapelig infrastruktur selv ved å bruke AWS Service Catalog, noe som reduserer avhengigheten av sentraliserte plattformteam. I tillegg gjør bruken av SageMaker-prosjekter det mulig for brukere å begynne koding og opplæringsmodeller i løpet av få minutter, samtidig som det gir standardiserte prosjektstrukturer og verktøy.
Fordi AWS Service Catalog fungerer som den sentrale metoden for å distribuere datavitenskapelig infrastruktur, kan plattformen enkelt utvides og oppgraderes i fremtiden. Nye AWS-tjenester kan tilbys sluttbrukere raskt når behovet oppstår, og eksisterende AWS Service Catalog-produkter kan oppgraderes på plass for å dra nytte av nye funksjoner.
Til slutt, overgangen mot administrerte tjenester på AWS betyr at dataressurser blir klargjort og stengt etter behov. Dette har gitt kostnadsbesparelser og fleksibilitet, samtidig som det er på linje med NatWests ambisjon om å være null i 2050 på grunn av en estimert 75 % reduksjon i CO2 utslipp.
konklusjonen
Innføringen av en sky-først-strategi hos NatWest Group førte til etableringen av en robust AWS-løsning som kan støtte et stort antall forretningsapplikasjonsteam på tvers av organisasjonen. Å administrere infrastruktur med AWS Service Catalog har forbedret skyen onboarding-prosessen betraktelig ved å bruke sikre, kompatible og forhåndsgodkjente byggeklosser av infrastruktur som enkelt kan utvides. Administrerte SageMaker-infrastrukturkomponenter har forbedret modellutviklingsprosessen og akselerert leveringen av ML-prosjekter.
For å lære mer om prosessen med å bygge produksjonsklare ML-modeller hos NatWest Group, ta en titt på resten av denne firedelte serien om det strategiske samarbeidet mellom NatWest Group og AWS Professional Services:
- Del 1 forklarer hvordan NatWest Group inngikk samarbeid med AWS Professional Services for å bygge en skalerbar, sikker og bærekraftig MLOps-plattform
- Del 3 gir en oversikt over hvordan NatWest Group bruker SageMaker-tjenester for å bygge reviderbare, reproduserbare og forklarbare ML-modeller
- Del 4 detaljer hvordan NatWest datavitenskapsteam migrerer sine eksisterende modeller til SageMaker-arkitekturer
Om forfatterne
Junaid Baba er DevOps-konsulent hos AWS profesjonelle tjenester Han utnytter sin erfaring innen Kubernetes, distribuert databehandling, AI/MLOps til akselerert skyadopsjon av kunder i den britiske finansbransjen. Junaid har vært hos AWS siden juni 2018. Før det jobbet Junaid med en rekke økonomiske oppstartsbedrifter som drev DevOps-praksis. Utenom jobben har han interesser i trekking, moderne kunst og stillbilder.
Yordanka Ivanova er dataingeniør i NatWest Group. Hun har erfaring med å bygge og levere dataløsninger til selskaper i finansnæringen. Før hun begynte i NatWest, jobbet Yordanka som teknisk konsulent hvor hun fikk erfaring med å utnytte et bredt spekter av skytjenester og åpen kildekode-teknologi for å levere forretningsresultater på tvers av flere skyplattformer. På fritiden liker Yordanka å trene, reise og spille gitar.
Michael England er programvareingeniør i Data Science and Innovation-teamet hos NatWest Group. Han brenner for å utvikle løsninger for å kjøre store maskinlæringsarbeidsmengder i skyen. Før han begynte i NatWest Group, jobbet og ledet Michael i programvareingeniørteam som utviklet kritiske applikasjoner i finans- og reisebransjen. På fritiden liker han å spille gitar, reise og utforske naturen på sykkelen.
- Myntsmart. Europas beste Bitcoin og Crypto Exchange.
- Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
- CryptoHawk. Altcoin Radar. Gratis prøveperiode.
- Kilde: https://aws.amazon.com/blogs/machine-learning/part-2-how-natwest-group-built-a-secure-compliant-self-service-mlops-platform-using-aws-service- katalog-og-amazon-sagemaker/
- "
- 100
- Om oss
- akselerert
- akselerer
- adgang
- Logg inn
- tvers
- tillegg
- Ytterligere
- Adopsjon
- Fordel
- Alle
- Amazon
- blant
- beløp
- beløp
- analyse
- analytics
- Søknad
- søknader
- tilnærming
- godkjenne
- arkitektur
- Kunst
- tildelt
- revisjon
- Autentisering
- Automatisert
- Automatisering
- Automatisering og standardisering
- tilgjengelig
- AWS
- Bank
- bli
- Bak scenen
- være
- nytte
- Fordeler
- BEST
- beste praksis
- bygge
- Bygning
- virksomhet
- karbon
- hvilken
- sentralisert
- utfordre
- utfordringer
- Sjekker
- Cloud
- Skyplattform
- skytjenester
- kode
- Koding
- samarbeid
- kombinasjon
- Felles
- Selskaper
- Selskapet
- sammenlignet
- komplekse
- samsvar
- kompatibel
- komponent
- Beregn
- databehandling
- Konfigurasjon
- Tilkoblinger
- konsulent
- Container
- Containere
- inneholder
- innhold
- kontinuerlig
- kontroll
- opprettet
- Opprette
- skaperverket
- kritisk
- skikk
- Kunder
- dato
- dataanalyse
- datavitenskap
- dataforsker
- levert
- levere
- levering
- Etterspørsel
- krav
- utplassere
- utplassert
- utplasserings
- distribusjon
- distribusjoner
- beskrevet
- design
- detalj
- detaljer
- utviklet
- Utvikler
- utviklere
- utvikle
- Utvikling
- forskjellig
- vanskelig
- digitalt
- direkte
- distribueres
- distribuert databehandling
- Docker
- ikke
- ned
- kjøring
- lett
- effektiv
- innsats
- Utdype
- muliggjøre
- Endpoint
- ingeniør
- Ingeniørarbeid
- Ingeniører
- Enterprise
- Miljø
- anslått
- evaluering
- utvikle seg
- eksempel
- gjennomføring
- eksisterende
- erfaring
- Trekk
- Egenskaper
- tilbakemelding
- finansiell
- finansielle tjenester
- Først
- Fix
- fleksibilitet
- Fokus
- følge
- etter
- Fotspor
- skjema
- Rammeverk
- funksjonalitet
- framtid
- gå
- styresett
- Gruppe
- Gruppens
- Guider
- lykkelig
- hjelpe
- hjelper
- Høy
- Hvordan
- HTTPS
- Identitet
- gjennomføring
- forbedret
- inkludere
- inkludert
- inkluderer
- økt
- bransjer
- industri
- informasjon
- Infrastruktur
- Innovasjon
- innovative
- Institusjon
- integrere
- integrert
- interesser
- Interface
- Internet
- involvert
- saker
- IT
- Jobb
- nøkkel
- nøkler
- kunnskap
- stor
- siste
- føre
- LÆRE
- læring
- Led
- utnytter
- utnytte
- Bibliotek
- Begrenset
- linje
- linking
- lokal
- maskin
- maskinlæring
- laget
- større
- GJØR AT
- administrer
- fikk til
- ledelse
- administrerende
- måte
- håndbok
- Saken
- modenhet
- betyr
- medlemmer
- Metrics
- millioner
- tankene
- ML
- modell
- modeller
- overvåking
- måneder
- mer
- flytte
- flytting
- flere
- navn
- nettverk
- Nye funksjoner
- Ny plattform
- nytt produkt
- nye produkter
- Antall
- tilbudt
- offline
- onboarding
- på nett
- åpen
- Drift
- Optimalisere
- organisasjon
- Annen
- samlet
- egen
- Spesielt
- samarbeid
- lidenskapelig
- Mønster
- ytelse
- fotografering
- pilot
- plattform
- Plattformer
- spiller
- Politikk
- politikk
- portefølje
- porteføljer
- prinsipp
- privat
- Private nøkler
- prosess
- Prosesser
- Produkt
- Produksjon
- produktivitet
- Produkter
- profesjonell
- Profil
- Profiler
- prosjekt
- prosjekter
- forfremmelse
- gi
- gir
- gi
- offentlig
- kvalitet
- Rask
- raskt
- Lesning
- redusere
- redusere
- regulatorer
- forholdet
- slipp
- utgitt
- Utgivelser
- avhengighet
- Rapporter
- Repository
- krever
- påkrevd
- Krav
- ressurs
- Ressurser
- REST
- Resultater
- anmeldelse
- Rute
- Kjør
- rennende
- skalerbarhet
- skalerbar
- Skala
- Scener
- Vitenskap
- Forsker
- forskere
- SDK
- sikre
- sikkerhet
- valgt
- Serien
- tjeneste
- Tjenester
- sett
- oppsett
- Del
- delt
- signifikant
- på samme måte
- Enkelt
- So
- Software
- Software Engineer
- software engineering
- løsning
- Solutions
- bruke
- Stabilitet
- stable
- Standard
- start-ups
- startet
- Tilstand
- uttalelser
- status
- lagring
- Strategisk
- Strategi
- studio
- støtte
- Støtter
- bærekraftig
- system
- Systemer
- oppgaver
- lag
- Teknisk
- Technologies
- Teknologi
- maler
- test
- Testing
- tester
- leddet
- tema
- derfor
- Gjennom
- tid
- verktøy
- mot
- Sporing
- trafikk
- Kurs
- Transform
- Transformation
- transitt
- reiser
- Traveling
- Stol
- ui
- Uk
- oppdateringer
- bruke
- Brukere
- bruke
- utnytte
- variasjon
- Se
- virtuelle
- synlighet
- Web-basert
- om
- mens
- HVEM
- innenfor
- uten
- Arbeid
- arbeidet
- arbeid
- trene
- virker
- verden