La data governance federata spiegata in parole semplici
|
7
min di lettura
Il vostro team di analytics ha bisogno di un dataset clienti per una nuova dashboard. La richiesta entra in una coda centrale, attende che uno steward interpreti la policy, passa a un revisore della sicurezza, quindi torna al business owner per chiarimenti. Nel frattempo, il dominio marketing ha già creato la propria definizione di cliente, la finanza ne usa un'altra e nessuno sa spiegare quale versione debba usare un report per il management.
Questa tensione è il cuore della data governance federata. Le organizzazioni hanno bisogno di regole coerenti su privacy, accessi, qualità, conservazione e compliance, ma hanno anche bisogno che i team di dominio prendano decisioni informate vicino ai dati. Il modello funziona separando i diritti decisionali a livello enterprise dall'esecuzione locale, e supportando questa separazione con una tecnologia condivisa e una responsabilità misurabile.
Indice
Modelli centralizzati, decentralizzati e federati a confronto
La ripartizione dei diritti decisionali tra centro e dominio
KPI di governance che dimostrano che la federazione funziona
Quando la governance centralizzata smette di scalare
Un retailer multinazionale descriveva una volta il proprio comitato di governance come un piccolo governo all'interno dell'azienda. Contava 400 persone in rappresentanza di regioni, funzioni, sicurezza, ufficio legale, analytics e tecnologia. Sulla carta la struttura sembrava rassicurante, ma ogni richiesta di accesso seguiva comunque lo stesso percorso: un dominio la presentava, il comitato centrale la esaminava e il comitato discuteva se un'eccezione locale avrebbe creato un rischio per l'intera azienda.
La coda ha messo in luce il problema. Le richieste sono passate da 12 a settimana a oltre 300 a settimana, mentre il tempo medio di approvazione si è allungato fino a 19 giorni. I data steward hanno iniziato ad andarsene perché il loro lavoro si era trasformato in un controllo amministrativo del traffico anziché in stewardship. Gli analisti aspettavano l'accesso a dati che conoscevano meglio dei revisori centrali, e il comitato passava il tempo a decidere questioni che appartenevano a un livello molto più vicino alla fonte.
Regola pratica: un team di governance non dovrebbe approvare ogni decisione solo perché è responsabile della policy.
Diverse pressioni sono arrivate insieme. Le fonti dati del retailer si sono moltiplicate per dieci tra cloud warehouse e piattaforme SaaS. Le aspettative normative e in materia di privacy differivano tra UE, Stati Uniti e APAC. I team di analytics volevano dashboard e modelli di machine learning consegnati in giorni anziché in trimestri. Un'unica coda centrale non poteva gestire questa combinazione senza sacrificare la velocità o la qualità delle revisioni.
L'azienda si trovava di fronte a una scelta difficile. Allentare la supervisione centrale e rischiare definizioni incoerenti, controlli di accesso deboli e responsabilità poco chiare. Oppure mantenere il processo esistente e trasformare la governance in un vincolo alla delivery che i team di business imparano ad aggirare.
La risposta strutturale è mantenere in un unico luogo le regole valide per tutta l'azienda, spostando l'interpretazione e l'esecuzione ordinarie nei domini che conoscono i dati. Il centro continua a proteggere il perimetro comune. I team locali acquisiscono autorità all'interno di quel perimetro. Il resto di questo modello operativo dipende dal rendere tale divisione esplicita, eseguibile e misurabile.
Che cosa significa davvero data governance federata
Partiamo da una città. Un'autorità centrale stabilisce norme edilizie, standard stradali, requisiti di emergenza e regole antincendio. I quartieri decidono comunque se hanno bisogno di appartamenti, case, negozi o scuole, e possono organizzare le strade locali in base alle proprie esigenze. Non sono liberi di ignorare le norme edilizie, ma non hanno bisogno del permesso del municipio per scegliere ogni planimetria.
La data governance federata funziona allo stesso modo. Un organo di governo centrale definisce policy, standard e regole di compliance a livello enterprise. I domini di business mantengono la responsabilità dell'implementazione e dell'esecuzione entro tali confini. Il modello è emerso come approccio enterprise distinto tra la fine degli anni 2000 e l'inizio degli anni 2010, in particolare quando le grandi organizzazioni hanno cercato di bilanciare il controllo centralizzato con la flessibilità decentralizzata in domini sempre più complessi (l'evoluzione della data governance).
La struttura
Il primo livello è la struttura dei diritti decisionali. Il chief data office, il consiglio enterprise o l'organo di governance centrale è responsabile delle regole che devono funzionare tra i domini. I data product owner e gli steward di dominio sono responsabili dei data product, dei workflow, delle definizioni e delle scelte operative all'interno dei propri confini.
Questa ripartizione previene due fallimenti comuni. La centralizzazione smette di essere il collo di bottiglia delle approvazioni, mentre la decentralizzazione non produce un insieme di regole incompatibili. La governance federata è quindi un'architettura ibrida, con standard centralizzati, stewardship decentralizzata e responsabilità condivisa (la governance federata come modello ibrido.
La piattaforma abilitante
Il secondo livello è una piattaforma condivisa che offre ai domini funzionalità self-service. Un catalogo può registrare data product e owner. I servizi di metadati possono veicolare classificazioni e contesto di business. Il lineage può mostrare come un campo si sposta tra i sistemi. I policy engine possono applicare regole di accesso e mascheramento senza chiedere a un revisore centrale di interpretare ogni richiesta.
La policy as code è importante. Le regole di governance diventano controlli eseguibili anziché documenti che le persone consultano in modo incoerente. Gli studi accademici sulla governance del data mesh descrivono l'applicazione automatica dei requisiti relativi a schemi, lineage, sicurezza, trasparenza e policy legali (governance computazionale nel data mesh).
Il risultato
Dovreste essere in grado di spiegare il modello a un collega in una sola frase: il centro definisce gli standard globali, i domini sono responsabili dei data product locali e l'infrastruttura condivisa applica automaticamente l'accordo. L'autonomia locale non è assenza di governance. È governance esercitata dalle persone più vicine ai dati, secondo regole che restano visibili e coerenti in tutta l'azienda.
Modelli centralizzati, decentralizzati e federati a confronto
Il modo più semplice per distinguere i modelli è seguire un modello di rischio di credito all'interno di una banca retail. Un team di rischio vuole combinare dati su prestiti, rimborsi e clienti per supportare un nuovo modello. La domanda di governance non riguarda solo chi approva l'accesso. Riguarda anche chi definisce i dati, chi li valida, chi gestisce la piattaforma e chi si assume la responsabilità quando il modello fallisce.
Dimensione | Centralizzato | Decentralizzato | Federato |
|---|---|---|---|
Diritti decisionali | Un unico team centrale è responsabile di standard e approvazioni | Ogni dominio decide per sé | Il centro è responsabile delle regole tra domini, i domini decidono localmente al loro interno |
Data stewardship | Steward centrali gestiscono definizioni e problemi | I team di dominio gestiscono i propri asset in modo indipendente | Gli steward di dominio sono responsabili di qualità e contesto locali, con supervisione enterprise |
Stesura e applicazione delle policy | Le policy sono scritte e riviste centralmente, spesso a mano | Le policy variano a seconda del dominio | Le policy sono condivise centralmente e applicate tramite servizi comuni |
Data product | Un team centrale costruisce o controlla i prodotti | Ogni dominio costruisce i prodotti in modo indipendente | I domini costruiscono e gestiscono i prodotti usando funzionalità di piattaforma condivise |
Finanziamento e gestione della piattaforma | L'IT centrale finanzia e gestisce la piattaforma | I domini scelgono e finanziano i propri strumenti | Un team di piattaforma centrale fornisce funzionalità riutilizzabili ai domini |
Modalità di fallimento | Code di approvazione e colli di bottiglia centrali | Definizioni contrastanti, lavoro duplicato e controlli frammentati | Confini mal definiti, scarsa adozione o controversie sulle regole condivise |
Nella versione centralizzata, il comitato di governance centrale della banca definisce le variabili approvate, esamina la richiesta di accesso, valida le classificazioni e approva l'uso in produzione. Il modello può ricevere un trattamento coerente, ma gli stessi revisori devono comprendere il contesto di business di ogni dominio.
Nella versione decentralizzata, prestiti, depositi e marketing decidono ciascuno come utilizzare le informazioni sui clienti. Il team di rischio di credito può muoversi rapidamente, ma potrebbe definire “cliente”, “conto attivo” o “ricavi” in modo diverso dagli altri team. Anche le pratiche di sicurezza possono divergere.
Nella versione federata, il centro definisce identità, privacy, classificazione e requisiti minimi di qualità. Il dominio prestiti è responsabile del proprio prodotto di rischio di credito, documenta gli input del modello, testa i dati prima della pubblicazione e concede l'accesso locale entro confini approvati. Una piattaforma condivisa registra il lineage e applica i controlli comuni.
La federazione non è un compromesso in cui ognuno ottiene una porzione più piccola di autorità. È un'allocazione deliberata dell'autorità. La logica operativa è in linea con il più ampio approccio data mesh alle architetture dati moderne, ma il focus resta la governance: chi può decidere, secondo quali regole, con quali evidenze.
La ripartizione dei diritti decisionali tra centro e dominio
La federazione riesce o fallisce in base a un artefatto pratico: la matrice dei diritti decisionali. Senza di essa, il centro presume di dover ancora approvare tutto, mentre i domini presumono di poter interpretare liberamente le policy. Entrambi i gruppi scalano l'incertezza e l'organizzazione ricrea il collo di bottiglia che intendeva eliminare.
Il centro dovrebbe riservarsi le decisioni che attraversano i confini di business o comportano rischi a livello enterprise. I domini dovrebbero essere responsabili delle decisioni che richiedono una conoscenza dettagliata di raccolta, trasformazione e consumo dei dati. La ripartizione non è identica per ogni organizzazione, ma le categorie dovrebbero essere esplicite.
Ambito decisionale | Responsabilità del centro | Responsabilità del dominio |
|---|---|---|
Classificazione e privacy | Livelli di classificazione enterprise e requisiti di privacy | Applicazione delle classificazioni agli asset del dominio e risoluzione delle questioni di classificazione locali |
Identità e accessi | Regole di identità enterprise, principi dei ruoli e requisiti di controllo | Decisioni di accesso locali entro confini approvati |
Definizioni | Definizioni condivise necessarie per il reporting tra domini | Calcoli specifici del dominio e contesto di business |
Qualità | Benchmark minimi di qualità e aspettative di servizio condivise | Test, monitoraggio, risoluzione dei problemi e pratiche di qualità alla fonte |
Metadati e lineage | Campi di metadati obbligatori e standard di interoperabilità | Documentazione dei prodotti, dettagli del lineage locale e manutenzione |
Conservazione | Principi di conservazione enterprise e vincoli normativi | Implementazione della conservazione nei sistemi del dominio e gestione delle esigenze locali approvate |
Dati di riferimento | Valori di riferimento enterprise approvati | Mapping di dominio e uso operativo di tali valori |
Eccezioni | Criteri per le eccezioni, autorità di approvazione e processo di revisione | Preparazione delle evidenze e richiesta di un'eccezione |
Considerate i dati dei clienti. Il dominio marketing è responsabile della logica di attribuzione delle campagne, incluso il modo in cui collega un'interazione a una campagna. Il centro stabilisce che cosa conta come cliente nel reporting enterprise, perché tale definizione deve restare stabile quando finanza, rischio e marketing si scambiano dati.
La zona intermedia contesa comprende convenzioni di denominazione, finestre di conservazione e definizioni semantiche. Un centro che impone ogni termine locale frustrerà gli esperti di dominio. Un dominio che modifica un termine condiviso senza consultazione comprometterà l'interoperabilità. Un consiglio con rappresentanti dei domini interessati può risolvere questi conflitti, documentare la decisione e registrare l'esito in termini di accessi o policy per una revisione successiva. Anche la panoramica di Denodo sulla governance federata sottolinea la distinzione tra decisioni enterprise e decisioni di dominio, inclusa la risoluzione dei conflitti tra domini tramite un consiglio (diritti decisionali nella governance federata).
Il centro dovrebbe pubblicare il perimetro. I domini dovrebbero operare al suo interno. I ruoli di data governance devono quindi indicare la persona responsabile di ciascuna decisione, non solo il team che vi partecipa.
Implementare la governance federata livello per livello
Una società di servizi finanziari non dovrebbe annunciare la federazione e assegnare immediatamente a ogni dominio un backlog di data product. Il modello ha prima bisogno di fondamenta operative. Un rollout a livelli evita che i team di dominio ricevano responsabilità senza le policy e gli strumenti necessari per sostenerle.
Il livello delle policy
Il team centrale parte da un insieme compatto di standard non negoziabili per accessi, classificazione, lineage e qualità. Il consiglio delle policy riunisce rappresentanti di sicurezza, privacy, ufficio legale, architettura e domini per definire le regole. I suoi output comprendono un registro delle policy, un modello di classificazione, requisiti minimi di metadati, aspettative di qualità e un processo per le eccezioni.
I primi domini non hanno bisogno di un regolamento enterprise perfetto. Hanno bisogno di regole abbastanza chiare da poter essere applicate e abbastanza circoscritte da poter essere fatte rispettare. Un gate di pubblicazione potrebbe richiedere un owner, una classificazione, uno schema, il lineage e controlli di qualità definiti prima che un data product diventi individuabile.
Il livello della piattaforma
Il team di piattaforma trasforma questi standard in servizi riutilizzabili. I domini hanno bisogno di un modo per registrare prodotti, associare contratti, monitorare i livelli di servizio, richiedere accessi e mostrare il lineage senza costruire pipeline di governance separate. Il catalogo diventa il luogo condiviso in cui i consumatori trovano ownership, definizioni, classificazioni e stato.
È anche qui che la società di servizi finanziari codifica i controlli. Le policy di accesso passano attraverso la piattaforma, i controlli sullo schema vengono eseguiti durante la delivery e il lineage viene acquisito man mano che i prodotti cambiano. Il centro ottiene visibilità senza dover esaminare ogni transazione ordinaria.
L'abilitazione dei domini
Solo dopo che i primi due livelli sono utilizzabili l'abilitazione dovrebbe diventare l'obiettivo principale. Ogni dominio partecipante nomina un product owner e uno steward, definisce i propri prodotti, scrive i contratti ed esegue revisioni della qualità. Un gruppo centrale di abilitazione affianca i team, fornisce template e aiuta a risolvere i problemi di adozione.
L'azienda può istituire un forum centrale delle policy per le questioni enterprise, un gruppo di lavoro sulla piattaforma per le lacune funzionali e revisioni di dominio per la qualità dei prodotti. Dovrebbe inoltre verificare se ciascun livello riduce il lavoro per quello successivo. La chiarezza delle policy dovrebbe ridurre le discussioni sulle eccezioni. L'automazione della piattaforma dovrebbe ridurre i controlli manuali. La responsabilità dei domini dovrebbe ridurre il triage centrale dei problemi.
Un rollout per fasi è più facile da sostenere quando gli artefatti restano visibili e modificabili. La guida pratica all'implementazione della data governance può aiutare i team a tradurre principi di governance generali in attività operative, owner e controlli.
Considerazioni su strumenti e piattaforma
Un'azienda retail può avere controlli di accesso e controlli di qualità sparsi tra permessi del warehouse, job di trasformazione, strumenti di ticketing ed estrazioni copiate. Ogni copia crea un altro punto in cui classificazione, mascheramento, lineage e conservazione possono divergere. Un livello di governance unificato integrato nel warehouse può eseguire i controlli dove i dati già risiedono, riducendo la necessità di spostarli in pipeline di governance separate.
La scelta degli strumenti dovrebbe partire dalla ripartizione dei diritti decisionali, non da una checklist di funzionalità. Il centro ha bisogno di visibilità e controllo sulle policy enterprise. I domini hanno bisogno di strumenti self-service che consentano loro di pubblicare, documentare, testare e mantenere i prodotti senza attendere l'engineering centrale.
Il livello di catalogo e metadati
Un catalogo attivo dovrebbe mostrare più dei nomi delle tabelle. Dovrebbe collegare ogni asset a un owner, una classificazione, una definizione di business, il lineage, lo stato della qualità e il percorso di accesso. I metadati dovrebbero aggiornarsi tramite eventi di sistema ove possibile, anziché dipendere interamente dalla documentazione manuale.
Il livello di applicazione delle regole
Un policy engine dovrebbe applicare i requisiti di identità, mascheramento, classificazione e conservazione nei sistemi che servono i dati. L'esecuzione in-database o in loco è importante perché può limitare lo spostamento dei dati e preservare i controlli già stabiliti nell'ambiente del cliente.
Il livello di affidabilità
Il contract testing intercetta modifiche incompatibili allo schema o alle regole di business prima che arrivino ai consumatori. L'osservabilità monitora freshness, modifiche strutturali, andamento dei volumi e segnali operativi. I team che valutano le pratiche di monitoraggio potrebbero trovare utile anche questa guida ai KPI di qualità dei dati per il SaaS per decidere quali segnali di affidabilità includere in un accordo di servizio di dominio.
Il livello dei workflow
Le richieste di stewardship esistono ancora, ma dovrebbero essere leggere. Un workflow dovrebbe instradare un'eccezione al dominio responsabile, registrare la decisione, conservare le evidenze di approvazione e rendere il risultato ricercabile. Non dovrebbe trasformare ogni normale decisione di accesso in una riunione di comitato.
Cercate interfacce aperte, controlli di accesso compatibili con la federazione, supporto per l'esecuzione in loco e prezzi che non penalizzino la condivisione responsabile dei dati. Una piattaforma può esporre il lineage e automatizzare i controlli, ma non può decidere se una definizione contesa appartenga al marketing o alla finanza. Le funzionalità di data observability dovrebbero supportare le decisioni di governance, non sostituire le persone che le prendono.
KPI di governance che dimostrano che la federazione funziona
Un comitato di governance ha bisogno di evidenze che il modello cambi il modo in cui si lavora. Le misure più efficaci collegano un risultato desiderato al livello responsabile di produrlo, distinguendo poi i segnali precoci dai risultati che arrivano più tardi.
I seguenti obiettivi trasformano il modello operativo in una scorecard. Dovrebbero essere concordati prima del rollout e poi rivisti con un contesto sufficiente a spiegare l'andamento, anziché celebrare una singola rilevazione favorevole.
KPI | Livello responsabile | Direzione obiettivo |
|---|---|---|
Tempo di pubblicazione di un dataset certificato | Dominio e piattaforma | Meno di cinque giorni lavorativi |
Dataset con owner attivo e SLA | Dominio | Oltre il novanta per cento |
Tasso di violazione delle policy per release | Centro e piattaforma | In calo sotto il due per cento |
Tempo medio di risoluzione di un incidente di qualità dei dati | Dominio e piattaforma | Meno di ventiquattro ore |
Latenza delle query per l'accesso governato | Piattaforma | In calo o stabile con la crescita dell'adozione |
Copertura del lineage | Piattaforma | In crescita sui prodotti critici |
Tempo di risoluzione delle eccezioni | Consiglio e centro | In calo con evidenze chiare |
I primi quattro obiettivi sono misure operative definite per questo modello di governance. Sono direttamente legati a velocità di pubblicazione, responsabilità, qualità dei controlli e ripristino. Gli ultimi tre aiutano a capire se la piattaforma condivisa può supportare l'esecuzione locale senza nascondere le dipendenze.
Anche il contesto di mercato mostra perché la misurazione è importante. Una previsione pubblicata valuta il mercato globale della data governance 5,6 miliardi di dollari nel 2025 e prevede 38,3 miliardi di dollari entro il 2035 (previsione del mercato della data governance). L'investimento da solo non dimostra che la governance funzioni. I KPI interni devono mostrare se l'investimento elimina gli attriti preservando il controllo.
Usate indicatori anticipatori come assegnazione degli owner, completamento dei contratti, copertura delle policy e acquisizione del lineage. Usate indicatori ritardati come incidenti, release fallite, rilievi di audit e pubblicazioni in ritardo.
Se l'autonomia dei domini aumenta mentre il tempo di certificazione resta invariato, il modello operativo potrebbe spostare la responsabilità senza migliorare il flusso. Se l'autonomia aumenta mentre gli incidenti crescono, i guardrail sono troppo laschi o la piattaforma non li applica in modo affidabile.
I dati delle indagini rafforzano la necessità di questa disciplina. Il 71% delle organizzazioni dichiara di avere un programma di governance, eppure il 54% indica ancora la governance tra le principali sfide per l'integrità dei dati e il 39% dei data leader fatica a dimostrare l'impatto della governance al management (risultati su adozione e impatto della governance). Un framework di KPI per la data governance può aiutare i team a definire le misure e le responsabilità necessarie per quel confronto con il management.
Errori comuni e un quadro operativo pratico
Il quadro operativo pratico è semplice da descrivere. Un team centrale snello pubblica le policy e le funzionalità di piattaforma condivise. I domini utilizzano queste funzionalità tramite un catalogo federato, sono responsabili dei propri prodotti e risolvono i problemi alla fonte. Un consiglio leggero gestisce i conflitti tra domini, mentre le revisioni dei KPI mostrano se l'assetto sta migliorando velocità, responsabilità e controllo.
L'errore più comune è trattare la federazione come una riorganizzazione anziché come un cambiamento del contratto. I leader rinominano i team, pubblicano uno statuto e si aspettano che i comportamenti cambino. I team di dominio continuano a scalare le questioni perché nessuno ha riscritto le decisioni che possono prendere, le eccezioni che possono approvare o i tempi di risposta su cui possono contare.
La soluzione è una matrice firmata di una pagina che copra le 12-15 decisioni riservate al centro, la persona che approva le eccezioni e lo SLA di risoluzione. Questa matrice dovrebbe trovarsi accanto al catalogo, dove le persone prendono le decisioni di governance, anziché in una presentazione che pochi team consultano. Il consiglio dovrebbe rivederla ogni trimestre alla luce della mappa dei KPI, modificando il perimetro quando le evidenze mostrano che una decisione appartiene a un altro livello.
Gli strumenti ombra sono un segnale d'allarme precoce. Se un dominio crea un catalogo o un workflow di accesso non approvato perché il percorso ufficiale è troppo lento, i leader dovrebbero affrontare sia il comportamento locale sia l'attrito centrale. Le indicazioni sulla gestione dello shadow IT per le PMI offrono un contesto utile sul perché gli strumenti non gestiti possano creare esposizioni in termini di sicurezza e compliance.
La data governance federata funziona quando la responsabilità è visibile, le policy sono eseguibili e i domini hanno un'autorità sufficiente per agire. Il centro protegge la fiducia condivisa. I domini mantengono il contesto pratico. La piattaforma rende l'accordo osservabile.
digna aiuta i team di dati a monitorare anomalie, tempestività, validazione a livello di record e modifiche dello schema all'interno del proprio ambiente dati, fornendo ai domini federati evidenze per le decisioni sulla qualità e preservando al contempo la visibilità centrale. Visitate digna per vedere come la sua piattaforma modulare di osservabilità può supportare data product governati su warehouse, lake e pipeline.
Domande frequenti
Che cos'è la data governance federata?
Un modello in cui il centro definisce gli standard globali, i domini sono responsabili dei data product locali e l'infrastruttura condivisa applica automaticamente l'accordo. Se non riuscite a spiegarlo a un collega in una sola frase come questa, il modello operativo non è ancora definito.
Quando la governance centralizzata smette di scalare?
Quando l'approvazione diventa il collo di bottiglia. Il comitato di governance di un retailer multinazionale è arrivato a contare 400 persone tra regioni, funzioni, sicurezza, ufficio legale, analytics e tecnologia, mentre le richieste sono passate da 12 a settimana a oltre 300 e il tempo medio di approvazione si è allungato fino a 19 giorni.
Quali sono i due livelli di un modello federato?
La struttura dei diritti decisionali, che separa le regole valide per tutta l'azienda dall'interpretazione locale ordinaria, e la piattaforma abilitante, che offre ai domini funzionalità self-service. Qui la policy as code è importante, perché è ciò che trasforma un accordo in qualcosa che l'infrastruttura può applicare senza bisogno di una riunione.
Come si confronta con i modelli centralizzati e decentralizzati?
Il modello centralizzato mantiene ogni decisione in un unico punto e rallenta; quello decentralizzato lascia libertà ai domini e perde coerenza; quello federato mantiene centrali le regole valide per tutta l'azienda, spostando l'interpretazione ordinaria nei domini che conoscono i dati. Le differenze emergono più rapidamente seguendo un asset condiviso attraverso ciascun modello.
Da dove nasce il modello federato?
È emerso come approccio enterprise distinto tra la fine degli anni 2000 e l'inizio degli anni 2010, quando le grandi organizzazioni hanno cercato di bilanciare il controllo centralizzato con la flessibilità decentralizzata in domini sempre più complessi. La pressione che lo ha generato, troppi domini per un solo comitato, da allora non ha fatto che aumentare.
