Perché il landscape esistente decide il design, non i requisiti funzionali

Come Solution Architect PL-600, l’errore più costoso non è scegliere il componente Power Platform sbagliato: è progettare l’integrazione prima di aver capito dove vive il dato autoritativo. La valutazione dei sistemi esistenti non è una formalità di discovery — è l’attività che determina se Microsoft Dataverse sarà un system of record (proprietario del dato) o un system of engagement (superficie di interazione che consuma dati altrui). Confondere i due ruoli genera duplicazione di master data, conflitti di ownership e debito tecnico che nessun connettore risolve a posteriori.

Inventariare sistemi, fonti autoritative e flussi

Il primo output atteso è una mappa del landscape: sistemi coinvolti (ERP come SAP/Dynamics 365 Finance, CRM legacy, HR, data warehouse, applicazioni custom), integrazioni già esistenti (batch notturni, API, middleware, iPaaS) e — soprattutto — quale sistema è authoritative source per ciascuna entità di business.

Per ogni entità (Customer, Product, Employee, Order) devi rispondere a tre domande di design:

  • Chi crea e possiede il record? Il sistema che detiene il ciclo di vita anagrafico è il master.
  • Chi lo consuma e chi lo modifica? Determina la direzionalità dell’integrazione (one-way, bidirezionale, write-back selettivo).
  • Quali sono i vincoli di conformità e latenza? Real-time, near-real-time o batch cambiano radicalmente il pattern.

Solo dopo questa mappatura ha senso decidere il posizionamento di Power Platform.

Dataverse: system of record o system of engagement?

Il trade-off centrale.

  • Dataverse come system of record è appropriato quando l’entità nasce nel processo che stai costruendo (es. un’app di gestione ispezioni, richieste interne, casi che non esistono a monte). Qui Dataverse possiede il dato, applica business rules, security roles e audit nativi.
  • Dataverse come system of engagement è la scelta corretta quando il master data risiede — e deve restare — in un sistema a monte. In questo caso Dataverse ospita una copia di lavoro (cached/projected data), mentre l’ERP rimane la fonte di verità. Il write-back verso il master avviene solo per i campi che il processo è autorizzato a modificare.

Per il secondo scenario, i pattern da valutare sono virtual tables (dato letto live dal sistema origine senza replica fisica — ideale quando la freschezza e il non-duplicare sono prioritari, a costo di dipendenza dalla disponibilità della source), oppure sincronizzazione via Azure Synapse Link / Fabric per analytics, o integrazione event-driven con Azure Service Bus / Event Grid per disaccoppiare i sistemi.

Allineamento al Well-Architected Framework

Le decisioni di integrazione vanno pesate sui pilastri:

  • Reliability: una virtual table introduce un single point of failure sulla source; un pattern replicato con retry e dead-letter queue è più resiliente ma eventualmente inconsistente.
  • Performance Efficiency: query cross-system in tempo reale non scalano come dati locali indicizzati.
  • Operational Excellence: meno copie di master data significa meno riconciliazione e minor superficie di errore.
  • Security: il dato sensibile andrebbe classificato con Microsoft Purview e i flussi governati con DLP policies; l’identità va federata su Microsoft Entra ID evitando credenziali locali nei connettori.

Dipendenze e vincoli che condizionano il design

Documenta esplicitamente: sistemi legacy senza API moderne (che impongono un middleware o un connector custom), finestre di manutenzione batch, ownership organizzativa del dato (un team che non cederà il controllo del master), requisiti di data residency e vincoli di licensing/throttling delle API a monte. Questi vincoli spesso escludono l’opzione tecnicamente più elegante prima ancora di valutarla.

Trappole tipiche d’esame

  • Requisito: l’anagrafica clienti è gestita in SAP e deve restarci per compliance → soluzione raccomandata: Dataverse come system of engagement con virtual tables o sync read-only; NON eleggere Dataverse a master duplicando l’anagrafica.
  • Requisito: serve il dato ERP sempre fresco, senza copie e senza riconciliazione → soluzione: virtual tables (accetti la dipendenza dalla disponibilità della source in cambio di zero duplicazione), non una replica batch.
  • Requisito: alto volume, analytics e report su dati Dataverse senza impattare l’app transazionale → soluzione: Synapse Link / Microsoft Fabric, non query dirette sul database operativo.
  • Requisito: due sistemi devono restare disaccoppiati e tollerare indisponibilità reciproca → soluzione: integrazione event-driven con Service Bus/Event Grid, non chiamate sincrone punto-a-punto.
  • Requisito: nessuna fonte autoritativa esiste per la nuova entità di processo → soluzione: Dataverse system of record a pieno titolo, con business rules e audit nativi; qui la virtual table sarebbe un anti-pattern.