Domino-Migration: Der frühe Vogel fängt den Wurm

Wenn die Entscheidung erst einmal gefallen ist, dass mittel- oder langfristig die Domino-Infrastruktur aus dem Unternehmen verschwinden wird, lässt die Investitionsbereitschaft der einzelnen Fachabteilungen in Domino-basierte Applikationen verständlicher Weise spürbar nach. Aber auch aufkommende Gerüchte oder durchgeführte Studien (auch wenn diese zu einem gegenteiligen Ergebnis kommen) können den Willen der IT- oder Geschäftsleitung nach einem Systemwechsel zu entsprechender Aussage verhelfen, und durch die aufkommende Ungewissheit zu dem gleichen Ergebniss führen.

Um dennoch zukunftssichere Applikationen zu entwickeln, bieten sich verschiedene Wege an, die sich (in Abhängigkeit zu der bestehenden und der zukünftigen Infrastruktur sowie der gewünschten strategischen Ausrichtung) jedoch stark unterscheiden können. Für jedes Unternehmen sind bestimmte Faktoren unterschiedlich zu bewerten, daher gibt es keinen „Königsweg“: Der zu beschreitende Weg ist immer individuell, und es müssen höchstwahrscheinlich ein paar Kompromisse eingegangen werden, um einen Übergang so geräuschlos wie nur möglich über die Bühne zu bringen.

Der mit Abstand wichtigste Punkt ist, sich möglichst früh vom liebgewonnenen Domino zu verabschieden, ohne eine falsch angebrachte Sentimentalität. Weitere wichtige Punkte, die es meiner Erfahrung zu beleuchten gilt, sind

1. die gewünschte Form der Migration
2. mögliche Ziel-Plattformen
3. zunkünftige Datenhaltung
4. die Authentifizierung der Anwender

Formen der Migration

Ist eine harte Migration gewünscht, sind praktisch alle Entscheidungen bereits getroffen, und eine weiteres Auseinandersetzen mit anderen Szenarien erübrigt sich: Sowohl Zielplatform als auch (Wunsch-)Termin stehen fest. Das Budget spielt dann wahrscheinlich auch keine Rolle, und ich wünsche viel Glück und gutes gelingen.

Wählt man hingegen eine weiche oder integrative Migrationen, erhöht sich der nötige Spielraum deutlich, und die Chance einer erfolgreichen Umstellung steigt, denn der Zeitdruck und das damit einhergebrachte Risiko eines Fehlschlages wird durch die Politik der kleinen (aber feinen) Schritte drastisch verringert.

Mögliche Zielplattformen

In einem Microsoft-lastigen Unternehmen bietet sich natürlich der IIS als Webserver an, um Applikationen darauf zu hosten. Der IIS unterstüzt neben den „Microsoft-eigenen“ Sprachen wie .NET auch weitere wie z.B. Java und PHP. Selbst Node.js wird unterstüzt.

Hier wäre also ein Ansatzpunkt, neue Applikationen direkt auf dem IIS zu betreiben. Falls momentan noch kein IIS im Einsatz ist, bietet es sich an, eine PHP-Applikationen auf dem Domino zu hosten, und diese dann später auf den IIS zu verschieben. Als Alternative kann auch ein Apache HTTP Server oder ein Tomcat dienen, wenn IT diesen betreiben kann (und will). Gleiches gilt natürlich auch für Node.js. Letztlich muss dieser Punkt mit der Administration abgeklärt werden.

Zieht man Client-basierte Applikationen (Stichwort „Angular JS“) in Betracht, kann die Applikation sogar in die Cloud verlagert werden, denn die Daten bleiben im Unternehmen: Zwar lädt der Browser die statischen Ressourcen aus der Cloud, doch werden die Daten vom Browser nur per REST-Schnittstelle im Unternehmensnetzwerk hin- und hergeschoben. Dadurch entfiele ein entsprechender administrativer Aufwand, die Applikation könnte auch von einem externen Anbieter problemlos betrieben werden (z.B. Bluemix).

Zukünftige Datenhaltung

Die Datenhaltung stellt wohl in bestimmten Stitautionen die größte Herausforderung dar, insbesondere wenn auch alte Daten migriert werden müssen. Gerade das Thema „Rich Text-Felder“ kann Probleme bereiten, denn je nach Verwendung wird es schwierig, bestehende Daten/Funktionalitäten 1:1 zu übernehmen. Auch einige eher selten genutzte Features auf Feldebene können eventuell nicht ohne erheblichen Aufwand abgebildet werden, doch muss man hier derweilen auch hinterfragen.

In den meisten Fällen sollte eine Umstellung allerdings Reibungslos möglich sein. Moderene Dokumentenbasierte Datenbanksysteme bieten einen ebenbürtigen Funktionsumfang, meist sogar noch deutlich mehr. Dennoch sollte meiner Erfahrung nach dieser Part nicht unterschätzt werden.

Authentifizierung

Eine wichtige Rolle stellt die Authentifizierung im Unternehmen dar: Wurde dies bisher vom Domino Server gehandelt, fällt diese Option zukünftig weg. Aber auch hierfür gibt es unterschiedliche Ansätze, je nachdem, woher die Applikation Ihre Daten erhält und wohin diese Daten abgelegt werden.

Wird der Domino Server nur zur Authenifizierung und nur einige Daten über den User benötigt, existiert mit LDAP eine relativ simple Lösung des Problems, die auch einfach migriert werden kann.

Sollen existierende Datenbanken angezapft werden, kann dieser Zugriff im Usercontext durch eine Proxy-Funktionalität geschehen (durch das Abgreifen/Durchschleifen des Domino Cookies). Eine spätere Umstellung kann dann für die Endapplikation transparent erfolgen, in dem letztlich der Code im Backend geändert wird, ohne das es hier zu Einschräkungen kommt.

Nutzer der Applikation

Ach, ein Thema habe ich bewusst aussen vor gelassen, dass aber ebenfalls eine große Rolle spielt: Die Nutzer der Applikation. Man darf Sie nie vergessen, und man muss versuchen, auf sie einzugehen, aber leider ist das die große Unbekannte, die praktisch unberechenbar ist: Es gibt Mitarbeiter, die sehr interessiert sind, und bei der Umstellung mitarbeiten. Gerade wenn die Möglichkeit dafür genutzt wird, das eine odere andere hilfreiche Zusatzfeature zu implementieren, und so den Mitarbeitern eine entsprechende Motivation zu bieten, wird verläuft eine Zusammenarbeit meist harmonisch und ertragreich. Letztlich sollte die Chance auf ein Redesign einer alten Applikation so gut wie möglich genutzt werden.

Aber man wird eventuell auch auf eine generelle Ablehnung stoßen, denn es war für die Mitarbeiter bisher möglich, viele Probleme im Arbeitsalltag auf „das Sch..ss Notes“ zu schieben. Diese Option entfällt zukünftig – was manchem Mitarbeiter in Erklärungsnot bringen könnte, und daher wird gemauert ohne Ende. Auch könnte es vorkommen, das vorhandene Features, die noch nie funktioniert haben, über Nacht zu Keyfeatures mutieren und deren „mangelnde Funktionalität“ die ganze Migration ad absurdum führen würden.

Da der „menschliche Faktor“ unberechenbar und damit unplanbar ist, kann (und sollte) er in der anfänglichen Planun nicht näher beachtet werden.

Fazit

Alles in allem lösbare Punkte, auf die ich im Einzelnen in den nächsten Tagen näher eingehen möchte. Es stehen noch Themen auf der Agenda, wie beispielsweise die Suche nach relevanten Applikationen, die migriert werden müssen. Und natürlich sollte die eine oder andere Anekdote, die ich in den letzten Jahren gesammelt habe, nicht fehlen.