Specifications

Lotus Redbooks Wiki – IBM Lotus Notes and Domino V8.5 Deployment Guide
46
From a similar perspective, you should consider your application servers carefully. In some ways, your
application servers are more difficult to assess than your mail servers because of different usage patterns
and differences in application design. However, many of the same things should be assessed in your review.
Information to collect while assessing your application environment includes:
• List of all application servers in your environment
•
List of any mixed-use servers (mail and application)
• Locations of critical and enterprise-wide applications
• List of servers dedicated to a specific application
• Inventory of all non-mail applications
• Usage patterns
• Critical and enterprise-wide applications
• Application servers
• Use of Web applications
• HTTP
• SSL
• RSS
• Replication topology
• Attachment handling
• Any specialized functions or features used by applications
• Backup methodology
• Dependencies between databases in complex applications (such as lookups)
• Use of applications to send mail
Using the database catalog on your application servers, or on any server on which you allow users to create
databases, is a good way to develop your application inventory. The catalog also provides information such
as ACL listings and information about reads and writes on the database. Additionally, you can redirect the
output of a directory list command on the operating system to develop a list of all databases and applications
on your servers.
Because of the varied nature of applications, there may well be other concerns as well. It is important to
work closely with your development teams to gain a full understanding of your application environment.
Historically, upgrading a Notes/Domino environment have had minimal impacts on existing Notes
applications. While trying to provide improvements based on widely adopted open standards, keeping
backward compatibility has always been very important. But just like for the messaging, applications need to
be properly planned as well during an upgrade.
First, we can start thinking about applications from the outset. There's a lot of work that can be done prior to
the actual upgrade. You will need all the details of your existing applications when discussing requirements
and architecture.
You can start by doing an inventory of your applications. Leverage this opportunity to clean up your
environment of unused applications. During this process, gather the following information:
•
Application owner(s)
•
User population using this application (executives, managers, departments or the entire
organization)
• Type and level of complexity of the application (template-based, custom, back-end connectivity and
integration)
• Importance of applications (mission-critical, company-wide, departmental, financial, data repository,
etc)
• Existing Issues – This will avoid any blame on the upgrade if it was already broken
Then, you will need to determine what you will do with them. Some applications might be simple enough to
upgrade their design directly, while others might require more testing and fixing their existing issues before