Das Ende der SharePoint-Reise? Oder ist der Weg das Ziel?

Das Ende der SharePoint-Reise? Oder ist der Weg das Ziel?

Viel ist passiert im Umfeld von Microsoft SharePoint, und als Technologie-Experten im SharePoint-Umfeld fragt man sich dieser Tage, wohin die Reise wohl gehen wird. Edin Kapic hat dies in einem herausragenden Artikel (hier: http://www.edinkapic.com/2015/01/where-are-you-going-sharepoint.html) beleuchtet, und er trifft damit ziemlich genau unsere eigene Einschätzung. Daher gibt es an dieser Stelle eine recht freie Übersetzung seines Artikels.

Die Entwicklung von SharePoint als lokaler Serverplattform hin zur Cloud und ihre Verbindung in Hybrid-Systemen

In den Anfängen der SharePoint-Entwicklung (das war vor 12  Jahren!) war die Welt der Entwickler einfach. Die Entwicklung erfolgte durch serverseitigen Code, und sonst nichts. Code musste auf einem SharePoint-Farmsystem laufen. Das hatte natürlich eine ganze Reihe von Vorteilen, entspricht das Server-Objektmodell doch in weiten Teilen dem Modell, dass auch von SharePoint intern verwendet wurde. Aber gleichzeitig war der Entwickler verantwortlich für die Performance seiner Lösung oder auch für Seiteneffekte, da der Code zusammen mit SharePoint-eigenem Code im selben IIS-Prozess oder –Dienst lief. Hatte man als Entwickler seine Hausaufgaben gemacht, so gab es wenig Probleme und unbegrenzte Möglichkeiten. Nur die Freude der IT-Administratoren hielt sich in Grenzen, hatten sie doch mit den Folgen zu kämpfen und mussten einen stabilen Betrieb der SharePoint-Plattform gewährleisten.

Als einzige Alternative zur serverseitigen Programmierung gab es noch die ASMX Webservices. Nur diese ermöglichten eine programmatische Ansprache von SharePoint, ohne direkt Code in eine SharePoint-Farm einzupflanzen, wenngleich die Dienste auch etwas klobig und wenig umfassend waren. Mit der Zeit entwickelten sich diese Programmieransätze weiter, Best Practices und Empfehlungen wurden entwickelt, und immer seltener wurden Situationen, in denen individuelle Farmlösungen eine komplette Serverfarm in die Knie zwangen.

Soweit war die Welt (außer für die manchmal leidgeprüften IT-Administratoren) in Ordnung, bis Microsoft damit begann, SharePoint Onlineinnerhalb ihrer Business Productivity Suite (BPOS)anzubieten. Auf einmal spürte auch Microsoft den Schmerz der IT-Administratoren und fing an zu verstehen, wie kompliziert das Hosten einer SharePoint-Umgebung sein konnte, die mit großen Freiheitsgraden durch Code angepasst werden konnte.

Richtig spannend wurde es, wenn Updates, Patches und Service Packs eingespielt wurden und gleichzeitig sichergestellt werden musste, dass individuell programmierte Lösungen weiter ordnungsgemäß funktionierten. Jetzt war Microsoft nicht nur mehr der Hersteller einer Plattform, sondern auch deren Betreiber und damit verantwortlich für die verwalteten Daten und Business-Lösungen.

In den ersten Jahren von SharePoint Online kristallisierte sich immer mehr heraus, dass Zustände und Freiheitsgrade, die in einem separaten Datacenter noch unter Kontrolle gehalten und verwaltet werden konnten, in einer Cloud-Umgebung mit vielen Mandanten nicht funktionieren konnten. Individuelle Lösungen sind in der Regel nicht darauf ausgelegt, automatisch mit wachsender Anzahl an Mandanten und Anforderungen mitzuskalieren. Erschwerend kam hinzu, dass diese nach einem der regelmäßigen Updates der SharePoint-Version auf den Microsoft-Servern womöglich garnicht mehr funktionierten. Sogar die als Lösung für das Dilemma propagierten „Sandkasten-Lösungen“ mit ausschließlich „ungefährlichem“ Code verhielten sich nicht so, dass sie für eine gehostete Umgebung geeignet waren.

In den goldenen SharePoint-Jahren war also eine umfassende Anpassung der SharePoint-Plattform mit Hilfe von serverseitigem Code möglich. Eigene Web-Parts, neue Controls, Timer-Dienste, Applikationsseiten, serverseitige Erweiterungen…alles, was das Herz eines Entwicklers höher schlagen ließ, konnte programmiert und umgesetzt werden. Die Lösungen konnten bei schlechter Programmierung sich selbst oder anderen Lösungen das Wasser abgraben und das Datacenter zu hundert Prozent oder mit 100%iger Speicherauslastung beschäftigen. Der Entwickler entschied, was wichtig und was unwichtig war, und konnte beliebigen serverseitigen Systemcode in eine SharePoint-Anpassung einfließen lassen.

Betrachtet man die Geschichte aus einem anderen Blickwinkel, so war ein stabiler und zuverlässiger Betrieb einer SharePoint-Plattform nur möglich, wenn diese unverändert vom Auslieferungszustand ohne Anpassungen betrieben wurde. Egal wie umsichtig Anpassungen vorgenommen wurden, die Verwendung von eigenem Code für eine SharePoint-Anpassung wurde durch Instabilitäten bezahlt.

Die Sicherheit des Codes selbst konnte zwar durch Einführung der CAS-Richtlinien verbessert werden, aber auch dies wurde häufig durch einfache Änderungen an der IIS Web.config außer Kraft gesetzt.

Skalierbarkeit und Performance wichtiger als Anpassungen

SharePoint Online durfte kein Fehlschlag werden. Zu verlockend war für Microsoft die Aussicht auf einen regelmäßigen Cashflow durch monatliche Mietzahlungen anstelle einer einmaligen Verkaufslizenz, bedeutete dies doch eine deutliche Aufbesserung der Bilanz der Microsoft Office Division. Das Abwägen zwischen den „weniger lukrativen“ Einmalkunden (die individuelle Lösungen und Anpassungen wünschten) und einer SharePoint Online-Cashcow (und damit der Erfordernis einer skalierbaren und performanten Plattform) führte daher schließlich zu einer Fokussierung der Online-Seite und ihrer Skalierbarkeit.

In der Folge verschwand die Möglichkeit, Servercode in SharePoint-Cloudumgebungen auszurollen, und auch zunächst beliebte Anpassungen per deklarativer XML traten in den Hintergrund. Alles war gut für diejenigen, die mit den Standardfeatures von SharePoint Online gut leben konnten. Und wem das nicht reichte, der konnte jetzt eine „App“ installieren. Die konnte per Client-Objektmodell etliche, wenn auch längst nicht alle Serverfunktionen ausführen. Diese App lief dann aber auf separaten Servern, verbrauchte eigene Ressourcen und nicht die der SharePoint-Cloudplattform und konnte keinen negativen Einfluss auf die eigentlichen SharePoint-Instanzen mehr ausüben.

Wie sieht jetzt die Zukunft für Kunden aus, die eine eigene SharePoint-Infrastruktur betreiben?

Es sieht ein wenig danach aus, als würde Microsoft („cloud first“) die existierende Realität verkennen. Große Unternehmen und Organisationen setzen SharePoint seit Jahren in einer eigenen Infrastruktur ein und bauen diese aus. SharePoint war niemals als Software für kleine Unternehmen gedacht. Auch wenn mit der SharePoint Foundation bzw. den zuvor so genannten Windows SharePoint Services eine kostenlose Basisvariante von SharePoint zur Verfügung stand, war und ist eines der Kernversprechungen von SharePoint die Möglichkeit, in Organisationen Informationen und Wissen auszutauschen und in Teams zusammenzuarbeiten. SharePoint eignet sich gut für das Überwinden von Abteilungsgrenzen und das Aufbrechen verkrusteter Unternehmenskulturen, Arbeitshürden, die eher aus großen Organisationen bekannt sind. Auch trägt die nicht gerade preiswerte Serverlizenz eher zu einer Nutzung durch große Unternehmen bei.

Mit SharePoint Online als Teil von Office365 steht jetzt dagegen ein Paket zur Verfügung, dass auch für kleinere Unternehmen attraktiv ist. Aber wird SharePoint durch kleinere Unternehmen genutzt? Ein Großteil der kleineren Office365-Kunden ist hauptsächlich an der Nutzung von Exchange Onlineinteressiert, ganz einfach weil eine E-Mail-Infrastruktur in allen Unternehmen, auch in kleinen, benötigt wird. SharePoint dagegen ist nicht jedermanns Sache. Wie viele der „Millionen Office365-Anwender“ nur den Teil „Exchange Online“ aus dem Office365-Angebot nutzen, ist nicht bekannt, aber es könnte der Großteil sein.

Es sieht so aus, als würde Microsoft am laufenden Band neue Online-Features für ihre imaginären SharePoint Online-Kundenauf den Markt werfen, während die echten SharePoint-OnPremise–Kunden mit den großen Budgets vom Regen (abnehmende Investitionen in neue On-Premise-Features) in die Traufe (limitierte Möglichkeiten zur Anpassung von Office365) kommen. Diese Kunden brauchen die Möglichkeit, SharePoint an ihre Bedürfnisse anzupassen, und das App-Modell und Office365 sind hier schlichtweg zu begrenzt. Ganz zu schweigen von den Anpassungen an das Corporate UI, nach denen große Unternehmen und Organisationen als Erstes fragen. Jetzt wartet ein Spießrutenlauf, um ganz einfach nur sicherzustellen, dass Masterseiten, CSS und JavaScript-Anpassungen bei einem SharePoint-Online-Update intakt bleiben.

Nur ein kleiner Teil der Unternehmen entscheidet sich für einen „Hybrid-Ansatz“, die Kombination aus eigener SharePoint-Farm mit der Office365-„Farm“. Sicherlich wird die Anzahl dieser Nutzer zunehmen, aber werden sie irgendwann ihre eigene SharePoint-Farm aufgeben? Sicherlich nicht in der nahen Zukunft. In den Unternehmen installierte SharePoint-Farmen werden uns noch auf viele Jahre begleiten.

Der Grund dafür liegt ganz einfach darin, dass die Cloud-Plattform nicht mit den Möglichkeiten der lokalen Installation gleichziehen kann. Die Cloud-Variante bietet weniger Flexibilität bei Anpassungen, aber gleichzeitig eine höhere Flexibilität bei der Bereitstellungsgeschwindigkeit und den Betriebskosten. Die Lücke zwischen beiden Varianten wird zunehmend kleiner, aber nicht verschwinden.

Die Cloud wird zusätzliche Erweiterungen, Services und Technologien bieten, mit denen eigene Lösungen und lokale SharePoint-Installationen verbessert und ergänzt werden können. Es kann daher gut zu einer Ausweitung von Hybrid-Szenarien kommen, aber auch reine On-Premise-Szenarien werden weiter existieren. Auf der anderen Seite gibt es reine Cloud-Szenarien wie das selbstlernende „Delve“, bei denen eine On-Premise-Bereitstellung alleine schon aufgrund der erforderlichen schieren Datenmenge nicht möglich ist. Für wirklich große Unternehmen mit eigenen Prozessen und einer eigenen Organisationsdynamik wird es jedoch auf absehbare Zeit kein reines Cloud-Szenario geben können. Aber Microsoft’s Hingabe zu lokalen SharePoint Server-Farmen ist Geschichte. Der neue Liebling heißt ohne Zweifel SharePoint Online!

Wir sehen in der Zukunft von SharePoint Server regelmäßigere Updates(wie auch in Windows oder Visual Studio), die dann nicht nur Bug Fixes, sondern gleichzeitig neue Features beinhalten. Die Hauptentwicklung wird in der Cloud stattfinden, und nicht alle Cloud-Features werden für eine lokale Serverfarm geeignet sein. Aber es sprechen eigentlich keine Gründe dagegen, die in der Cloud ausgerollten iterativen Verbesserungen von Zeit zu Zeit in die Welt der SharePoint-Farm zu übertragen. Der 3-Jahres-Zyklus für SharePoint wird Zug um Zug durch ein regelmäßiges Update alle paar Wochen ersetzt werden. Von zentraler Bedeutung für die Betreiber einer SharePoint Farm sind nicht die allerneuesten Features, sondern eine stabile, regelmäßig verbesserte und ausgebaute Lösung, so dass sich mit diesem Weg sehr gut leben lässt.

Und wie geht es mit den SharePoint-Spezialisten weiter?

Was geschieht nun mit den Heerscharen an SharePoint-Entwicklern, Architekten, Consultants, Power Usern und Designern? Ein bischen kann man sich von Microsoft alleine gelassen vorkommen. Die Botschaften, die Microsoft an Kunden aussendet, sind selten eindeutig, auch wenn die Transparenz einiger Microsoft-Teams in den letzten Jahren bemerkenswert zugenommen hat. Dennoch ist es wenig hilfreich, unklare Signale zu senden oder die rechtmäßigen Fragen der Unternehmenskunden zu ignorieren, und es stärkt die Zweifel an der Kontinuität eingeschlagener Richtungen (man denke nur an Silverlight, Sandbox-Solutions, Autohosted Apps….)

Aber auch eine andere Wahrheit bleibt: das einzig Beständige in dieser Welt ist der Wandel. Der technologische Wandel hat schon immer stattgefunden, aber niemals so schnell wie heute. Diese Gratwanderung zwischen der Annahme der neuen technischen Möglichkeiten und dem Beibehalten bewährter Vorgehensweisen (man könnte auch sagen „der Angst vor Veränderungen“) gab es schon immer, aber sie wird durch die Beschleunigen der technischen Entwicklungen nicht leichter. Aber letztlich geht es darum, genau diese Gratwanderung zu meistern.

Es ist nicht ratsam, jeder Microsoft-Werbebotschaft zu verfallen. Als SharePoint-Spezialisten besteht unsere Rolle darin, unsere Kunden zu den Microsoft-Technologien in ihrem Interesse zu beraten. SharePoint ist und bleibt ein Werkzeug, um Lösungen für Unternehmen zu erstellen. SharePoint ist nicht die Lösung selbst, nur der Baukasten. Das sollten wir nicht vergessen.

Für uns an der vordersten Technologiefront bedeutet dies ständiges Lernen, Üben und vertraut werden mit den neuen Möglichkeiten. Zum Glück war es niemals einfacher, die neuen Vorgehensweisen zu erlernen und Hilfestellungen zu bekommen (siehe zum Beispiel das OfficeDev PnP team).

Verbringen Sie einen Teil Ihrer Zeit damit, die Cloud und ihre Funktionen kennen zu lernen, experimentieren Sie mit Apps, JavaScript und hybriden Umgebungen, freunden Sie sich mit Delve und Office Graph an, und bleiben Sie neugierig. So gelangen Sie an neue Tools, um technische Lösungen für Unternehmensprozesse zu erstellen. Und genau darum geht es für uns Technologiespezialisten!

 
Kommentare

Bisher keine Kommentare

Hinterlassen Sie eine Antwort