Bau mir ein Haus mit Office 365 – SharePoint Lösungen migrieren

Die alten Hasen unter den Lösungsarchitekten und IT Pros für Office 365 haben aktuell keinen leichten Stand, insbesondere, wenn sie noch weitgehend in Denkmuster von SharePoint on-prem verhaftet sind. Neben einer Fülle neuer Tools sorgen gravierende Paradigmenwechsel bei Identitäten, Servicearchitekturen und Entwicklungsmodelle immer noch für reichlich Neuland. Seit etwa fünf Jahren ist es mittlerweile als SharePoint IT Pro Usus, das latente Gefühl des Hinterherlaufens bzw. des Getriebenseins zu spüren, wenn man all die Ankündigungen, Konferenzen und Seminare sieht. Allerdings: Viele Aspekte von Office 365 bleiben beim Endanwender ungenutzt oder werden abgeschaltet. Sollte man für die Migration seiner SharePoint-Lösungen den Denkhorizont bei der Migration von Datentöpfen und Lösungen da nicht erweitern?

Anlass dieses Artikels ist ein interessantes Gespräch über Möglichkeiten, eine große vorhandene interne SharePoint-Lösung vielleicht anderen Mandanten auch als Lösung anzubieten. Aktuell noch auf SharePoint Server 2010 laufend wird die Anwendung gerade auf SharePoint 2016 migriert. Mit allen typischen Dreckecken und verbastelten Elementen, auf die man häufig bei Lösungen aus der Zeit trifft. Viel Datenablage, diverse Farm Solutions, Branding, haufenweise Workflows: all das gebündelt auf diversen Websites einer Sitecollection.

Die durchaus gute Idee: Lasst uns diese Anwendung, die unseren Benutzern schon über viele Jahre geholfen und sich bewährt hat, doch als Software as a Service anbieten! Als Serviceprovider für eine schmale monatliche Mark darf dann jeder seine eigene Instanz mieten.

Lasst uns eine SharePoint-Lösung migrieren!

Eigenes Hosting scheidet aus, allein wegen Identitäten und Lizenzen. Bleibt noch die Cloud, ist aber auch nicht ganz trivial. Insbesondere wer wo welche Hoheit über Daten und Funktionen besitzt und wer den Tenant betreibt hat schon genug kniffeliges Potential. Zusammengefasst stürzen Vorüberlegungen beim Brainstorming ein wenig in sich zusammen. Wie technisch was migriert werden kann, wie sich die altbekannten Produkte in SharePoint Online vielleicht doch ganz anders verhalten als beim on-premise Server oder wie sich ein Deployment gestalten kann – geht man etwas in die Details, werden die Unterschiede in der Entwicklung deutlich sichtbar.

Trotzdem kratzt das alles nur an der Oberfläche. Wie sich langsam immer mehr herauskristallisiert ist vielleicht gar nicht der gewachsene Moloch das Problem. Die Grundidee der Anwendung ist gut. Aber lässt man nicht ganz viele Chancen und Möglichkeiten liegen, wenn man sich sklavisch an die 1:1-Überfährung macht?

Anwendungsfälle und die Frage der Blickwinkel

Also denken wir das alles mal weiter. Bisher ist es so, dass aus den Versatzstücken von SharePoint-Features, Listen und Bibliotheken, einem Informationsmanagementunterbau mit Metadaten und Typen, Workflows und einigen Produkten etwas bausteinartig zusammengefügt worden ist. Das ist das Wesen von SharePoint und wird es im Grundton wohl auch immer bleiben. Diese Bausteine selbst sind dabei nicht immer ideal und mittlerweile auch teilweise reichlich in die Jahre gekommen. Vor fünf bis sieben dieser Jahre hat sich also jemand hingesetzt und Stakeholder interviewet, Anforderungen aufgeschrieben und diese auf Basis der genannten Versatzstücke in ein Konzept und später in den Server gegossen. Man hatte ja nix anderes.

Erst einmal stellt sich die Frage, ob sich mit der Erde nicht auch die Anforderung über die Jahre weitergedreht hat. Oftmals sind superduper-wichtige Anforderungen mit Personalwechsel in der Abteilung, Prozesschanges oder einfach der bloßen Überschätzung zu Zeiten der Aufnahme auf einmal obsolet oder werden anders gehandhabt. Manchmal werden Teile der Anwendung nicht mehr genutzt. Oder ein ambitionierter Verantwortlicher hat sich mit Google bewaffnet mit fragwürdigen Mitteln an Changes gewagt. Vielleicht ist die Rechtsgrundlage anders oder die Anwendung wird ganz anders gelebt als antizipiert. Gründe gibt es viele, die fachlichen Anforderungen noch einmal zu hinterfragen.

Daneben gibt es aber auch die Weiterentwicklung von Systemen und Arbeitsweisen (der ominöse „Arbeitsplatz x.0 | x > 1“ lässt grüßen). Mobilität, service-orientierte Herangehensweisen, integrative Aspekte – all das wird mittlerweile tatsächlich verlangt und kann klassische SharePoint-Applikationen beim Verfehlen unfassbar alt aussehen lassen.

Schließlich ist das zusammengefasst auch eine Frage der Perspektive des Benutzers, der damit arbeitet. Ist es wirklich noch die Anwendung rund um eine Datenablage, die maßgeblich ist? Warum muss man denn erst die Applikation wechseln, wenn man die Informationen hieraus an ganz anderer Stelle braucht?

Ein schönes Beispiel für diese Denke ist da ein Teil der Implementierung der Data Loss Prevention: Anstatt mühsam in Arbeitsvorschiften in Dokumenten einer bestimmten SharePoint-Seite nachzuschauen, wie mit einer bestimmten Kritikalität umzugehen ist, wird diese dem Mitarbeiter gezeigt, während er damit arbeitet. Die ewig alte Leier von Bringschuld und Holpflicht weicht damit einem übergreifenden Konzept, welches direkt an der Stelle ansetzt, an der sich der Benutzer befindet. Und das ist hier gerade die Email, an der er herumtippt, und nicht der SharePoint-Dokumentenfriedhof.

Solcherlei Beispiele gibt es viele. Anwendungsfälle sind oftmals eingepfercht in den Technologien, die zum Zeitpunkt der Implementierung für eben diese da waren. Dabei werden die Informationen oftmals immer in etwas anderes überführt und müssen für die Nutzung wieder mühsam rausgepult werden.

Office 365 ist mehr als SharePoint Online

Wie im Anreißer bereits breit ausgerollt gibt es haufenweise Werkzeuge in Office 365, deren Quantität und Qualität auch noch immer größer wird. Es gibt darüber hinaus aber auch noch für IT Pros und Lösungsarchitekten Third-Party Produkte, Techniken und Community-Artefakte, die sich immer mehr als allgemein gesetzt herausstellen und die man natürlich alle kennen sollte. Liest man Artikel darüber, wirkt das alles immer so selbstverständlich. Ob OfficePnP, all die schönen Groups-Details oder das SharePoint Framework für Publishing Sites: „Kennste das nicht, biste out.“ Beim Blick auf die Ankündigungen und Vollzugsmeldungen wird das auch nicht besser. Bloß anders als beim SharePoint Server für zu Hause lassen sich bestimmte Aspekte einfach nicht mehr so galant ignorieren, der Benutzer halt in Office 365 seine Self-Service-Ansatzpunkte und klickt in der Cloud  eben auf Dinge.

An dieser Stelle möchte ich einen Kernsatz dieses Artikels unterbringen: Liebe SharePoint-Architekten, traut Euch, einen Schritt zurückzutreten und das Ganze aus einem weiteren Winkel zu betrachten. Ihr hattet noch nie so schöne Instrumente und so prall gefüllte, nahezu fertige Teillösungen an der Hand! Die hervorragende Infografik von Matt Wade (Quelle: http://icsh.pt/O365Table) gibt einem immer mal wieder eine Idee, was sich außer SharePoint noch so alles benutzen lässt.

Insbesondere Teams, PowerApps und Flow bieten dabei ungeahnte Möglichkeiten, wenn man sich dann noch provider-gehostete Erweiterungen und Versatzstücke dazu denkt.  Azure macht’s von außen möglich, außerdem können Add-Ins direkt in den Office Clients wirken. Auch alles, was in der Office Group als technologischen Unterbau beheimatet ist, erweitert das Spektrum. Über allem thront natürlich noch der Microsoft Graph und all die anderen APIs. Die Liste lässt sich nahezu beliebig fortführen.

Gesamtbild schlägt (vielleicht) SharePoint-Insel

Kommen wir zurück zu unserer Altanwendung, der neues Leben eingehaucht werden soll. Ein radikaler Ansatz statt einer 1:1 Migration wäre hier beim Schritt von SharePoint 2010 on-premise zu SharePoint online: Nehmen wir das Wissen und die Erfahrung aus dieser Sitecollection, die Prozesse und die Datenstrukturen, legen diese fein säuberlich mit dem Refactoring der Anforderungen zur Seite und pfeffern das ganze restliche Ding für unser Vorhaben in die Tonne. Vieles kann man eh nicht direkt migrieren (Farm Solutions, Brandingsünden, Drittherstellertools, z.T. Workflows), anderes möchte man nicht migrieren.

Befreit von diesem Ballast und mit Blick auf das übrig gebliebene lassen sich Fragen stellen:

• Ist das zugrundeliegende Datengerüst wirklich noch so gut für Listen und Lookups geeignet? Oder ist die Zeit doch für eine Datenbnak im Hintergrund gekommen?
• Gibt es globale Listen, die irgendwo anders liegen liegen müssten? Ist die Konfiguration mandantenfähig? Gibt es Timerjobs, die eigentlich woanders laufen müssten?
• Wie ist die grundsätzliche Logik und der Prozess abgebildet? Durch Versatzstücke wie WebParts und VisualStudio-Workflows? Durch on-prem Nintex mit gecustomizten Activities? Kann oder muss das woanders laufen? Was ergeben sich daraus für Konsequenzen für Entwicklung und Hosting?
• Macht das alles so noch Sinn in SharePoint von der Bedienung her? Ist das in Zukunft kompatibel mit Modern Pages?
• Macht es Sinn, alles Fachliche aus SharePoint herauszuziehen und in eine provider-hosted App mit state-of-the-art Web-Programmierung, Application Lifecycle, Deploymentmodell etc. zu packen und SharePoint nur noch für das Filehosting und Gruppenverwaltung per CSOM und REST fernzusteuern?
• Können Bereiche der Zusammenarbeit mit Groups oder Teams ergänzt oder substituiert werden statt Deployment von Teamsites zu verwenden um Arbeitsbereiche zu schaffen?
• Kann die Anwendung um kommunikationsorientierte Elemente erweitert werden? Kommentierungen, Austausch, Vorschlagswesen? Was ist mit Yammer-Kanälen, Communities, Microfeeds?
• Sind die Funktionen der Anwendung so abstrahierbar, dass sich Azure Functions oder eine ApiApp anbieten um Funktionen auszulösen? Vielleicht mit Swagger-Beschreibung, um Flow daran zu hängen und damit Funktionen aus vielen verschiedenen Bereichen zu triggern?
• Macht es Sinn, die Suche um Managed Properties und Abfrageregeln zu erweitern, um „intelligent“ Facetten der Anwendung auch im Suchcenter abzubilden? Kann man direkte, kontextsensitive Handreichungen von Aspekten der Anwendung in anderen Bereichen des SharePoints bringen?
• Kann man die APIs der Anwendung vielleicht in Office Clients als Add-Ins bereitstellen? Oder das Einfließenlassen von Informationen in Word und Excel, automatische Erkennung in Outlook Emails?
• Kann es helfen, bei der Arbeit in Teams Informationsbeschaffung aus der Anwendung durch einen Bot zu erfragen? Was wären sinnvolle Fragen, wobei könnte unkompliziert weiterhelfen, was lässt sich durch ihn automatiseren?
• Überhaupt Teams: Macht es Sinn, die Funktionalität einer solchen Anwendung vielleicht als Team Registerkarte direkt in Projekten oder Arbeitsbereichen dort einfließen zu lassen?
• Kann Reporting durch PowerBI abgebildet werden? Wenn die Anwendung sowieso auf andere Füße gestellt wird, kann man hier sinnvolle Datenquellen bereitstellen, die man so wieder visualisieren und anderswo einbinden kann?
• Sind das SharePoint Framework oder Third Party Produkte wie skybow geeignet, die eigenen alten WebParts der Anwendung in flexible Bausteine zu überführen?
• Können in anderen Bereichen APIs angesteuert werden (per Flow, Nintex, REST, SOAP, usw.) um Informationen aus der Anwendung aktiv zu pushen?
• Eröffnen sich durch die Services von Office 365 Möglichkeiten, durch native Apps oder PowerApps mobile Endgeräte anzusprechen? Ist das gewünscht? Soll das ausgebaut werden?
• Usw. usf.

Es ist vollkommen klar, dass es gute Gründe gibt, den Großteil dieser Fragen kategorisch als „nicht relevant“ anzutun. Schließlich geht es ja bisweilen um hochwichtige, geschäftskritische Prozesse, da spielt man nicht mit rum oder geht das Risiko ein, sich in den Optionen zu verzetteln.

Trotzdem sollte man sich trauen, zumindest probehalber den Schritt zurück zu wagen und einmal verstohlen zu blinzeln. Vielleicht entpuppen sich ja doch ungeahnte Potentiale, an die man voher vielleicht einfach nicht gedacht hat.

Grafik: C. Flammarion – Universum – Paris 1888 – Colored Heliocentric Panorama https://commons.wikimedia.org/wiki/File:C._Flammarion_-_Universum_-_Paris_1888_-_Colored_Heliocentric_Panorama.jpg