Modernization is a journey, not a destination.
This topic has been on my company's radar for a little while now. A few months ago, we started the implementation process to migrate to a new ERP package, which fell in line with a POWER8 upgrade. This is quite a major overhaul of core systems and will continue well into the year. I'm sure I'll have tales of ERP project pitfalls and successes over the coming months, so stay tuned for that.
The Notes Browser Plug-in is another solution that has gained some traction because it essentially replicates all Notes functions inside the browser. This solution got the biggest applause by the way when it was announced at Lotusphere a few years back, a mere 90 minutes into the opening general session. The problem with that solution is it's hardly a plug-in. Plug-ins aren't hundreds of megabytes in size. You install the plug-in like a client, except you actually use the browser instead of the client. Calling the Notes Browser Plug-in a plug-in is akin to calling The Godfather a commercial.
Now with the coming IBM Verse product, it appears that IBM's focus is on the browser, not the IBM Notes client. Customers and partners have been told to get used to seeing their mail in the browser, because that's where Verse will be delivered. The strategy for the client apps is the Notes Browser Plug-in.
With that being said, we had a decision to make for custom application development that mostly revolved around Notes technology. We could have either gone the Xpages route, which entailed keeping our data inside an NSF database, or done something entirely different and rewritten applications in another language. In the end, we chose to use PHP with Zend Server and tie into DB2 for i. The reason we didn't use Xpages was not the learning curve of the languages but to bring someone up to speed quickly in terms of Domino development. If we have developer turnover, in my opinion it's much easier to bring someone in to maintain PHP code than to replace an Xpages developer. There are some nuances with DB2, just like any other database, but we have a lot of in-house DB2 skill who can fill the gap. Of course, your shop may be able to take Xpages and the Notes Browser Plug-in to make a workable, supportable solution. For us, it just doesn't work that well. More power to you.
This is not to say that the Notes client is going away any time soon. I haven't heard anything of the sort. What I am hearing is the strategy. That strategy doesn't have Notes at the top of the list. With Verse, what you have is a completely online email experience. One of the great features about a client like Notes is that you can take it offline. Until IBM comes out with a solution to an executive who pops his head in my office door asking how he can work on emails offline with Verse, then I'll be skeptical. This is a major stumbling block for product adoption if Verse will eventually eclipse Notes down the line.
While the "Internet of everything" is an end game, we're a ways off. Many commercial flights still don't offer Wi-Fi. Only 1,800 planes in the U.S. and Canada have Wi-Fi service. Given that there are roughly 8,500 planes total, we have a long way to go before we're always connected. That doesn't solve the problem for the executive who doesn't get good coverage while at the lake cabin. Or the executive who likes the blazing speed of an offline mail replica. The need to be offline with Verse is still a problem that needs to be solved, and that may still be Notes.
The great news is that IBM Domino will be a component of Verse. To what degree is still a bit of a mystery, and nothing on-premises is going to be available to download for a while.
We still use and plan to use Domino for vendor-supported applications, mail, LDAP, Traveler, Sametime, and all the other good stuff Domino does well. Let the vendors worry about modernizing their own products. It was just the custom application modernization that really needed a new direction.
People struggle with a similar challenge today with RPG applications on IBM i. I think this challenge is a little different because RPG depends on nothing but the IBM i operating system, as the language is not deeply tied to a client. One of the challenges for RPG shops is finding RPG programmers to maintain existing systems. It's certainly true that many universities don't teach RPG, but if we've invested in RPG and plan on investing in modernizing RPG, then I think what we need to be doing is telling local colleges we need modern RPG programmers. They're not going to be teaching languages that aren't in demand. We also need to be telling our colleges we need people with experience using RDi, not SEI. IBM's Academic Initiative is doing a good job, but we need to be augmenting that with our own efforts of promoting RPG as a very much alive and in-demand language, along with IBM i as a modern platform. We need to be modernizing our RPG to completely free-form so that we don't need to worry about finding RPG programmers who know what a C-spec is or have to explain the concept of an indicator.
While RPG does business logic like nobody's business, we also need to be investigating other languages that do have support on IBM i. We can't rely on RPG as the only tool in our arsenal. If so, we're setting ourselves up for a rougher ride than we have to take. IBM i has allowed us many options for development, especially in the last five years. We need to be expanding our horizons with more open tools to ensure we're not solely bound by reliance on any one framework or language.