Domino Applications in the New World of HCL Nomad Web

HCL Nomad Web is a completely new way for customers and their user base to interact with applications in their Notes/Domino environment. Everything is affected from clients to servers and the network in-between.

Some of the changes are tasks for the IT teams as SafeLinx brings a new component into your IT infrastructure. Others, influence the way your user base accesses their data. As a great benefit, comes the opportunity to run without a traditionally installed Notes Client when you are utilizing what Nomad Web has to offer.

No matter how you turn it, this new technology brings transformation. And with this transformation comes the opportunity to consolidate. To look at the infrastructure that was built for challenges of a different time and assess what is still needed. What should my network and server infrastructure look like? What happens to my applications if I consolidate servers? Which applications are still relevant in today’s business processes? And what deadwood should have been removed long ago?

The topic of “considering what is still valuable” in your application landscape becomes even more pressing if we consider that Nomad Web also brings limitations with it: no client-side Java, no XPages, no use of OS calls, or file system interaction just to name a few. A more comprehensive list can be found in HCLs Documentation about “HCL Nomad for web browsers – Limitations“.

The question now is: “What is worth bringing along and how much will it cost?”

Not considering this can have disastrous effects in business processes depending on functionality provided by Notes applications. Investing resources in irrelevant applications is also something that find customers desperately trying to avoid.

In this context we have found that understanding, tracking, and acting on a set of KPIs is what helps our customers to decide how to use their resources most effectively. These KPIs are generated by evaluating a set of questions and data analysis techniques we want to outline here.

We found with many customers that assuming you know which applications are relevant is a great recipe to overlook important components. The same goes for just treating everything as part of the project. The weeding out of system databases, directories, mail files, mail archives, roaming components, 3^rd party applications, and in general pieces that simply make your Domino server work without providing benefits and functionality to the business will leave you with a set of applications that are worth considering for your project.

That’s one of the most frequently asked questions we have on our table. And now that we have our project focused on the real applications it makes sense to look at the answers. Applications that haven’t been accessed in over a year are in general a good candidate for sunsetting. Everything with a shorter inactivity period may still be a seasonal database that may only be used once a year for example during the end of the fiscal year. That is what makes it so important to monitor usage continuously and look at available activity history. A simple snapshot over a few weeks is simply not enough to make effective decisions. Apart from the question of effectiveness, there is always the big goal of avoiding risk to important business processes. You don’t want to be responsible for freezing the ability to work in one of your profit centers.

In order to avoid the risk of impacting critical applications, you have to find an approach to understanding what is important for each business unit. Learning who creates content in a database and who reads this information gives you the ability to not only approach the right departments when it comes to transforming applications to work with a future target platform. It also gives you the ability to assign cost centers to the efforts required to potentially re-develop an application to make it future-proof.

This is the next logical step at your Nomad Web journey. For some applications that will be relatively easy. As long as you keep the templates up to date, everything based on standard templates should be future-proofed by HCL for you. For most customers that should already be a considerable portion of frequently used applications like File Libraries, Team Rooms, etc. The remainder are applications with custom development, where compatibility and potential roadblocks in source code and design need to be evaluated.

This step is necessary to understand how much remediation effort is required. The classic way to approach this task would be to ask your development team to inspect databases for potential issues. Depending on the size of your environment that can be the easiest and quickest way to go. As long as you have the manpower to do so. In many situations though, we find that the required manpower is simply not there anymore. Development teams aren’t as big as they used to be and rarely are the developers still available who have high familiarity with why things were coded the way they are.

An approach to solve this issue is the use of 3^rd party solutions like panagenda iDNA. It not only provides usage information but also scan and inventory the entire code base. These solutions allow you to use a central code repository to identify these patterns and function points which may lead to issues. In addition, they can give insight into code duplication in your environment. It is a big difference if you analyze and re-develop a code block once and then deploy it to 19 other DBs with the same code block. Or if you have to analyze 20 DBs individually, just to find that code blocks are identical.

At the end of the day, it will be an ongoing process. With many iterations and constant refinement around these key tasks: