2024
Jan
18
Notes/Domino Anwendungsmodernisierung - Die Zeit ist jetzt!
Viele Unternehmen betreiben ihre Notes/Domino-Infrastruktur seit vielen Jahren, teils sogar seit Jahrzehnten. Ein Großteil der heute noch eingesetzten Notes-Applikationen stammt ursprünglich aus den 1990er-Jahren und wurde hier und da funktional erweitert. Grundlegende Modernisierungen und Neuentwicklungen wurden meist nicht durchgeführt.
Das kann natürlich verschiedene Gründe haben. Zum einen, weil die Lösung sicher und stabil alle an sie gestellten Anforderungen erfüllt und zum anderen, weil viele Unternehmen ihre E-Mail Kommunikation auf andere Plattformen migriert haben und die, laut der Microsoft-Berater ach so einfache, Migration der komplexen Notes-Anwendungen dann doch nicht so einfach war.
Nicht daran unschuldig war sicherlich auch die IBM, die den Trend zu mobilen und browserbasierten Applikationen für die Notes/Domino-Plattform verschlafen hat. Gute Ansätze, die bereits Prototypenstatus hatten, verblieben auf Geheiß des Managements in der Schublade. Und so kam, was kommen musste.
Seit Ende 2018 haben sich viele Dinge verändert. Der neue Eigentümer des vormaligen IBM und Lotus Software-Portfolios, HCL, investiert kräftig in die Weiterentwicklung der Plattform. Aus Notes 9.0.1 wurde inzwischen 12.0.2 und seit Dezember 2023 steht sogar Version 14 zur Verfügung.
Mit NOMAD für mobile Endgeräte und Desktop-Browser stehen Clients zur Verfügung, die die vielen Vorteile von Notes-Applikationen weiteren Nutzergruppen zugänglich machen.
Kein Wunder also, wenn man immer häufiger liest, dass Kunden zu Notes/Domino zurückkehren. Das umfasst sowohl den Wiedereinstieg in die Software-Maintenance und Upgrade auf die neueste Version bei solchen Unternehmen, die Notes/Domino noch für einige Applikationen nach der Mail-Migration weiter genutzt haben, als auch solche, die nach einem kompletten Ausstieg zurückkehren.
Grund genug, sich einmal intensiver mit einem der größten Probleme der Notes/Domino-Plattform zu beschäftigen: Wie bekommt man den Shift zur Entwicklung moderner und anwenderfreundlicher Applikationen hin?
Das kann natürlich verschiedene Gründe haben. Zum einen, weil die Lösung sicher und stabil alle an sie gestellten Anforderungen erfüllt und zum anderen, weil viele Unternehmen ihre E-Mail Kommunikation auf andere Plattformen migriert haben und die, laut der Microsoft-Berater ach so einfache, Migration der komplexen Notes-Anwendungen dann doch nicht so einfach war.
Nicht daran unschuldig war sicherlich auch die IBM, die den Trend zu mobilen und browserbasierten Applikationen für die Notes/Domino-Plattform verschlafen hat. Gute Ansätze, die bereits Prototypenstatus hatten, verblieben auf Geheiß des Managements in der Schublade. Und so kam, was kommen musste.
Seit Ende 2018 haben sich viele Dinge verändert. Der neue Eigentümer des vormaligen IBM und Lotus Software-Portfolios, HCL, investiert kräftig in die Weiterentwicklung der Plattform. Aus Notes 9.0.1 wurde inzwischen 12.0.2 und seit Dezember 2023 steht sogar Version 14 zur Verfügung.
Mit NOMAD für mobile Endgeräte und Desktop-Browser stehen Clients zur Verfügung, die die vielen Vorteile von Notes-Applikationen weiteren Nutzergruppen zugänglich machen.
Kein Wunder also, wenn man immer häufiger liest, dass Kunden zu Notes/Domino zurückkehren. Das umfasst sowohl den Wiedereinstieg in die Software-Maintenance und Upgrade auf die neueste Version bei solchen Unternehmen, die Notes/Domino noch für einige Applikationen nach der Mail-Migration weiter genutzt haben, als auch solche, die nach einem kompletten Ausstieg zurückkehren.
Grund genug, sich einmal intensiver mit einem der größten Probleme der Notes/Domino-Plattform zu beschäftigen: Wie bekommt man den Shift zur Entwicklung moderner und anwenderfreundlicher Applikationen hin?
Woher kommt Lotus / IBM / HCL Notes eigentlich?
Um zu verstehen, wieso Notes-Anwendungen häufig aussehen, wie sie aussehen und wie einige der Beschränkungen begründet sind, muss man zunächst einmal einen Blick zurück zu den Anfängen von Notes werfen.
So richtig los ging es mit Lotus Notes mit der Version 3.2 in Deutschland. Damals schrieben wir das Jahr 1993. Das Internet war noch kein Thema. Mit Notes verschickte man sich fast ausschließlich E-Mails innerhalb der eigenen Organisation oder aber Unternehmen, mit denen man als Lieferant oder Kunde eng zusammenarbeitete. Die Verbindung zwischen den Servern übernahmen Modems. Der amerikanische Online-Dienst (AOL) sollte erst noch einen Gateway-Dienst zwischen Lotus Notes und „diesem Internet“ auf den Markt bringen.
Die große Besonderheit von Notes war aber, dass „jede und jeder“ mit dem System eigene Applikationen entwickeln können sollte. Sozusagen die Geburt der „Low Code – No Code“-Entwicklung und dem „Citizen Developer“. Terminologien, die gerade in der jüngeren Vergangenheit wieder stark gehyped werden. Ob alle, die auf dieser Sau durchs Dorf reiten auch wissen, wer’s erfunden hat? Spoiler: Die Schweizer waren es nicht.
Zu dieser Zeit hieß Notes-Entwicklung: Man konnte Felder auf Masken platzieren, Ansichten gestalten und mit der Formelsprache vergleichbar zu Excel einfache Operationen durchführen. Der eine oder andere Pionier schaffte es auch, Formeln, die sich über mehrere DIN A4-Seiten erstreckten, zusammenzubauen. Wehe, irgendwo fehlte eine Klammer oder ein Semikolon....
Erst mit der Version 4 kam die erste „richtige“ Programmiersprache hinzu: LotusScript, eine sehr Visual Basic ähnelnde Sprache, die im weiteren Versionsverlauf immer mächtiger wurde.
Doch damit nicht genug: IBM spendierte Notes alsbald einen Web-Server (Domino), JAVA, eine halbherzige JavaScript und CSS-Implementierung für den Client und irgendwann dann die, von vielen wahlweise geliebten oder gefürchteten, XPages.
Auf der einen Seite haben wir Entwickler mit der Zeit immer mehr und komplexer werdende Werkzeuge an die Hand bekommen, auf der anderen Seite wurde ein Großteil der Applikationen von Menschen gebaut, die dies nicht hauptberuflich taten und sich für den jeweiligen Anwendungsfall verschiedener der angebotenen Technologien bedienten, um ihr Businessproblem zu lösen. Es ist nämlich nicht so, dass die oben aufgelisteten Programmiersprachen und Technologien jeweils für sich 100% aller Funktionen abdecken. Auch heute gibt es noch Beschränkungen, die es erforderlich machen, innerhalb von LotusScript auf JAVA oder Formelsprache-Funktionen zurückzugreifen.
Bei der Gestaltung von Anwendungen sah es meist nicht anders aus. Entwickler bedienten sich häufig bei den mitgelieferten Templates und erweiterten diese oder aber ließen ihrer Kreativität freien Lauf, was meist keine ganz so gute Idee war.
Eines der größten Probleme ist und bleibt aber, die Vermischung von Design und Business-Logik in Anwendungen, die den Notes-Client nutzen. Egal, ob wir über mehrere Seiten Quellcode hinter einem Button auf einer Maske sprechen oder komplexen Prozessen, die beim Verlassen eines Eingabefeldes gestartet werden. Eine derartige Code-Struktur erschwert es, die Applikation ohne Parallelentwicklung Nutzern per Web-Browser zugänglich zu machen.
Um zu verstehen, wieso Notes-Anwendungen häufig aussehen, wie sie aussehen und wie einige der Beschränkungen begründet sind, muss man zunächst einmal einen Blick zurück zu den Anfängen von Notes werfen.
So richtig los ging es mit Lotus Notes mit der Version 3.2 in Deutschland. Damals schrieben wir das Jahr 1993. Das Internet war noch kein Thema. Mit Notes verschickte man sich fast ausschließlich E-Mails innerhalb der eigenen Organisation oder aber Unternehmen, mit denen man als Lieferant oder Kunde eng zusammenarbeitete. Die Verbindung zwischen den Servern übernahmen Modems. Der amerikanische Online-Dienst (AOL) sollte erst noch einen Gateway-Dienst zwischen Lotus Notes und „diesem Internet“ auf den Markt bringen.
Die große Besonderheit von Notes war aber, dass „jede und jeder“ mit dem System eigene Applikationen entwickeln können sollte. Sozusagen die Geburt der „Low Code – No Code“-Entwicklung und dem „Citizen Developer“. Terminologien, die gerade in der jüngeren Vergangenheit wieder stark gehyped werden. Ob alle, die auf dieser Sau durchs Dorf reiten auch wissen, wer’s erfunden hat? Spoiler: Die Schweizer waren es nicht.
Zu dieser Zeit hieß Notes-Entwicklung: Man konnte Felder auf Masken platzieren, Ansichten gestalten und mit der Formelsprache vergleichbar zu Excel einfache Operationen durchführen. Der eine oder andere Pionier schaffte es auch, Formeln, die sich über mehrere DIN A4-Seiten erstreckten, zusammenzubauen. Wehe, irgendwo fehlte eine Klammer oder ein Semikolon....
Erst mit der Version 4 kam die erste „richtige“ Programmiersprache hinzu: LotusScript, eine sehr Visual Basic ähnelnde Sprache, die im weiteren Versionsverlauf immer mächtiger wurde.
Doch damit nicht genug: IBM spendierte Notes alsbald einen Web-Server (Domino), JAVA, eine halbherzige JavaScript und CSS-Implementierung für den Client und irgendwann dann die, von vielen wahlweise geliebten oder gefürchteten, XPages.
Auf der einen Seite haben wir Entwickler mit der Zeit immer mehr und komplexer werdende Werkzeuge an die Hand bekommen, auf der anderen Seite wurde ein Großteil der Applikationen von Menschen gebaut, die dies nicht hauptberuflich taten und sich für den jeweiligen Anwendungsfall verschiedener der angebotenen Technologien bedienten, um ihr Businessproblem zu lösen. Es ist nämlich nicht so, dass die oben aufgelisteten Programmiersprachen und Technologien jeweils für sich 100% aller Funktionen abdecken. Auch heute gibt es noch Beschränkungen, die es erforderlich machen, innerhalb von LotusScript auf JAVA oder Formelsprache-Funktionen zurückzugreifen.
Bei der Gestaltung von Anwendungen sah es meist nicht anders aus. Entwickler bedienten sich häufig bei den mitgelieferten Templates und erweiterten diese oder aber ließen ihrer Kreativität freien Lauf, was meist keine ganz so gute Idee war.
Eines der größten Probleme ist und bleibt aber, die Vermischung von Design und Business-Logik in Anwendungen, die den Notes-Client nutzen. Egal, ob wir über mehrere Seiten Quellcode hinter einem Button auf einer Maske sprechen oder komplexen Prozessen, die beim Verlassen eines Eingabefeldes gestartet werden. Eine derartige Code-Struktur erschwert es, die Applikation ohne Parallelentwicklung Nutzern per Web-Browser zugänglich zu machen.
Realitätscheck: Was ist dran an den Versprechen des Herstellers
Bereits in den ersten Jahren des aktuellen Jahrtausends wurden die Stimmen der Kunden immer lauter, die den Hersteller in der Pflicht sahen, dafür zu sorgen, dass die bestehenden Anwendungen Browser- und mobilfähig werden. Böse gesprochen erwartete man den „magischen Knopf“, der aus frühen Jugendwerken hippe Apps werden ließe, die selbst Steve Jobs hätten begeistern können.
HCL selbst bewegt sich seit der Übernahme des Software-Portfolios im Spannungsfeld der Erwartungen. Man möchte einerseits denjenigen Kunden gerecht werden, die über Jahrzehnte in die Plattform investiert haben und nicht mal eben alle Anwendungen darauf neu entwickeln können und andererseits dem Wunsch nach modernen Programmierwerkzeugen, die gerade von der jüngeren Entwicklergeneration bevorzugt werden, wobei Domino lediglich als Datenspeicher dient.
Den Bestandskunden werden mit den Nomad-Clients endlich Alternativen zum klassischen Notes-Client geboten. HCL verspricht eine Kompatibilität ohne Anpassungen im Web-Browser und mit nur minimalen Änderungen, die bei mobiler Nutzung, insbesondere auf dem Smartphone, erforderlich sind.
Jeder, der mal eine Notes-Applikation gesehen hat, bei der es sich nicht lediglich um eine Abwandlung der Doc-Library aus dem Lieferumfang handelt, weiß, dass das ziemlicher Nonsens ist. Und dabei sind nicht einmal die plattformspezifischen Einschränkungen gemeint, die das Arbeiten mit Datei-Attachments behindern.
Doch damit nicht genug: HCL hat sich auch daran versucht, den „magischen Knopf“ zu bauen. Das Feature dahinter nennt sich „Domino Restyle“ und bietet eine ganze Reihe von Optionen, um über bestehende Notes-Anwendungen ein einheitliches Design auszurollen. Vom Prinzip her funktioniert das Feature recht gut für weniger komplexe Anwendungen. Aber auch hier: Notes ist mehr als die, auf jedem Usertreffen zu Demozwecken herangezogene „Wine Tasting“ App.
Drittanbieterprodukte, die eine App-Modernisierung in Stunden statt Wochen versprechen, stehen im Allgemeinen auch nicht besser da, da auch diese Tools am Ende des Tages Jahre alten Quellcode beibehalten, häufig sogar vervielfältigen, was die Kosten für Wartung und Weiterentwicklung erhöhen wird.
Der Applikationsmodernisierungsansatz der GFI
Wir von der GFI verfolgen da einen anderen Ansatz. Eine Applikation, die fünfzehn oder mehr Jahre treue Dienste geleistet hat und weiter betrieben werden soll, hat eine ernsthafte Überholung verdient.
Dazu gehört auch, dass man zunächst einmal kritisch prüft, welche Funktionen, Felder, Auswertungen etc. überhaupt noch benötigt werden. Nicht selten wurden Dinge auf Wunsch einzelner handelnder Personen implementiert, die sich längst im wohlverdienten Ruhestand befinden und die seitdem nicht mehr verwendet werden.
Als Nächstes geht es daran, Wünsche an eine neue Version in konkrete Anforderungen zu verwandeln. Hier empfiehlt es sich, Poweruser recht früh bspw. in Workshops einzubinden und bspw. mit „Design Thinking“-Methoden losgelöst vom Ist-Stand die zukünftige Anwendung zu beschreiben. Auf jeden Fall sollten auch die Nutzungsszenarien thematisiert werden. Nicht alle Funktionen werden mobil, zumal auf einem Smartphone benötigt. Allerdings muss eine mobile Oberfläche darauf optimiert werden, dass Benutzer mit möglichst wenigen Klicks die für sie relevanten Informationen erhalten und eine Erfassung auch auf einem Touchscreen unfallfrei möglich ist.
Darüber hinaus sollte man ein Augenmerk auf mögliche „Quick wins“ legen, also jenen Features, die einer Vielzahl von Usern die Arbeit erleichtern. Dabei ist es ganz egal, um was es sich handelt. Sei es nun, dass man mit der, in einem CRM vorhandenen Auftragsnummer die SAP GUI so ansteuert, dass direkt dieser Beleg ohne umständliches Abtippen der Belegnummer geöffnet wird oder aber die Automatisierung von Datenimporten zeitgesteuert über eine Schnittstelle läuft, anstelle dass ein Nutzer eine Auswertung aus System A manuell ziehen und in System B manuell einlesen muss.
Großbaustelle: UI
Bei der Überarbeitung der UI stehen Notes-Entwickler vor besonderen Herausforderungen. Während die User inzwischen eine ganze Reihe von Web basierten Applikationen gewohnt sind, die sich darüber hinaus noch an unterschiedliche Bildschirmgrößen anpassen (Responsive Webdesign), ist man bei der Entwicklung von Notes-Anwendungen immer noch den Restriktionen des Notes-Clients unterworfen, insofern man nicht gleich auf die ausschließliche Nutzung des Webbrowsers setzt.
XPages können – auch für die Arbeit im Client – eine Alternative darstellen. Jedoch erkauft man sich diese Möglichkeit durch einen vielfach höheren Entwicklungsaufwand, der das, bei Notes so beliebte, Rapid Prototyping übermäßig erschwert.
Welchen Weg man am Ende wählt, hängt von vielen Faktoren ab. Hat man sich jedoch für die Arbeit mit den verschiedenen HCL Clients (Notes, Nomad Web, Nomad iOS/Android) entschieden, wird man auch heute noch mit einigen Einschränkungen leben müssen.
Zunächst einmal muss man einsehen, dass es recht wenig Sinn macht, einen wie auch immer ausgebildeten Designer mit der Gestaltung des UI zu beauftragen, der sich noch nie mit der Notes/Domino-Plattform und den verschiedenen Design-Elementen beschäftigt hat.
Für die aktuelle Version unseres CRM haben wir uns nach mehreren Anläufen mit teils frustrierenden Ergebnissen dazu entschieden, einem langjährigen Entwickler aus unserem Team die Aufgabe zu geben, ein neues UI für das Produkt zu entwickeln. Was zunächst mutig, wenn nicht gar übermütig klingt, war dann der Schlüssel zum Erfolg. Bereits der erste Entwurf begeisterte mit seiner Schlichtheit, Übersichtlichkeit und Aufgeräumtheit.
Saubere Codebase: Trennung von Design und Business Logik
Wie weiter oben bereits angemerkt, befindet sich „der Quellcode“ der bestehenden Anwendungen teilweise redundant und über viele Stellen verteilt.
Wie einfach eine Anwendung erweiterbar und mit wie wenig Aufwand eine Applikation wartbar ist, entscheidet sich recht früh in der Entwicklungsphase. Aus diesem Grunde haben wir uns eine einheitliche Codebase geschaffen, auf der sämtliche Neuentwicklungen basieren werden.
Den Kern bilden eine ganze Reihe von Bibliotheken mit nützlichen Funktionen. Sei es, um den Zugriff auf die Zwischenablage zu steuern oder um bspw. mit Dateianhängen in Notes-Dokumenten sinnvoll umzugehen. Diese Basisfunktionen sind so ausgelegt, dass man sie in jeder beliebigen Notes-Datenbank einfach zum Einsatz bringen kann.
Darauf aufbauend nutzen wir ein Framework, welches mit seiner Klassen-Struktur dabei hilft, Code je nach Einsatzort und -zweck, sinnvoll abzulegen.
Somit können wir sicherstellen, dass zum Beispiel der Austausch des Frontends (bspw. Webbrowser statt Notes-Client) mit sehr überschaubarem Aufwand pro Maske/Dokumentenart möglich ist.
Standardisierte Schnittstellen zu Produkten wie Microsoft Office oder SAP sorgen für geringere Wartungsaufwände. Bei einem Release Wechsel notwendige Anpassungen werden dann beispielsweise einmal im Kernel realisiert und stehen nach dem Roll-out allen anderen Applikationen zur Verfügung.
Fazit
Die Modernisierung bestehender Notes/Domino-Applikationen lohnt sich in jedem Fall. Wichtig dabei ist jedoch, dass man sich über die anfallenden Aufwände im Klaren ist. Mit der richtigen Strategie lassen sich, egal mit welchem Client, tolle Applikationen bauen, die auch in vielen Jahren noch sicher und stabil kritische Unternehmensprozesse abbilden können.
Bereits in den ersten Jahren des aktuellen Jahrtausends wurden die Stimmen der Kunden immer lauter, die den Hersteller in der Pflicht sahen, dafür zu sorgen, dass die bestehenden Anwendungen Browser- und mobilfähig werden. Böse gesprochen erwartete man den „magischen Knopf“, der aus frühen Jugendwerken hippe Apps werden ließe, die selbst Steve Jobs hätten begeistern können.
HCL selbst bewegt sich seit der Übernahme des Software-Portfolios im Spannungsfeld der Erwartungen. Man möchte einerseits denjenigen Kunden gerecht werden, die über Jahrzehnte in die Plattform investiert haben und nicht mal eben alle Anwendungen darauf neu entwickeln können und andererseits dem Wunsch nach modernen Programmierwerkzeugen, die gerade von der jüngeren Entwicklergeneration bevorzugt werden, wobei Domino lediglich als Datenspeicher dient.
Den Bestandskunden werden mit den Nomad-Clients endlich Alternativen zum klassischen Notes-Client geboten. HCL verspricht eine Kompatibilität ohne Anpassungen im Web-Browser und mit nur minimalen Änderungen, die bei mobiler Nutzung, insbesondere auf dem Smartphone, erforderlich sind.
Jeder, der mal eine Notes-Applikation gesehen hat, bei der es sich nicht lediglich um eine Abwandlung der Doc-Library aus dem Lieferumfang handelt, weiß, dass das ziemlicher Nonsens ist. Und dabei sind nicht einmal die plattformspezifischen Einschränkungen gemeint, die das Arbeiten mit Datei-Attachments behindern.
Doch damit nicht genug: HCL hat sich auch daran versucht, den „magischen Knopf“ zu bauen. Das Feature dahinter nennt sich „Domino Restyle“ und bietet eine ganze Reihe von Optionen, um über bestehende Notes-Anwendungen ein einheitliches Design auszurollen. Vom Prinzip her funktioniert das Feature recht gut für weniger komplexe Anwendungen. Aber auch hier: Notes ist mehr als die, auf jedem Usertreffen zu Demozwecken herangezogene „Wine Tasting“ App.
Drittanbieterprodukte, die eine App-Modernisierung in Stunden statt Wochen versprechen, stehen im Allgemeinen auch nicht besser da, da auch diese Tools am Ende des Tages Jahre alten Quellcode beibehalten, häufig sogar vervielfältigen, was die Kosten für Wartung und Weiterentwicklung erhöhen wird.
Der Applikationsmodernisierungsansatz der GFI
Wir von der GFI verfolgen da einen anderen Ansatz. Eine Applikation, die fünfzehn oder mehr Jahre treue Dienste geleistet hat und weiter betrieben werden soll, hat eine ernsthafte Überholung verdient.
Dazu gehört auch, dass man zunächst einmal kritisch prüft, welche Funktionen, Felder, Auswertungen etc. überhaupt noch benötigt werden. Nicht selten wurden Dinge auf Wunsch einzelner handelnder Personen implementiert, die sich längst im wohlverdienten Ruhestand befinden und die seitdem nicht mehr verwendet werden.
Als Nächstes geht es daran, Wünsche an eine neue Version in konkrete Anforderungen zu verwandeln. Hier empfiehlt es sich, Poweruser recht früh bspw. in Workshops einzubinden und bspw. mit „Design Thinking“-Methoden losgelöst vom Ist-Stand die zukünftige Anwendung zu beschreiben. Auf jeden Fall sollten auch die Nutzungsszenarien thematisiert werden. Nicht alle Funktionen werden mobil, zumal auf einem Smartphone benötigt. Allerdings muss eine mobile Oberfläche darauf optimiert werden, dass Benutzer mit möglichst wenigen Klicks die für sie relevanten Informationen erhalten und eine Erfassung auch auf einem Touchscreen unfallfrei möglich ist.
Darüber hinaus sollte man ein Augenmerk auf mögliche „Quick wins“ legen, also jenen Features, die einer Vielzahl von Usern die Arbeit erleichtern. Dabei ist es ganz egal, um was es sich handelt. Sei es nun, dass man mit der, in einem CRM vorhandenen Auftragsnummer die SAP GUI so ansteuert, dass direkt dieser Beleg ohne umständliches Abtippen der Belegnummer geöffnet wird oder aber die Automatisierung von Datenimporten zeitgesteuert über eine Schnittstelle läuft, anstelle dass ein Nutzer eine Auswertung aus System A manuell ziehen und in System B manuell einlesen muss.
Großbaustelle: UI
Bei der Überarbeitung der UI stehen Notes-Entwickler vor besonderen Herausforderungen. Während die User inzwischen eine ganze Reihe von Web basierten Applikationen gewohnt sind, die sich darüber hinaus noch an unterschiedliche Bildschirmgrößen anpassen (Responsive Webdesign), ist man bei der Entwicklung von Notes-Anwendungen immer noch den Restriktionen des Notes-Clients unterworfen, insofern man nicht gleich auf die ausschließliche Nutzung des Webbrowsers setzt.
XPages können – auch für die Arbeit im Client – eine Alternative darstellen. Jedoch erkauft man sich diese Möglichkeit durch einen vielfach höheren Entwicklungsaufwand, der das, bei Notes so beliebte, Rapid Prototyping übermäßig erschwert.
Welchen Weg man am Ende wählt, hängt von vielen Faktoren ab. Hat man sich jedoch für die Arbeit mit den verschiedenen HCL Clients (Notes, Nomad Web, Nomad iOS/Android) entschieden, wird man auch heute noch mit einigen Einschränkungen leben müssen.
Zunächst einmal muss man einsehen, dass es recht wenig Sinn macht, einen wie auch immer ausgebildeten Designer mit der Gestaltung des UI zu beauftragen, der sich noch nie mit der Notes/Domino-Plattform und den verschiedenen Design-Elementen beschäftigt hat.
Für die aktuelle Version unseres CRM haben wir uns nach mehreren Anläufen mit teils frustrierenden Ergebnissen dazu entschieden, einem langjährigen Entwickler aus unserem Team die Aufgabe zu geben, ein neues UI für das Produkt zu entwickeln. Was zunächst mutig, wenn nicht gar übermütig klingt, war dann der Schlüssel zum Erfolg. Bereits der erste Entwurf begeisterte mit seiner Schlichtheit, Übersichtlichkeit und Aufgeräumtheit.
Saubere Codebase: Trennung von Design und Business Logik
Wie weiter oben bereits angemerkt, befindet sich „der Quellcode“ der bestehenden Anwendungen teilweise redundant und über viele Stellen verteilt.
Wie einfach eine Anwendung erweiterbar und mit wie wenig Aufwand eine Applikation wartbar ist, entscheidet sich recht früh in der Entwicklungsphase. Aus diesem Grunde haben wir uns eine einheitliche Codebase geschaffen, auf der sämtliche Neuentwicklungen basieren werden.
Den Kern bilden eine ganze Reihe von Bibliotheken mit nützlichen Funktionen. Sei es, um den Zugriff auf die Zwischenablage zu steuern oder um bspw. mit Dateianhängen in Notes-Dokumenten sinnvoll umzugehen. Diese Basisfunktionen sind so ausgelegt, dass man sie in jeder beliebigen Notes-Datenbank einfach zum Einsatz bringen kann.
Darauf aufbauend nutzen wir ein Framework, welches mit seiner Klassen-Struktur dabei hilft, Code je nach Einsatzort und -zweck, sinnvoll abzulegen.
Somit können wir sicherstellen, dass zum Beispiel der Austausch des Frontends (bspw. Webbrowser statt Notes-Client) mit sehr überschaubarem Aufwand pro Maske/Dokumentenart möglich ist.
Standardisierte Schnittstellen zu Produkten wie Microsoft Office oder SAP sorgen für geringere Wartungsaufwände. Bei einem Release Wechsel notwendige Anpassungen werden dann beispielsweise einmal im Kernel realisiert und stehen nach dem Roll-out allen anderen Applikationen zur Verfügung.
Fazit
Die Modernisierung bestehender Notes/Domino-Applikationen lohnt sich in jedem Fall. Wichtig dabei ist jedoch, dass man sich über die anfallenden Aufwände im Klaren ist. Mit der richtigen Strategie lassen sich, egal mit welchem Client, tolle Applikationen bauen, die auch in vielen Jahren noch sicher und stabil kritische Unternehmensprozesse abbilden können.
Marc-Oliver Schaake
Geschäftsführung - Consulting - Projektmanagement - Development
Lotus Notes Consultant & Entwickler seit 1995- SAP to Notes-Projekte
- Verantwortlich für Produktentwicklung