Questo post è scritto in collaborazione con Claudia Chitu e Spyridon Dosis dell'ACAST.
Fondata nel 2014, Acasta è la società di podcast indipendente leader a livello mondiale, che offre ai creatori di podcast e agli inserzionisti di podcast la migliore esperienza di ascolto. Sostenendo un ecosistema indipendente e aperto per il podcasting, Acast mira ad alimentare il podcasting con gli strumenti e la monetizzazione necessari per prosperare.
L'azienda utilizza i servizi cloud AWS per creare prodotti basati sui dati e adattare le migliori pratiche di progettazione. Per garantire una piattaforma dati sostenibile durante le fasi di crescita e redditività, i loro team tecnologici hanno adottato una piattaforma decentralizzata architettura della rete dati.
In questo post, discutiamo di come Acast ha superato la sfida delle dipendenze accoppiate tra i team che lavorano con i dati su larga scala utilizzando il concetto di mesh di dati.
Il problema
Con una crescita ed espansione accelerate, Acast ha dovuto affrontare una sfida che ha risonanza a livello globale. Acast si è trovata con diverse business unit e una grande quantità di dati generati in tutta l'organizzazione. L’architettura monolitica e centralizzata esistente faticava a soddisfare le crescenti richieste dei consumatori di dati. Gli ingegneri dei dati trovavano sempre più difficile mantenere e scalare l'infrastruttura dei dati, con conseguenti accessi ai dati, silos di dati e inefficienze nella gestione dei dati. Un obiettivo chiave era migliorare l'esperienza dell'utente end-to-end, partendo dalle esigenze aziendali.
Acast doveva affrontare queste sfide per raggiungere una scala operativa, ovvero il numero massimo globale di persone in grado di operare in modo indipendente e fornire valore. In questo caso, Acast ha cercato di affrontare la sfida di questa struttura monolitica e il momento opportuno per valorizzare i team di prodotto, i team tecnologici e i consumatori finali. Vale la pena ricordare che hanno anche altri team di prodotto e tecnici, inclusi team operativi o aziendali, senza account AWS.
Acast ha un numero variabile di team di prodotto, in continua evoluzione unendo quelli esistenti, dividendoli, aggiungendo nuove persone o semplicemente creando nuovi team. Negli ultimi 2 anni hanno avuto tra le 10 e le 20 squadre, composte da 4-10 persone ciascuna. Ogni team possiede almeno due account AWS, fino a 10 account, a seconda della proprietà. La maggior parte dei dati prodotti da questi account viene utilizzata a valle per scopi di business intelligence (BI) e in Amazzone Atena, da centinaia di utenti aziendali ogni giorno.
La soluzione implementata da Acast è una rete di dati, architettata su AWS. La soluzione rispecchia la struttura organizzativa piuttosto che una decisione architetturale esplicita. Secondo il Manovra di Conway inversa, l’architettura tecnologica di Acast mostra isomorfismo con l’architettura aziendale. In questo caso, gli utenti aziendali possono, attraverso l'architettura data mesh, ottenere informazioni più rapide e sapere direttamente chi sono i proprietari specifici del dominio, accelerando la collaborazione. Questo sarà ulteriormente dettagliato quando discuteremo di Gestione dell'identità e dell'accesso di AWS Ruoli (IAM) utilizzati, perché uno dei ruoli è dedicato al gruppo aziendale.
Parametri di successo
Acast è riuscito a avviare e ridimensionare un nuovo prodotto di dati orientato al team e al dominio e la sua infrastruttura e configurazione corrispondente, con conseguente minore attrito nella raccolta di informazioni e utenti e consumatori più felici.
Il successo dell'implementazione ha significato valutare vari aspetti dell'infrastruttura dei dati, della gestione dei dati e dei risultati aziendali. Hanno classificato le metriche e gli indicatori nelle seguenti categorie:
- Utilizzo dei dati – Una chiara comprensione di chi consuma quale fonte di dati, materializzata con una mappatura di consumatori e produttori. Le discussioni con gli utenti hanno dimostrato che erano più contenti di avere un accesso più rapido ai dati in modo più semplice, un'organizzazione dei dati più strutturata e una mappatura chiara di chi è il produttore. Sono stati compiuti molti progressi per promuovere la loro cultura basata sui dati (alfabetizzazione dei dati, condivisione dei dati e collaborazione tra le unità aziendali).
- Governance dei dati – Con il loro oggetto del livello di servizio che indica quando le origini dati sono disponibili (tra gli altri dettagli), i team sanno chi avvisare e possono farlo in un tempo più breve quando arrivano dati in ritardo o altri problemi con i dati. Con l’istituzione di un ruolo di data steward, la proprietà è stata rafforzata.
- Produttività del team di dati – Attraverso retrospettive ingegneristiche, Acast ha scoperto che i propri team apprezzano l’autonomia nel prendere decisioni riguardanti i propri domini di dati.
- Efficienza in termini di costi e risorse – Questa è un'area in cui Acast ha osservato una riduzione della duplicazione dei dati e quindi una riduzione dei costi (in alcuni account, rimuovendo la copia dei dati al 100%), leggendo i dati tra gli account consentendo al tempo stesso il ridimensionamento.
Panoramica della mesh di dati
Una mesh di dati è un approccio sociotecnico per costruire un'architettura di dati decentralizzata utilizzando una progettazione self-service e orientata al dominio (in una prospettiva di sviluppo software) e prende in prestito la teoria della progettazione guidata dal dominio di Eric Evans e quella di Manuel Pais e Matthew Skelton. teoria delle topologie di squadra. È importante stabilire il contesto per capire cos'è la mesh di dati perché pone le basi per i dettagli tecnici che seguono e può aiutarti a capire come i concetti discussi in questo post si inseriscono nel quadro più ampio di una mesh di dati.
Per ricapitolare prima di approfondire l’implementazione di Acast, il concetto di mesh di dati si basa sui seguenti principi:
- È guidato dal dominio, al contrario delle pipeline come preoccupazione di prima classe
- Serve i dati come un prodotto
- È un buon prodotto che soddisfa gli utenti (i dati sono affidabili, la documentazione è disponibile ed è facilmente utilizzabile)
- Offre governance computazionale federata e proprietà decentralizzata: una piattaforma dati self-service
Architettura guidata dal dominio
Nell'approccio di Acast di possedere i set di dati operativi e analitici, i team sono strutturati con proprietà basata sul dominio, leggendo direttamente dal produttore dei dati, tramite un'API o in modo programmatico dallo storage Amazon S3 o utilizzando Athena come motore di query SQL. Alcuni esempi di domini Acast sono presentati nella figura seguente.
Come illustrato nella figura precedente, alcuni domini sono liberamente associati agli endpoint operativi o analitici di altri domini, con una proprietà diversa. Altri potrebbero avere una dipendenza più forte, come previsto, per il business (alcuni podcaster possono essere anche inserzionisti, creando creatività di sponsorizzazione e conducendo campagne per i propri programmi o effettuando transazioni pubblicitarie utilizzando il software come servizio di Acast).
I dati come prodotto
Trattare i dati come un prodotto implica tre componenti chiave: i dati stessi, i metadati, il codice e l’infrastruttura associati. In questo approccio, i team responsabili della generazione dei dati vengono chiamati produttori. Questi team di produttori possiedono una conoscenza approfondita dei loro consumatori e comprendono come viene utilizzato il loro prodotto dati. Eventuali modifiche previste dai produttori di dati vengono comunicate in anticipo a tutti i consumatori. Questa notifica proattiva garantisce che i processi a valle non vengano interrotti. Fornendo ai consumatori un preavviso, questi hanno tempo sufficiente per prepararsi e adattarsi ai cambiamenti imminenti, mantenendo un flusso di lavoro fluido e ininterrotto. I produttori eseguono una nuova versione del set di dati iniziale in parallelo, avvisano individualmente i consumatori e discutono con loro il periodo di tempo necessario per iniziare a consumare la nuova versione. Quando tutti i consumatori utilizzano la nuova versione, i produttori rendono non disponibile la versione iniziale.
Gli schemi di dati vengono dedotti dal formato comune concordato per condividere file tra i team, che è Parquet nel caso di Acast. I dati possono essere condivisi in file, eventi in batch o in streaming e altro ancora. Ogni team ha il proprio account AWS che agisce come entità indipendente e autonoma con la propria infrastruttura. Per l'orchestrazione, usano il file Kit di sviluppo cloud AWS (AWS CDK) per l'infrastruttura come codice (IaC) e Colla AWS Cataloghi dati per la gestione dei metadati. Gli utenti possono anche avanzare richieste ai produttori per migliorare il modo in cui i dati vengono presentati o per arricchire i dati con nuovi punti dati per generare un valore aziendale più elevato.
Poiché ogni team possiede un account AWS e un ID catalogo dati di Athena, è semplice vedere tutto ciò attraverso le lenti di un data Lake distribuito su Amazon S3, con un catalogo comune che mappa tutti i cataloghi di tutti gli account.
Allo stesso tempo, ogni team può anche mappare altri cataloghi sul proprio account e utilizzare i propri dati, che produce insieme ai dati di altri account. A meno che non si tratti di dati sensibili, è possibile accedere ai dati a livello di programmazione o dal file Console di gestione AWS in modalità self-service senza dipendere dagli ingegneri dell'infrastruttura dati. Si tratta di un modo condiviso e indipendente dal dominio per gestire autonomamente i dati. La scoperta del prodotto avviene tramite la registrazione a catalogo. Utilizzando solo pochi standard comunemente concordati e adottati in tutta l'azienda, ai fini dell'interoperabilità, Acast ha affrontato i silos frammentati e le difficoltà legate allo scambio di dati o al consumo di dati indipendenti dal dominio.
Con questo principio, i team hanno la garanzia che i dati siano sicuri, affidabili e accurati e che vengano gestiti controlli di accesso adeguati a ciascun livello di dominio. Inoltre, sull'account centrale, vengono definiti i ruoli per diversi tipi di permessi e accessi, utilizzando Centro di identità AWS IAM autorizzazioni. Tutti i set di dati sono rilevabili da un unico account centrale. La figura seguente illustra come viene strumentato, in cui due ruoli IAM vengono assunti da due tipi di gruppi di utenti (consumatori): uno che ha accesso a un set di dati limitato, ovvero dati limitati, e uno che ha accesso a dati non limitati. Esiste anche un modo per assumere uno qualsiasi di questi ruoli, per gli account di servizio, come quelli utilizzati dai processi di elaborazione dati in Flussi di lavoro gestiti da Amazon per Apache Airflow (Amazon MWAA), per esempio.
Come Acast ha risolto il problema dell'allineamento elevato e di un'architettura liberamente accoppiata
Il diagramma seguente mostra un'architettura concettuale di come i team di Acast organizzano i dati e collaborano tra loro.
Acast ha utilizzato il Quadro ben architettato affinché l'account centrale migliori la propria pratica di esecuzione di carichi di lavoro analitici nel cloud. Attraverso le lenti dello strumento, Acast è stata in grado di garantire un monitoraggio migliore, ottimizzazione dei costi, prestazioni e sicurezza. Li ha aiutati a comprendere le aree in cui avrebbero potuto migliorare i propri carichi di lavoro e come affrontare i problemi comuni, con soluzioni automatizzate, nonché come misurare il successo, definendo i KPI. Ha fatto risparmiare loro tempo per acquisire conoscenze che altrimenti avrebbero richiesto più tempo per essere reperite. Spyridon Dosis, responsabile della sicurezza delle informazioni di Acast, condivide: "Siamo lieti che AWS sia sempre all'avanguardia nel rilascio di strumenti che consentono la configurazione, la valutazione e la revisione della configurazione di più account. Questo è un grande vantaggio per noi, che lavoriamo in un’organizzazione decentralizzata”. Spyridon aggiunge inoltre: "Un concetto molto importante che apprezziamo sono le impostazioni predefinite di sicurezza di AWS (ad esempio la crittografia predefinita per i bucket S3)."
Nel diagramma dell'architettura, possiamo vedere che ciascun team può essere un produttore di dati, ad eccezione del team che possiede l'account centrale, che funge da piattaforma dati centrale, modellando la logica da più domini per dipingere il quadro aziendale completo. Tutti gli altri team possono essere produttori o consumatori di dati. Possono connettersi all'account centrale e scoprire set di dati tramite il catalogo dati AWS Glue su più account, analizzarli nell'editor di query Athena o con i notebook Athena oppure mappare il catalogo sul proprio account AWS. L'accesso al catalogo centrale Athena è implementato con IAM Identity Center, con ruoli per dati aperti e accesso limitato ai dati.
Per i dati non sensibili (dati aperti), Acast utilizza un modello in cui i set di dati sono per impostazione predefinita aperti a tutta l'organizzazione per la lettura, utilizzando una condizione per fornire il parametro ID assegnato dall'organizzazione, come mostrato nel seguente snippet di codice:
Quando gestiscono dati sensibili come quelli finanziari, i team utilizzano un modello collaborativo di gestione dei dati. L'amministratore dei dati collabora con il richiedente per valutare la giustificazione dell'accesso per il caso d'uso previsto. Insieme, determinano i metodi di accesso appropriati per soddisfare le esigenze mantenendo la sicurezza. Ciò potrebbe includere ruoli IAM, account di servizio o servizi AWS specifici. Questo approccio consente agli utenti aziendali esterni all'organizzazione tecnologica (il che significa che non dispongono di un account AWS) di accedere e analizzare in modo indipendente le informazioni di cui hanno bisogno. Garantendo l'accesso tramite policy IAM alle risorse AWS Glue e ai bucket S3, Acast fornisce funzionalità self-service pur continuando a gestire i dati delicati attraverso la revisione umana. Il ruolo di data steward si è rivelato prezioso per comprendere i casi d'uso, valutare i rischi per la sicurezza e, in definitiva, facilitare l'accesso che accelera il business attraverso approfondimenti analitici.
Per il caso d’uso di Acast, non erano necessari controlli granulari degli accessi a livello di riga o colonna, quindi l’approccio era sufficiente. Tuttavia, altre organizzazioni potrebbero richiedere una governance più dettagliata sui campi dei dati sensibili. In questi casi, soluzioni come Formazione AWS Lake potrebbe implementare le autorizzazioni necessarie, fornendo comunque un modello di accesso ai dati self-service. Per ulteriori informazioni, fare riferimento a Progetta un'architettura data mesh utilizzando AWS Lake Formation e AWS Glue.
Allo stesso tempo, i team possono leggere direttamente da altri produttori, da Amazon S3 o tramite un'API, mantenendo la dipendenza al minimo, il che aumenta la velocità di sviluppo e consegna. Pertanto, un account può essere un produttore e un consumatore in parallelo. Ogni team è autonomo ed è responsabile del proprio stack tecnologico.
Ulteriori apprendimenti
Cosa ha imparato Acast? Finora abbiamo discusso del fatto che la progettazione architettonica è un effetto della struttura organizzativa. Poiché l'organizzazione tecnologica è composta da più team interfunzionali ed è semplice avviare un nuovo team, seguendo i principi comuni del data mesh, Acast ha imparato che ciò non avviene sempre senza soluzione di continuità. Per configurare un account completamente nuovo in AWS, i team affrontano lo stesso percorso, ma leggermente diverso, considerando le proprie peculiarità.
Ciò può creare alcuni attriti ed è difficile convincere tutti i team che producono dati a raggiungere un’elevata maturità come produttori di dati. Ciò può essere spiegato dalle diverse competenze sui dati in questi team interfunzionali e dal fatto che non si tratta di team dati dedicati.
Implementando la soluzione decentralizzata, Acast ha affrontato in modo efficace la sfida della scalabilità adattando i propri team per allinearli alle esigenze aziendali in evoluzione. Questo approccio garantisce un elevato disaccoppiamento e allineamento. Inoltre, hanno rafforzato la proprietà, riducendo significativamente il tempo necessario per identificare e risolvere i problemi perché la fonte a monte è immediatamente conosciuta e facilmente accessibile con SLA specifici. Il volume delle richieste di supporto dati ha registrato una riduzione di oltre il 50%, poiché gli utenti aziendali hanno la possibilità di ottenere informazioni più rapide. In particolare, sono riusciti a eliminare decine di terabyte di spazio di archiviazione ridondante che in precedenza venivano copiati esclusivamente per soddisfare le richieste downstream. Questo risultato è stato reso possibile attraverso l’implementazione della lettura incrociata dei conti, che ha portato all’eliminazione dei costi di sviluppo e manutenzione associati a questi gasdotti.
Conclusione
Acast ha utilizzato la legge sulla manovra di Conway inversa e ha impiegato servizi AWS in cui ogni team di prodotto interfunzionale ha il proprio account AWS per creare un'architettura mesh di dati che consenta scalabilità, proprietà elevata e consumo di dati self-service. Ciò ha funzionato bene per l'azienda, per quanto riguarda l'approccio alla proprietà dei dati e alle operazioni, per soddisfare i principi ingegneristici, con il risultato che la mesh dei dati è un effetto piuttosto che un intento deliberato. Per altre organizzazioni, la mesh di dati desiderata potrebbe apparire diversa e l’approccio potrebbe avere altri insegnamenti.
Per concludere, a moderna architettura dei dati su AWS consente di costruire in modo efficiente prodotti dati e infrastrutture data mesh a basso costo senza compromettere le prestazioni.
Di seguito sono riportati alcuni esempi di servizi AWS che puoi utilizzare per progettare la mesh di dati desiderata su AWS:
Informazioni sugli autori
Claudia Chitu è un Data Strategist e un leader influente nello spazio Analytics. Focalizzata sull'allineamento delle iniziative relative ai dati con gli obiettivi strategici generali dell'organizzazione, utilizza i dati come forza guida per la pianificazione a lungo termine e la crescita sostenibile.
Spyridon Dosis è un professionista della sicurezza informatica in Acast. Spyridon supporta l'organizzazione nella progettazione, implementazione e gestione dei propri servizi in modo sicuro, proteggendo l'azienda e i dati degli utenti.
Srikant Das è un Acceleration Lab Solutions Architect presso Amazon Web Services. Ha oltre 13 anni di esperienza nell'analisi dei Big Data e nell'ingegneria dei dati, dove gli piace creare soluzioni affidabili, scalabili ed efficienti. Al di fuori del lavoro, gli piace viaggiare e bloggare le sue esperienze sui social media.
- Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
- PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
- PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
- PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
- Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
- Fonte: https://aws.amazon.com/blogs/big-data/design-a-data-mesh-on-aws-that-reflects-the-envisioned-organization/
- :ha
- :È
- :non
- :Dove
- $ SU
- 10
- 100
- 120
- 13
- 2014
- 2020
- a
- capace
- Chi siamo
- accelerata
- accelera
- accelerazione
- accesso
- Accesso ai dati
- accessibile
- accessibile
- Il mio account
- responsabile
- conti
- preciso
- realizzazione
- operanti in
- recitazione
- Action
- adattare
- l'aggiunta di
- indirizzo
- indirizzata
- Aggiunge
- adottato
- Ads - Annunci
- avanzare
- gli inserzionisti
- concordato
- avanti
- mira
- allineare
- allineamento
- allineamento
- Tutti
- consentire
- consente
- lungo
- anche
- sempre
- Amazon
- Amazon Web Services
- Tra
- tra
- quantità
- an
- Analitico
- analitica
- analizzare
- ed
- e infrastruttura
- in qualsiasi
- Apache
- api
- apprezzare
- approccio
- opportuno
- architettonico
- architettura
- SONO
- RISERVATA
- aree
- AS
- aspetti
- valutare
- valutazione
- associato
- assumere
- assunto
- garanzia
- At
- Automatizzata
- autonomo
- Autonomia
- disponibile
- AWS
- Colla AWS
- Formazione AWS Lake
- basato
- BE
- perché
- stato
- prima
- essendo
- MIGLIORE
- best practice
- Meglio
- fra
- Big
- Big Data
- Blogging
- bootstrap
- più ampia
- costruire
- Costruzione
- affari
- business intelligence
- ma
- by
- Responsabile Campagne
- Materiale
- funzionalità
- Custodie
- casi
- catalogo
- cataloghi
- categoria
- centro
- centrale
- centralizzata
- certo
- Challenge
- sfide
- impegnativo
- championing
- Modifiche
- classificato
- pulire campo
- Cloud
- servizi cloud
- codice
- collaborando
- collaborazione
- collaborativo
- arrivo
- Uncommon
- comunemente
- comunicato
- azienda
- componenti
- compromettendo
- computazionale
- concetto
- concetti
- concettuale
- concludere
- condizione
- Configurazione
- Connettiti
- considerando
- Consistente
- consiste
- costruire
- consumare
- Consumer
- Consumatori
- consumo
- contesto
- continuamente
- controlli
- Corrispondente
- Costo
- riduzione dei costi
- Costi
- potuto
- accoppiato
- creare
- Creazione
- creativi
- creatori
- team interfunzionali
- Cultura
- dati
- l'accesso ai dati
- Dati Analytics
- infrastruttura dati
- Lago di dati
- gestione dei dati
- Piattaforma dati
- punti dati
- elaborazione dati
- condivisione dei dati
- data-driven
- dataset
- giorno
- decentrata
- decisione
- decisioni
- dedicato
- più profondo
- Predefinito
- defaults
- definito
- definizione
- consegnare
- consegna
- richieste
- dipendenze
- Dipendenza
- dipendente
- Dipendente
- Design
- progettazione
- desiderato
- dettagliati
- dettagli
- Determinare
- Mercato
- DID
- diverso
- difficile
- direttamente
- scopri
- scoperta
- discutere
- discusso
- discussioni
- display
- distribuito
- paesaggio differenziato
- immersione
- do
- documentazione
- non
- dominio
- domini
- Dont
- spinto
- e
- ogni
- facilmente
- ecosistema
- editore
- effetto
- in maniera efficace
- efficiente
- in modo efficiente
- elevando
- eliminato
- occupato
- impiegando
- impiega
- il potere
- enable
- abilitato
- Abilita
- consentendo
- crittografia
- fine
- da un capo all'altro
- endpoint
- motore
- Ingegneria
- Ingegneri
- accrescere
- Migliora
- arricchire
- garantire
- assicura
- Intero
- entità
- previsto
- eric
- stabilire
- Etere (ETH)
- valutare
- eventi
- Ogni
- ogni giorno
- evoluzione
- esempio
- Esempi
- Tranne
- exchange
- esistente
- espansione
- previsto
- esperienza
- Esperienze
- ha spiegato
- facilitando
- lontano
- più veloce
- pochi
- campi
- figura
- File
- dati finanziari
- Trovare
- ricerca
- in forma
- concentrato
- seguire
- i seguenti
- Nel
- forza
- formato
- formazione
- essere trovato
- frammentato
- Contesto
- attrito
- da
- Carburante
- Adempiere
- pieno
- completamente
- ulteriormente
- Inoltre
- Guadagno
- raccolta
- generato
- la generazione di
- ottenere
- globali
- Globalmente
- Go
- Obiettivi
- buono
- la governance
- governo
- rilascio
- granulare
- Gruppo
- Gruppo
- Crescita
- Crescita
- guidare
- ha avuto
- Manovrabilità
- accade
- più felice
- contento
- Avere
- avendo
- he
- Aiuto
- aiutato
- Alta
- superiore
- il suo
- Come
- Tutorial
- Tuttavia
- http
- HTTPS
- umano
- centinaia
- IAC
- IAM
- ID
- identificare
- Identità
- illustra
- realizzare
- implementazione
- implementato
- Implementazione
- importante
- competenze
- in
- Uno sguardo approfondito sui miglioramenti dei pneumatici da corsa di Bridgestone.
- includere
- Compreso
- sempre più
- studente indipendente
- indipendentemente
- Individualmente
- inefficienze
- Influente
- informazioni
- informazioni di sicurezza
- Infrastruttura
- inizialmente
- iniziative
- Richieste
- intuizioni
- Intelligence
- destinato
- intento
- Interoperabilità
- ai miglioramenti
- sicurezza
- IT
- SUO
- stessa
- Offerte di lavoro
- viaggio
- jpg
- conservazione
- Le
- Sapere
- conoscenze
- conosciuto
- laboratorio
- lago
- Cognome
- In ritardo
- Legge
- leader
- principale
- IMPARARE
- imparato
- meno
- lenti
- meno
- Livello
- piace
- Limitato
- Ascolto
- alfabetizzazione
- logica
- a lungo termine
- più a lungo
- Guarda
- lotto
- Basso
- fatto
- mantenere
- mantenimento
- manutenzione
- Maggioranza
- make
- gestito
- gestione
- modo
- carta geografica
- mappatura
- matthew
- maturità
- massimo
- Maggio..
- significato
- si intende
- significava
- misurare
- Media
- Soddisfare
- fusione
- maglia
- Metadati
- metodi
- Metrica
- forza
- ordine
- modello
- modellismo
- monetazione
- monitoraggio
- Scopri di più
- Inoltre
- multiplo
- necessaria
- Bisogno
- di applicazione
- esigenze
- New
- segnatamente
- computer portatili
- Avviso..
- notifica
- numero
- oggetto
- obiettivo
- osservato
- of
- Offerte
- Responsabile
- on
- ONE
- quelli
- esclusivamente
- aprire
- dati aperti
- operare
- operativo
- operativa
- Operazioni
- opposto
- or
- orchestrazione
- minimo
- organizzazione
- organizzativa
- organizzazioni
- organizzazione
- Altro
- Altri
- altrimenti
- risultati
- al di fuori
- ancora
- complessivo
- proprio
- proprietari
- proprietà
- possedere
- possiede
- dipingere
- Parallel
- parametro
- Persone
- per
- performance
- permessi
- prospettiva
- fasi
- immagine
- posto
- previsto
- pianificazione
- piattaforma
- Platone
- Platone Data Intelligence
- PlatoneDati
- più
- Podcast
- podcasting
- punti
- Termini e Condizioni
- possedere
- possibile
- Post
- pratica
- pratiche
- precedente
- Preparare
- presentata
- in precedenza
- Direttore
- principio
- principi
- Proactive
- i processi
- lavorazione
- produrre
- Prodotto
- produttore
- Produttori
- produzione
- Prodotto
- Prodotti
- professionale
- redditività
- Progressi
- proteggere
- fornire
- fornisce
- fornitura
- scopo
- fini
- aumentare
- piuttosto
- raggiungere
- Leggi
- prontamente
- Lettura
- ricapitolare
- riducendo
- riduzione
- riferimento
- di cui
- riflette
- per quanto riguarda
- Iscrizione
- rilascio
- affidabile
- rimozione
- rimozione
- richieste
- richiedere
- risolvere
- risuona
- risorsa
- Risorse
- responsabile
- limitato
- risultante
- recensioni
- rischi
- Ruolo
- ruoli
- Correre
- running
- stesso
- salvato
- Scalabilità
- scalabile
- Scala
- scala
- senza soluzione di continuità
- sicuro
- problemi di
- rischi per la sicurezza
- vedere
- visto
- Fai da te
- delicata
- serve
- servizio
- Servizi
- set
- Set
- flessibile.
- Condividi
- condiviso
- azioni
- compartecipazione
- lei
- ha mostrato
- mostrato
- Spettacoli
- significativamente
- silos
- semplice
- semplicemente
- singolo
- leggermente diversa
- lisciare
- frammento
- So
- finora
- Social
- Social Media
- Software
- software come un servizio
- lo sviluppo del software
- unicamente
- soluzione
- Soluzioni
- risolto
- alcuni
- Fonte
- fonti
- lo spazio
- specifico
- specificato
- sponsorizzazione
- SQL
- pila
- Stage
- standard
- inizia a
- Di partenza
- dichiarazione
- affermando
- Ancora
- conservazione
- lineare
- Strategico
- Stratega
- ruscello
- rafforzato
- più forte
- La struttura
- strutturato
- Lottando
- il successo
- Con successo
- tale
- sufficiente
- supporto
- supporti
- sostenibile
- Crescita sostenibile
- attrezzatura
- presa
- team
- le squadre
- Tech
- Consulenza
- Tecnologia
- modello
- decine
- di
- che
- I
- le informazioni
- loro
- Li
- teoria
- Là.
- perciò
- Strumenti Bowman per analizzare le seguenti finiture:
- di
- questo
- quelli
- tre
- Prosperare
- Attraverso
- tempo
- periodo di tempo
- a
- insieme
- strumenti
- top
- transazioni
- Di viaggio
- provato
- affidabili sul mercato
- seconda
- Tipi di
- ultimo
- in definitiva
- capire
- e una comprensione reciproca
- ininterrotto
- unità
- imminenti
- su
- us
- uso
- caso d'uso
- utilizzato
- Utente
- Esperienza da Utente
- utenti
- usa
- utilizzando
- utilizzati
- Prezioso
- APPREZZIAMO
- variabile
- vario
- Fisso
- Velocità
- versione
- molto
- via
- volume
- Prima
- Modo..
- we
- sito web
- servizi web
- WELL
- sono stati
- Che
- quando
- quale
- while
- OMS
- chi
- volere
- con
- senza
- Lavora
- flusso di lavoro
- flussi di lavoro
- lavoro
- lavori
- Il mondo di
- valore
- sarebbe
- scritto
- anni
- Tu
- Trasferimento da aeroporto a Sharm
- zefiro