Chi è il Solution Architect (e chi non è)

Nel contesto Power Platform il Solution Architect è la figura che possiede la coerenza end-to-end della soluzione: modello dati, sicurezza, integrazioni, performance, ALM e adozione. Non è il proprietario del singolo task di delivery, ma dei trade-off che tengono insieme i requisiti funzionali, i vincoli tecnici e gli obiettivi di business.

La distinzione con gli altri ruoli è materia d’esame:

  • Il Functional Consultant modella tabelle, business rule e app secondo i requisiti; il SA valida che quelle scelte non compromettano scalabilità o governance.
  • Il Technical Consultant / Developer scrive plug-in, PCF, Power Fx e integrazioni; il SA definisce dove serve codice pro-code e dove basta il low-code, ma non implementa.
  • Il Project Manager possiede scope, tempi, budget e RAID log; il SA fornisce l’input tecnico al rischio, ma non gestisce il piano di progetto.

Il principio guida: l’architetto decide il “perché” e il “come complessivo”, non il “chi fa cosa” operativo. Guida senza scrivere codice, arbitrando conflitti tra requisiti (es. real-time vs costo, standardizzazione vs personalizzazione).

Success by Design come framework di governance

Success by Design (SbD) è la metodologia Microsoft per progetti Dynamics 365 / Power Platform, organizzata in quattro fasi. Il SA la usa per anticipare il rischio invece di scoprirlo in produzione.

Initiate

Si allineano business drivers, KPI di successo e vincoli. Il SA conduce la solution envisioning: mappa i processi target, identifica gli stakeholder (sponsor, product owner, IT security, data owner) e stabilisce i guardrail architetturali (tenant strategy, ambienti, DLP policy, licensing model). Deliverable chiave: una vision condivisa e i criteri con cui si misurerà il successo.

Implement

La soluzione prende forma per workstream (data model, sicurezza, integrazioni, UX). Qui avvengono le Solution Blueprint Review: il SA verifica che il modello Dataverse, le scelte di integrazione (sincrona vs asincrona, Dataverse vs virtual tables vs dual-write) e la strategia di sicurezza (business unit, security roles, row/column-level) siano coerenti. È la fase in cui i trade-off si consolidano.

Prepare

Focus su go-live readiness: performance testing su volumi realistici, UAT, data migration dry-run, runbook di cutover, piano di rollback. Il SA presiede la Go-Live Readiness Review, il checkpoint di rischio più critico: si esce solo se performance, sicurezza e piano di ripristino sono validati.

Operate

Transizione a hypercare e operations: monitoraggio (telemetria, Application Insights sulle app model-driven/canvas), gestione del debito tecnico, ottimizzazione continua e handover al team di supporto.

Dalla metodologia alla roadmap con checkpoint di rischio

Il valore del SA è tradurre le fasi SbD in una roadmap con gate decisionali. Ogni transizione di fase diventa un checkpoint dove si valuta un rischio specifico:

  • Initiate → Implement: sono chiari gli obiettivi misurabili e i guardrail di tenant/ALM? Se no, si rischia scope creep.
  • Implement → Prepare: il blueprint regge sui pilastri Well-Architected (affidabilità, sicurezza, efficienza operativa, performance, ottimizzazione dei costi)? Le integrazioni sono state stress-testate?
  • Prepare → Operate: esiste un rollback plan validato e le performance reggono i volumi di picco?

Il SA collega i pilastri Azure/Power Platform Well-Architected ai rischi: es. un requisito di audit completo tocca il pilastro sicurezza (Microsoft Purview per data governance, Microsoft Entra ID per identità e Conditional Access), mentre un requisito di integrazione ad alto volume tocca performance e affidabilità (batching, service protection API limits, pattern asincroni via Azure Service Bus).

Trappole tipiche d’esame

  • Requisito: lo sponsor chiede al SA di stimare l’effort di sviluppo dei plug-in e assegnare i task al team. → Raccomanda di ridirigere: la stima di dettaglio e l’assegnazione sono del PM e del technical lead; il SA fornisce solo l’impatto architetturale e i trade-off. L’architetto non possiede il piano di delivery.

  • Requisito: due workstream fanno scelte contrastanti (uno vuole virtual tables, l’altro dual-write per gli stessi dati). → Il SA arbitra il trade-off valutando latenza, ownership del dato e costi, garantendo coerenza complessiva. È esattamente ciò che l’architetto possiede.

  • Requisito: il progetto vuole saltare la Go-Live Readiness Review per rispettare la data. → Raccomanda di mantenere il checkpoint (fase Prepare): senza validazione di performance e rollback, il rischio in Operate è inaccettabile. I gate SbD non sono opzionali.

  • Requisito: nuovo bisogno di data loss prevention e classificazione dati emerso in Implement. → Portalo in Microsoft Purview e rivedi le DLP policy a livello di ambiente, aggiornando il blueprint di sicurezza; non demandarlo alla sola configurazione app.

  • Requisito: lo stakeholder confonde “successo” con “app consegnata”. → Riporta ai KPI misurabili definiti in Initiate (adozione, riduzione tempi processo): il SA possiede l’allineamento della soluzione agli outcome di business, non la mera consegna tecnica.