La strategia dei dati è una delle decisioni architetturali più difficili da correggere a posteriori. Come Solution Architect PL-600 devi stabilire dove i dati vivono, in quale tier di storage, e per quanto tempo vengono conservati, allineando queste scelte ai requisiti geografici, regolatori e di costo fin dalla fase di discovery — non quando il legal solleva il problema a progetto avviato.
Data residency: region e sovereign cloud
La region dell’environment Dataverse determina dove risiedono fisicamente i dati at-rest. La scelta si fa alla creazione dell’environment ed è de facto immutabile: non esiste un “sposta l’environment in un’altra region” self-service. Cambiare geografia significa migrare dati, integrazioni, flussi, app e riautorizzare le connection — un progetto, non un’impostazione.
Le opzioni principali:
- Commercial cloud multi-geo: scegli la datacenter region (es. Europe, con dati in EU) allineata alla presenza del tenant. Per una PMI italiana con requisiti GDPR standard, una region EU copre la maggior parte dei casi.
- Sovereign / national cloud (US Government/GCC, China operato da 21Vianet): tenant e stack separati, feature parity ridotta e connettori limitati. Si sceglie solo se un mandato normativo lo impone, perché vincola l’intero ecosistema.
- Multi-geo tenant: environment in region diverse sotto lo stesso tenant, utile per una multinazionale che deve tenere i dati HR tedeschi in Germania e quelli asiatici in APAC.
Raccomandazione di design: se hai anche solo il sospetto di un requisito di data residency (settore pubblico, sanità, financial services, dati di dipendenti UE), fissa la region prima di provisionare l’environment di produzione e documenta la decisione. Il pilastro Security del Well-Architected Framework e i controlli di compliance boundary vanno valutati qui, non in collaudo.
Tier di storage Dataverse
La capacità Dataverse è a livello di tenant, ripartita in tre pool distinti che si prezzano e si ottimizzano separatamente:
- Database capacity — righe delle tabelle relazionali, il tier più costoso. Le tabelle elastic (Cosmos-backed) sono adatte a volumi altissimi e schema flessibile.
- File capacity — colonne file/immagine e allegati; molto più economico del database.
- Log capacity — audit log e Dataverse auditing.
Trade-off chiave: allegati e note pesanti gonfiano il pool più caro se lasciati inline. Spostare i binari verso File capacity, o esternalizzare su Azure Blob Storage con integrazione, abbatte i costi senza perdere l’indicizzazione dei metadati. Il pilastro Cost Optimization premia chi mappa il dato al tier corretto invece di trattare tutto come database.
Retention e archiviazione
Dataverse offre long-term retention: le righe che soddisfano una policy vengono spostate in uno store di archivio a basso costo, restando interrogabili (via Synapse Link / analisi) ma liberando database capacity. È la leva giusta per dati “caldi vs freddi”: ordini chiusi, ticket risolti, storici che servono per compliance ma non per l’operatività quotidiana.
La governance dei dati — classificazione, DLP, sensitivity label, retention regolatoria — si orchestra con Microsoft Purview, mentre le DLP policy di Power Platform bloccano la combinazione di connettori business e non-business. Definisci retention e archiviazione come parte del data model, non come afterthought operativo.
Capacity e costo
Monitora il consumo nel Power Platform admin center e progetta con margine: superare la capacità genera costi add-on o blocchi. La disciplina architetturale sta nel rightsizing — elastic tables per il volume, File capacity per i binari, long-term retention per lo storico — bilanciando Cost Optimization e Performance Efficiency del Well-Architected Framework.
Trappole tipiche d’esame
- Requisito: i dati dei dipendenti UE devono restare in EU, scoperto dopo il go-live → Raccomanda di fissare la region EU alla creazione dell’environment; a posteriori l’unica via è una migrazione completa, quindi la data residency va validata in discovery. È la trappola canonica: rimandarla al legal quando spostare l’environment è di fatto impossibile.
- Requisito: agenzia governativa con mandato di sovereign cloud → Raccomanda il national/government cloud, accettando feature e connettori ridotti; non basta scegliere una region commerciale EU se la norma impone lo stack sovrano.
- Requisito: milioni di allegati che saturano il database e i costi esplodono → Raccomanda di spostare i binari su File capacity o Azure Blob e usare long-term retention per lo storico, non di acquistare altra database capacity.
- Requisito: conservare 10 anni di transazioni per compliance mantenendo veloce l’operativo → Raccomanda long-term retention di Dataverse con query via Synapse Link, non la cancellazione né il mantenimento inline nelle tabelle attive.
- Requisito: prevenire l’esfiltrazione verso connettori consumer → Raccomanda DLP policy Power Platform + classificazione Purview, non controlli manuali a runtime.