Per gestire la community di utenti nel modo più efficace, analizzare come organizzare al meglio gli utenti a livello di sito o di organizzazione. Laddove possibile, creare gruppi definiti dall'utente a livello di sito o di organizzazione e team condivisi a livello di organizzazione, quindi utilizzare questi gruppi e team durante la creazione dei contesti di applicazione.

Quando si decide quali ruoli devono essere utilizzati nei team condivisi e locali, assicurarsi di controllare i modelli di team che verranno utilizzati in modo da abbinare i ruoli nei team di contesto ai ruoli utilizzati nei modelli di team in base alle esigenze.

Per offrire agli utenti la massima efficienza di accesso ai dati aziendali, è importante utilizzare team di contesto progettati non solo per un controllo di accesso accurato ma anche per prestazioni ottimali del sistema.

I siti in cui sono previste migliaia di prodotti, progetti o librerie devono attenersi scrupolosamente alle seguenti linee guida nella progettazione di una struttura per i team di contesto. Queste linea guida possono contenere potenziali ottimizzazioni anche per team progettati e in uso da tempo. Le tecniche di ottimizzazione possono offrire vantaggi anche a siti di dimensioni inferiori.

Progettare la struttura dei team basandosi interamente su team locali risulta spesso più facile, ma i team locali sono business object caratterizzati da un impiego molto elevato di memoria e potenza di elaborazione. Quanto più elaborata e specifica è la struttura di un team, tanto più è impegnativa per risorse di sistema come quelle riportate di seguito.

Strutture di team molto grandi e complesse, moltiplicate per le migliaia di prodotti e contenitori in cui vengono utilizzate, possono incidere significativamente sulle risorse di sistema. Non solo strutture di team complesse possono rallentare le funzionalità specifiche del team, ma in casi estremi il carico generato sulle risorse di sistema può avere un impatto negativo sulle prestazioni complessive del sistema. È pertanto importante un'accurata pianificazione per progettare una struttura di team ottimale in grado di soddisfare le esigenze aziendali e non influire negativamente sulle prestazioni.

Nella progettazione di una struttura di team, la motivazione principale è soddisfare i requisiti aziendali in termini di permessi per i diversi segmenti della community di utenti ai fini dell'accesso al contenuto nei contesti di applicazione. Nel processo di progettazione dei team, attenersi alle linee guida riportate di seguito.

In genere, i permessi necessari agli utenti rientrano in due categorie: se i diritti di accesso devono essere basati sul ruolo di un utente in un contesto di applicazione o se devono essere concessi all'utente indipendentemente dal suo ruolo in un contesto. Questa distinzione consente di determinare se l'accesso deve essere concesso ai partecipanti indipendenti dal contesto o ai partecipanti specifici del contesto.

Per i partecipanti che devono accedere agli oggetti, che siano membri o meno del contesto di applicazione in cui risiedono gli oggetti, creare delle regole di controllo d'accesso utilizzando i seguenti partecipanti: utenti, gruppi definiti dall'utente, organizzazioni o pseudoruoli.

Si supponga, ad esempio, che tutti gli utenti di un'organizzazione debbano disporre del permesso di lettura per i documenti di specifica nello stato Rilasciato di tutti i prodotti pubblici all'interno dell'organizzazione. Per concedere ai partecipanti dell'organizzazione il permesso di lettura per il tipo di documenti di specifica nello stato Rilasciato, applicare questi diritti di accesso attraverso una regola di controllo d'accesso definita in un dominio PDM, di default o dell'organizzazione.

Per i partecipanti che richiedono l'accesso a oggetti che si trovano in un contesto di applicazione in base al ruolo nel contesto, creare le regole di controllo d'accesso utilizzando gruppi di sistema e ruoli dinamici. Quando si creano le regole di controllo d'accesso per i ruoli, occorre valutare se la regola deve essere applicata a un ruolo dinamico, se le esigenze del permesso per tale ruolo sono uguali tra contesti oppure se è necessario creare la regola per un gruppo di sistema perché le esigenze di permesso del ruolo cambiano tra i contesti di applicazione.

È ad esempio possibile che gli utenti responsabili della progettazione di un prodotto debbano disporre del permesso di creazione e modifica per tipi di dati specifici. Questo si applica solo ai prodotti per cui agli utenti è stato assegnato lavoro di progettazione. Applicare questi permessi attraverso i ruoli dinamici associati ai progettisti nei team locali o condivisi.

Quando si crea un contesto di applicazione, è possibile valutare l'utilizzo di un team condiviso se i partecipanti e i ruoli del team sono uguali tra un insieme di contesti. Se i ruoli del team o i partecipanti nei ruoli cambiano tra i contesti di applicazione, utilizzare un team locale. Se le modifiche tra i contesti di applicazione sono secondarie, prendere in considerazione l'utilizzo di un team condiviso esteso a livello locale.

È possibile combinare le diverse opzioni. Non è necessario implementare una singola opzione per tutti i casi. Ad esempio, è possibile scegliere di utilizzare i team condivisi per i contesti di libreria e i team locali per determinati insiemi di contesti di progetto e di prodotto e i team condivisi estesi localmente per altri insiemi di contesti di progetto e di prodotto.

Nell tabelle seguenti vengono forniti ulteriori dettagli sulle varie tecniche per gestire i permessi per i team e sul relativo impatto sulle prestazioni.

Esistono alcune procedure comuni da evitare quando si progettano i team. Nella tabella riportata di seguito sono elencate diverse procedure con i rispettivi svantaggi.

Di seguito sono riportate alcune tecniche di ottimizzazione del sistema utili correlate ai team.