Dette innlegget er skrevet i samarbeid med Claudia Chitu og Spyridon Dosis fra ACAST.
Grunnlagt i 2014, Acast er verdens ledende uavhengige podcastselskap, som løfter podcastskapere og podcastannonsører for den ultimate lytteopplevelsen. Ved å forkjempe et uavhengig og åpent økosystem for podcasting, har Acast som mål å drive podcasting med verktøyene og inntektsgenereringen som trengs for å trives.
Selskapet bruker AWS Cloud-tjenester for å bygge datadrevne produkter og skalere beste praksis for ingeniørarbeid. For å sikre en bærekraftig dataplattform midt i vekst- og lønnsomhetsfaser, tok deres teknologiteam i bruk en desentralisert datanettingsarkitektur.
I dette innlegget diskuterer vi hvordan Acast overvant utfordringen med koblede avhengigheter mellom team som arbeider med data i stor skala ved å bruke konseptet med et datanettverk.
Problemet
Med en akselerert vekst og ekspansjon, møtte Acast en utfordring som gir gjenklang globalt. Acast befant seg med ulike forretningsenheter og en enorm mengde data generert på tvers av organisasjonen. Den eksisterende monolitten og sentraliserte arkitekturen slet med å møte de økende kravene til dataforbrukere. Dataingeniører fant det stadig mer utfordrende å vedlikeholde og skalere datainfrastrukturen, noe som resulterte i datatilgang, datasiloer og ineffektivitet i dataadministrasjon. Et hovedmål var å forbedre ende-til-ende-brukeropplevelsen, med utgangspunkt i forretningsbehovene.
Acast trengte å takle disse utfordringene for å komme til en operasjonell skala, noe som betyr et globalt maksimum av antall mennesker som uavhengig kan operere og levere verdi. I dette tilfellet prøvde Acast å takle utfordringen med denne monolittstrukturen og den høye tiden til verdi for produktteam, teknologiteam og sluttforbrukere. Det er verdt å nevne at de også har andre produkt- og teknologiteam, inkludert drifts- eller forretningsteam, uten AWS-kontoer.
Acast har et variabelt antall produktteam, som utvikler seg kontinuerlig ved å slå sammen eksisterende, dele dem opp, legge til nye personer eller ganske enkelt opprette nye team. De siste 2 årene har de hatt mellom 10–20 lag, bestående av 4–10 personer hver. Hvert lag eier minst to AWS-kontoer, opptil 10 kontoer, avhengig av eierskapet. Majoriteten av dataene som produseres av disse kontoene brukes nedstrøms til business intelligence (BI) formål og i Amazonas Athena, av hundrevis av bedriftsbrukere hver dag.
Løsningen Acast implementerte er et datanettverk, bygget på AWS. Løsningen speiler organisasjonsstrukturen snarere enn en eksplisitt arkitektonisk beslutning. I henhold til Omvendt Conway-manøver, Acasts teknologiarkitektur viser isomorfisme med forretningsarkitekturen. I dette tilfellet blir bedriftsbrukerne aktivert gjennom datamaskeringsarkitekturen for å få raskere tid til innsikt og vite direkte hvem de spesifikke domeneeierne er, og påskynde samarbeidet. Dette vil bli mer detaljert når vi diskuterer AWS identitets- og tilgangsadministrasjon (IAM) roller brukt, fordi en av rollene er dedikert til forretningsgruppen.
Parametre for suksess
Acast lyktes med å starte opp og skalere et nytt team- og domeneorientert dataprodukt og tilhørende infrastruktur og oppsett, noe som resulterte i mindre friksjon i å samle inn innsikt og fornøyde brukere og forbrukere.
Suksessen med implementeringen innebar å vurdere ulike aspekter ved datainfrastrukturen, dataadministrasjon og forretningsresultater. De klassifiserte beregningene og indikatorene i følgende kategorier:
- Databruk – En klar forståelse av hvem som forbruker hvilken datakilde, materialisert med en kartlegging av forbrukere og produsenter. Diskusjoner med brukere viste at de var mer fornøyde med å ha raskere tilgang til data på en enklere måte, en mer strukturert dataorganisasjon og en tydelig kartlegging av hvem produsenten er. Det er gjort mye fremgang for å fremme deres datadrevne kultur (datakompetanse, datadeling og samarbeid på tvers av forretningsenheter).
- Datastyring – Med deres tjenestenivåobjekt som angir når datakildene er tilgjengelige (blant andre detaljer), vet teamene hvem de skal varsle og kan gjøre det på kortere tid når det kommer for sent inn data eller andre problemer med dataene. Med en dataforvalter-rolle på plass er eierskapet styrket.
- Datateamets produktivitet – Gjennom tekniske retrospektiver fant Acast ut at teamene deres setter pris på autonomi til å ta beslutninger angående datadomenene deres.
- Kostnads- og ressurseffektivitet – Dette er et område hvor Acast observerte en reduksjon i dataduplisering, og dermed kostnadsreduksjon (i noen kontoer, fjerning av kopien av data 100%), ved å lese data på tvers av kontoer samtidig som skalering ble mulig.
Oversikt over datanettverk
Et datanett er en sosioteknisk tilnærming for å bygge en desentralisert dataarkitektur ved å bruke et domeneorientert, selvbetjent design (i et programvareutviklingsperspektiv), og låner Eric Evans teori om domenedrevet design og Manuel Pais og Matthew Skeltons. teori om teamtopologier. Det er viktig å etablere konteksten for å forstå hva datanettverk er fordi det setter scenen for de tekniske detaljene som følger og kan hjelpe deg å forstå hvordan konseptene som er diskutert i dette innlegget passer inn i det bredere rammeverket til et datanettverk.
For å oppsummere før du dykker dypere inn i Acasts implementering, er datanettkonseptet basert på følgende prinsipper:
- Det er domenedrevet, i motsetning til rørledninger som en førsteklasses bekymring
- Den tjener data som et produkt
- Det er et godt produkt som gleder brukere (data er pålitelige, dokumentasjon er tilgjengelig og det er enkelt å bruke)
- Den tilbyr føderert beregningsstyring og desentralisert eierskap – en selvbetjent dataplattform
Domenedrevet arkitektur
I Acasts tilnærming til å eie de operasjonelle og analytiske datasettene, er team strukturert med eierskap basert på domene, som leser direkte fra produsenten av dataene, via en API eller programmatisk fra Amazon S3-lagring eller bruker Athena som en SQL-spørringsmotor. Noen eksempler på Acasts domener er presentert i følgende figur.
Som illustrert i den foregående figuren, er noen domener løst koblet til andre domeners operasjonelle eller analytiske endepunkter, med et annet eierskap. Andre kan ha sterkere avhengighet, som forventes, for virksomheten (noen podcastere kan også være annonsører, lage sponsorreklamer og kjøre kampanjer for sine egne show, eller utføre annonser ved å bruke Acasts programvare som en tjeneste).
Data som et produkt
Å behandle data som et produkt innebærer tre nøkkelkomponenter: selve dataene, metadataene og tilhørende kode og infrastruktur. I denne tilnærmingen omtales team som er ansvarlige for å generere data produsenter. Disse produsentteamene har inngående kunnskap om forbrukerne sine, og forstår hvordan dataproduktet deres brukes. Eventuelle endringer planlagt av dataprodusentene kommuniseres på forhånd til alle forbrukere. Denne proaktive varslingen sikrer at nedstrømsprosesser ikke forstyrres. Ved å gi forbrukerne forhåndsvarsel, har de tilstrekkelig tid til å forberede seg på og tilpasse seg de kommende endringene, og opprettholde en jevn og uavbrutt arbeidsflyt. Produsentene kjører en ny versjon av det første datasettet parallelt, varsler forbrukerne individuelt og diskuterer med dem deres nødvendige tidsramme for å begynne å konsumere den nye versjonen. Når alle forbrukere bruker den nye versjonen, gjør produsentene den første versjonen utilgjengelig.
Dataskjemaer utledes fra det vanlige avtalte formatet for å dele filer mellom team, som er Parquet i tilfellet med Acast. Data kan deles i filer, batch- eller strømmehendelser og mer. Hvert team har sin egen AWS-konto som fungerer som en uavhengig og autonom enhet med sin egen infrastruktur. For orkestrering bruker de AWS skyutviklingssett (AWS CDK) for infrastruktur som kode (IaC) og AWS Lim Datakataloger for metadatahåndtering. Brukere kan også sende forespørsler til produsenter om å forbedre måten dataene presenteres på eller for å berike dataene med nye datapunkter for å generere en høyere forretningsverdi.
Med hvert team som eier en AWS-konto og en datakatalog-ID fra Athena, er det enkelt å se dette gjennom linsene til en distribuert datainnsjø på toppen av Amazon S3, med en felles katalog som kartlegger alle katalogene fra alle kontoene.
Samtidig kan hvert team også kartlegge andre kataloger til sin egen konto og bruke sine egne data, som de produserer sammen med data fra andre kontoer. Med mindre det er sensitive data, kan dataene nås programmatisk eller fra AWS-administrasjonskonsoll på en selvbetjent måte uten å være avhengig av datainfrastrukturingeniørene. Dette er en domeneagnostisk, delt måte å selvbetjente data på. Produktoppdagelsen skjer gjennom katalogregistreringen. Ved å bruke bare noen få standarder som vanligvis er blitt enige om og vedtatt på tvers av selskapet, for interoperabilitetsformål, adresserte Acast de fragmenterte siloene og friksjonen for å utveksle data eller konsumere domeneagnostiske data.
Med dette prinsippet får teamene forsikring om at dataene er sikre, pålitelige og nøyaktige, og passende tilgangskontroller administreres på hvert domenenivå. Dessuten, på den sentrale kontoen, er roller definert for ulike typer tillatelser og tilgang, ved hjelp av AWS IAM Identity Center tillatelser. Alle datasett kan oppdages fra en enkelt sentral konto. Følgende figur illustrerer hvordan det er instrumentert, der to IAM-roller antas av to typer brukergrupper (forbrukergrupper): en som har tilgang til et begrenset datasett, som er begrensede data, og en som har tilgang til ikke-begrensede data. Det er også en måte å påta seg noen av disse rollene for tjenestekontoer, for eksempel de som brukes av databehandlingsjobber i Amazon administrerte arbeidsflyter for Apache Airflow (Amazon MWAA), for eksempel.
Hvordan Acast løste for høy justering og en løst koblet arkitektur
Følgende diagram viser en konseptuell arkitektur for hvordan Acasts team organiserer data og samarbeider med hverandre.
Acast brukte Velarbeidet rammeverk for den sentrale kontoen for å forbedre praksisen med å kjøre analytiske arbeidsbelastninger i skyen. Gjennom linsene til verktøyet var Acast i stand til å adressere bedre overvåking, kostnadsoptimalisering, ytelse og sikkerhet. Det hjalp dem å forstå områdene der de kunne forbedre arbeidsbelastningen og hvordan de kan løse vanlige problemer, med automatiserte løsninger, samt hvordan de kan måle suksessen, definere KPIer. Det sparte dem for tid å få læringen som ellers ville tatt lengre tid å finne. Spyridon Dosis, Acasts informasjonssikkerhetsansvarlig, deler: "Vi er glade for at AWS alltid er i forkant med å lansere verktøy som muliggjør konfigurasjon, vurdering og gjennomgang av multikontooppsett. Dette er et stort pluss for oss som jobber i en desentralisert organisasjon.» Spyridon legger også til, "Et veldig viktig konsept vi verdsetter er AWS-sikkerhetsstandardene (f.eks. standardkryptering for S3-bøtter)."
I arkitekturdiagrammet kan vi se at hvert team kan være en dataprodusent, bortsett fra teamet som eier den sentrale kontoen, som fungerer som den sentrale dataplattformen, og modellerer logikken fra flere domener for å male hele forretningsbildet. Alle andre team kan være dataprodusenter eller dataforbrukere. De kan koble til den sentrale kontoen og oppdage datasett via AWS Glue Data Catalog på tvers av kontoer, analysere dem i Athena spørringsredigering eller med Athena notatbøker, eller tilordne katalogen til sin egen AWS-konto. Tilgang til den sentrale Athena-katalogen er implementert med IAM Identity Center, med roller for åpne data og begrenset datatilgang.
For ikke-sensitive data (åpne data), bruker Acast en mal der datasettene som standard er åpne for hele organisasjonen å lese fra, ved å bruke en betingelse for å gi den organisasjonstildelte ID-parameteren, som vist i følgende kodebit:
Når de håndterer sensitive data som økonomi, bruker teamene en samarbeidsmodell for dataansvarlig. Dataansvarlig samarbeider med rekvirenten for å evaluere tilgangsbegrunnelsen for den tiltenkte brukssaken. Sammen bestemmer de passende tilgangsmetoder for å møte behovet samtidig som sikkerheten opprettholdes. Dette kan inkludere IAM-roller, tjenestekontoer eller spesifikke AWS-tjenester. Denne tilnærmingen gjør det mulig for forretningsbrukere utenfor den tekniske organisasjonen (som betyr at de ikke har en AWS-konto) uavhengig tilgang til og analysere informasjonen de trenger. Ved å gi tilgang gjennom IAM-policyer på AWS Glue-ressurser og S3-bøtter, gir Acast selvbetjeningsfunksjoner samtidig som den styrer delikate data gjennom menneskelig gjennomgang. Dataforvalter-rollen har vært verdifull for å forstå brukstilfeller, vurdere sikkerhetsrisikoer og til slutt forenkle tilgang som akselererer virksomheten gjennom analytisk innsikt.
For Acasts brukstilfelle var det ikke nødvendig med granulære tilgangskontroller på rad- eller kolonnenivå, så tilnærmingen var tilstrekkelig. Imidlertid kan andre organisasjoner kreve mer finmasket styring over sensitive datafelt. I de tilfellene vil løsninger som AWS Lake formasjon kunne implementere nødvendige tillatelser, samtidig som de gir en selvbetjent datatilgangsmodell. For mer informasjon, se Design en datanettingsarkitektur ved å bruke AWS Lake Formation og AWS Glue.
Samtidig kan team lese fra andre produsenter direkte, fra Amazon S3 eller via en API, og holde avhengigheten på et minimum, noe som øker hastigheten på utvikling og levering. Derfor kan en konto være en produsent og en forbruker parallelt. Hvert lag er autonomt og er ansvarlig for sin egen teknologistabel.
Ytterligere læring
Hva lærte Acast? Så langt har vi diskutert at den arkitektoniske utformingen er en effekt av organisasjonsstrukturen. Fordi den tekniske organisasjonen består av flere tverrfunksjonelle team, og det er enkelt å starte opp et nytt team, etter de vanlige prinsippene for datanettverk, lærte Acast at dette ikke går sømløst hver gang. For å sette opp en helt ny konto i AWS, går team gjennom den samme reisen, men litt annerledes, med tanke på deres egne særtrekk.
Dette kan skape visse friksjoner, og det er vanskelig å få alle dataproduserende team til å nå en høy modenhet av å være dataprodusenter. Dette kan forklares med de forskjellige datakompetansene i disse tverrfunksjonelle teamene og ikke er dedikerte datateam.
Ved å implementere den desentraliserte løsningen taklet Acast skalerbarhetsutfordringen effektivt ved å tilpasse teamene deres til å tilpasse seg endrede forretningsbehov. Denne tilnærmingen sikrer høy frakobling og innretting. Videre styrket de eierskapet, og reduserte tiden som trengs for å identifisere og løse problemer betydelig fordi oppstrømskilden er lett kjent og lett tilgjengelig med spesifiserte SLAer. Volumet av forespørsler om datastøtte har sett en reduksjon på over 50 %, fordi forretningsbrukere har mulighet til å få raskere innsikt. Spesielt har de eliminert titalls terabyte med redundant lagring som tidligere ble kopiert utelukkende for å oppfylle nedstrømsforespørsler. Denne prestasjonen ble muliggjort gjennom implementering av avlesning på tvers av kontoer, noe som førte til fjerning av tilhørende utviklings- og vedlikeholdskostnader for disse rørledningene.
konklusjonen
Acast brukte Inverse Conway Maneuver-loven og benyttet AWS-tjenester der hvert tverrfunksjonelle produktteam har sin egen AWS-konto for å bygge en datamaskeringsarkitektur som tillater skalerbarhet, høyt eierskap og selvbetjent dataforbruk. Dette har fungert bra for selskapet, når det gjelder hvordan dataeierskap og drift ble tilnærmet, for å oppfylle deres tekniske prinsipper, noe som resulterte i å ha datanettverket som en effekt snarere enn en bevisst hensikt. For andre organisasjoner kan det ønskede datanettverket se annerledes ut, og tilnærmingen kan ha andre erfaringer.
For å konkludere, a moderne dataarkitektur på AWS lar deg effektivt konstruere dataprodukter og datanettinfrastruktur til en lav kostnad uten å gå på kompromiss med ytelsen.
Følgende er noen eksempler på AWS-tjenester du kan bruke til å designe ønsket datanettverk på AWS:
Om forfatterne
Claudia Chitu er en datastrateg og en innflytelsesrik leder i Analytics-området. Fokusert på å samkjøre datainitiativer med de overordnede strategiske målene for organisasjonen, bruker hun data som en veiledende kraft for langsiktig planlegging og bærekraftig vekst.
Spyridon Dose er en informasjonssikkerhetsekspert i Acast. Spyridon støtter organisasjonen i å designe, implementere og drifte sine tjenester på en sikker måte og beskytte selskapets og brukernes data.
Srikant Das er en Acceleration Lab Solutions Architect hos Amazon Web Services. Han har over 13 års erfaring innen Big Data-analyse og Data Engineering, hvor han liker å bygge pålitelige, skalerbare og effektive løsninger. Utenom jobben liker han å reise og blogge sine opplevelser i sosiale medier.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- kilde: https://aws.amazon.com/blogs/big-data/design-a-data-mesh-on-aws-that-reflects-the-envisioned-organization/
- : har
- :er
- :ikke
- :hvor
- $OPP
- 10
- 100
- 120
- 13
- 2014
- 2020
- a
- I stand
- Om oss
- akselerert
- akselererer
- akselerasjon
- adgang
- Tilgang til data
- aksesseres
- tilgjengelig
- Logg inn
- ansvarlig
- kontoer
- nøyaktig
- prestasjon
- tvers
- skuespill
- Handling
- tilpasse
- legge
- adresse
- adressert
- Legger
- vedtatt
- annonser
- avansere
- annonsører
- avtalte
- fremover
- mål
- justere
- justering
- innretting
- Alle
- tillate
- tillater
- langs
- også
- alltid
- Amazon
- Amazon Web Services
- Amid
- blant
- beløp
- an
- Analytisk
- analytics
- analysere
- og
- og infrastruktur
- noen
- Apache
- api
- verdsette
- tilnærming
- hensiktsmessig
- arkitektonisk
- arkitektur
- ER
- AREA
- områder
- AS
- aspekter
- vurdere
- evaluering
- assosiert
- anta
- antatt
- forsikring
- At
- Automatisert
- autonom
- Autonomi
- tilgjengelig
- AWS
- AWS Lim
- AWS Lake formasjon
- basert
- BE
- fordi
- vært
- før du
- være
- BEST
- beste praksis
- Bedre
- mellom
- Stor
- Store data
- Blogging
- Bootstrap
- bredere
- bygge
- Bygning
- virksomhet
- business intelligence
- men
- by
- Kampanjer
- CAN
- evner
- saken
- saker
- katalog
- kataloger
- kategorier
- sentrum
- sentral
- sentralisert
- viss
- utfordre
- utfordringer
- utfordrende
- største tolker
- Endringer
- klassifisert
- fjerne
- Cloud
- skytjenester
- kode
- samarbeider
- samarbeid
- samarbeids
- kommer
- Felles
- vanligvis
- kommunisert
- Selskapet
- komponenter
- kompromittere
- beregnings
- konsept
- konsepter
- konseptuelle
- konkluderer
- tilstand
- Konfigurasjon
- Koble
- vurderer
- Består
- består
- konstruere
- forbruke
- forbruker
- Forbrukere
- forbruk
- kontekst
- kontinuerlig
- kontroller
- Tilsvarende
- Kostnad
- kostnadsreduksjon
- Kostnader
- kunne
- kombinert
- skape
- Opprette
- reklamene
- skaperne
- Tverrfunksjonelle lag
- Kultur
- dato
- data tilgang
- Data Analytics
- datainfrastruktur
- Data Lake
- Dataledelse
- Dataplattform
- datapunkter
- databehandling
- datadeling
- data-drevet
- datasett
- dag
- desentralisert
- avgjørelse
- avgjørelser
- dedikert
- dypere
- Misligholde
- mislighold
- definert
- definere
- leverer
- levering
- krav
- avhengig
- Avhengighet
- avhengig
- avhengig
- utforming
- utforme
- ønsket
- detaljert
- detaljer
- Bestem
- Utvikling
- gJORDE
- forskjellig
- vanskelig
- direkte
- oppdage
- Funnet
- diskutere
- diskutert
- diskusjoner
- skjermer
- distribueres
- diverse
- dykking
- do
- dokumentasjon
- ikke
- domene
- domener
- ikke
- drevet
- e
- hver enkelt
- lett
- økosystem
- redaktør
- effekt
- effektivt
- effektiv
- effektivt
- heve
- eliminert
- ansatt
- ansette
- anvender
- empowered
- muliggjøre
- aktivert
- muliggjør
- muliggjør
- kryptering
- slutt
- ende til ende
- endepunkter
- Motor
- Ingeniørarbeid
- Ingeniører
- forbedre
- Forbedrer
- berike
- sikre
- sikrer
- Hele
- enhet
- for seg
- eric
- etablere
- Eter (ETH)
- evaluere
- hendelser
- Hver
- hver dag
- utvikling
- eksempel
- eksempler
- Unntatt
- utveksling
- eksisterende
- utvidelse
- forventet
- erfaring
- Erfaringer
- forklarte
- tilrettelegging
- langt
- raskere
- Noen få
- Felt
- Figur
- Filer
- økonomi
- Finn
- finne
- passer
- fokuserte
- følge
- etter
- Til
- Tving
- format
- formasjon
- funnet
- fragmentert
- Rammeverk
- friksjon
- fra
- Brensel
- Innfri
- fullt
- fullt
- videre
- Dess
- Gevinst
- samle
- generert
- genererer
- få
- Global
- Globalt
- Go
- Mål
- god
- styresett
- styrende
- innvilgelse
- granulær
- Gruppe
- Gruppens
- Økende
- Vekst
- førings
- HAD
- Håndtering
- skjer
- lykkeligere
- lykkelig
- Ha
- å ha
- he
- hjelpe
- hjulpet
- Høy
- høyere
- hans
- Hvordan
- Hvordan
- Men
- http
- HTTPS
- menneskelig
- Hundrevis
- IAC
- IAM
- ID
- identifisere
- Identitet
- illustrerer
- iverksette
- gjennomføring
- implementert
- implementere
- viktig
- forbedre
- in
- dyptgående
- inkludere
- Inkludert
- stadig
- uavhengig
- uavhengig av hverandre
- indikatorer
- individuelt
- ineffektivitet
- Innflytelsesrik
- informasjon
- informasjonssikkerhet
- Infrastruktur
- innledende
- initiativer
- forespørsler
- innsikt
- Intelligens
- tiltenkt
- hensikt
- Interoperabilitet
- inn
- saker
- IT
- DET ER
- selv
- Jobb
- reise
- jpg
- holde
- nøkkel
- Vet
- kunnskap
- kjent
- lab
- innsjø
- Siste
- Late
- Law
- leder
- ledende
- LÆRE
- lært
- minst
- objektiver
- mindre
- Nivå
- i likhet med
- Begrenset
- Lytting
- literacy
- logikk
- langsiktig
- lenger
- Se
- Lot
- Lav
- laget
- vedlikeholde
- opprettholde
- vedlikehold
- Flertall
- gjøre
- fikk til
- ledelse
- måte
- kart
- kartlegging
- matthew
- modenhet
- maksimal
- Kan..
- betyr
- midler
- ment
- måle
- Media
- Møt
- sammenslåing
- mesh
- metadata
- metoder
- Metrics
- kunne
- minimum
- modell
- modellering
- inntjenings
- overvåking
- mer
- Videre
- flere
- nødvendig
- Trenger
- nødvendig
- behov
- Ny
- spesielt
- notatbøker
- Legge merke til..
- varsling
- Antall
- objekt
- Målet
- observerte
- of
- Tilbud
- Offiser
- on
- ONE
- seg
- bare
- åpen
- åpne data
- betjene
- drift
- operasjonell
- Drift
- motsetning
- or
- orkestre
- rekkefølge
- organisasjon
- organisasjons
- organisasjoner
- organisering
- Annen
- andre
- ellers
- utfall
- utenfor
- enn
- samlet
- egen
- eiere
- eierskap
- eie
- eier
- maling
- Parallel
- parameter
- Ansatte
- for
- ytelse
- tillatelser
- perspektiv
- faser
- bilde
- Sted
- planlagt
- planlegging
- plattform
- plato
- Platon Data Intelligence
- PlatonData
- i tillegg til
- podcast
- Podcasting
- poeng
- Politikk
- besitter
- mulig
- Post
- praksis
- praksis
- forut
- Forbered
- presentert
- tidligere
- Principal
- prinsipp
- prinsipper
- Proaktiv
- Prosesser
- prosessering
- produsere
- produsert
- produsent
- Produsentene
- produserende
- Produkt
- Produkter
- profesjonell
- lønnsomhet
- Progress
- beskytte
- gi
- gir
- gi
- formål
- formål
- heve
- heller
- å nå
- Lese
- lett
- Lesning
- oppsummering
- redusere
- reduksjon
- referere
- referert
- Gjenspeiler
- om
- Registrering
- frigjør
- pålitelig
- fjerning
- fjerne
- forespørsler
- krever
- løse
- resonerer
- ressurs
- Ressurser
- ansvarlig
- begrenset
- resulterende
- anmeldelse
- risikoer
- Rolle
- roller
- Kjør
- rennende
- samme
- lagret
- skalerbarhet
- skalerbar
- Skala
- skalering
- sømløst
- sikre
- sikkerhet
- sikkerhetsrisiko
- se
- sett
- Selvbetjening
- sensitive
- serverer
- tjeneste
- Tjenester
- sett
- sett
- oppsett
- Del
- delt
- Aksjer
- deling
- hun
- viste
- vist
- Viser
- betydelig
- siloer
- enklere
- ganske enkelt
- enkelt
- litt annerledes
- glatter
- tekstutdrag
- So
- så langt
- selskap
- sosiale medier
- Software
- programvare som en tjeneste
- programvareutvikling
- utelukkende
- løsning
- Solutions
- løst
- noen
- kilde
- Kilder
- Rom
- spesifikk
- spesifisert
- sponsoravtale
- SQL
- stable
- Scene
- standarder
- Begynn
- Start
- Uttalelse
- sier
- Still
- lagring
- rett fram
- Strategisk
- Strategist
- stream
- styrket
- sterkere
- struktur
- strukturert
- Sliter
- suksess
- vellykket
- slik
- tilstrekkelig
- støtte
- Støtter
- bærekraftig
- Bærekraftig vekst
- takle
- ta
- lag
- lag
- tech
- Teknisk
- Teknologi
- mal
- titus
- enn
- Det
- De
- informasjonen
- deres
- Dem
- teori
- Der.
- derfor
- Disse
- de
- denne
- De
- tre
- Thrive
- Gjennom
- tid
- tidsramme
- til
- sammen
- verktøy
- verktøy
- topp
- handler
- Traveling
- prøvd
- troverdig
- to
- typer
- ultimate
- Til syvende og sist
- forstå
- forståelse
- uavbrutt
- lomper
- kommende
- upon
- us
- bruke
- bruk sak
- brukt
- Bruker
- Brukererfaring
- Brukere
- bruker
- ved hjelp av
- benyttes
- Verdifull
- verdi
- variabel
- ulike
- enorme
- Hastighet
- versjon
- veldig
- av
- volum
- var
- Vei..
- we
- web
- webtjenester
- VI VIL
- var
- Hva
- når
- hvilken
- mens
- HVEM
- hvem
- vil
- med
- uten
- Arbeid
- arbeidsflyt
- arbeidsflyt
- arbeid
- virker
- Verdens
- verdt
- ville
- skrevet
- år
- du
- Din
- zephyrnet