Wie sieht eine effiziente SharePoint-Architektur aus?
Viele Unternehmen oder einzelne große Abteilungen stehen vor der Aufgabe, die Daten alter Netzlaufwerke zu Microsoft Teams und SharePoint zu migrieren. Aber wie sieht eine effiziente SharePoint Architektur aus?
Grundsätzlich gibt es zwar in der „SharePoint Information Architecture“ meist weder falsch noch richtig, es gibt immer Ausnahmen und auch für jede extreme Option und Kombination geeignete Anwendungsfälle. Jedoch gibt es typische Fehler, die von Anfang an vermieden werden können, indem man sich die Konsequenzen eines bestimmten SharePoint Aufbaus bewusst macht.
Hierzu sollen in diesem Artikel die Vorteile einer „flachen“ SharePoint Architektur – mit mehreren kleinen SharePoint Sites – im Gegensatz zu einer einzelnen großen SharePoint Site beleuchtet werden.
1. Vereinfachter Überblick über zwei mögliche Handlungsoptionen
Nehmen wir als Beispiel eine große fiktive Abteilung A, mit mehreren Unterabteilungen, die sich auf SharePoint zu organisieren hat. Grundsätzlich gibt es für die Gestaltung eines solchen SharePoint „Abteilungs-Intranets“ zwei extreme Optionen: Entweder die ganze Abteilung wird auf einer großen SharePoint Website untergebracht, oder es werden mehrere kleine SharePoint Websites erstellt.
Typischerweise wollen die meisten Nutzer sofort – als scheinbar einfache Lösung – eine große SharePoint Website erstellen und existierende Ordner- und Denkstrukturen 1:1 übernehmen. Überstürzten Aktionismus gilt es hier jedoch zu vermeiden.
2. Argumente für einen SharePoint Aufbau mit mehreren kleinen SharePoint Sites statt einer großen Website
Microsoft selbst gibt als „Leitbild“ für die Nutzung von SharePoint eine „flache“ SharePoint Architektur vor: Man solle eine möglichst „flache“ Struktur aufbauen, d.h. für jedes einzelne Thema bzw. jede Aufgabe eine einzelne SharePoint Website erstellen.
Als Beispiel einer solchen Architektur haben wir unsere eigene unternehmensweite SharePoint Architektur vereinfacht abgebildet: Jedes “Thema” wie z.B. “Compliance” erhält eine eigene “unternehmens-öffentliche” SharePoint Kommunikationswebsite und ggf. noch ein eigenes Microsoft Team (mit automatischer erstellter SharePoint Teamwebsite…) für die Zusammenarbeit in einem kleineren Kreis. Jede SharePoint Website/ Microsoft Team hat unterschiedliche Nutzergruppen und Berechtigungen. Das mag auf den ersten Blick komplizierter erscheinen, ist aber langfristig die meist zweckmäßigere Lösung.
In folgendem Video ist zu sehen, wie diese Architektur wirklich aussieht: In der Regel bekommt der Endnutzer fast nichts davon mit, dass er in diesem Beispiel auf vier (!) verschiedenen SharePoint Websites unterwegs war. Mehrere SharePoint Websites bedeuten also nicht gleich mehr Unübersichtlichkeit!
Laut Microsoft sei durch eine flache SharePoint- Architektur das Verwalten von Rechten und die Zuständigkeiten deutlich klarer als bei „großen“ Websites geregelt. Außerdem habe man mit einer flachen Struktur eine höhere Flexibilität bei inhaltlichen Änderungen. Diese und weitere Gründe für mehrere kleine SharePoint- Sites sollen im Folgenden etwas genauer beleuchtet werden.
2.1. Einfacheres Rechtemanagement, Zuständigkeiten und Berechtigungsgruppen durch eine flache SharePoint-Architektur
– Rechte- und Zugriffsmanagement
Ein Großteil der Zugriffe und Rechte werden schnell, einfach und direkt über die SharePoint Standardrollen (Besitzer = volle Rechte, Mitglieder = Bearbeitungsrechte, Besucher (nur bei Kommunikationswebsites) = Leserechte) geregelt. Bei einer großen SharePoint Site für eine ganze Abteilung müssen zwangsweise granulare Rechte auf Seiten-/ Ordnerebene vergeben und vor allem verwaltet werden – selbst wenn man innerhalb einer Abteilung sehr transparent und offen arbeitet. Ggf. wäre es bei einer großen SharePoint Seite noch möglich, verschiedene „Dokumentenbibliotheken“ mit unterschiedlichen Zugriffsrechten einzurichten, um hier einen Kompromiss zu finden. Hierbei gilt es aber zu beachten, dass Website-Besitzer i.d.R. immer Zugriff auf alle Inhalte und Dateien haben. Allein das könnte ein Argument gegen eine große Website sein, da alle Besitzer auch Zugriff auf ggf. sensible Personal-, Budgetdokumente, etc. hätten. Der Zugriff lässt sich nur in den erweiterten Berechtigungen einschränken.
– Zuständigkeiten
Die Verwendung von mehreren kleinen SharePoint Seiten hat außerdem den Vorteil von klareren Zuständigkeiten bzgl. des SharePoint Website Managements. Mit den o.g. Standardrollen kann bei verschiedenen Websites viel einfacher der Bearbeitungs-/ Lesezugriff gesteuert werden.
– Berechtigungsgruppen (gilt nur für SharePoint Teamwebsites bzw. Microsoft Teams!)
Hinter jedem Microsoft Team liegt automatisch eine SharePoint Teamwebsite und eine sogenannte „Microsoft 365 Gruppe“. Die M365 Gruppe ist eine Berechtigungsgruppe, durch die der Zugriff auf fast alle Microsoft 365 Inhalte dynamisch und einfach gesteuert werden kann (andere SharePoint Sites und Seiten, Ordner, Dateien, Power BI, …). Bei vielen, kleineren SharePoint (Team-)websites ist so eine feinmaschige Kontrolle des Zugriffes möglich, die bei einer großen Berechtigungsgruppe nicht gegeben ist.
2.2 Flexibilität bei organisatorischen Veränderungen
Neben dem einfacheren und übersichtlicheren Management wird durch eine flache SharePoint Architektur die Flexibilität bei organisatorischen Veränderungen erhöht.
Wenn man bspw. bei einer existierenden „großen“ Website einzelne Unterabteilungen mit Dokumenten “ausgliedern” muss, dann müssten sämtliche betroffene Ordner/Dateien in eine neue Website migriert werden. Bei mehreren tausend Dateien ist dies ohne Migrationstool sehr aufwendig und fehleranfällig. Etwaige geteilte Links werden zudem häufig nicht mehr funktionieren. Mitglieder/ Rollen müssten zusätzlich entfernt und neu zugewiesen werden.
Bei separaten, kleineren SharePoint Websites dagegen wäre die “Migration” im Idealfall (!) mit wenigen Mausklicks getan: Die Navigation und/oder Hub-Zuordnung wechselt man mit wenigen Mausklicks.
2.3 Technische Einschränkungen
– Maximaler Speicherplatz pro SharePoint Website
Eine SharePoint Site bietet Speicherplatz von maximal 25 TB (25.000 GB). Diesbezüglich dürfte eine einzelne SharePoint Site über Jahre absolut ausreichend sein. Zur Veranschaulichung: 1TB sind 6,5 Millionen Dokumentseiten, die allgemein als Office-Dateien, PDF-Dateien und Präsentationen gespeichert werden. Probleme bekommen nur diejenigen, die alte Arbeitsweisen übernehmen und tausende zusätzliche Datei-Versionen, -Kopien, und -Duplikate anlegen. Viele Dateien auf mehreren SharePoint Websites aufzuteilen, kann dabei langfristig ein Vorteil sein.
– Dateienlimit pro Dokumentbibliothek
Relevanter ist aber vermutlich die Einschränkung von 5.000 Dateien pro „Dokumentbibliothek“. Theoretisch kann man auch deutlich mehr Dateien in einer Dokumentbibliothek speichern, allerdings führt dies zu Einschränkungen beim Suchen, Filtern und bei verschiedenen Ansichten, die man beachten und lösen muss. Größere Dokumentenbibliotheken führen zudem zwangsläufig zu einer geringeren Performance.
Zwar könnte man diese mit einiger Arbeit auch auf einer großen SharePoint Site durch mehrere „Dokumentenbibliotheken“ lösen. Trotzdem lautet die Empfehlung, Dateien auch auf möglichst viele „Sites“ zu verteilen, um weiterführende Probleme von Anfang an zu vermeiden.
– Maximale URL & Dateipfad-Explorer Länge
Die maximale URL-Länge beträgt 400 Zeichen und richtet sich nach folgender Formel: URL = Protokoll + Servername + Ordner- oder Dateipfad + Ordner- oder Dateiname + Parameter
Hier eine Beispiel- URL: http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Promotion/Some%20File.xlsx
Sie enthält 94 von 400 möglichen Zeichen. Dieses Beispiel spiegelt aber fast den Best Case wider: Bei großen, verschachtelten und komplexen Ordnerhierarchien und langen Dateinamen wird man unweigerlich Probleme bekommen.
Neben der URL-Länge stellt sich zudem das Problem der Windows-Dateiexplorer-Pfadlänge von max. 260 Zeichen, die relevant ist, wenn man z.B. die Dokumentenbibliothek via OneDrive Synchronisierung in seine gewohnte Windows-Dateiexplorer Struktur einbinden möchte.
Hier ein Beispielpfad:
C:\Users\marcus.machon\OneDrive – Tiba Managementberatung GmbH\Power BI Desktop\0 Power BI Desktop\Showcases & Samples\Project_for_the_Web_Accelerator_report_v1.1.pbit
Dies sind schon 167 von 260 möglichen Zeichen.
Auch hieraus ergibt sich die Empfehlung, mehrere Seiten mit separaten, kleinen Dokumentbibliotheken in der „Breite“, statt in die „Tiefe“ aufzubauen.
2.4 SharePoint ist kein reiner Cloud Speicherort!
SharePoint ist kein 1:1 Ersatz für Netz-/Gruppenlaufwerke. SharePoint ist auch nicht vergleichbar mit „Dropbox“ und Co. Wenn man so denkt, dann holt man sich früher oder später viele vermeidbare Probleme und Risiken ins Haus. Hierzu zwei Beispiele:
– Risiko der Löschung aller Dateien
Nutzt man eine SharePoint-Site für sämtliche Dateien und die Mitarbeiter:innen arbeiten wie früher ausschließlich via der OneDrive Date-Explorer Synchronisation, dann ist das Risiko erheblich größer, dass irgendwann, irgendjemand alle Ordner und Dateien aus Versehen löscht: Der-/diejenige wollte beispielsweise einfach den Ordner von seinem PC entfernen, wusste aber nicht, dass bei aktiver Synchronisation alle Dateien auch in SharePoint gelöscht werden. Grundsätzlich lassen sich die Dateien zwar aus dem Papierkorb wiederherstellen (falls dies früh genug auffällt). Und natürlich kann dies auch bei vielen kleinen SharePoint Seiten passieren. Allerdings ist der – potenziell dauerhafte -Dateiverlust bei nur einer großen SharePoint Seite deutlich größer.
– Unübersichtlichkeit und „vergrabene“ Inhalte
Wenn man wenige, große SharePoint Seiten einrichtet, müssen zwangsweise viele Inhalte auf dieser Seite „vergraben“ werden. Dokumente werden häufig in tiefen verschachtelten Ordnerhierarchien oder auf mehrere Dokumentbibliotheken verteilt. Dies beeinträchtigt bei „alten Denk- und Arbeitsweisen“ meist die Navigation und Suche, sodass dies schlussendlich die Akzeptanz und Zufriedenheit der Nutzer beinträchtigen kann.
SharePoint ist mehr als „Speicherort“. Natürlich kann man Dateien in SharePoint speichern und verwalten. Das ist aber nur eine von zahlreichen weiteren Funktionen: Mit SharePoint kann jeder selbst mittels Baukastensystems innerhalb weniger Minuten eigene Intranet-/Wiki-/Community-Seiten erstellen. Mit sogenannten Webparts bindet man kinderleicht Power BI Reports, Yammer Communities, Dateien, Videos, Countdown-Timer, uvm. ein. Mit SharePoint kann man auch News Beiträge erstellen und mittels „Roll-up“ automatisch auf anderen SharePoint Sites anzeigen lassen. Oder man erstellt mit wenigen Mausklicks komplette Newsletter aus den Beiträgen. Allein wenn man SharePoint Nachrichten effizient nutzen will, machen „separate“ SharePoint Websites Sinn, da dort immer die „Quelle“/ die entsprechende SharePoint Website angezeigt wird. Natürlich auch mit automatischer Berücksichtigung der Berechtigungen, solange man sich an den Standard hält: Nutzer:innen sehen nur die Nachrichten, für die sie berechtigt sind.
Ist ein Verständnis für die verschiedenartige Anwendbarkeit von SharePoint vorhanden, wird man nicht so schnell in die Falle tappen, SharePoint als große „Dropbox“ falsch zu verwenden.
Wir unterstützen und beraten Sie gerne beim Aufbau Ihrer persönlichen SharePoint-Websites. Darüber hinaus bietet die Tiba noch andere mehrwertstiftende Lösungen und Automatisierungen rund um Microsoft 365 an. Informieren Sie sich hier.
Autor: Marcus Machon, Leiter CoC Digitalisierung der Tiba Managementberatung
Quellen:
https://learn.microsoft.com/de-de/sharepoint/information-architecture-modern-experience
https://experience.dropbox.com/de-de/resources/how-much-is-1tb
https:// sharepointmaven.com
Architecting Your Intranet – YouTube
powered by Borlabs Cookie