Modernizing Notes applications - lessons from the trenches
Not only since mobile first became fashionable corporations are trying to ditch the Lotus IBM Notes client - for various reasons.
These efforts were branded " modernization", " web enablement", " mobile enablement" or if a competitor had a word " migration". Initially there was hope that this would be a short, painless and automated process (the upgrades, not the migrations that is). But reality taught a few facts that you need to consider: wipe them out, all of them modernize them all in one go (it is called economy of scale).
Nathan and Peter share a video, the modernization of the nifty-fifty, a recent case study and the service offering. Go check them out.
The biggest issue I see with this approach is the usual cautious stand in IT today:" let us do one (insignificant) application first and see how it goes. Then we linearly extrapolate and get scared" That is the total opposite of Asymmetric Modernization, so it will require clever persuasion to get a project approved.
As usual YMMV
These efforts were branded " modernization", " web enablement", " mobile enablement" or if a competitor had a word " migration". Initially there was hope that this would be a short, painless and automated process (the upgrades, not the migrations that is). But reality taught a few facts that you need to consider:
- A Rich Client is based on RichText, a browser client on HTML. There is no 1:1 mapping (otherwise one format would be superfluous), only some approximation (just ask Ben about it). Much more: there is no 1:1 mapping of the event models and APIs. So any automation would lead to incredible hacks
- The Notes client's and Domino server's LotusScript runtimes are, while dated, incredibly robust and forgiving. The amount of OMG code I've seen in Notes applications (including my own
) tops any other platform.
Still that code gets the job done and out of the way. However that doesn't translate into another language in an automated fashion, but rather demands the repayment of quite some technical debt - Code that gets a client with one user huffing and puffing can't simply be expected to run for hundreds or thousands of users on a single server
- Users expect web (and mobile) applications to be fresh and modern. If Jack Sparrow couldn't find the fountain of youth, how can an automated tool do that?
This is a clear conflict of interest between the users ("shall be modern and fresh") and the ones paying for it ("make it work in a browser, fast & cheap") - a classic for Why enterprise software sucks
John D. Head clearly outlines expectations and possibilities for modern user interfaces. Teamstudio provides a nice set of modern mobile controls (that even work offline for a fee) - The amount of Notes applications mostly get underestimated greatly. Use a scientific method to create evidence
Nathan and Peter share a video, the modernization of the nifty-fifty, a recent case study and the service offering. Go check them out.
The biggest issue I see with this approach is the usual cautious stand in IT today:" let us do one (insignificant) application first and see how it goes. Then we linearly extrapolate and get scared" That is the total opposite of Asymmetric Modernization, so it will require clever persuasion to get a project approved.
As usual YMMV
XPages application in a browser
XPages application on a tablet
XPages application mobile phone view
Posted by Stephan H Wissel on 09 May 2013 | Comments (5) | categories: XPages
We're mobilising small applications in minutes and for a complex CRM-System (15 databases)we only needed 3 days to have all you CRM-data on your mobile device
But you can reduce your development time.
Our target is not to move application 1:1. We really want to modernize them by moving them to a webbased Xpages-frontend.