La fit/gap analysis è il cuore del lavoro del Solution Architect: prima di scrivere una sola riga di codice, devi mappare ogni requisito funzionale e non funzionale sulle capability native della piattaforma. L’obiettivo non è dimostrare cosa Power Platform “può fare”, ma decidere cosa conviene fare rispetto a costo, rischio e sostenibilità nel tempo.

Classificare i requisiti

Ogni requisito va etichettato in tre categorie:

  • Fit: coperto out-of-the-box da Dynamics 365 (Sales, Customer Service, Field Service) o dalle primitive di Dataverse/Power Apps senza configurazione significativa.
  • Gap: nessuna capability nativa lo soddisfa; richiede configurazione avanzata, estensione o integrazione.
  • Workaround accettabile: un compromesso di processo o una configurazione leggera che soddisfa lo spirito del requisito senza replicarlo alla lettera.

Il valore dell’architetto sta proprio nel negoziare i workaround: convincere lo stakeholder che un business process flow standard, invece di una UI custom, copre il 90% del bisogno a una frazione del costo e del debito tecnico.

La scala configure-first

La regola d’oro PL-600 è procedere dal meno invasivo al più invasivo, salendo di gradino solo quando quello inferiore non basta:

  1. Configure — tabelle, colonne, form, view, business rules, business process flow, security roles. Zero codice, aggiornamenti gestiti da Microsoft.
  2. Extend low-code — Power Automate cloud flow, Power Fx, canvas/model-driven customization, Copilot Studio agents, connettori standard e custom.
  3. Extend pro-code — plug-in Dataverse, custom API, PCF (Power Apps Component Framework), client scripting. Serve solo per logica transazionale server-side o UI non ottenibile in low-code.
  4. Integrate — Azure Functions, Logic Apps, Service Bus, eventi Dataverse verso sistemi esterni.
  5. Build/Buy — soluzione ISV da AppSource oppure sviluppo di un’app first-party dedicata.

Ogni gradino aggiunge debito tecnico: più codice significa più test di regressione a ogni wave update, più competenze rare da mantenere e più rischio di supportabilità. Un plug-in mal scritto che blocca il pipeline transazionale è molto più costoso, nel ciclo di vita, di una business rule equivalente.

Build vs buy

Quando il gap è ampio e trasversale (es. gestione documentale, e-signature, calcolo provvigioni complesso), la domanda diventa acquistare o costruire. Raccomanda buy quando:

  • esiste una soluzione AppSource matura e certificata che copre il requisito core;
  • il dominio non è un differenziatore competitivo del cliente;
  • il TCO del build (sviluppo + manutenzione pluriennale + skill) supera il costo di licenza dell’ISV.

Raccomanda build quando il processo è un vero vantaggio competitivo, quando nessun prodotto si adatta senza customizzazioni pesanti che ne romperebbero la supportabilità, o quando i vincoli di data residency/compliance escludono il SaaS di terze parti. Attenzione: un ISV che va “forkato” con customizzazioni non supportate è spesso il peggiore dei due mondi.

Allineamento al Well-Architected

Valuta ogni decisione sui pilastri del Power Platform Well-Architected Framework: Reliability (il plug-in regge i picchi e i timeout Dataverse?), Security (chi accede al connettore custom, con quali credenziali?), Operational Excellence (ALM con solution managed e pipeline, o modifiche unmanaged in produzione?), Performance Efficiency e Experience Optimization. Una soluzione tecnicamente elegante ma non gestibile in ALM è un anti-pattern d’esame.

Trappole tipiche d’esame

  • Requisito: “notificare un team quando un record cambia stato” → soluzione raccomandata: Power Automate cloud flow con connettore standard, non un plug-in custom. La trappola è scegliere pro-code per logica che il low-code copre in modo aggiornabile.
  • Requisito: “integrare un ERP on-premises via API REST” → soluzione: connettore custom + on-premises data gateway (o Azure Logic Apps), non replicare i dati ERP in Dataverse con un sync artigianale che genera drift e debito.
  • Requisito: “il cliente vuole una funzionalità di firma elettronica conforme” → soluzione: buy una soluzione AppSource certificata, non costruire da zero una capability non differenziante e onerosa da mantenere in compliance.
  • Requisito: “validazione complessa multi-record al salvataggio, transazionale e atomica” → soluzione: plug-in Dataverse sincrono nella pipeline, perché business rule e flow non garantiscono l’atomicità server-side. Qui salire a pro-code è giustificato.
  • Requisito: “UI custom per replicare esattamente un vecchio gestionale” → soluzione: proponi un workaround con model-driven app standard e negozia la user experience. La trappola è ricostruire pixel-per-pixel il legacy con PCF e canvas pesanti, creando un guscio custom che vanifica i vantaggi della piattaforma e diventa impossibile da aggiornare.

Il messaggio ricorrente PL-600: il gap più pericoloso non è quello che non sai colmare, ma quello che colmi con troppo codice quando configurazione o connettore standard sarebbero rimasti più sostenibili e supportabili.