Dal requisito al modello di licensing
Il primo compito dell’architetto non è scegliere una licenza, ma mappare personas e pattern di consumo al modello economico corretto. Le domande guida sono: quante app usa realmente ogni utente, servono capacità Dynamics 365 (Sales, Customer Service, Field Service) o basta un’app custom su Dataverse, il carico è prevedibile o stagionale, e soprattutto chi o cosa genera traffico verso la piattaforma.
Le opzioni principali:
- Power Apps Premium (per-user): diritto a un numero illimitato di app custom e portali per l’utente nominale. Lo raccomandi quando la persona è un power user che tocca molte app o quando il portafoglio applicativo è in crescita.
- Power Apps per app: copre una singola app (o portale) per utente. Conviene per popolazioni ampie ma con un solo caso d’uso — tipico degli scenari “molti utenti, un’app”. Attenzione: oltre 2-3 app per utente il per-user diventa più economico.
- Licenze Dynamics 365: includono i diritti Power Platform nel contesto della propria app. Estendere una tabella D365 è coperto; costruire un’app autonoma non correlata richiede una licenza Power Apps aggiuntiva.
- Pay-as-you-go (via subscription Azure): fatturazione a consumo per monthly active user per app. È la scelta d’elezione per carichi imprevedibili, utenti sporadici o pilot, perché elimina l’impegno anticipato.
- Capacity add-on: Dataverse storage, Power Platform Requests, AI Builder credits, hosted RPA. Sono acquisti mirati, non licenze utente.
Dataverse: storage e request come vincoli di design
Lo storage Dataverse si articola in tre pool distinti — Database, File e Log — con costi molto diversi (il Database è di gran lunga il più caro per GB). Un errore di design frequente è tenere allegati e immagini nelle colonne File/Database anziché offloadare su Azure Blob o SharePoint tramite file/image columns con storage esterno. Il tenant riceve una base fissa più un accrual per licenza idonea, quindi lo storage cresce con le licenze acquistate: stimalo sui volumi di righe × dimensione media × tasso di crescita, includendo audit log e retention.
Il secondo vincolo, spesso ignorato, sono le Power Platform request (create/read/update/delete, chiamate a connettori, esecuzioni di flow). Ogni licenza porta un entitlement giornaliero per l’utente interattivo, ma le API request non interattive — integrazioni server-to-server, application user, service account, flow schedulati — non sono coperte dai posti nominali e consumano capacità che va licenziata con Power Platform Requests add-on o pay-as-you-go. Separato è il tema dei service protection limit (finestra scorrevole per utente/server): non si comprano, si mitigano con batching, $batch, backoff e distribuzione del carico.
Capacity planning, TCO e ROI
Il trade-off centrale, in ottica Power Platform Well-Architected (pilastri Performance Efficiency e Operational Excellence, con il costo come dimensione trasversale), è tra over-provisioning e sorpresa a runtime. Comprare capacità di picco tutto l’anno gonfia il TCO; sottodimensionare produce throttling in produzione e utenti bloccati.
La raccomandazione architetturale:
- Baseline prevedibile → licenze committed (per-user/per-app) per il costo unitario minimo.
- Picchi e incertezza → pay-as-you-go sul delta, trasformando CapEx in OpEx elastico.
- Integrazioni → dimensiona separatamente le request non interattive e monitorane il consumo dal Power Platform Admin Center e con le capacity/analytics report, impostando alert prima della saturazione.
Il ROI si difende non solo minimizzando la licenza, ma quantificando il valore (ore risparmiate, processi automatizzati, riduzione di shadow IT) contro un TCO che include storage, add-on, ambienti non-produzione e governance.
Trappole tipiche d’esame
- Requisito: 5.000 dipendenti usano una sola app di timesheet → soluzione: Power Apps per app (non per-user), il più economico per “molti utenti, un’app”.
- Requisito: un’integrazione notturna con SAP tramite application user genera centinaia di migliaia di chiamate → soluzione: capacità Power Platform Requests dedicata o pay-as-you-go; dimensionare sui soli utenti nominali è l’errore classico perché il traffico non interattivo non è coperto.
- Requisito: pilot di 3 mesi con adozione incerta → soluzione: pay-as-you-go, nessun impegno anticipato, si converte a licenze committed una volta nota la baseline.
- Requisito: crescita di allegati documentali molto rapida → soluzione: file/image column su storage esterno (Blob) invece di gonfiare il costoso Database capacity Dataverse.
- Requisito: l’utente estende solo tabelle Dynamics 365 Sales → soluzione: nessuna licenza Power Apps aggiuntiva; è coperto nel contesto della licenza D365, che serve invece per app custom non correlate.