Microsoft Sharepoint und warum die Portalwelt doch nicht so einfach ist

von Peter Soth

Vor geraumer Zeit plante ich, einen etwas kritischen Blog Post zum Thema Sharepoint zu verfassen. Dann verwarf ich diese Idee zunächst wieder, da ich mir dachte, dass es aktuell sowieso keinen Sinn macht diesen zu schreiben. Grund hierfür war, dass ich allerorts auf meine Frage »Was machen sie eigentlich im Intranet« reflexartig die Antwort »Sharepoint« erhielt.

Ende Januar stellten wir auf der i+e Messe in Freiburg aus. Dort präsentierten wir unter anderem unsere individuellen Lösungen zu den Themen Enterprise 2.0 Portale und Wissensdatenbanken. Auf meine Frage, ob nicht schon Sharepoint im Einsatz ist, hörte ich nun oft den Satz »ja haben wir, aber Sharepoint funktioniert nicht so richtig«. Um es vorwegzunehmen, ich möchte in diesem Blog-Post den Sinn dafür schärfen, dass Sharepoint  ein komplexes Unterfangen sein kann und es leider nicht so einfach ist, wie es viele meinen.

 

Warum liebt die IT Abteilung Sharepoint aber nicht die Endbenutzer?

Ein Portalprojekt gehört mit zu den diffizilsten überhaupt. Der Vorteil von Portalen ist, dass sie dem Benutzer einen personalisierten Zugriff auf Informationen aus unterschiedlichsten Drittsystemen auf einen Blick ermöglichen. Vergleichbar mit dem Cockpit in einem Flugzeug. Die Schwierigkeit liegt hierbei darin, diese zahlreichen Systeme (wie CMS, DMS, SAP etc.) zu integrieren und für die Personalisierung ein passendes Rollenkonzept zu entwerfen. Einen wertvollen Überblick gibt hier mein Blog-Post mit dem Titel »Projektphasenmodell für Portal-Projekte« [1]. Sharepoint möchte dieses Problem dadurch lösen, dass es zum einen alle Drittsysteme (CMS, DMS) ersetzt (was es auch theoretisch kann) und dass es nicht modifiziert wird [2]. Hier ein Auszug aus dem Microsoft Sharepoint Blog [3]:

»Use SharePoint as an out-of-box application whenever possible - We designed the new SharePoint UI to be clean, simple and fast and work great out-of-box. We encourage you not to modify it which could add complexity, performance and upgradeability and to focus your energy on working with users and groups to understand how to use SharePoint to improve productivity and collaboration and identifying and promoting best practices in your organization.«

Diese Aussage mag die IT-Abteilung erfreuen, das Problem ist jedoch, dass jedes Unternehmen über unterschiedliche Prozesse verfügt, die abgebildet werden sollen. Einen interessanten Artikel hierzu gibt es von der Nielsen Norman Group [4], in dem empfohlen wird, Sharepoint auf jeden Fall anzupassen. Hier eine Textstelle:

»Examining more detailed aspects of intranet design reveals further differences. For example, most intranets have an employee directory , but the criteria used to find employees differ dramatically. Knowledge-intensive organizations  often emphasize the ability to find colleagues by their expertise, whereas other types of organizations might deem other attributes more important. Similarly, the information displayed on individual employee profile pages is not just industry-dependent , but also varies dramatically depending on company culture.«

Ersetzen von Drittsystemen durch Sharepoint

Ein genereller Wunsch von IT-Abteilung ist es, die Anzahl von Systemen zu reduzieren. Die Idee hierbei ist Kosten einzusparen. Warum soll zusätzliche Software gekauft werden, wenn Sharepoint das auch alles kann?  Dies mag von Fall zu Fall durchaus Sinn machen. Jedoch sollte bedacht werden, dass sich die Altsysteme seit Jahren - mit bestens eingespielten Prozessen - im Einsatz befinden. Zum Beispiel wird in der Pharmabranche gerne Documentum als DMS benutzt, um die restriktiven gesetzlichen Vorgaben bzgl. der Dokumentenaufbewahrung (Records Retention) abzubilden. Hierfür gibt es ebenso Lösungen von Microsoft Partnern. Nichtsdestotrotz darf hier der Aufwand einer Migration nicht unterschätzt werden. Ein zusätzlicher Punkt - sofern nur ein System für alles zur Verfügung steht - der bereitwillig verdrängt wird, ist die Frage der Security. Wie man weiß, sind Monokulturen empfänglich für einen Schädlingsbefall. Die Hacker wird es freuen, wenn sie sich nur noch mit einer Anwendung auskennen müssen. Des Weiteren fällt das gesamte Intranet, bei einem Problem mit Sharepoint, aus. Beispielsweise bei einem Fehler verursacht durch einen fehlerhaft eingespielten Patch.

Browser Unterstützung von Sharepoint

Die bisherige Dominanz von Windows auf dem Desktop schwindet immer mehr aufgrund der Tatsache, dass Benutzer mobile Endgeräte wie iPhone oder iPad einsetzen wollen. Sharepoint unterstützt nur den Internet-Explorer [5][6] in vollem Umfang. Dies liegt vor allem daran, dass für verschiedene Funktionalitäten ActiveX Controls benutzt werden. Eine Technologie, die seit Jahren aus Sicherheitsgründen nicht so gerne gesehen wird und zudem nicht auf einem iPad funktioniert. Hierfür gibt es Lösungen, dies bedingt jedoch eine Erweiterung der Standardinstallation.

Sicherheitsaspekte

Sharepoint ist per se nicht unsicher, allerdings ist - hervorgerufen durch seine Komplexität - eine falsche Konfiguration leicht möglich. Selbige stellt vor allem im Internet ein Problem dar. Hier gibt es einen interessanten Foliensatz [7], der aufzeigt, dass man mit schlichten wget Kommandos in der Lage ist, aus einem ungesicherten Sharepoint-Server Dokumente zu ziehen. Ein weiteres Sicherheitsproblem liegt zudem darin, dass Sharepoint damit beworben wird, dass die Fachabteilung auch vieles ohne die IT bewerkstelligen kann. Beispielsweise können Websites einfach bereitgestellt werden. Hierdurch entstehen jedoch ausufernde Strukturen, die sich nur schwer verfolgen und kontrollieren lassen. Dies stellt meines Erachtens ein ernsthaftes Problem dar. Unter folgendem Link [8] findet sich ein interessanter Foliensatz mit weiteren Informationen zu diesem Thema, inklusive einer Lösung der Firma CA.

Skalierbarkeit von Sharepoint und der Bedarf an Hardware

Microsoft Produkte sind allgemein als ressourcenhungrig bekannt. Mein neues Notebook besitzt aktuell 8GByte RAM und hiervon benötigt Windows 7 bereits 3 GByte nach dem Start. Dies ist auch einer der Gründe, warum wir beispielsweise unter Linux entwickeln. Ein Problem hierbei ist, dass Sharepoint im tiefsten Kern immer noch COM Objekte benutzt und das Memory Management von COM-Objekten ist bekanntermaßen nicht das Beste. Aus eigener Erfahrung kann ich das bestätigen, als ich vor einigen Jahren als Softwareentwickler für HP arbeitete, kämpften wir bei COM/DCOM nicht nur mit Speicherproblemen. Auf dieser Seite von HP [9] findet sich eine umfangreiche Sizing- bzw. Konfigurationsanleitung. Ehrlich gesagt schockierte mich, wie viel Hardware Sharepoint dann doch erfordert. Für eine Konfiguration von maximal 200 Benutzern wird für WFE + Suche 16 GByte und für den SQL-Server 20 GByte Memory benötigt. Die Angaben von Microsoft können hier [10] eingesehen werden. Für eine Entwicklungs- bzw. Evaluationsumgebung werden laut Microsoft minimal 8GByte benötigt. Will man jedoch diesem Blog-Post [11] glauben, so sind mindestens 32 GByte auf einem Entwicklungsrechner nötig. Unsere Lösungen benötigen bei weitem weniger.

Lizenzkosten von Sharepoint

Unter folgendem Link [12] findet sich ein Preisrechner. Es ist jedoch anzumerken, dass dieser aus dem Jahr 2010 stammt. Gibt man in diesen 200 User (wie für die obige Hardwareauswahl benutzt) ein, so kommt man auf Kosten von 61.434 Dollar (siehe Bild rechts). Ich habe den Fast Server mit in die Rechnung aufgenommen, da auch unsere Lösungen über eine vergleichbare Suchlösung verfügen. Auf diesen Preis wird noch die Software Assurance (25-40%) hinzugerechnet, sofern man Updates auf neuere Versionen in Betracht zieht. Diese Zahlen geben jedoch nur eine erste grobe Orientierung und können sich von Kunde zu Kunde enorm unterscheiden.

Betriebskosten

Ein weiterer zentraler Punkt bei der Betrachtung von Sharepoint stellen die Betriebskosten dar. Laut einem Bericht im Windows Developer Magazin [13] unterschätzen Unternehmen den Daten- und Personalbedarf von Sharepoint. Der Datenbedarf steigt vor allem deshalb so massiv an, da sich in Unternehmen viele Sharepoint-Inseln entwickeln und Daten demzufolge redundant abgelegt werden. Dieses Problem ist seit Langem von Excel bekannt. Freut sich der Fachbereich zunächst, dass er ohne IT starten kann, entstehen später jede Menge Informations-Silos. Aus diesem Grund ist eine IT-Governance bei Sharepoint lebensnotwendig. Der Personalbedarf ist laut Bericht vor allem deshalb gestiegen, da sich beim laufenden Betrieb herausstellt, dass Microsoft Sharepoint doch nicht so einfach ist, wie ursprünglich angenommen.

Fazit

Die Gespräche, die ich auf der Messe führen konnte, zeigten mir, dass dieses Thema wieder etwas kritischer betrachtet wird. Für unsere Enterprise 2.0 bzw. Wissensdatenbanklösungen wird es auch weiterhin einen Markt geben. Mit diesem Blog-Post wollte ich aufzeigen, dass Sharepoint ein hochkomplexes System ist. Über eine Standardinstallation lässt sich die Komplexität reduzieren, jedoch mit dem großen Nachteil, dass die Endbenutzer meistens mit solch einem System nicht zufrieden gestellt werden können. Portalprojekte besitzen nun einmal eine hohe Komplexität. Es gibt bei Sharepoint für alles eine Lösung, falls nicht direkt von Microsoft, dann von einem Partner. Hierbei sollte man nicht vergessen, dass für einen Dollar, den Microsoft verdient, die Partner noch weitere 8 Dollar mitverdienen [14]. Konzerne leben hiermit wohl besser als Mittelständler. Folglich ist es wichtig, dass bei einem etwaigen Einsatz von Sharepoint auch Alternativen beleuchtet werden, wobei dies ggf. kein triviales Unterfangen ist, wenn neben Microsoft obendrein alle Partner so gut daran verdienen.

Update 30.10.2013

Es ist natürlich wunderbar, wenn die eigene Meinung durch Dritte belegt wird. So hat Jeffrey Mann (Vice President Research Gartner) auf der jährlichen Gartner ITxpo, die in Orlando Florida stattfindet eine Präsentation mit dem Titel »Should Microsoft Kill SharePoint« gehalten. Die Frage wurde selbstverständlich mit »Nein« beantwortet. Interessant ist das Ganze trotzdem, sofern man ein wenig zwischen den Zeilen liest.
So wird darauf hingewiesen, dass Microsft Sharepoint zu groß und komplex ist. Aus diesem Grund möchte Microsoft Sharepoint gerne mehr in die Cloud verlagern. Jedoch sind viele Kunden nicht bereit, in die Cloud zu folgen. Demzufolge gilt es zu hinterfragen, ob Microsoft zwei Versionen (mit und ohne Cloud) unterstützen wird. Die Zeit wird zeigen, wie sich Microsoft in diesem Punkt verhalten wird. Lauf Jeffry Mann [15] haben Firmen hier auf jeden Fall noch eine Frist bis 2018. Zu diesem Zeitpunkt läuft der Main-Stream-Support von Sharepoint 2013 aus. Jeffry Mann empfiehlt Firmen, sich schon jetzt Gedanken zu machen, was es bedeutet, wenn Microsoft nur noch eine Sharepoint Version in der Cloud bereitstellen würde.
»Q: What should organizations with complex, on-premises SharePoint installations do?
Jeffrey: The implications I’ve mentioned will unfold slowly over several years — there is no need to take panicky, immediate action. SharePoint Server 2013 will be a viable platform for doing what it does now, at least until 2018 (when mainstream support ends). However, it is not too early to start planning for a post-SharePoint world.« 
Weitere Links zu diesem Thema: [16] [17] [18][19]

Update 29.01.2014

Personalisierung der Navigation

In der Sharepoint-Welt spricht man typischerweise nicht von einer Personalisierung, sondern lediglich von Rechten, z. B. auf der Basis von AD-Gruppen.
Mit dem Sharepoint-Standard lassen sich allerdings schon einfache Fälle der Benutzer-basierten Personalisierung nicht lösen wie dieses Beispiel zeigt:
Ein Benutzer interessiert sich für die Firmenstandorte Stuttgart, Karlsruhe und München. Abhängig davon sollen ihm neue Menüpunkte in der Navigation angezeigt werden. In Sharepoint bräuchte man hierfür - um im Sharepoint Standard-Repertoire zu bleiben - bereits vordefinierte AD-Gruppen für jede mögliche Kombination (S, S-KA, S-KA-M, KA, ...). Es ist sofort ersichtlich, dass dies keine geeigneter Lösungsweg ist.
Bedenklich sind zudem weit verbreitete Vorschläge, die Navigation in SharePoint 2013 per Javascript anzupassen... [20] [21]

 

Maximieren/Minimieren von WebParts (Portlets)

Ein in Portalen gängiger Weg um an mehr Informationen zu gelangen, ist den Inhalt eines Portlets zu maximieren. In Framework-Portalen [22] besteht die Möglichkeit, diese Events abzufangen und entsprechend darauf zu reagieren oder aktiv das Portlet zu maximieren. In Portlets, die beispielsweise Inhalt aus Content Management Systemen darstellen, bietet sich ein Maximieren an, um weiterführende Links im gesamten Body-Bereich zu öffnen.
Sharepoint bietet diese Möglichkeiten nicht. Soll dem Benutzer dieses erprobte Usability-Konzept dennoch angeboten werden, muss dies selbst entwickelt werden.

Kategorien: ClaretportalIT-ConsultingPortaleSharepoint

Zurück