Data & AI Team Topologies

Data Infrastructure

Data Platform

Data Strategy

Data Products

Data Governance

Progettare l’architettura dei team per ottimizzare la delivery di prodotti dati & AI

Industries:

Finance & Insurance - Retail & GDO - Energy & Utility - Transportation - Life Science - Industrial

Solutions:

AI - Data Infrastructure - Data Platform - Data Strategy - Data Products - Data Governance

Contesto

Nel mercato attuale, estremamente dinamico e competitivo, è fondamentale per le aziende ottimizzare i flussi di generazione del valore basati su prodotti dati & AI, per stare al passo con la velocità di cambiamento richiesta, cogliere le opportunità e soddisfare continuamente le aspettative dei clienti.

Il ruolo sempre più centrale e strategico che stanno assumendo i dati e l’AI richiede alle organizzazioni di essere in grado di:
• gestire il carico cognitivo del landscape dati & AI e mantenere le conoscenze di dominio nel tempo, per essere efficienti nell’evoluzione di prodotti e servizi;
• distribuire le responsabilità di sviluppo delle soluzioni su diversi gruppi di lavoro garantendo governance e standard di qualità comuni, per aumentare la capacità produttiva;
• ridurre il tempo di consegna, per anticipare i competitor e cogliere le opportunità di mercato;
• introdurre in modo sostenibile le innovazioni tecnologiche e metodologiche, per mantenere soddisfacente l’esperienza utente.

Come affermato nel libro “Managing Data as a Product”, un’organizzazione è un complesso sistema sociotecnico, composta da persone e tecnologie. L’architettura sociale (detta anche architettura organizzativa) definisce come le persone vengono organizzate e interagiscono per generare gli outcome attesi. L’architettura tecnologica definisce come le tecnologie vengono composte e integrate per produrre valore. Tra le persone e le tecnologie (e analogamente fra le rispettive architetture) c’è una forte correlazione. Le interazioni tra persone e tecnologie avvengono all’interno di processi.

Any organization can be viewed as a complex sociotechnical system

Un’organizzazione può essere vista come un complesso sistema sociotecnico

A livello operativo, le persone sono tipicamente organizzate in Team, ciascuno dei quali può implementare una o più business capability. Nel libro “Team Topologies” , Matthew Skelton e Manuel Pais affermano: “Relying on individuals to comprehend and effectively deal with the volume and nature of information required to build and evolve modern software is not sustainable… We must, therefore, start with the team for effective software delivery”. Pertanto, il Team deve essere considerato a tutti gli effetti come l’elemento fondamentale dell’architettura sociale che abilita la generazione del valore.

La componente sociale è quella che influenza maggiormente l’intera architettura aziendale, come descritto dalla legge di Conway: “Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations”. Pertanto, in una determinata organizzazione, il modo in cui sono divise le responsabilità e i perimetri dei team e in cui questi interagiscono all’interno dei processi inevitabilmente condiziona le scelte che si possono fare nella progettazione delle architetture dati & AI, influenzando l’efficacia e l’efficienza di generazione del business outcome, così come la capacità o meno di soddisfare le aspettative degli stakeholder.

Quantyca ha avuto modo di constatare sul campo, lavorando con clienti di dimensioni, cultura aziendale e industry differenti, che modelli organizzativi inadatti al contesto spesso causano ostacoli alla velocità di delivery e alla scalabilità delle data platform. Le problematiche che spesso si osservano sono:

Design monolitici

Nei contesti in cui le data platform vengono sviluppate e mantenute da team centrali, il design del modello dati e delle soluzioni architetturali tende ad essere monolitico, senza confini logici e fisici tra i diversi business subdomain. Di conseguenza, con l’aumentare dei volumi il carico cognitivo aumenta e il modello e la piattaforma diventano eccessivamente complessi, con un numero elevato di interconnessioni interne tra i componenti costituenti che ne ostacolano l’estensibilità e la manutenibilità.

Mancanza di presidio del ciclo di vita dei dati

La divisione delle responsabilità per funzioni tecniche di data management e stage delle data pipeline tradizionalmente adottata (es: team di offloading, team di data modeler, team di DWH engineer, team di BI, team di operations) impedisce ai team di avere piena consapevolezza del ciclo di vita end-to-end dei dati che elaborano, dei processi operazionali che li generano, degli utilizzatori che li consumano e delle finalità di utilizzo, dei problemi di data quality insiti nei dati, del loro significato di dominio. Di conseguenza, il servizio complessivo offerto all’azienda dalla funzione di data management è poco efficace e distante da quello che il business si aspetta, perché si privilegiano ottimi locali a ottimi globali.

Colli di bottiglia

I modelli organizzativi che prevedono eccessive dipendenze da team specialistici (DBA, AMS, Infrastrutture) rendono i processi poco efficienti in quanto tali team faticano a rispondere alla domanda concorrente e sempre più pressante da parte di molteplici stakeholder (data engineer, AI engineer, utenti di business, analisti, data scientist, data provider esterni). Di conseguenza, il lead time di implementazione di nuovi prodotti dati & AI o di piccoli miglioramenti sui prodotti esistenti è di gran lunga superiore alle aspettative e l’azienda rischia di essere costantemente in ritardo nel rilasciare prodotti e servizi sul mercato.

Problemi di Interoperabilità e qualità

La mancanza di policy, metodologie e standard comuni di sviluppo e deployment dei prodotti dati & AI rappresenta una fonte di rischio rilevante per i contesti in cui diversi attori, siano essi team di sviluppo interni all’azienda o consulenti esterni, operano nell’ecosistema, in quanto ciascuno di essi adotta le proprie pratiche. Di conseguenza, i prodotti realizzati sono scarsamente interoperabibli e il livello di qualità è difforme tra di essi, causando un forte ostacolo al riuso dei dati e delle funzionalità di AI.

Debito tecnologico

La mancanza di team che abbiano la capacità di approfondire, valutare, sperimentare e diffondere le nuove pratiche offerte dal landscape tecnologico globale impedisce all’azienda di evolvere in modo sostenibile le tecnologie e le metodologie, causando debito tecnico che inficia ulteriormente il costo di manutenzione delle soluzioni dati & AI.

La struttura dei team di lavoro e le modalità con cui questi interagiscono necessitano di essere progettate e adattate nel tempo in modo coerente e sinergico con l’evoluzione dell’architettura tecnologica, affinché il design complessivo dell’intero sistema sociotecnico aziendale abiliti una delivery efficiente. È necessario responsabilizzare i Team (più che i singoli individui) come elementi organizzativi principali su cui si basa la delivery e metterli nelle condizioni di performare al meglio. Allo stesso tempo, serve tenere sempre presente che l’obiettivo comune deve essere il successo dell’intera organizzazione, non di singoli team, dipartimenti o funzioni aziendali.

Alcune delle domande da porsi in fase di progettazione sono le seguenti:
• Quali sono i flussi di generazione di valore di business principali?
• Qual è lo scopo e la topologia che ciascun team deve avere per produrre valore?
• Quali business o technical capability i team devono implementare?
• Quali competenze e caratteristiche comportamentali i membri di un particolare team devono avere per contribuire in modo efficace alla performance complessiva del team?
• In che modo i team devono comunicare, interagire e relazionarsi tra di loro per contribuire agli obiettivi strategici condivisi dell’azienda e portare avanti il business as usual?

Quantyca aiuta le aziende ad ottimizzare la topologia dei propri team in funzione del contesto e degli obiettivi di business agendo in modo sinergico sui seguenti elementi organizzativi chiave:

🠖 Responsabilità chiare ed esplicite
Permettono di rimuovere ambiguità, massimizzare il focus di ogni team sul proprio scopo e migliorare le caratteristiche comportamentali che ogni individuo deve avere per contribuire allo scopo del proprio team.

🠖 Autonomia ed empowerment dei Team
Permettono ai team di minimizzare le interdipendenze e i tempi di attesa, nonché di ridurre i colli di bottiglia e le comunicazioni superflue cross team, eliminare le procedure burocratiche che rallentano i flussi di generazione del valore.

🠖 Governance federata computazionale
Permette di mantenere la governance e la qualità dei prodotti dati & AI senza precludere la scalabilità dell’architettura organizzativa, con un approccio inclusivo alla definizione delle policy e sfruttando l’automazione per l’enforcing.

Punti Critici

L’adozione di un modello operativo basato sui principi sopra descritti è a tutti gli effetti un processo di Change Management, che richiede di cambiare alcune prospettive:

Da un una prospettiva di tipo upstream/downstream a una di tipo customer/supplier

Nei modelli organizzativi tradizionali, i team sono normalmente ingaggiati all’interno dei processi (tramite apertura di ticket o altri mezzi) a fronte di esigenze on demand di altri team o in modo routinario secondo procedure prestabilite. Per aumentare l’efficienza e la scalabilità delle iniziative di data management, è necessario prevedere che la mission principale di alcuni team sia quella di lavorare “a servizio” di altri, con l’obiettivo di rendere questi ultimi più performanti possibile. Questo richiede un cambio di prospettiva, tale per cui i team “serviti” sono da considerarsi dei veri clienti, dal punto di vista del team supplier; pertanto, la relazione tra di essi deve essere improntata alla cura verso le esigenze del team cliente, alla raccolta di feedback da parte di esso e alla ricerca del miglioramento della sua esperienza.

Da un focus sulle funzioni tecnologiche a un focus sul business outcome

I dati e le applicazioni di AI sono da gestire con un approccio di product management, garantendo che ci sia un presidio unico e continuativo sull’intero ciclo di vita di un data/AI product. Un approccio a catena di montaggio, in cui i team sono composti da specialisti di una specifica funzione tecnica ma conoscono poco delle fasi che vengono a monte e valle nella data value chain, ricevono input da team upstream e “passano la palla” a team downstream, non è più adatto a garantire il presidio, la cura e la conoscenza sui dati necessaria per fornire un valore vero al business. Al contrario, è necessario che chi lavora con i dati e l’AI abbia una conoscenza approfondita del dominio e sia allineato agli obiettivi della funzione aziendale o della linea di business che supporta. Inoltre, per essere in grado di gestire in autonomia l’intero ciclo di vita dei dati, è necessario che i team siano cross funzionali, ovvero siano costituiti da persone con competenze variegate e complementari (progettazione, sviluppo, dataops, product management…).

Da una governance centralizzata ad una governance federata e computazionale

La metodologia tradizionale di applicazione della governance prevedeva di limitare soggetti e team che avevano i permessi di effettuare determinate operazioni ad alto privilegio (ad esempio: aggiornare il modello dati, avviare le pipeline CICD per il rilascio dei workload in ambiente di produzione, configurare i workflow di orchestrazione, predisporre le risorse infrastrutturali…). In questo modo si garantiva il rispetto degli standard e delle buone pratiche, che erano conosciute da un pool ristretto di persone, evitando che altre persone, che non conoscevano tali pratiche, potessero eluderle. Questo modello di governance non è più adatto a scenari che richiedono scalabilità organizzativa e velocità di delivery. Al contrario, è possibile applicare la governance in un modo più scalabile e inclusivo, ovvero coinvolgendo nelle decisioni una rappresentanza di ciascun gruppo di lavoro operante nell’ecosistema dati & AI e rendendola responsabile di garantire l’applicazione delle policy comuni all’interno del proprio team. Nei casi in cui serva rafforzare la verifica di alcune policy e il rispetto di guardrail, è possibile “computazionali” le policy (policy as code) e farne enforcing in modo automatico tramite la piattaforma.

Soluzione

Quantyca propone un framework che estende quello descritto nel libro “Team Topologies”, rendendolo più adatto ad essere applicato per la funzione di data & AI management. Nel modello proposto, vengono distinti i team operativi, che si occupano di implementare le capability di data & AI development, dai comitati di coordinamento, che hanno potere decisionale su vari aspetti che governano le attività dei team operativi.

L’applicazione del framework in ciascun contesto specifico può non richiedere necessariamente la costituzione di tutti i team operativi e dei comitati di coordinamento di seguito descritti. Le scelte, sia in fase iniziale di una roadmap di trasformazione, sia nello scenario previsto a regime, vanno fatte a seguito di un assessment dello stato corrente di un’organizzazione, valutando tutti gli aspetti legati alla cultura aziendale, a fattori strutturali dell’azienda (ad esempio la sua dimensione), ai vincoli organizzativi, alla maturità delle competenze e agli obiettivi strategici che l’azienda si prefigge.

Nella definizione dell’architettura organizzativa, serve considerare sia la natura statica dei team, chiamata topologia, sia la dinamica tra i team, detta modalità di interazione. È buona pratica razionalizzare tutte le possibili topologie e modalità di interazione che i team possono adottare in un set ristretto, per ridurre la complessità del modello operativo complessivo.

Mapping common industry team types to the fundamental topologies sets up organizations for success, removing gray areas of ownership and overloaded/underloaded teams
Team Topologies

È consigliabile identificare la topologia di ciascun team selezionandone una tra le quattro topologie fondamentali:

Stream-aligned

I team Stream-aligned hanno lo scopo di implementare nel modo più efficiente e autonomo possibile un singolo flusso end-to-end di generazione del valore, che produce un business outcome (può declinarsi nello sviluppo di una linea di prodotto, un insieme di funzionalità o una user experience). In ambito dati & AI, questi team gestiscono l’intero ciclo di vita dei prodotti dati & AI di rilevanza per un business subdomain, dall’ideazione, passando per la progettazione, lo sviluppo, la fase di testing, il rilascio e la manutenzione continua. Di conseguenza, la selezione dei membri deve essere tale da coprire tutte le capability che il team, nel suo complesso, necessita di avere per gestire tutte le fasi della pipeline di prodotto, nonché le competenze di product management basilari. Ciò non significa che il team debba avere competenze specialistiche e avanzate su ciascuna delle capability, ma è sufficiente una copertura fondamentale cross-funzionale (data & AI architecture, data modelling, software development, workflow management, dataops, infrastructure development, user experience, product management). Per massimizzare il livello di servizio offerto, è fondamentale che questi team consolidino e conservino nel tempo le conoscenze di dominio rilevanti, lavorando fianco a fianco con i Business SME, i Data Owner e i Data Steward.

Enabling

Gli Enabling Team hanno lo scopo di supportare i team stream-aligned nell’acquisizione di competenze sulle metodologie e tecnologie più innovative offerte dal landscape dati & AI, nonché nell’adozione delle policy e degli standard globali che si decide in modo federato di adottare, a cui tutti i team stream-aligned devono adeguarsi per garantire che i prodotti realizzati siano interoperabili. Alcuni esempi di ambiti metodologici e tecnologici su cui i team di enabling concentrano i propri sforzi di diffusione delle conoscenze verso i team stream-aligned sono il Metadata Management e il DataOps ma, più in generale, l’operato dei team di enabling è centrale della diffusione di tutti gli aspetti di Data & AI Culture. La presenza dei team di enabling permette ai team stream-aligned di focalizzarsi sul flusso di valore principale per il business, introducendo tuttavia le innovazioni in modo sostenibile e mantenendo contenuto il debito tecnico accumulato. I membri selezionati per i team di enabling devono possedere capacità di continuous learning, ricerca e sviluppo, formazione e change management.

Complicated Subsystem

I Complicated Subsystem Team hanno l’obiettivo di sviluppare, mantenere e amministrare sottosistemi o parti di un sistema che presentano un’alta complessità tecnica o di dominio, tale da richiedere competenze avanzate e specialistiche in un’area funzionale. In ambito data & AI, talvolta è conveniente prevedere i Complicated Subsystem Team per la gestione dei sistemi legacy o per lo sviluppo di funzionalità di dominio altamente specialistiche e che richiedono SME dedicati (ad esempio, un sistema di calcolo dell’inventario in tempo reale, un motore di customer recommendation o customer segmentation). Si consiglia di ricorrere alla creazione di team di questa topologia solo quando strettamente necessario e la scelta deve essere motivata da una riduzione rilevante del carico cognitivo sui team stream-aligned. I membri scelti per far parte dei Complicated Subsystem Teams devono avere competenze profonde e un’esperienza significativa nell’area di interesse (devono essere a tutti gli effetti degli SME).

Platform

I Platform Team hanno l’obiettivo di ridurre il carico cognitivo dei team stream-aligned, realizzando servizi che implementano funzionalità tecniche comuni, che sono esposti tramite portali o API e possono essere utilizzati in autonomia dai team stream-aligned. Tali servizi sono esenti da logiche di dominio, astraggono la complessità dell’infrastruttura tecnologica sottostante, implementando in modo standardizzato, ottimizzato e governato task tecnici specifici e semplificando la Developer Experience. In ambito data & AI, i Platform Team sono altamente consigliati per implementare la foundation delle componenti tecnologiche che costituiscono l’architettura e per sviluppare servizi di piattaforma a supporto del ciclo di vita dei data product e della loro fruizione da parte degli utenti. La disponibilità di tali servizi di piattaforma evita ai team stream-aligned la necessità di possedere competenze tecniche avanzate. Al contrario, i membri che costituiscono i Platform Team devono avere competenze profonde in ambito di coding, dataops e product development, nonché la predisposizione alla collaborazione e al customer support.

È importante definire in modo chiaro la topologia di un team, perché questo aiuta sia i membri stessi del team a sviluppare le competenze e le aspettative comportamentali richieste per contribuire al meglio allo scopo del team sia gli altri team a comprendere il valore che un team specifico è chiamato ad offrire. Nella pratica, soprattutto in contesti organizzativi semplici, può essere ragionevole assegnare più responsabilità ad un unico team, sebbene questa non sia generalmente una scelta ottimale. In ogni caso, anche in tali scenari, è richiesto al team a cui vengono assegnati molteplici ruoli di avere sufficiente maturità da distinguere le varie topologie che implementa a adattare il proprio modo di operare nel passaggio continuo da una topologia all’altra.

Le topologie descritte offrono pattern per progettare la natura statica di un team. Tuttavia, essendo l’azienda un sistema sociotecnico in cui diversi attori e team interagiscono, la complessità da indirizzare spesso risiede nella dinamica delle interazioni.

Il libro “Team Topologies” suggerisce tre modalità di interazione su cui si consiglia far convergere la dinamica tra i team:

Collaboration

È una modalità che prevede che due team collaborino a stretto contatto uno con l’altro, condividendo parzialmente le responsabilità, gli obiettivi, il perimetro di azione e complementandosi a vicenda con le rispettive competenze. È una modalità idonea per attività di esplorazione o prototipazione, ma non consigliata per una delivery scalabile, in quanto aumenta il carico cognitivo complessivo dei team coinvolti e riduce l’efficienza a causa del grado di coordinamento richiesto tra di essi.

X-as-a-Service

È una modalità che prevede un’interazione ridotta al minimo tra i team coinvolti, in cui un team svolge il ruolo di fornitore di servizi e l’altro team di consumatore. Il team consumatore utilizza i servizi offerti dal fornitore tramite le API messe a disposizione da quest’ultimo. I perimetri di responsabilità sono ben distinti e l’interazione è regolata da agreement stipulati sulle API e sul livello di servizio atteso (è un modello “a basso accoppiamento”). Si tratta di una modalità ottimale per una delivery scalabile, sicura, efficiente e consistente, mentre è meno efficace in fase di sperimentazione o introduzione di innovazione.

Facilitating

È una modalità che prevede un’interazione tra due team in cui uno di essi ha il compito di affiancare e supportare l’altro nel proprio lavoro, facilitando l’acquisizione di conoscenze e la padronanza degli aspetti tecnologici necessari per la generazione del valore e per la gestione continua del cambiamento evolutivo. Il team facilitatore non sviluppa i prodotti in prima persona, ma lavora al fianco del team facilitato per contribuire al successo di quest’ultimo. È una modalità ottimale per i contesti e le fasi di una roadmap in cui è necessario preservare la scalabilità e la velocità di delivery senza rinunciare a introdurre, gestire e sostenere continuamente il cambiamento, evitando di generare eccessivo debito tecnico.

La modalità di interazione tra due team può cambiare nel tempo, in base ai segnali che si osservano nei processi quotidiani e nella forma che assume l’architettura complessiva.

In ambito dati & AI, il modello più adatto per la maggior parte degli scenari è quello mostrato nella figura seguente (anche se, in determinati casi particolari, conviene valutare caso per caso leggere variazioni).

The-most-common-team-architecture-design-for-data-AI-management

Il design di architettura dei team più comune per la gestione dei dati e dell’AI

Le situazioni più comuni sono quelle che prevedono i Platform Team operanti in modalità di X-as-a-Service verso i team di prodotto (stream-aligned), mentre in modalità Collaboration con i team di Enabling (soprattutto nelle fasi di ideazione e prime prototipazioni dei servizi di piattaforma). Al contrario, i team di Enabling solitamente lavorano in modalità Collaboration verso i team di prodotto nelle fasi iniziali del cambiamento, gestendo a quattro mani gli sviluppi, per poi transire gradualmente verso una modalità Facilitating (quella consigliata a regime), per rendere sempre più autonomi i team di prodotto. L’interazione tra Complicated Subsystem Teams (ove presenti) e i team di prodotto è solitamente di tipo Collaboration o X-as-a-Service.

Oltre ai team operativi descritti fino ad ora, il framework proposto da Quantyca suggerisce di considerare la costituzione dei comitati di coordinamento rappresentati nella figura seguente.

The management committees proposed by Quantyca’s Team Topologies Framework

I comitati di coordinamento del framework di Team Topologies proposto da Quantyca

Ciascuno dei comitati ha responsabilità ben precise:

Strategy Steering Committee

Ha l’autorità della definizione e monitoraggio periodico della Data & AI Strategy e delle attività di Portfolio Management. È l’organismo con più alto potere decisionale, che determina le priorità degli investimenti e l’allocazione del budget sui programmi in portfolio in coerenza con gli obiettivi strategici. È composto da figure di Management e di Advisory.

Federated Modelling Committee

Ha l’autorità di definire ed evolvere il modello concettuale aziendale (Core Domain Ontology) ai fini della costruzione del Knowledge Graph, che esprime la porzione di semantica condivisa da tutti i business subdomain, su cui essi trovano un agreement in fase di modellazione. È composta da una rappresentanza di Data Owner / Data Steward selezionati da ciascun business subdomain e da figure specialistiche (Advisor, Knowledge Modeler).

Project Management Commitee

Ha l’autorità di monitorare l’avanzamento operativo dei business case, risolvere eventuali fattori bloccanti e gestire la sincronizzazione del backlog dei vari team necessaria per completare i business case in esecuzione nel modo più efficiente possibile. È composto da una rappresentanza di Project Manager / Product Manager / Team Leader per ciascun team operativo.

Federated Governance Committee

Ha l’autorità di definire le policy di governance globali, gli standard e le scelte architetturali condivise a cui tutti i team si devono adeguare. È composto da una rappresentanza di Data Architect / Team Leader di tutti i team operativi coinvolti e da figure specialistiche (Advisor, Enterprise Architect, Data Governance SME).

Federated Modelling Committee

Il percorso completo

Quantyca, tramite il CoE di Organizational & Change Governance, ha affinato la progettazione e l’implementazione del framework in base ai feedback raccolti dai contesti di applicazione e consolidato l’esperienza di supporto ai clienti per adottare gradualmente gli strumenti descritti.

Il percorso completo di adozione prevede le seguenti fasi:

1 Assessment AS-IS Team Topologies framework

Mappatura dello stato corrente relativo a modello di distribuzione delle ownership, team esistenti e relativa topologia, modalità di interazione tra i team.

2 Progettazione TO-BE Team Topologies framework

Progettazione dello stato target desiderato in allineamento con il design della Target Platform Blueprint.

3 Definizione Minimum Viable Team Topologies framework

Progettazione dello stato iniziale del framework di Team Topologies, da adottare nelle prime fasi di una roadmap di cambiamento incrementale, in allineamento con design della Minimum Viable Platform Blueprint. Nelle fasi iniziali, solitamente si consiglia di adottare una versione più semplificata del framework, introducendo il minimo dei team e dei comitati necessari.

4 Implementazione Minimum Viable Team Topologies framework

Costituzione dei team previsti in fase iniziale della roadmap, condivisione dello scopo e delle aspettative a ciascun team, avvio dei lavori dei comitati federati.

5 Monitoraggio e raffinamento periodico

Valutazione periodica dell’efficienza dei team e dei potenziali segnali organizzativi che suggeriscano un cambiamento, introduzione modifiche al Team Topologies framework.

Vantaggi

Adottare un framework di Team Topologies come quello descritto comporta tre principali vantaggi:

Focus sul business outcome

Favorire un modello operativo che sia incentrato sugli stream di valore invece che sui singoli stage della pipeline.

Performance dei team

Migliorare la performance e la motivazione dei singoli team chiarendone lo scopo, il valore atteso, la topologia e la modalità con cui ci si aspetta interagisca con gli altri.

Efficienza operativa

Favorire la velocità e l’agilità di sviluppo dei prodotti dati & AI, riducendo al minimo i passaggi di consegna, i tempi di attesa, le interdipendenze e le interazioni non necessarie tra i team.