Pianificazione dell'implementazione di Power BI: pianificare e progettare contenuti

Questo articolo consente di pianificare e progettare i contenuti come parte della gestione del ciclo di vita dei contenuti. È destinato principalmente a:

• Centro di eccellenza (COE) e team BI: team responsabili della supervisione di Power BI nell'organizzazione. Questi team includono decision maker che decidono come gestire il ciclo di vita del contenuto di Power BI.
• Autori di contenuti e proprietari di contenuti: utenti che creano contenuti che vogliono pubblicare nel portale di Fabric per condividerli con altri utenti. Questi utenti sono responsabili della gestione del ciclo di vita del contenuto di Power BI creato.

La gestione del ciclo di vita è costituita dai processi e dalle procedure usate per gestire il contenuto dalla creazione al ritiro finale. Come descritto nel primo articolo in questa serie, la gestione del ciclo di vita dei contenuti di Power BI è importante per garantire la distribuzione affidabile e coerente dei contenuti agli utenti aziendali.

La prima fase del ciclo di vita dei contenuti consiste nel pianificare e progettare i contenuti. In genere il ciclo di vita dei contenuti si avvia eseguendo la pianificazione della soluzione BI. Si raccolgono i requisiti per comprendere e definire il problema che la soluzione deve affrontare e arrivare alla progettazione di una soluzione. Durante questa fase di pianificazione e progettazione, si prendono decisioni chiave per prepararsi alle fasi successive.

L'immagine seguente illustra il ciclo di vita del contenuto di Power BI, evidenziando la fase uno, in cui si pianificano e progettano i contenuti.

Quando si raccolgono i requisiti, è necessario descrivere chiaramente gli aspetti relativi ai contenuti che influiscono sull'approccio alla gestione del ciclo di vita. È consigliabile documentare questi aspetti come parte della pianificazione e della progettazione della soluzione.

Le sezioni seguenti di questo articolo descrivono gli aspetti chiave e le considerazioni di una soluzione che motivano l'approccio alla gestione del ciclo di vita durante la pianificazione e la progettazione dei contenuti.

Identificare e descrivere i contenuti

Quando si progetta la soluzione, è necessario descrivere i contenuti, chi li creerà, chi li supporterà e quanto questi contenuti siano essenziali per l'organizzazione. È consigliabile affrontare questi fattori durante o dopo la raccolta dei requisiti nell’ambito della progettazione della soluzione.

Rispondere alle domande seguenti sui contenuti per prendere decisioni sulla gestione del ciclo di vita in un secondo momento.

Qual è il formato dei contenuti?

Il tipo, l'ambito e la complessità dei contenuti motivano le decisioni chiave sulla gestione. Ad esempio, un singolo report per un gruppo di destinatari limitato richiede un approccio diverso alla gestione del ciclo di vita rispetto a un modello semantico che verrà usato dall'intera organizzazione e da più carichi di lavoro downstream diversi.

Rispondere a domande come le seguenti per determinare il tipo di contenuto che verrà creato.

• Quali tipi di elementi si prevede di creare e quanti di ciascuno di essi? Ad esempio, si creeranno elementi di dati come flussi di dati o modelli semantici, elementi di report come report o dashboard, o una combinazione di entrambi?
• In che modo i contenuti vengono distribuiti ai consumer di contenuti? Ad esempio, i consumer useranno gli elementi di dati per creare i propri contenuti, visualizzeranno solo report centralizzati, o una combinazione di entrambi?
• Quanto sono complessi i contenuti? Ad esempio, è un piccolo prototipo o è un modello semantico di grandi dimensioni che comprende più processi aziendali?
• Si prevede che la scalabilità, l'ambito e la complessità dei contenuti aumentino nel tempo? Ad esempio, in futuro i contenuti comprenderanno altre aree geografiche o aree aziendali?
• Quanto tempo si prevede che l'azienda richieda questi contenuti? Ad esempio, questi contenuti supporteranno un'iniziativa chiave dell'azienda con una sequenza temporale limitata?

Chi creerà e supporterà i contenuti?

Gli autori di contenuti hanno esigenze, capacità e flussi di lavoro diversi. Questi fattori influenzeranno il successo di diversi approcci di gestione del ciclo di vita. I team più grandi e centrali che lavorano in collaborazione richiedono spesso una gestione più sofisticata del ciclo di vita dei contenuti rispetto ai team più piccoli di autori self-service.

Rispondere a domande come le seguenti per determinare chi creerà o supporterà i contenuti.

• Quante persone diverse si prevede che creeranno questi contenuti? Collaboreranno più autori di contenuti, o è un singolo individuo a essere responsabile della creazione dei contenuti?
• Gli autori di contenuti hanno familiarità con la gestione del ciclo di vita e i concetti correlati, ad esempio il controllo della versione? Gli autori di contenuti comprendono i vantaggi della gestione del ciclo di vita?
• I creatori di contenuti che sviluppano la soluzione saranno gli stessi utenti che lo supporteranno dopo la distribuzione?
• Gli autori di contenuti o i loro team dispongono di procedure di gestione del ciclo di vita esistenti per supportare le soluzioni esistenti?
• Gli autori di contenuti attualmente usano strumenti di gestione del ciclo di vita come Azure DevOps?

Qual è il livello di importanza dei contenuti?

A seconda dell'importanza che i contenuti rivestono per l'azienda, verranno prese decisioni mirate sulla sua gestione. I contenuti critici per l'azienda richiedono approcci più affidabili per la gestione del ciclo di vita dei contenuti, al fine di salvaguardare la qualità e ridurre le possibili interruzioni.

Rispondere a domande come le seguenti per determinare se i contenuti sono critici.

• Quanto sono critici questi contenuti per l'azienda? Quanto è urgente la richiesta di svilupparli?
• Le decisioni o le azioni critiche per l'azienda verranno prese in base alle informazioni fornite da questi contenuti?
• In che misura si prevede di distribuire questi contenuti (a livello di organizzazione, o in un team locale limitato)?
• I dirigenti o altri decision maker strategici si affidano a questi contenuti per il loro lavoro?
• Qual è l'impatto di questi contenuti? Ad esempio, se i contenuti improvvisamente non sono disponibili, quali effetti potrebbero verificarsi sull’azienda, ad esempio ricavi persi o processi aziendali interrotti?

Dopo aver identificato e descritto in modo sufficiente i contenuti che verranno creati, è necessario decidere in che modo gli autori di contenuti devono collaborare.

Decidere in che modo gli autori di contenuti devono collaborare

Man mano che una soluzione aumenta nell'ambito e nella complessità, potrebbe essere necessario che più creatori di contenuti e proprietari lavorino in collaborazione. Quando si creano soluzioni complesse, è consigliabile usare strumenti efficaci che consentano di strutturare, gestire e supportare la collaborazione. Esistono molti modi per collaborare quando si producono contenuti di Power BI, ad esempio usando Microsoft Teams o Azure DevOps.

Microsoft Teams

Per i progetti più piccoli o più semplici, gli autori di contenuti possono collaborare usando Microsoft Teams.

Usando Microsoft Teams, gli autori di contenuti strutturano la comunicazione, la pianificazione e il lavoro nei team e nei canali. Microsoft Teams è spesso una scelta ottimale per gli scenari di collaborazione più semplici. Ad esempio, i team decentralizzati che producono contenuti per un gruppo di destinatari limitato possono usare raccolte di documenti per archiviare file e controllo della versione. Possono usare anche altri strumenti e servizi integrati.

Per collaborare e comunicare in Microsoft Teams, è possibile usare i servizi di supporto per tutto il ciclo di vita dei contenuti di Power BI.

• Planner: i proprietari di contenuti possono usare Planner per creare piani, che vengono usati per tenere traccia delle attività e definire l'ambito di lavoro dei contenuti. Le attività possono descrivere problemi, bug o funzionalità nella soluzione, nonché gli stakeholder corrispondenti.
• SharePoint: gli autori di contenuti possono archiviare e gestire i file in una raccolta documenti di Microsoft Teams o in un sito connesso per ogni canale. I file di contenuti archiviati in SharePoint possono usare il controllo della versione per monitorare e gestire le modifiche ai contenuti. Per altre informazioni sul monitoraggio e sulla gestione delle modifiche tramite SharePoint, vedere Fase 2: Sviluppare contenuti e gestire le modifiche.
• Approvazioni: autori e proprietari di contenuti possono configurare e usare flussi di lavoro per approvare le modifiche o le versioni dei contenuti dopo la revisione.
• Infrastruttura e Power BI: autori e proprietari di contenuti possono accedere al portale di Fabric da Microsoft Teams. Da qui possono gestire o discutere i contenuti e aggiungere report utili alle schede nei canali di Teams.
• Altre integrazioni: gli autori di contenuti possono usare altri servizi Microsoft o di terze parti che si integrano con Microsoft Teams per soddisfare al meglio il flusso di lavoro e le esigenze preferiti.

È consigliabile definire un processo strutturato che stabilisca in che modo i creatori di contenuti devono usare Microsoft Teams per collaborare. Assicurarsi di determinare:

• Come gestire l'accesso ai team e ai canali.
• Chi è responsabile della gestione dei team e dei canali.
• L'ambito e l'organizzazione del lavoro in team, canali e piani distinti.
• Come gli autori di contenuti devono usare una raccolta documenti per organizzare i file e monitorare e gestire le modifiche. Ad esempio, come organizzare la raccolta documenti e se gli autori di contenuti devono archiviare ed estrarre i file.
• Se gli autori di contenuti devono usare Aggiornamento OneDrive per pubblicare automaticamente i file di Power BI Desktop (con estensione pbix).
• Come vengono risolti i conflitti di sincronizzazione file.
• Quando archiviare e rimuovere file che non sono più rilevanti da una raccolta documenti.

Azure DevOps

Gli autori di contenuti e i proprietari possono anche comunicare e collaborare in un hub centrale organizzato usando Azure DevOps.

Usando Azure DevOps, gli autori di contenuti usano progetti per strutturare le comunicazioni, la pianificazione e il lavoro. Inoltre, gli autori di contenuti possono orchestrare la gestione del ciclo di vita dei contenuti da Azure DevOps eseguendo controllo del codice sorgente, convalida e distribuzione. Il controllo del codice sorgente è il processo di gestione di modifiche più granulari al codice e ai metadati dei contenuti.

Azure DevOps è spesso una scelta ottimale per scenari di collaborazione più avanzati, perché sono disponibili servizi di supporto e opzioni per orchestrare la creazione e la distribuzione dei contenuti.

È consigliabile definire un processo strutturato che stabilisca in che modo i creatori di contenuti devono usare Azure DevOps per collaborare. Assicurarsi di determinare:

• Modalità di definizione dell'ambito del lavoro e modalità di creazione, denominazione e uso dei rami di contenuti.
• Modalità di raggruppamento e commit delle modifiche e relativa descrizione nei messaggi di commit da parte degli autori.
• Chi sia responsabile della revisione e dell'approvazione delle modifiche tramite le richieste pull.
• Come eseguire il pull dei conflitti di merge delle richieste risolti e chi sono gli utenti che li risolvono.
• Modalità di unione delle modifiche apportate in rami diversi in un singolo ramo.
• Modalità di test del contenuto e chi debba eseguire il test prima della distribuzione del contenuto.
• Modalità e tempistiche di distribuzione delle modifiche nelle aree di lavoro di sviluppo, test e produzione.
• Modalità e tempistiche di esecuzione del rollback delle modifiche o delle versioni distribuite della soluzione.

Dopo aver deciso se e come i creatori di contenuti devono collaborare, occorre decidere dove archiviare i file. Molti di questi file verranno archiviati nella posizione in cui si sceglie di collaborare.

Decidere dove archiviare i file

Quando si creano contenuti, in genere si producono tipi diversi di file. È importante decidere dove archiviare questi file, in modo da poterli gestire in modo efficace.

I tipi di file da archiviare spesso includono:

• File di contenuto: file che contengono i dati o i metadati dei contenuti. I file di contenuto con dati come file con estensione pbix e file di progetto Power BI (con estensione pbip) contengono informazioni riservate. Archiviare i file di contenuto in una posizione sicura accessibile solo da coloro che devono accedervi. Inoltre, è consigliabile archiviare i file di contenuto in un percorso che supporta il controllo della versione, ad esempio una raccolta documenti in Microsoft Teams o un repository Git in Azure DevOps. Esempi di file di contenuto includono:
  • File di Power BI Desktop (con estensione pbix)
  • File di progetto Power BI (con estensione pbip)
  • File di report impaginati di Power BI (con estensione rdl)
  • File di metadati del modello (con estensione bim o TMDL)
  • File di metadati del flusso di dati (con estensione json)
• File di origine dati: file utilizzati da elementi di dati come modelli semantici o flussi di dati. Il contenuto dipende direttamente dai file di origine dati, quindi è importante considerare attentamente dove vengono archiviati poiché la loro rimozione comporterà un errore di aggiornamento dei dati. Inoltre, questi file potrebbero contenere informazioni riservate. Archiviare quindi i file di origine dati in un ambiente sicuro, affidabile e attendibile, con accesso limitato da parte di altri utenti. Esempi di file di origine dati possono includere:
  • Origini dati strutturate, ad esempio cartelle di lavoro di Excel, Parquet o file CSV.
  • Origini dati semistrutturate, ad esempio file JSON o XML.
  • Origini dati non strutturate, ad esempio immagini importate nei report.
• File di supporto: file che supportano la creazione o la gestione dei contenuti, ma non sono necessari per il funzionamento. I file di supporto devono essere archiviati in un percorso che supporta il controllo della versione e a cui possono accedere altri strumenti e autori di contenuti. Esempi di file di supporto possono includere:
  • File di regole Best Practice Analyzer (con estensione json).
  • File del tema di Power BI (con estensione json).
  • File di codice sorgente per contenuti e query.
  • File di visualizzazione personalizzata (con estensione pbiviz).
• Modelli e documentazione: file che agevolano la creazione di contenuti self-service o descrivono i contenuti esistenti. I modelli e la documentazione devono essere facilmente accessibili dalle persone che hanno bisogno di usarli. Esempi di modelli e documentazione possono includere:
  • File modello di Power BI (con estensione pbit).
  • Modelli di visualizzazione e report di esempio.
  • Progetti e documentazione delle soluzioni.
  • Pianificazione e roadmap delle soluzioni.
  • Richieste utente e problemi relativi alle soluzioni.

Sono disponibili diverse opzioni per archiviare i file. Assicurarsi di selezionare il percorso appropriato, a seconda del tipo di file, del relativo contenuto e della modalità di utilizzo.

SharePoint Online o OneDrive

Una soluzione comune per l'archiviazione dei file consiste nell'usare i siti di SharePoint . SharePoint è ampiamente accessibile per la maggior parte degli utenti e altamente integrato con Power BI e altre applicazioni di Microsoft 365, come Microsoft Teams. Inoltre, dispone di un controllo della versione predefinito, che consente di archiviare la maggior parte dei tipi di file. Il controllo della versione consente di visualizzare e gestire diverse versioni salvate di un file.

Quando si archiviano file in SharePoint, prendere in considerazione i punti seguenti.

• Organizzazione: assicurarsi di mantenere una struttura coerente e logica in modo che sia semplice trovare file specifici. Usare convenzioni di denominazione valide, organizzare i file in cartelle e archiviare file che non sono più rilevanti per i progetti in corso.
• Aggiornamento OneDrive: è possibile collegare un modello semantico pubblicato o un report a un file con estensione pbix archiviato in un sito di SharePoint o OneDrive for Business (noto anche come OneDrive aziendale o per l’istituto di istruzione). Con questo approccio, non è più necessario pubblicare il modello semantico per attuare le modifiche. Le modifiche sono invece visibili dopo un aggiornamento automatico di OneDrive, che avviene ogni ora. Anche se conveniente, tenere presente che questo approccio presenta alcuni rischi e difficoltà. Una volta eseguita un’azione, non può essere annullata facilmente.
• Report di anteprima: in SharePoint è possibile visualizzare i report di Power BI senza dover installare Power BI Desktop o scaricare il file con estensione pbix in locale. Quando si aprono i report in questo modo, vengono visualizzati nel browser. Questa funzionalità può essere un'alternativa pratica alla visualizzazione dei report dal portale di Fabric. È abilitata per impostazione predefinita nelle impostazioni del tenant di Fabric.

È consigliabile archiviare i tipi di file seguenti in SharePoint.

• Modelli e documentazione: archiviare modelli e documentazione in SharePoint quando non si dispone di una soluzione di archiviazione esistente. SharePoint è ideale per questi file, perché è possibile concedere l'accesso ad altri e gestire i file senza operazioni di installazione o processi complessi.
• File di supporto: archiviare i file di supporto in SharePoint quando non si dispone di una soluzione di archiviazione esistente. Tuttavia, alcuni file di supporto (ad esempio i file del tema di Power BI con estensione json per i report) potrebbero essere archiviati meglio in un sistema di controllo della versione che consente di visualizzare e gestire le modifiche salvate.
• File di contenuto: archiviare i contenuti in SharePoint quando non sono fondamentali per l'azienda o quando non si ha accesso a un repository remoto come Azure Repos.
• Origini dati: archiviare le origini dati in SharePoint solo quando sono di piccole dimensioni e di complessità ridotta. Esercitare la disciplina quando si usa SharePoint per archiviare i file di origine dati. Prendere in considerazione altre possibili alternative, ad esempio OneLake.

OneLake

Se si ha una capacità di Fabric, OneLake può essere una buona scelta per archiviare i file di origine dati. È possibile caricare o sincronizzare i file in OneLake usando Esplora file di OneLake, dove possono essere trasformati in tabelle da usare in carichi di lavoro downstream come Power BI. Per origini dati più grandi o aggiornate regolarmente, è possibile caricare automaticamente i file in OneLake usando Data Factory di Fabric o altre applicazioni che usano l'API Azure Data Lake Storage (ADLS) Gen2 o l’SDK Azure Storage Python.

Repository remoto

Gli autori di contenuti possono eseguire il commit e salvare il lavoro dal computer locale a un repository remoto, ad esempio un repository Git Azure Repos, a intervalli regolari durante lo sviluppo. Un repository remoto contiene la versione più recente della soluzione ed è accessibile dall'intero team di sviluppo. In genere, un repository remoto semplifica gli approcci di gestione del ciclo di vita più avanzati rispetto all'uso di Teams, SharePoint o OneDrive. Questo perché, usando un repository remoto, gli autori di contenuti possono trarre vantaggio da opzioni più complesse per collaborare ai file o monitorare e gestire le modifiche dei file. Ad esempio, gli autori di contenuti possono lavorare nel proprio ramo del repository remoto per apportare modifiche e richiedere di unire tali modifiche nel ramo principale quando sono pronte.

È consigliabile archiviare i tipi di file seguenti in un repository remoto.

• Modelli e documentazione: archiviare modelli e documentazione in un repository remoto quando si gestisce il progetto con servizi correlati come Azure DevOps.
• File di supporto: archiviare i file di supporto in un repository remoto quando ne è disponibile uno per monitorare e gestire facilmente le modifiche.
• File di contenuto: archiviare i contenuti in un repository remoto quando sono fondamentali per l'azienda o si intende collaborare con altri sviluppatori agli stessi contenuti. Un repository remoto è ideale per tenere traccia delle modifiche ai contenuti e agevolare la collaborazione.

Nessun file: contenuti creati nel portale di Fabric

Gli autori di contenuti possono creare contenuti direttamente nel portale di Fabric. In questo scenario, in genere non funzionano direttamente con i file di contenuto. In genere è consigliabile creare contenuti nel portale di Fabric solo quando i tipi di elementi non possono essere creati altrove (ad esempio flussi di dati, dashboard o scorecard). È anche possibile creare report e modelli semantici nel portale di Fabric quando non si ha accesso a un computer Windows e pertanto non è possibile usare Power BI Desktop. Per altre informazioni, vedere Strumenti utente e dispositivi.

Elenco di controllo: quando si pianificano e progettano i contenuti, le decisioni chiave e le azioni includono:

Contenuto correlato

Nell'articolo successivo di questa serie viene illustrato come sviluppare i contenuti e gestire le modifiche come parte della gestione del ciclo di vita dei contenuti.