SharePoint Hub Sites - die Neudefinition des Intranet? Eine Betrachtung aus der Beraterpraxis
Im Zuge der Neuausrichtung von SharePoint hat Microsoft mit den Hub Sites und den Communication Sites eine ganz neue Publikations-Infrastruktur eingeführt. Damit drängen sich einige spannende Fragen auf: Wie war bisher ein SharePoint-Intranet definiert, wo lagen die größten Probleme, was erwarten eigentlich die Anwenderunternehmen, und wie gut erfüllt die neue Architektur die Versprechen?
Klassisches Intranet ist in den letzten Jahren diverse Male totgesagt worden, wurde dann doch immer wieder mal ausgegraben und mit verschiedensten Ansätzen, Plattformen und Tools wiederbelebt. Ich selber habe diverse Intranets in dieser Zeit konzeptioniert oder umgesetzt. Was ein Intranet nun ganz genau ist, kann ich allerdings so richtig immer noch nicht sagen.
Was ist eigentlich ein Intranet? Von „Public Folder“ bis „Agentur-Kapriolen“
Da hat jeder so seine Vorstellung, was zu einem Intranet gehört, wie so etwas auszusehen hat und welche Informationen und Funktionen „ja wohl Industriestandard“ sind. Es geht sicherlich um Publishing bzw. Bereitstellung von Informationen. News sind fast immer dabei. Und Dokumente. Und Wikis. Und Kommunikation in Foren und Kommentaren. Oder ist das schon wieder etwas anderes?
So bunt sich Entwürfe von verschiedenen Unternehmen unterscheiden, spiegeln sie doch immer ein wenig die Unternehmenskultur und die Denke der mit dem Projekt beauftragten Mitarbeiter wieder. So gibt es von „Unser Intranet sind die Public Folders in Exchange 2007, wozu brauchen wir mehr? Könnten Sie bitte nur dafür sorgen, dass die hunderttausend Folder mit den paar Terabyte wieder performant reagieren?“ bis zu „Die Agentur hat aber dieses blaue Minisymbol hier in einen ausklappbaren Slider definiert, der zu sehen ist, wenn man in etwa in der Nähe eine Mausgeste macht. Sie machen das natürlich responsive und für Touch, ja?“.
Beides sind Extrempositionen, aber beides haben wir auch schon genau so erlebt. Vielfach werden Anforderungen an SharePoint-Intranets von Anwendern aus deren „Common Sense“ zusammenkopiert oder von Agenturen entworfen, für die SharePoint irgendwie so was ähnliches wie WordPress ist. Den Satz „SharePoint kennen und können wir“ aus dieser Richtung goutiere ich seit Jahren mit einer Art prophetischer Voraussicht und werde selten enttäuscht.
SharePoint – mit JavaScript und Hacks verbogen
Und so wird dann oftmals etwas vom Dienstleister mit JavaScript in Seiten reingedrückt, was partout nicht passen will, weil SharePoint nun mal nicht so funktioniert. Projekte, bei denen Pixelschubsen auf dem letzten Meter sich zu monatelangem Verzug hochschaukelt oder bei denen im Rahmen der Programmierung klar wird, dass man um bestimmte Versatzstücke einfach nicht herumkommt und mit hässlichen Hacks die „Websiteinhalte“ verschwinden lässt oder Social Features „wegzaubert“.
Richtig glücklich ist am Ende da meist niemand mit, denn die Erwartungskonformität des Kunden liegt eher schräg auf dem Ergebnis und Architekt und Techniker brauchen ab sofort vor lauter Haareraufen signifikant weniger Shampoo. Kurzum: Freude an Technik geht für alle Beteiligten anders. Denn wo vielleicht auf der einen Seite ein Designansatz gewählt wird und auf der anderen Seite ein methodischer Ansatz steht und der dritte im Bunde dann mit Standards und Technik um die Ecke kommt, entsteht häufig ein ordentliches Konfliktpotential über die Deutungshoheit dessen, was da eigentlich entstehen soll.
Mit dem spröden Charme alter Websites
SharePoint hat das einem aber auch nicht einfach gemacht: Schön geht traditionell anders. SharePoint-Seiten versprühten oft im Standard den spröden Charme von Webseiten, die vor fünf Jahren schon eher so mittelmäßig aussahen. Dazu kommt noch der Überbau an technischen Konzepten, an denen sich schon Generationen von Fach- und Endanwendern die Zähne ausgebissen haben. Kein Wunder also, warum der Gedanke des klassischen designten Publishingportals mit einheitlicher Navigation und den implementierten Versuchen, das auf SharePoint-Basis zu machen, so häufig knatscht.
Die SharePoint Hub Sites – Microsofts neue Publishing-Story
Nun aber genug der anekdotischen Redundanz, schließlich ist uns heuer ein neuer alter Heiland geboren worden. Nach Jahren der gefühlten grauen Maus unter all den neuen, schönen Features von Teams, Planner und wie sie alle heißen mögen, bringen einige neue Features ein ganz neues Potential in Microsofts Publishing-Story. Der Grundstein dafür wurde mit den Modern Sites gelegt, die erst jetzt so langsam rund werden. Die neuen Features, die tröpfchenweise in den letzten Jahren immer mal wieder dazukamen und anfangs schmerzlich in der rudimentären Ausstattung des Featuresets vermisst wurden, fangen nach und nach an, ineinanderzugreifen.
So ist das Aufbauen einer Communication Site mittlerweile ein Kinderspiel. Und hält man sich an das, was diese Site sein möchte und versucht nicht, daraus mit Raketenforschung sonstwas draus zu stricken, funktioniert der Anwendungsfall tadellos. Die Arbeitsschritte zum Publizieren einer neuen Nachricht oder eines Artikels wirken rund, die Oberflächen muten fast schon modern an und die neuen SharePoint-Framework(-SPfx)-WebParts fühlen sich einfach gut an.
Übergreifende Navigation – bisher verzweifelt gesucht
Und nun kommt also die Hub Site, die wie am Ende einer guten Erzählung die um sich herum mäandernden Erzählstränge endlich im vorletzten Kapitel zusammenbringt und eine Klammer um die Erzählung tackert. Seit man den Anwendern sagte, dass es keine gute Idee ist, all seine Inhalte in eine Websitesammlung (Sitecollection) mit hunderten Subsites zu werfen, wird nämlich so etwas wie eine übergreifende Navigation verzweifelt gesucht.
Auch hier bissen sich die vorhandenen Mechanismen (Managed Navigation) deutlich mit dem, was diese Anwender erwarteten. Da hilft alle gute technische Begründung nichts und der JavaScript-Entwickler wimmert leise. Ich prophezeie einmal tollkühn: Mit Hub Sites bewegen sich beide Seiten, wenn sie sich von dem Gedanken lösen können, dass ein Intranet heutzutage so wie vor fünfzehn Jahren aufgebaut werden muss. Vorausgesetzt also, der eine hört zu und versteht, und der andere erklärt es vernünftig.
Hubs als „Mini-Themenintranet“
Dadurch, dass Hubs definiert werden, können organisatorische Ebenen, verschiedene fachliche Themen, Kampagnen oder Art von Kommunikation in den Mittelpunkt der Publizierung gestellt werden. Diesen Hubs können vollkommen dynamisch von definierten Gruppen weitere Seiten flexibel eingehängt werden. So wachsen sie organisch oder verfallen vielleicht auch wieder in eine Starre, wenn sich beispielsweise ein Thema erledigt hat und keine neuen Inhalte auf den angeschlossenen Sites mehr generiert wird.
Hubs sammeln ähnliche Informationen und stellen sie zusammenhängend als eine Art Mini-Themenintranet dar. Dabei verlieren die dem Hub angeschlossenen Sites aber nie ihren eigenen Fokus. Jede angehängte Site bleibt weiter ihrem eigentlichen Zweck verbunden ohne Kompromisse für die Aggregation einzugehen und ohne das Rechte- und Rollenkonzept zu verändern.
Die weiteren Funktionen von Hub-Site wären noch:
- Aggregation von Neuigkeiten
- Gemeinsame Navigation über alle angeschlossenen Sites hinweg
- Suchvorschläge und Ergebnisse in dem Kosmos der Hub Site
- Weitergabe des Hub Site Brandings an die dazugehörigen Sites
Das Einrichten dauert keine fünf Minuten, das Anschließen erledigt sich bei der Einrichtung von angeschlossenen Sites quasi mit.
Die einzelnen Sites können nun natürlich wie gehabt mit den gängigen Mechanismen aus den Groups und damit auch den Teams kombiniert werden. So kann man Arbeitsräume mit definierten Lebenszyklen für Dokumente und Informationen schaffen und damit auch die Publizierung direkt dort vollenden, wo das Zusammenarbeiten stattfindet. Konnte man vorher natürlich auch schon, allerdings ist die Information jetzt allen Mechanismen der Hub Site unterworfen und reiht sich in das vordefinierte Publizieren ein.
Suche macht das Streben nach perfekter Navigation überflüssig
Nimmt man einmal an, dass es in Intranets aufgrund des Wachstums von Informationen sowieso ein Ding der Unmöglichkeit ist, die alles umfassende Navigation des Unternehmenswissens zu schaffen, schmiegt sich der Gedanke der Hub Sites wohlig an das Pflichtenheft. Die Suche wird immer mehr von Endanwendern akzeptiert, auch wenn es scheinbar nach wie vor ein Unterschied wie Himmel und Hölle ist, ob man zu Hause im Internet nach dem günstigsten Handytarif surft oder ob man auf der Arbeit nach einem wichtigen Dokument sucht. Gute Voraussetzungen also, einen Hybriden zwischen diesen beiden grundlegenden Welten zu etablieren und sich somit quasi in der Mitte zu treffen.
Die Navigation wird auf den Themenkomplex oder das verbindende Momentum der Sites heruntergebrochen; man könnte auch sagen, dass sie thematisch und damit nachvollziehbar wird. Weniger poetisch gesehen fällt schlicht und ergreifend die oberste Navigationsebene weg, da sie durch die Hub Sites ersetzt wird. Vorteil hierbei ist, dass dies nicht in ein Raster gesteckt werden muss, sondern sich organisch dem Bedarf anpassen kann. Statt 30 Oberpunkte auf der ersten Ebene einer globalen Navigation hat man also einfach 30 Hub Sites, die sich nach Belieben ihren Schwerpunkten widmen dürfen.
Noch kann nicht jeder Hub Sites erstellen
Wachstum ist also kein Problem. Die Erstellung von Hub Sites ist aktuell noch an ein bisschen PowerShell gekoppelt, welches aber so simpel wie möglich gehalten ist. Das bedeutet im Umkehrschluss allerdings, dass man mit den entsprechenden Rechten ausgestattet sein muss, um überhaupt eine Hub Site entstehen lassen zu können. Letztlich hat man damit auch aus Governance-Sicht eine Gewissheit, Kontrolle über die entstehenden Hub Sites zu haben. Man definiert also die Planeten, um die dann die Satelliten darum kreisen lassen zu können.
Für jede Hub Site wird eine Menge von Gruppen oder Einzelpersonen als Principals angegeben, die in der Lage sind, den Hub verwalten zu können. Auch damit ist es möglich, den jeweiligen Themenverantwortlichen das Heft in die Hand zu geben und eigenverantwortlich zu gestalten.
Das Intranet ist zurück. Als bessere Form der Informationsverteilung
Zurück zu meiner Prophezeiung: Die Welt hat sich weitergedreht und selbst in konservativen Häusern ist aufgrund wachsender Datenmenge und dem Druck, kostbares Wissen nicht in den Schubladen versauern zu lassen, die Einsicht gekommen, dass Dateisysteme nicht das Ende der Fahnenstange sind. Und auch, dass das Intranet aus den frühen 2000ern konzeptionell überholt erscheint und viel Potential für die Arbeit der Mitarbeiter liegen lässt. Hub Sites bieten einen sanften Übergang als Boje für thematische Fachnetze, sodass nicht alles unstrukturiert im SharePoint vor sich hin liegen muss.
Die Hub Sites können damit eine Lücke besetzen, die seit einigen Jahren im Office 365 Universum irgendwie nie so richtig besetzt schien. Folgt man den typischen Lebenszyklus-Modellen von Informationen, kommt man zwangsläufig irgendwann an den Punkt, an dem eine Information an eine lesende Zielgruppe gegeben wird. Diese Bereitstellung mit einer entsprechenden Aufbereitung können die Hub Sites unterstützen, zusammen mit den Modern Sites und den altbekannten SharePoint-Mechanismen. Bringt man das mit Flow und Azure Information Protection zusammen, schließt sich der Kreis, was eigentlich mit meinem Dokument passiert, wenn das Projekt beendet, die Messe gelesen und der Lebenszyklus in die eher gemütliche Phase eingebogen ist.
Das Potential ist jedenfalls immens, diese Story zu Ende zu erzählen. Ich bin gespannt, ob und wie sich der Gedanke in den Organisationen da draußen durchsetzen wird.
(Der Originalbeitrag ist auf Spmoshpit.de erschienen.)
Im echten Leben ist er in Bremen Enterprise Architect und Head of Development bei der deroso Solutions GmbH. Schwerpunkte seiner Arbeit sind sowohl Office 365 und Azure als auch seit 2005 alle on-premise-Iterationen des SharePoint Servers. Er ist weiterhin mehrfach MCSE, MSCA, MCPD und MCTS.