Für eine möglichst effektive Verwaltung der Benutzer-Community analysieren Sie, wie die Benutzer am besten auf Standort- oder Organisationsebene organisiert werden. Erstellen Sie wenn möglich benutzerdefinierte Gruppen auf Site-Ebene oder Organisationsebene und gemeinsam benutzte Teams auf Organisationsebene, und verwenden Sie dann diese Gruppen und Teams bei der Erstellung von Anwendungskontexten.

Wenn Sie entscheiden, welche Rollen in gemeinsam benutzten und lokalen Teams verwendet werden sollen, stellen Sie sicher, die Teamvorlagen zu überprüfen, die verwendet werden, damit Sie die Rollen mit den Rollen in den Kontext-Teams vergleichen können.

Um Benutzern den effektivsten Zugriff auf Geschäftsdaten bereitzustellen, ist es wichtig, Kontext-Teams zu verwenden, die nicht nur für eine präzise Zugriffssteuerung, sondern auch für optimale Systemleistung konzipiert sind.

Für jeden Standort mit Tausenden von Produkten, Projekten oder Bibliotheken sollte besonders sorgfältig darauf geachtet werden, dass beim Entwurf einer Struktur für Kontext-Teams die folgenden Richtlinien berücksichtigt werden. In diesen Richtlinien können auch für lange verwendete Teamkonstruktionen mögliche Optimierungen gefunden werden. Auch kleine Standorte können von diesen Optimierungstechniken profitieren.

Der Entwurf von Teamstrukturen ist meist bei komplett lokalen Teams am einfachsten. Jedoch sind lokale Teams sehr arbeitsspeicher- und rechenleistungsintensive Geschäftsobjekte. Je durchdachter und feiner die Struktur eines Teams ist, umso größer sind die an Systemressourcen gestellten Anforderungen wie:

Sehr große und komplexe Teamstrukturen, multipliziert mit den Tausenden von Produkten und Containern, die diese verwenden, können Systemressourcen stark beanspruchen. Komplexe Teamstrukturen können nicht nur teamspezifische Funktionen verlangsamen, in Extremfällen können sie Systemressourcen auch so stark beanspruchen, dass die Leistung des Gesamtsystems beeinträchtigt wird. Sorgfältige Planung ist daher wichtig, um eine optimale Teamstruktur zu entwerfen, die den Geschäftsanforderungen zugutekommt und keine Leistungsbeeinträchtigungen mit sich bringt.

Die primäre Motivation beim Entwurf von Teamstrukturen besteht darin, Geschäftsanforderungen rund um Berechtigungen für verschiedene Segmente der Benutzer-Community beim Zugriff auf Inhalte in Anwendungskontexten zu erfüllen. Verwenden Sie die folgenden Richtlinien in Ihrem Teamkonstruktionsprozess.

Berechtigungsanforderungen für Ihre Benutzer gehören im Allgemeinen zu zwei Kategorien: Zugriffsrechte auf Grundlage einer Benutzerrolle in einem Anwendungskontext oder Zugriffsrechte unabhängig von der Benutzerrolle in einem Kontext. Diese Unterscheidung hilft Ihnen dabei, festzulegen, ob der Zugriff kontextunabhängigen oder kontextspezifischen Teilnehmern gewährt werden soll.

Für Teilnehmer, die Zugriff auf Objekte benötigen, unabhängig davon, ob sie Mitglied des Anwendungskontexts der Objekte sind, erstellen Sie Zugriffssteuerungsregeln unter Verwendung der folgenden Teilnehmer: Benutzer, benutzerdefinierte Gruppen, Organisationen oder Pseudo-Rollen.

Nehmen wir beispielsweise an, dass alle Benutzer in einer Organisation Leseberechtigung für Spezifikationsdokumente mit dem Status "Freigegeben" in jedem öffentlichen Produkt innerhalb der Organisation benötigen. Diese Zugriffrechte erzwingen Sie über eine Richtlinien-Zugriffssteuerungsregel, die in der Domäne "/Default/PDM" der Organisation definiert ist und dem Organisationsteilnehmer Leseberechtigung für den Spezifikationsdokumenttyp mit Status "Freigegeben" gewährt.

Für Teilnehmer, die Zugriff auf Objekte in einem Anwendungskontext auf Basis ihrer Rolle in diesem Kontext benötigen, erstellen Sie Zugriffssteuerungsregeln unter Verwendung von Systemgruppen und dynamischen Rollen. Bei der Erstellung von Zugriffssteuerungsregeln für Rollen sollten Sie berücksichtigen, ob die Regel für eine dynamische Rolle gedacht ist, ob die betreffende Rolle in jedem Kontext dieselben Berechtigungen benötigt oder ob die Rolle für eine Systemgruppe erstellt werden muss, weil sie in jedem Anwendungskontext unterschiedliche Berechtigungen benötigt.

Nehmen wir beispielsweise an, dass Benutzer, die für die Konstruktion eines Produkts zuständig sind, die Berechtigung zum Erstellen und Ändern für spezifische Datentypen haben müssen. Dies gilt nur für Produkte, bei denen ihnen Konstruktionsarbeiten zugewiesen sind. Diese Berechtigungen erzwingen Sie über die dynamischen Rollen, die Konstrukteuren in gemeinsam benutzten oder lokalen Teams zugewiesen sind.

Verwenden Sie bei der Erstellung eines Anwendungskontexts ein gemeinsam benutztes Team, wenn die Teamrollen und die Teilnehmer in diesen Rollen in verschiedenen Kontexten identisch sind. Verwenden Sie ein lokales Team, wenn für unterschiedliche Anwendungskontexte auch unterschiedliche Teamrollen oder unterschiedliche Teilnehmer in den Rollen erforderlich sind. Unterscheiden sich die Anwendungskontexte nur geringfügig, sollten Sie ein gemeinsam benutztes, lokal erweitertes Team in Erwägung ziehen.

Eine Kombination von Optionen ist durchaus möglich. Es muss keine Option für alle Fälle angewendet werden. So können Sie beispielsweise gemeinsam benutzte Teams für Bibliothekskontexte verwenden, lokale Teams für bestimmte Kombinationen von Produkt- und Projektkontexten und gemeinsam benutzte Teams, die lokal erweitert sind, für andere Kombinationen von Produkt- und Projektkontexten.

Die folgenden Tabellen enthalten mehr Details zu den verschiedenen Techniken für das Verwalten von Berechtigungen für Teams und deren Auswirkungen auf die Leistung.

Es gibt einige Vorgehensweisen, die es beim Entwurf von Teams zu vermeiden gilt. Die folgende Tabelle zeigt einige Vorgehensweisen und ihre Mängel auf.

Nachstehend finden Sie einige nützliche Systemoptimierungstechniken in Verbindung mit Teams.