Ratgeber: SharePoint mit Bordmitteln erweitern, Drittanbieter-Tools kaufen oder Programmieren – Vor- & Nachteile

Wenn Sie in SharePoint neue Funktionen benötigen oder wenn Sie bestehende angepasst oder erweitert haben wollen, stehen Sie regelmäßig vor der Grundsatzfrage: Erreicht man das Ziel über eine einfache Anpassung des bestehenden SharePoint, sollte dafür ein Drittanbieter-Tool beschafft werden, oder wäre eine individuelle App-Entwicklung die bessere Lösung? Im folgenden Beitrag erörtern wir die Vor- und Nachteile des jeweiligen Ansatzes und geben Empfehlungen, was bei der Wahl von Drittanbieter-Tools oder Individualentwicklung zu beachten ist.

Zunächst einmal starten wir aber mit einer Aufstellung aller potenziellen Probleme, wenn es um die Erweiterung von SharePoint geht:

Mögliche Probleme und Risiken beim Einsatz von SharePoint-Tools und Individualentwicklungen:

1. Backup muss funktionieren: Fast jedes Unternehmen setzt eine Backup-Lösung für SharePoint ein. Vorab sollte geprüft werden, ob der Backup-Mechanismus auch mit der neuen Erweiterung funktioniert, vor allem, wohin die Daten gespeichert werden. Gemäß dem Spruch „Backup kann jeder, Restore nur wenige“ sollte vor allem der Restor-Fall geklärt werden – also, ob die Daten tatsächlich so zurückgespielt, dass das neue Tool damit klarkommt.
2. Sicher auch bei Migration: Was passiert, wenn auf eine neue SharePoint-Version migriert wird? Oder von der SharePoint Foundation auf Server oder Server-Enterprise? Für derartige Fälle muss ein Tool gerüstet sein, um beispielsweise zu verhindern, dass dauerhaft ein Enterprise-Server am Laufen gehalten werden muss.
3. Bereit für die Cloud: Das Thema Cloud betrifft zunehmend auch Anwender, die vorerst keinen Einsatz planen. Denn Microsoft fokussiert inzwischen klar die Cloud-Entwicklung, so dass immer mehr Funktionen am Server direkt oder indirekt davon betroffen sind. Je besser also eine neue Lösung die Cloud-Funktionen unterstützt, desto zukunftssicherer ist sie.
4. Zukunft durch Weiterentwicklung: Eine wichtige Frage ist auch die wirtschaftliche Solidität des Anbieters. Vor allem geht es darum, ob sich jemand um die Weiterentwicklung kümmert und ob ausführliche Dokumentationen existieren. In jedem Fall sollte vermieden werden, dass Tools eingesetzt werden, die nicht mehr weiterentwickelt und betreut werden (können).
5. Mobile Endgeräte: Immer wichtiger wird die Flexibilität für Endgeräte aller Art. Eine SharePoint-Lösung sollte auf einem 24-Zoll-Monitor ebenso laufen wie auf einem Smartphone. Hierbei ist auch zu beachten, dass Microsoft in SharePoint 2016 einige neue Mobile-Erweiterungen eingebaut hat. Drittanbieter-Tools, die das ignorieren oder überschreiben, könnten zukünftig Probleme bereiten.
6. Sicheres Einspielen von Patches: Wie gut und einfach eine SharePoint-Erweiterung betreut werden kann, hängt auch von der Einbettung in SharePoint ab. Je tiefer die Software verankert ist, desto mehr Expertise ist beim Patchen erforderlich, damit die Stabilität des Gesamtsystems nicht gefährdet wird.
7. Kostenkontrolle: Kosten sind bei Entwicklungsprojekten ein kritischer Punkt. Ist die Programmierung am Anfang noch überschaubar, kommen häufig im Verlauf des Projekts weitere ungeplante Kosten dazu. Weitere Aspekte sind die zukünftige Pflege sowie das Lizenzthema, also beispielsweise, wie lange diese gültig ist und was passiert, wenn mehr Nutzer benötigt werden.
8. Einfache Bedienung: Stark unterschätzt wird oft auch die Bedienerfreundlichkeit und Nutzerakzeptanz. Es gab bereits viele Tools für SharePoint, zwar gut funktionieren, aber über eine komplett andere Bedienlogik verfügen und so die Arbeit der Anwender erschwerten. Oft werden dann anfangs Schulungen durchgeführt, die Initiatoren betätigen sich eifrig als Intensivnutzer, doch nach einiger Zeit nimmt die Verwendung ab. Falls dann auch noch Handbücher oder Dokumentationen fehlen, verkümmern solche Tools schnell. Wir haben schon häufig gute Erweiterungen aus dem Bereich Diskussionen und Wikis gesehen, die von niemandem mehr eingesetzt werden.

Warum nicht die Bordmittel von SharePoint ausreizen?

Die obige Auflistung zeigt, dass eine Anschaffung oder Entwicklung von SharePoint-Erweiterungen nicht unkritisch ist. Warum also zunächst nicht einfach prüfen, wie weit man mit den Bordmitteln von SharePoint kommt? Aus unserer Erfahrung wissen wir, dass viele Anwender das volle Potenzial von SharePoint gar nicht kennen. Erst wenn klar ist, das die integrierten Funktionen nicht ausreichen, sollte als zweiter Schritt überlegt werden, welche Funktionen rund um SharePoint verfügbar sind.

Hierbei gibt es auch SharePoint-nahe Tools von Microsoft, beispielsweise den SharePoint-Designer für das Erstellen von Workflows. Dessen Möglichkeiten sind zwar begrenzt, aber für viele einfachere Aufgaben reicht das aus, und man bewegt sich nahe am SharePoint Standard. Als neue Alternative aus der Cloud kommt Microsoft Flow für Workflows auf Office-365-Basis ins Spiel. Auch damit bewegt man sich nah am Standard und hat so kaum mit Kompatibilitätsproblemen zu rechnen.

Überlegungen: SharePoint-Tools programmieren (lassen)

Erst wenn diese Möglichkeiten ausgeschöpft sind, sollte die Option Programmierung erwogen werden – ob per externem oder internem Programmierer. Auch hier gilt es, genau darauf zu achten, welche Technologie zum Einsatz kommt. Microsoft hat SharePoint nämlich über die Jahre mit einer Reihe von teilweise konkurrierenden Programmiermodellen ausgestattet. Sehr oft trifft man hier die Solutions an, die von Microsoft jahrelang propagiert wurden. Damit lassen sich zwar sehr umfangreiche Lösungen realisieren, jedoch hat sich die tiefe Einbettung in SharePoint auch als Achillesferse entpuppt.

Seit 2013 bevorzugt der Hersteller das App-Modell, zunächst die SharePoint-hosted Apps, und inzwischen die sehr beliebten Provider-hosted Apps. Bei den Entwicklungsmöglichkeiten ist man hierbei zwar deutlich eingeschränkter, doch kann so eine App den SharePoint-Betrieb nicht gefährden.

Genaue Planung und Kostenkotrolle: Pflichtenheft

Falls es tatsächlich auf eine individuelle Entwicklung hinauslaufen sollte, kommt es auf eine möglichst präzise Beschreibung an. Die Schilderung eines vorhandenen Problems gegenüber einem Programmierer oder Berater heißt noch lange nicht, dass er das Bedürfnis genau versteht. Es sollte daher möglichst früh der Kostenrahmen festgelegt werden, der Funktionsumfang, welche Rechte und Berechtigungen das Tool auf dem SharePoint Server benötigt und welche Auswirkungen zu erwarten sind. Ansonsten kann es böse Überraschungen geben, denn ein späterer Umbau kommt immer teurer als eine ausführliche Planung.

Oft besteht dabei die Erwartungshaltung, dass man bei der Planung schnell Ergebnisse sehen möchte und daher voreilig mit dem Programmieren loslegt. Schnell kommen dann weitere Aspekte hinzu, die dazu führen können, dass man wieder alles über den Haufen wirft. Um so etwas zu vermeiden, sollte man daher ein Pflichtenheft ausarbeiten, in dem klar festgelegt ist, was man als Auftraggeber erwartet und was das neue Tool können soll. Diese Ausführungen übergibt man dann möglichst komplett, damit der Programmierer oder das Beratungshaus sich darauf einstellen kann. Der Vorteil dabei ist, dass Sie eine vollständig individuelle Lösung erhalten.

Fazit: Zwischen Standardisierung und individuellen Bedürfnissen

Am Ende stellt sich die Frage, ob dieser Vorteil tatsächlich die die oben beschriebenen Nachteile überwiegt. Zieht man einen Vergleich mit dem Fahrzeugbau, fahren wir heute alle mit standardisierten Fahrzeugen und nehmen auch hin, dass der eine oder andere Knopf nicht dort ist, wo wir ihn hingesetzt hätten. Vielleicht müssen wir diesen Standardisierungsprozess in der IT-Welt noch durchleben, damit wir zukünftig mehr Standardversionen akzeptieren lernen. In jedem Fall wäre das der angenehmere Weg gegenüber dem oft steinigen Weg mit Drittanbietern.

Das Video: Individuelle Entwicklungen und Drittanbietertools – Vorteile und Nachteile