Previous Page TOC Next Page



— 5 —


Building a Deployment Plan


This chapter covers the fundamentals of planning for a Notes installation. The text gives you the ammunition to take to your manager or executive to get the time up front for the necessary planning. This chapter shows you what is involved in a typical deployment plan; the next chapter shows you how to customize each of the steps in this typical deployment plan.

To a project manager responsible for installing Notes, a deployment plan should be like a soldier and his rifle; you should never be without one. A deployment plan is your overall plan for designing/installing/configuring Notes.

Why build a deployment plan? You're busy. Your users are busy. Maybe you've never done a Notes installation and don't know what to plan for anyway (and consultants are so expensive).

Wrong. Planning saves money. Planning saves time. You will save time and money by planning ahead, even if it means bringing in a consultant. All Notes installations, large or small, should go through the steps outlined here and in Chapter 6, "Customizing Your Deployment Plan."

You build a deployment plan because there is no other way to build an accurate budget and schedule. If you happen to work in an organization that has the luxury of working without budgets and schedules, then you should consider the headaches that you can avoid for yourself and others by doing a little planning. Every organization should plan its Notes installation regardless of the current workload, urgency, or corporate culture. In short, develop a deployment plan before installing Notes in a production environment. This chapter shows you the basic steps you should follow when deploying Notes. Each deployment will have some unique needs. Chapter 6, "Customizing Your Deployment Plan," shows you how to customize a deployment plan for your organization.

Notes is a client/server product. A deployment plan for Notes resembles a deployment plan for any other client/server system. As with any client/server system, you install the servers before installing the clients, you assign user IDs and passwords, and you need to have a help desk available to answer questions. If your organization has already been through a major client/server deployment, the lessons learned there will apply to a Notes deployment. The major difference involves the impact Notes has on the working relationships within an organization.

Most organizations that have difficulty deploying Notes have not properly prepared. Behavioral and cultural barriers can block the successful adoption of Notes. For Notes to be successful, people must share information with each other and with other departments. In organizations that reward individual performance, this cooperation can be a difficult goal to achieve. In many organizations, information is power; sharing information can mean a loss of power. People will simply refuse to use Notes if it means losing power. Simply providing training is not enough; many organizations will need to change policies regarding performance appraisals and pay. We cannot stress this enough: Pay attention to the people within your organization. The people who will use Notes will determine the success or failure of Notes.

Studies clearly show that your chance for success increases for projects that are well connected. Make sure your Notes project team

Just to emphasize the importance of planning, we start out with some common nightmare scenarios.

Ways to Fail


Don't say you've never been warned. Planning saves time. Planning saves money. You are NOT too busy to plan. Nonetheless, it's an easy step for many people to skip , because the pain comes later. What can you expect if you fail to plan your Lotus Notes deployment or if you do a poor job of it? We will discuss a few of the common scenarios that will lead you down the path to disaster with Lotus Notes.

Failure 1: Multiple Isolated Pilots


In large organizations, controlling (or even influencing) the actions of independent business units or departments is extremely difficult. The press is full of articles about Lotus Notes, and it is quite natural for more than one department within an organization to be researching Lotus Notes. As these research projects become pilots and get rolled out into production usage, you end up with multiple, isolated islands of Lotus Notes within an organization. You are then faced with the difficult task of reconciling all the different domains, naming conventions, network selections, and operating systems utilized in the various pilots. More than likely, the domains never will be completely reconciled, leading to permanently higher administration costs associated with administering multiple domains.

Having multiple isolated pilots also tends to waste dollars on Notes licenses. You lose the ability to buy in bulk and get your volume discount.

To avoid the isolated pilots syndrome, you need to widely publicize the "officially blessed" Notes pilot. Communicate the advantages of rolling up other pilots into the officially blessed one, as well as the advantages of waiting for the rollout of the blessed pilot. Corporate newsletters, department meetings, and e-mail are typical ways of publicizing your official Notes pilot. You should try to reach anyone with the power and budget to set up an independent Notes pilot. This usually includes all departmental managers throughout the organization. Usually, communicating the bottom line (saving on administration costs and Notes licenses) is enough. If you need to get into the more esoteric advantages of integrating efforts with the rest of the organization, then you probably have already lost the battle.

You can lower resistance to the official pilot if you make it easy for other unofficial pilots to join up. One way to do this is to establish a corporate owner to serve as a clearinghouse for naming standards, certificates, and the Public Address Book. The corporate owner does not control these independent pilots, but does make it easy for the official pilot to control those aspects of Notes (naming, security, standards) that can get out of hand. Over time, many unofficial Notes pilots will find it easier to combine forces with the official pilot rather than continue to manage an independent Notes network.

Failure 2: Lack of Training


Parts of Notes resemble other products that are already on the market. If you do a poor job of training—or no training at all—people will interpret Notes based on product(s) with which they are already familiar. It is extremely common for end users to look at Notes as a very large—but not particularly fancy—e-mail package.

You need to plan training for administrators and application developers. Don't rely solely on on-the-job training. Notes is not just an extension of traditional IS systems. Notes represents a new kind of application, which can lead to a long learning curve for untrained personnel. If you don't properly train administrators and application developers, they will have poor productivity during an extended learning curve. You also risk permanently higher costs supporting poor applications developed during the learning phase. The largest cost associated with skipping training is lost opportunities. Properly trained users, administrators, and application developers generate fresh, creative ways to use Notes. Untrained personnel will be frustrated, wondering what the big deal is.

Users require training in Notes and possibly in a new operating system. Deploying Notes is not the same as deploying a spreadsheet or word processing program. Notes is a systems product, not a finished application. It is more complex and requires more training than a word processor or spreadsheet.

Failure 3: Growing Too Fast


The most common way that Notes projects fail is that they grow faster than the IS organization can support them. Initial successes generate a huge demand for new applications. After Notes is installed, ideas for new applications are generated every day. Business units waiting for Notes wonder why IS cannot just install Notes everywhere. Why should they wait? The pressure on IS to step up the number of installations can result in some poor decisions. Don't install more Notes clients than your support organization is ready to handle! Unsupported users can quickly lose enthusiasm. Once that enthusiasm is lost, it's difficult to regain it.

Avoid growing pains by designing your Notes network to support the entire organization. This strategy lays the base for installing Notes quickly when business demand kicks in. Plan big when deploying Notes. Underestimating the work to be done can cause you to have an overloaded staff.

Failure 4: The IS Organization Fails to Respond Adequately


The IS organization within many corporations is threatened by Lotus Notes or doesn't understand Lotus Notes very well. When there is a lack of leadership from the IS organization, business units step in and develop their own solutions. One of the bugaboos of Notes is that almost any organization can set up a small network with a few simple applications. A common result of these "roll-your-own" mini-Notes networks is poorly implemented applications that don't scale to large numbers of users. Little thought is given to the underlying network, meaning that fewer users and applications can be supported. Even if these independent business units manage to develop a popular application, it fails when an attempt is made to let large numbers of people use it. For example, an application that makes heavy use of agents can be great when only a few users access a database. When hundreds or thousands of people create their own agents, the database cannot carry the load. You could end up with a set of daily agents that take more than a day to run.

These applications also tend to be difficult to change. The application often needs to be rewritten when incorporating simple changes. This costs money and leads to frustrated users. Once the precedent of allowing these applications to be developed is set, it will be difficult to stop. We'll let you explain to these cowboy developers (ever so politely) that their applications are no good.

You also lose the opportunity of buying Notes licenses in volume in this scenario.

Failure 5: Failure to Set Standards


Control is a fundamental cultural issue within many corporations. Power means having a clearly defined turf. This leads to problems with Lotus Notes. Managers are reluctant to give up control over information and control over application development. With Notes, users and IS staff both have the ability to develop applications (except for desktop licenses). IS, the traditional home of application development, may view letting users develop applications as a loss of power. IS staffs should develop guidelines for Notes application development. The two ends of the spectrum are complete control (everything must pass strict standards) and complete chaos (anything goes). Most companies end up somewhere in the middle. Users can develop their own applications but are subject to some simple standards, while the IS staff controls the Notes servers and charges business units a small fee to house their applications. Address this issue early on—before you actually roll out any production applications.

You must have standards in place for screen design and for field naming, and you need to set some guidelines for which applications will be subject to these standards. Mission-critical applications should be tightly controlled, while departmental applications require less control (for example, less testing required, no enforced color scheme). Discussion databases for small projects may only need to be based on a common template.

One way to approach the standards issue is to divide applications into three categories:

Obviously, more control is required for Enterprise/Strategic applications than for Departmental or Personal applications. Only you can decide which applications fall into which category.

Once Notes applications have been rolled out without using any standards, you can't go back. You cannot enforce standards after the fact, and you will have a very difficult time getting people who have been used to total freedom to follow new standards. If you don't enforce standards early on, you will have applications that don't cross platforms, that have crazy selections for colors and fonts, and that don't integrate with IS systems. You will end up with many slight variations on common themes, causing confusion among your users, and you will lose the ability to generate a common look and feel for your key corporate applications.

Failure 6: Assuming That Application Development Is Easy


Forget the myth that developing Notes applications is trivial. It is true that an intelligent person who has had exposure to simple application-development tools for about half an hour can build his first simple discussion database. It is also true that Notes is a true rapid-application-development environment. Notes has integrated user interface development, networking, and database-development capabilities, enabling anyone to quickly "throw together" functioning applications. The ease and speed of developing a Notes pilot leads to the expectation that all Notes application development is trivial. But quick does not equal easy!

There are several mine fields along the way that will only become evident when you try to scale these applications and roll them out to multiple business units. Notes is most useful when coordinating the activities of multiple groups. A good Notes application reconciles the needs of many groups; integrating functionality from multiple groups into a functioning application requires experience. Your application developers should at least have experience in client/server and end-user interface development.

Developing client/server applications that can scale from hundreds to thousands of users requires special knowledge. Building applications that minimize administration costs requires planning. You should dispel the myth that Notes development can be done by anyone. Reasonable guidelines controlling Notes application development can help educate users about the steps involved in developing and maintaining complex applications.

Now that you know the consequences of poor planning, you should be able to convince your management to build in some time and money for planning. If you follow the deployment plan outlined here, you will maximize your chances of avoiding these problems.

Developing a Deployment Plan


This section gives an overview of the typical steps in a Notes deployment. Remember, there is no single right way to deploy Notes. You still have work to do in planning out your Notes deployment. Even small organizations should follow every step here.

Deploying Notes is similar to deploying other client/server systems products. The same level of detailed planning is required, and the progression of the deployment plan is similar. You start by setting some goals, then do some design work, staff a support center, train users, pilot some applications, and repeat. A Notes deployment cycles through a series of planning/doing loops. Start by forming a project team. They plan a set of applications. The applications are built and deployed. Feedback is gathered and used to plan the next phase. Every cycle should be no more than six months.

Your plan will be greatly influenced by the size of your ultimate planned installation. If your goal is an enterprise-wide installation, you don't necessarily take the same approach as if you are only planning a departmental installation. For example, Notes e-mail becomes critical when planning an enterprise-wide installation. You need to be far more concerned about user naming and e-mail reliability with an enterprise installation than with a departmental installation. In a departmental installation, the chance of having duplicate names is low, and there are easy-to-use backups (phone, sneakernet) should e-mail go down for an afternoon.

Be sure that you plan for the number of users to grow to 200% of the initial pilot over the first year. You will pilot the application to a small number of users—typically a work group. You will use everything you learn during the pilot to change and update all of your processes, training, etc., for the initial rollout. That pilot step is extremely important! Therefore, choose that first application very carefully.

Following are the steps involved in a Notes deployment:

  1. Form a project team.
  2. Assess the enterprise.
  3. Define the scope of your deployment.
  4. Design your notes network.
  5. Create a Notes support organization.
  6. Develop your standard operating procedures.
  7. Build the pilot application.
  8. Implementation and training.

This chapter lays out the concepts common to most installations. Chapters 6-9 provide more detail on carrying out the steps discussed here.

Step 1: Form a Project Team


You need to involve everyone who will be affected by the Notes deployment as early as possible. We recommend forming a project team to lead the efforts. You should have

Chapter 8, "Preparing Your Organization," covers the responsibilities assigned to each role. Some people may fill multiple roles. For example, in many small organizations one person plays the role of administrator, database manager, and application developer (we're not recommending this, but it is somewhat common). If you cannot identify all team members at the beginning of the project, add them to the group as soon as possible. For a small organization, the project team may be three or four people, with only one or two full time. For a large corporate rollout, we recommend a team of ten people essentially full time over the course of the initial deployment (6 to 18 months).

Exit criteria: When each role has been assigned to a person, step 1 is done. It is possible to advance to step 2 while some support roles have not been assigned. Make sure that you have a project manager and experienced application developer before advancing to step 2.

Step 2: Assess the Enterprise


You need to assess both the organizational and physical readiness of your organization. You need to assess the culture, skills, and policies throughout your organization to identify future roadblocks. You need an accurate inventory of the current network and workstations installed to plan the upgrades needed.

Cultural Readiness

The first action your project team needs to take is to review your organization's decision to use Notes. Ask yourself these questions (and more!):

When you know your general goals, draw up a chart showing potential applications by department. For each department, assess the department's readiness for the applications. We recommend having several half-day sessions with groups of five to eight people that will be affected by the Notes rollout. Include people from different departments in a single session. These sessions should include at least one experienced Notes application developer to give some feedback on what is attainable in what time frame.

You may recognize this technique as a variation of the joint application design (JAD) technique pioneered many years ago inside IBM for use on key application-development projects. JAD is a proven technique for discovering requirements and solutions quickly. Use JAD sessions to lay out the issues and get preliminary decisions made. There are whole weeklong trainings on JAD sessions, so we won't be able to provide a complete description here. Following are some key points regarding JAD sessions:

Be sure to get an experienced moderator for your JAD sessions. The moderator must keep the meeting on track. A good moderator knows when to cut a conversation short and can get everyone to contribute. The scribe is responsible for taking all notes. If possible, the scribe should be taking notes on a blackboard or overhead so that everyone can see the notes. This enables a person to see that his ideas are being accurately reported. The moderator and scribe should not be adding content to the meeting. A good moderator can make the difference between a successful and wasted session. There are several consulting groups, possibly within your organization, where you can get experienced moderators for these design sessions.

Holding these preliminary sessions is an extremely important step in the Notes deployment plan. Notes has the potential to change the culture within organizations, affecting the whole enterprise. You need to get at the underlying issues, fears, and considerations as early as possible. Before holding your JAD sessions, pass out a report/questionnaire containing an overview of the Notes project, the applications being considered, and the possible impact on the company. You should consider highlighting how Notes is being used in other companies. A short testimonial from your CEO couldn't hurt. Explain the goals for the meeting specifically. Your Notes deployment will not be successful without "buy-in" by all participating members. Addressing all concerns helps to build the momentum necessary for enthusiastic cooperation.

After getting everyone's issues and comments on the table, the project team should choose an application and a department for the initial pilot. Before building large-scale production applications, build a small but useful application. This pilot application should be important to the business and not time critical.

The pilot application is a critical choice. Success or failure with the pilot can set the tone of your Notes deployment. Many organizations begin with a few discussion databases. We don't recommend choosing a discussion database as the pilot application. There just isn't enough depth to a discussion database to provide a learning experience for the project team. Develop some discussion databases for use by the team during the rollout, but don't choose a discussion database as the pilot application.

After choosing a pilot application, the team should decide on some success criteria. How will you measure a successful pilot? A successful deployment? Common answers to these questions involve reducing cycle times and lowering costs. If you want to make some before/after comparisons, the team will need some baseline measurements before rolling out Notes. Many organizations don't define specific success criteria. These organizations rely on anecdotal success stories related to the Notes deployment as the measure of success. Either method, before/after measurements or anecdotal stories, can work, depending on the culture within an organization.

Physical Readiness

You have two goals. You need a detailed plan for the pilot and a long-range plan for the entire organization.

You should have an accurate inventory of all servers and workstations that will be involved with the pilot, to plan the specific hardware/software upgrades needed.

You also need to start a dialogue with any group within your organization involved with planning and supporting the network. You need to evaluate any current plans to support remote and mobile users. You may need to provide estimates for the amount of network traffic generated by Notes. Notes itself places an insignificant load on a network. The amount of data transferred is dependent on your applications design. The best way to develop estimates for your applications is to build some small demos and run some tests.

Chapter 7, "Determining Hardware and Software Needs," has more information on planning for your hardware and software needs (including forms you can use to gather information).

Exit criteria: This step is complete when you have identified cultural issues that will be affected by Notes, identified a Notes pilot application, and completed an evaluation of the current network.

Step 3: Define the Scope of Your Deployment


This step directly addresses failure 3, growing too fast. "Fast" is a relative term. Quick growth isn't bad if you've planned for it. Unplanned growth can lead to failure. You need to plan for growth in several areas.

Develop estimates for each of these categories. Chapter 6, "Customizing Your Deployment Plan," shows you how to turn these estimates into the number of administrators you need to train and the budget you should plan. Plan for success. You won't be disappointed.

Exit criteria: This step is complete when you have developed estimates for the number and type of users, applications, servers, and geographic locations that will use Notes.

Step 4: Design Your Notes Network


This is the step where you start to use the information gathered in steps 1 through 3. This is also the first step where detailed technical knowledge of Notes is needed. Make sure that your application developers and administrators have completed (or will soon complete) their training before starting this step. Remember to plan big, but implement in small chunks. Learn from your mistakes and revise your standards and plans accordingly. I don’t mean for the following list to imply that you can completely design your Notes network before you have any real-world experience. Your Notes network will evolve over time. Use this list as a guideline for designing and revising your plans.

These are the steps you should follow when designing a Notes network (in order):

  1. Identify supported desktop platforms.
  2. Identify supported server platforms.
  3. Identify supported network protocols.
  4. Develop a WAN strategy for remote access.
  5. Decide the location of servers.
  6. Identify your replication architecture (network topology).
  7. Size the hardware for desktop and servers.
  8. Identify current IS systems that must integrate with Notes.
  9. Identify current desktop applications that must integrate with Notes.
  10. Decide which application-development tools to support.
  11. Create your naming structures.
  12. Name your Notes domains.
  13. Name your Notes networks.
  14. Name your Notes servers.
  15. Choose gateways for mail, fax, Internet, etc.
  16. Assign users to home servers.

Chapter 7, "Determining Hardware and Software Needs," and Chapter 9, "Designing Your Notes Network," cover all the details you need to carry out these steps.

Exit criteria: This step is complete when you have initial plans showing where servers will be placed, standards showing how the decision to place a server will be made, estimates for how many users and applications each server must support, the name of each item in the Notes network (servers, domains, networks), and the systems that must integrate with the Notes network.

Step 5: Create a Notes Support Organization


You can start this step as soon as you have formed a project team. You should complete this step before proceeding to step 6. We recommend having the new support organization involved with developing the standard operating procedures.

Chapter 8, "Preparing Your Organization," discusses this step in more detail.

Exit criteria: This step is complete when you have selected the personnel for the support team.

Step 6: Develop Standard Operating Procedures


Notes integrates application developer and administrative functions in a single interface. It is remarkably easy for application developers to place unnecessary burdens on administrators and vice versa. Although a set of standard operating procedures can help, nothing beats a close working relationship between your application developers and administrators.

You may not want to develop policies for all the issues outlined here. Large organizations need more structure than small ones. The project team should at least discuss each issue listed here to decide if a formal policy is required.

You should develop a standard operating procedure or policy for each of the following items.

This level of security will be new to anyone new to Notes. Release 4 has added several new security features so that even an organization with experience using Release 3 should revise its security policies. For these reasons, security will be given special consideration here.

Security Policies and Procedures

Notes is probably your first encounter with a client/server system with integrated military-level security. Much of an administrator's time is spent maintaining various elements of Notes security (user IDs, certificates, access control lists). Planning can save considerable expense later by reducing the amount of administrative effort required for your Notes installation. In addition, the security of your network and data depends on correctly designing your security policies and procedures. Follow these steps to set up your security system:

  1. Assign people to roles.
  2. Create your organizational certificate.
  3. Create your organizational unit certificates.
  4. Create special administrator groups.
  5. Define default access control lists for databases.
  6. Define access control lists for special databases.
  7. Define default access control lists for servers.
  8. For each server, create a group of common users.
  9. Provide physical security for all servers.

Each of these items is discussed in detail in the following sections.

Build the Security Team

Even though Notes includes some of the best security technology available, you must pay special attention to the way you divide roles and responsibilities. Giving too much responsibility to a single individual opens security loopholes. Involving too many people in Notes security produces an unworkable system. The following roles play a part in maintaining Notes security:

During the initial rollout, you should assign at least one person to each of these roles. Each database will need a database manager (at this stage, one database manager should be able to handle all databases). Each server should have an administrator (one administrator can cover multiple servers). The number of certifiers you need will depend on the security policies and naming standards you implement. You should try to centralize management of certifiers as much as possible to minimize security leaks. Chapter 17, "Administering Notes Databases," contains detailed information for database managers; Chapter 18, "Administering Notes Security," outlines the responsibilities of an administrator. In summary, the security responsibilities of database manager include

The security responsibilities of an administrator include

The security responsibilities of a certifier include

The most important role is that of the certifier. The certifier is the person who essentially serves as a notary public, guaranteeing the identity of the user IDs within your organization. The certifier, through the ability to create user IDs, has complete access to your entire Notes system. Therefore, you need to choose your certifier carefully. Should one of your certifiers leave the company, to be absolutely certain of your security you need to create a new certificate and recertify all people certified with a certificate to which the certifier had access. Unfortunately, recertifying hundreds or thousands of users is impractical, which means that you must find other ways to help increase your security level.

One way to minimize the security problems associated with certifiers is to require three or more passwords for each certifier ID created. This method forces two people to be involved in the creation of each user ID, preventing a single certifier from creating fake user IDs.

Another way to maintain security after a certifier leaves is to limit access to servers to people listed in the Public Address Book. When this feature is enabled, Notes checks the public key contained in the Public Address Book against the one from the user attempting to access the server. Because a certifier cannot re-create the public key of users, just the user's name, this prevents a certifier who has left the company from gaining access to servers with fake user IDs. This feature hurts performance, however, because the server needs to check every access against the Public Address Book. This method is also impractical if you need to allow access to your servers from several domains.

Security Policy Overview

There are a few guiding principles you should follow when designing your security scheme. Despite the number of new concepts involved, Notes security is really very straightforward:

Before setting out to design a Notes security scheme, you need to ensure that your servers are physically secure. They should be kept under lock and key at all times. If your servers are not physically secure, your Notes data is not secure.

You won’t always be able to follow these guidelines. In particular, you may need to customize your ACLs to help avoid mistakes.

Define Default Access Control Lists

Your default access control lists should be set up to ensure smooth operation of your Notes network. This includes replication between servers, mail routing, and proper administrator access, in addition to denying access to external servers and unauthorized personnel. These recommendations are for internal applications. Access control lists for externally available databases need to be determined on a case-by-case basis. See Chapter 6, "Customizing Your Deployment Plan," for recommendations on creating access control lists for inter-enterprise applications. Chapter 18, "Administering Notes Security," contains step-by-step instructions for adding and deleting items in an ACL.

Your first step in creating your access control lists is to answer these questions:

The answer to these questions determine the default ACLs for your databases and servers.

The default ACL contains the name of the person who created the database. You should remove this name. Avoid putting any user names in ACLs. Each person who needs access to a database should be part of a group. This can save time when you need to change a user's name or the user leaves the company. It also enables an administrator to enforce correct change procedures. If application developers had their names listed explicitly in the ACL as managers, there would be no way to stop them from making changes directly to a production database. You should delete the name of the database creator from the production copy of the database.

There are exceptions to this rule of not allowing user names in ACLs. A user who doesn't belong in any current group may have a legitimate need to access a database. In this case, you would be forced to create a group for a single user, or put that user's name directly into the ACL. Realistically, it's just not worth the trouble of creating many groups with one or two names just to avoid putting those names in ACLs. This is an area that requires judgment on the part of the administrator.

There are several groups of people who should be accounted for in your Notes ACLs. Add the following groups to your default ACLs:

This default ACL doesn't apply to the Notes Name and Address Book, MAIL.BOX, or the Notes log. Each of these databases is a special case.

Define Access Control Lists for Special Databases

The Notes log, MAIL.BOX, and Name and Address Book are special administrative databases that deserve special consideration. Most organizations will use the default settings for these databases. Make sure that you understand the reasoning behind the default settings.

The Name and Address Book security settings should be set up to ease the administrative burden by enabling distributed management of the NAB. Large organizations can divide the task of managing the Name and Address Book by department or geographic location. For example, each department can have a certifier responsible for adding and deleting users in that department. The administrative burden is eased by allowing more than one administrator to create and manage persons and groups and by allowing individuals to fill in miscellaneous information in their personal documents.

Users also have a role in maintaining the Name and Address Book. The Name and Address Book is designed to have individuals edit certain portions of their own personal records (phone number, address, etc.). Most users will need training before they edit their own person record in the Name and Address Book. You can provide even more help by having a macro fill in fields, such as address, which are the same for large numbers of users.

The Name and Address Book is the directory for all users and servers, and the repository for server connection documents, groups, and network entries (and more!). The Name and Address Book is also used for scheduling tasks and for mail routing. Because the access to the Name and Address Book is used for so many key functions within Notes, you should limit access to the Name and Address Book while still allowing for distributed management. In particular you need to limit manager and editor access to those administrators who will be responsible for mail routing and certifying users. Chapter 13, "Administrative Tools," covers the Name and Address Book in complete detail.

The default settings for MAIL.BOX should be left unchanged. The default access is depositor, which prevents anyone from reading mail while it is being routed, and enables users to add new mail. Only administrators need to be able to read entries in MAIL.BOX. Administrators need to be able to access dead mail, which is also stored in MAIL.BOX.

The Notes log contains information that should never be changed. The log contains information about activity on your Notes servers and isn’t of much interest to normal users. If you have any hesitation about having users being able to see how often John Doe is accessing database XYZ, limit access to the log to administrators. Otherwise, the default reader access is acceptable.

Administrators and Security

Many organizations want to restrict manager access to data so that administrators do not have complete access to databases. Unfortunately, Notes does not yet have the access levels needed to accomplish this goal. At the present time, Notes administrators need manager access to databases to change access control lists, a task most administrators must be able to perform. The author recommends giving manager access to administrators who are responsible for servers for these reasons:

So it's actually impossible to prevent your administrators from gaining manager access to data. There simply is no way to close off all possibilities to someone who has high-level access to system resources. To even attempt to do so will simply add to his administrative burden while not actually increasing the security of your data. If you need to protect your data from access by administrators, you need to encrypt it with a key that administrators don't have. In this case, administrators still have manager access to the database, but wouldn't be able to read the data. Because encrypting data isn't practical for the vast majority of applications, however (the point of Notes is to share information), you must allow administrators to have access to data.

Use Dedicated Notes Servers

Notes servers should not be file servers. This is fundamental to Notes security. The only access people should have to a Notes server is through a Notes client. If you provide access through a file server or through telnet or FTP, none of the security provided by the Notes server prevents users from copying database files to their local harddrive. Once a database file is on the local harddrive, the user can gain access to all the data in the database. There are many ways to breach the security of a Notes server that also functions as a file server. If you care about security, deploy only dedicated Notes servers.

Create Your Organizational Certificate

You need to create a single organizational certificate. The only use for this certificate is to create the organizational unit certificates. Do not certify users with the organizational certificate. Certifying users with the organizational certificate makes it difficult to set up default ACLs that use wild cards.



TIP Choose people for the role of certifier carefully. Restrict access to your organizational certificate to one or a few people. Store the certificate in a safe place.

You need to store the organizational certificate in a safe. Restrict access to the certificate. For organizations serious about security, require at least three passwords to access an organizational certificate.

Chapter 18, "Administering Notes Security," contains step-by-step instructions for creating an organizational certificate.

Create Your Organizational Unit Certificates

You need to create one certificate for each of your organizational units. You should require two passwords to access an organizational unit certificate.

Chapter 18, "Administering Notes Security," contains step-by-step instructions for creating organizational unit certificates.

Create Special Administrative IDs

You must create two IDs for each administrator if you want to use the default ACL recommended above: one for use in everyday administrative duties, and one for use when changing access control lists. The normal administrative ID is the one used for mail routing and making changes and updates to databases, except for those changes that affect the access control lists. When she has to update an access control list for a database, the administrator would change to her manager access ID, change the access control list, and then log off. This scheme protects you from inadvertent changes to the access control lists—one of the main sources of problems in many Notes networks. It also allows you to restrict access to ACLs to a small group of administrators. Don't give a special manager ID to those administrators who should not be changing the access control lists.

Physical Security

None of these security steps has any meaning if people have physical access to the server machines; anyone with access to the server console has manager access to all databases on that server, including the Name and Address Book. For a medium-to-large corporation, set up servers in the computer room. For a small organization, or if you are setting up servers at remote sites, you may need to put them in a locked closet.

Application Development Methodology


All organizations with more than a single application developer should set some application development guidelines. These guidelines can be suggestions or requirements, depending on the type of application being built. All applications that will be used by people outside of your company (inter-enterprise applications) should have a common look and feel. Applications developed to support a specific project should have fewer restrictions—but are you sure that the application won't be used elsewhere? You need to specify this look and feel before you begin developing applications. You are not likely to go back and change your applications after the fact.

Guidelines should specify acceptable fonts, colors, and point sizes. Common forms or sections of forms can be built for all application developers to use. Your application development guidelines should also specify an overall approach for your application development. Most applications should use a prototyping approach, with the one exception being inter-enterprise applications (see Chapter 6, "Customizing Your Deployment Plan," for details).

Step 7: Build a Pilot Application


You should have chosen a pilot application back in step 2 of the planning process. Now it's time to make it a reality. You should complete a pilot application within six months of the beginning of your Notes project (three months isn't an unreasonable goal, either). This is an aggressive schedule for some organizations that are used to longer development schedules. You must strive to deliver useful functionality to the business within six months. This will enable you to gain some experience first-hand that you can use to refine your procedures and application designs. The authors have yet to encounter a situation where it was not practical to deliver valuable functionality within six months. If six months sounds too aggressive for your application, rethink your application.

Pilot users should be very involved in the development of the pilot application. Set the expectation level of your pilot users. They should know that they are being used as guinea pigs. A pilot application should deliver value to the business, but its primary purpose is to teach your organization how to build and maintain Notes applications.

Whole books have been written on the topic of Notes application development, so this book cannot do justice to this topic. Chapter 17, "Administering Notes Databases," covers some tips for developing administrator-friendly applications.

But far more important than any set of tips and tricks is your overall approach. The authors feel that using the correct development methodology (or even just having a development methodology) is crucial. You are more likely to end up with the correct functionality by following the correct approach. Notes applications are best developed using a prototyping methodology. You should spend a few days (up to two weeks maximum) developing some functionality, show it to users, get feedback, and repeat. You should then be able to zero in on a useful design. When you have a design that you want to put into production, spend a few weeks making the application production-quality. Test the application and roll it out.

Always deliver functionality in small chunks. You should avoid at all costs the "big bang" method of developing applications. Smaller chunks represent a smaller resource commitment. By controlling the resource investment in each deliverable, you give yourself greater freedom to make midcourse corrections. It's much easier to throw out six weeks of work than it is to throw out six months of work. This strategy allows you to remain responsive to end users in the face of constant change. One of the things that makes Notes great is the ease with which you can develop powerful applications. Notes frees you from the need to chart multi-year application development projects with all the associated risk and heartache. There isn't a better platform for developing non-transaction-oriented applications.

Step 8: Implementation and Training


We have grouped implementation and training because you should strive to schedule end-user training and installation together. Users should receive training within 48 hours of having Notes installed on their workstations (either before or after). Several steps must be carried out for each user.

This phase takes longer than the other phases combined. All the planning is meant to save you time during the actual rollout of Notes. Implementation should be divided into at least two phases: a pilot phase, and a production phase. Large organizations will have even more phases (see Chapter 6, "Customizing Your Deployment Plan"). A team of five people should be capable of adding 50-100 users a week, assuming that the team will also provide support for current Notes users. When planning your initial timeline, plan to add 50 users a week starting at the end of the pilot phase. This is a conservative estimate. Most organizations can add more than 50 Notes users per week once the team has some experience.

Create User IDs


You will create one user ID file for each Notes user. You need to plan and set up a standard operating procedure for the creation, distribution, and backup of user ID files. Some organizations create all user ID files with a default password. When the user first accesses the user ID file, she changes the password to her own personal preference. To protect against lost user ID files, the administrator should back up all user ID files created. While keeping these backups up to date is a burden, it's worthwhile for organizations that use encrypted data. Keeping backup copies of ID files makes it possible to decrypt data that was encrypted using an ID file.

Summary


There are good reasons to plan your Notes installation. You can save money, time, and heartache while increasing your chances of success if you follow the eight-step plan outlined in this chapter. Starting from scratch and taking you through to full production, this plan outlines the steps you must accomplish when installing Notes.

The key concepts to remember for any situation are these: phase your implementation, gather feedback, and use that feedback in the next phase. No matter what situation you're in, you should be able to deliver meaningful functionality to your end users within three to six months. If your schedule doesn't call for a production deployment within the first three to six months, you need to reexamine the functionality or choice of application. Always remember to choose an application for your pilot that is important for your business so that there is enough business demand, but one that is not time-critical. Deploying a time-critical application with brand new technology is a high-risk strategy. While it may pay off, you will often end up with an extreme case of frustration. However, deploying Notes need not be an exercise in frustration. With a little foresight in the form of a proper deployment plan, deploying Notes should be a relatively straightforward process.

This Notes installation blueprint is the starting point for all Notes installation projects. You will need to customize the plan for your circumstances. Chapter 6, "Customizing Your Deployment Plan," shows you how to customize this eight-step plan for your organization.

Previous Page Page Top TOC Next Page