Previous Page TOC Next Page



— 6 —


Customizing Your Deployment Plan


Chapter 5, "Building a Deployment Plan," presented the concepts and steps of a typical deployment plan. Because every Notes installation is unique, you should expect to customize your deployment plan. You need to customize your deployment plan if your organization is rolling out more than one type of application, or to more than one type of user. For example, you may be supporting both headquarters users and mobile users, and you may be developing applications for IBM's Notes network or CompuServe Enterprise Connect for Notes. Consult each of the relevant sections of this chapter and modify the deployment plan for each class of application and user that you are going to support.

In this chapter, you learn how to customize a deployment plan for your particular situation. You learn how to


Setting a Budget


First, a disclaimer. These are guidelines only; your mileage may vary. The hardest question to answer (impossible, actually) without some information about your particular organization is, "How much will Notes cost?" The real costs aren't in software licenses but in support, training, and application development. How do you plan and budget ahead of time for a product as complex as Notes? Start with an initial guess and refine it constantly.

Determining Hardware and Software Costs


The first step in determining your budget is to add up your hardware and software costs. These should be fairly straightforward to determine (see Chapter 7, "Determining Hardware and Software Needs," for details). Determining your personnel costs is a bit more difficult.

Determining Personnel Costs


Every organization with which this author works wants to know, "How many people will I need?" This question is particularly difficult to answer with Notes, because Notes isn't an application that you just install and start using. Each organization will develop its own applications that run on top of Notes. The number of support people needed is determined by the type of applications being developed, the quality of your development, and the amount of planning you put into your Notes network (see Chapter 5, "Building a Deployment Plan," for details). Organizations do need to have some initial personnel estimates to work with, and this section is meant to help you generate those estimates. If your first guess is within 25 percent, feel lucky.

Determining the Number of Administrators

The numbers that we present in this section are based on experience with Notes Release 3.x. Notes Release 4.0 contains features that reduce the cost associated with administering Notes. Also, as NotesView and its companion products become widespread, administrators should be able to handle more users. Therefore, consider the numbers in this section a minimum base for the number of users per administrator. Unless you have a very special situation, the estimates in this section should result in you overestimating the number of administrators you need. If you use these numbers in your budgeting, you should have a safe budget for your overall deployment.

There is a wide variety across organizations in the number of users that a Notes administrator supports. The numbers range from one administrator per two hundred users up to one administrator per one thousand users. In a few cases, organizations have only one administrator per two or three thousand users (in these organizations, Notes isn't being used effectively, or most of the work is being offloaded onto other departments). There is a more than 10 to 1 variance from the lowest to the highest number of users that an administrator can support. Why would that be? First off, an administrator's job definition varies from one organization to the next. 'Administrator' doesn't mean the same thing from one corporation to another. In some corporations, a single administrator handles everything (help desk, installation, troubleshooting, application development, etc.); in other organizations administrators are specialized. Some administrators work 80 hours a week, throwing off the numbers somewhat. Consider the number of variables involved in estimating the number of users that your administrators can support:

Given the number of variables involved, how do you arrive at an estimate for your organization? To arrive at a rough estimate, just calculate the number of users you need to support in each of the following categories, estimate the number of administrators needed to support each category, and add up the total number of administrators. You should have a fair estimate of the numbers of administrators and support personnel that you will need.

Foreign offices should be handled as a main campus or remote office, depending on the size of the international office.

Add one remote-site coordinator for each remote office. A remote-site coordinator must be capable of rebooting the server, but doesn't need to be a fully trained administrator.

Complex applications and additional add-on products require more administrators. Estimating the additional effort required to administer complex applications and additional add-on products isn't possible in the general case. During the pilot, you need to measure how many hours are going into administering your applications and add-on products, and revise your cost estimates accordingly.

Poorly trained administrators not only make maintaining your Notes network more expensive, they also increase the number of user complaints. In the extreme, they can give your entire Notes project a bad reputation before you even get to the first production installation.

Add up the number of administrators for each category and use that as your initial estimate. Don't forget to refine this estimate based on your experience during the initial rollout and pilot application. Note also that these numbers assume that you have properly trained administrators and that you are rolling out Notes on tested, stable hardware and software configurations for both your server and desktop.

Determining the Number of Application Developers

The next estimate to tackle is the number of application developers you will need. The number of application developers varies even more than the number of administrators. The factors that affect the number of developers are

The number of developers varies widely from one organization to the next, with no real rhyme or reason. The number of users per application developer varies from 100 to over 2,000, with the factors enumerated above being the key variables.

Setting a Time Line


One of the first activities your deployment team should complete is to develop an initial time line for the project. Your key deliverables on the time line should revolve around something of value to the corporation, such as a usable mini-application or even e-mail. Be sure to set deadlines for the choice for your first deliverable, the pilot phase for your first application, and your first production use of an application. Your time line should also include other events that lead up to these deadlines. For example, you should include the expected arrival date for all your hardware and software. Chapter 7, "Determining Hardware and Software Needs," recommends buying name-brand hardware. Because there is often a backlog for servers and popular desktops, determining your hardware and software needs early and placing orders helps eliminate the small disasters that can kill a Notes deployment. You also should include your training schedule in your time line. Publishing a time line that includes a training schedule helps to involve the rest of the corporation. It's a way to get other departments involved in planning before you need to commit to signing contract trainers.

Considerations for Mobile Users


Mobile users are primarily laptop users who connect to your headquarters offices via dial-up. Special considerations for mobile users include training, the timing of your installation, distributing and updating large databases, security, and Name and Address Book management.

Training is particularly important for mobile users. Mobile users must perform some tasks that are normally performed by an administrator. These tasks include creating replica databases and managing a personal address book. Developing a training schedule for your mobile users is complicated by the fact that they aren't often at headquarters. Even when they are at headquarters, it's difficult to know in advance what their schedule is going to be. It may not be possible to have all mobile users attend sit-down training sessions. When developing training for mobile users, consider computer-based training and customized screen cams (video recordings). Try to provide some personal introduction to Notes for all mobile users, even if they are unable to attend a regularly scheduled Notes training.



NOTEOne way to train remote users is to distribute custom Screen cams. Screen Cam is a Lotus product that you can use to create movies (including voiceover) to explain a computer product. Use this technology to create introductory training for your organization's applications.

Timing the Notes installation for a mobile user is also difficult. You need to pick a time when you know he is going to be at headquarters. The user must be able to do without his computer for an hour so that you can install and test Notes. You should coordinate the installation of Notes with end-user training. If the mobile user can't attend a training session, schedule the installation while the user is at lunch or in a long meeting.

Mobile users also have the highest rate of support problems due to the use of modems, a particularly troubling spot in many organizations. You should spend extra time testing the hardware and software combinations used by your mobile users. You should have access during platform testing to each type of laptop and modem used by your mobile users.

Mobile users often need off-hours support. Make sure that someone from the support team is available 24 hours a day to handle emergencies. You should involve the support staff in planning for this type of support.

The application developers and administrators must pay particular attention to the applications used by mobile users. Of particular concern are large databases or databases requiring data to be updated more than twice a day. Because your mobile users are dialing in, the cost of distributing large amounts of data is greater than it is for headquarters users. Not only do you have the connection charge, which is the predominant cost, but you also have the cost of maintaining the extra disk space for each user. There may be additional costs involved with upgrading laptops to support very large databases. Notes Release 4 comes with several features to simplify developing applications for mobile users. These features include field-level replication and passthru. Field-level replication reduces the cost of updating large documents by replicating only the individual fields that have changed. Notes passthru lets you use Notes as the entry point into your Notes network, eliminating the need to set up special servers for mobile users or have modems and phone connections for each server. Figure 6.1 shows a mobile user using passthru.

Figure 6.1.
Notes passthru enables mobile users to connect to Notes servers on an internal network. Non-Notes servers can't be accessed by using passthru.

Dial-in users can dial in to a Notes server and access some or all of the Notes servers on the LAN. Each passthru server can be configured to allow or deny passthru connections to any other server on the network. In addition, each server can be configured to accept or reject passthru connections.

Mobile users must be concerned about the security of data on their laptops. There has been more than one case when laptops have been stolen by competitors. You can't stop theft, but Notes does allow you to prevent anyone from reading the data in your Notes databases. Notes enables you to encrypt all the databases on a laptop. Notes encryption is strong enough to force thieves to spend several days breaking the code. There is one drawback to this approach. If the laptop user ever loses his user ID file, which was used to encrypt all the data on his laptop, you may have to rebuild all the databases on the laptop. Keeping a backup copy of ID files will prevent this situation only if you make sure to keep those backups up to date.

The real support problems for most mobile users concern the Name and Address Book. Mobile users should have access to the person documents contained in the Public Address Book. One straightforward way to accomplish this objective is to have mobile users replicate the corporate Name and Address Book. Another (not exclusive) method is to have mobile users manage person documents in their own Personal address books. Replicating the corporate Name and Address Book often isn't practical because of the file size and cost involved. I don't recommend having mobile users replicate the Public Address Book. Excluding this option means that the mobile user needs to type the full name and address into the To: field, or maintain person documents in his or her Personal Address Book.

Actually, a third option is available to handle the problem of mail addressing for mobile users, but this method requires some planning. You can create a new database that includes only person documents. Have mobile users replicate this database and specify it as a secondary Address Book. Make sure that the database inherits its design from the Public Address Book template, but isn't a replica of the Public Address Book. You need to have some way of automatically updating this database with changes to person documents in the Public Address Book. The DB/Utilities package from DSSI (818-991-0200) contains utilities that can accomplish this task.

If any of your applications use Reader Names to control replication, mobile users need to create server group documents in the Personal Address Book. The most common group documents are LocalDomainServers and OtherDomainServers. When sending mail, Notes uses connection and location documents in the Personal Address Book to determine the proper routing path. Even if you use user profiles to generate the initial connection and location documents in Personal Address Books, you should plan on helping mobile users to modify or add connection and location documents as they travel to new locations.

You also need to develop special installation scripts to handle the specialized Name and Address Book needs of mobile users. Some mobile users will want a local replica of the corporate Name and Address Book. This requires you to set up two Name and Address Books on the laptop. This goal is accomplished by setting the NOTES.INI names parameter. The names entry should be


Names=userid,names,corpname.nsf

where corpname.nsf is the name of the database containing person documents from the corporate Public Address Book.

The Personal Address Book should be used as the primary address book. The primary address book is the first one listed in the names parameter. Using the Personal Address Book as the primary address book saves memory.

When configuring passthru servers for mobile users, plan for peak usage. It won't take very many busy signals to drive your mobile users to some other solution. Having users encounter a few busy signals may not sound so bad to an administrator, and it does save a bit on modem costs, but the lost productivity outweighs any savings. Because reliable access to headquarters information is very important, be sure to buy enough modems to handle more than your peak number of planned dial-in users. The bottom line is that you need to have enough phone lines to handle your peak volume. Volume depends on the number of mobile users, the average length of the calls, the frequency of calls (once a day, once an hour, and so on), and the reliability of the connections (some international calls have very poor reliability). Some organizations need only two modems, but most should consider an 8- or 16-multi-port card such as the one built by Digiboard. For complete details on supporting mobile users, see Chapter 19, "Supporting Dial-Up Users." Here we have only pointed out those issues that you need to take into consideration when developing your deployment plan.

Customizing Plans for a Small Company


Any company with 20 to 500 Notes licenses is considered a small Notes installation. While 500 licenses may seem to be a rather large cutoff, the tasks and the number of people involved don't vary much between 20 and 500 users. We refer to installations with less than 20 licenses as micro installations. Micro installations are usually handled by a single person over one or two weeks.

Small companies often choose Notes because it can fill many application slots and has the ability to grow with the business. For example, Notes can be used as a message center, as a fax server, for e-mail, and so on. Small companies operate under constraints that large organizations don't have. Primarily, small companies have a concern about the availability of skilled personnel to support Notes. The Notes administrator in a small company must be a true jack-of-all trades.

Small companies can't justify the expense of a full-time administrator. Notes is a rather large product encompassing replication, database design, application development, network protocols, remote-site management, mobile-user support, and military-level security. Packing all the information needed to support all aspects of Notes into one or two heads is a daunting task and requires some special planning. Steps must be taken to minimize the amount of information that the support staff must master. Large organizations are concerned about this, but small companies must make this priority number one.

When deploying Notes in a small organization, the project staff is faced with constant temptation. There is always considerable pressure to take the easy route, the quick route. The administrator in a small organization may not have enough information to lobby effectively for some planning time. In this section, we show you where it is okay to take the easy route and where you need to bite the bullet, do the planning, and take a little extra time up front to avoid problems later.

So let's go through our standard deployment plan step by step and discuss the ways a small enterprise will customize this deployment plan.

Step 1: Form a Project Team


Whereas in a large organization you have a support team of eight to ten people, a small company's project team may consist of a single administrator. It isn't uncommon (although not recommended) to have a single person as your system administrator, application developer, and support engineer. People deploying Notes within a small organization have to wear more hats than people deploying Notes in a large organization.

Step 2: Assess the Enterprise


Assessing the enterprise within a small organization may sound less daunting than assessing the enterprise within a large organization. However, the lack of time and resources constrains the amount of detailed work that a small company is able to do. Hopefully, your small organization has only one operating system installed (if any). This minimizes the number of variables that you need to deal with. It is still cost effective to have a temporary worker go to each desktop and confirm the hardware and software installed.

Follow the guidelines in Chapter 5, "Building a Deployment Plan," when assessing the cultural readiness and physical readiness of your small organization.

Step 3: Define the Scope of Your Deployment


Small organizations often plan from the start to deploy Notes across the entire enterprise. Even if this case isn't true for you, determining the geographic and organizational scope of your Notes deployment should be straightforward. In addition, it's fairly easy to estimate the number of users you are likely to have six months, one year, and two years into the future. You should plan to place everyone in your company on Notes in a matter of months. The only difficult estimate for a small company is the number of applications to be developed over the first year.

Step 4: Design Your Notes Network


The design stage is where a small company will make or break their Notes deployment. If you do a good job of designing your Notes network, your support costs stay affordable. If you do a poor job, your support costs blossom out of control.

Your primary consideration should be to minimize the number of network protocols and operating systems. One is ideal; two should be the absolute maximum for a small organization. Attempting to force all the knowledge needed to adequately support more than one protocol or more than one desktop operating system into the head of a single person is a recipe for disaster. When you add responsibilities for support and application development, this is also a recipe for burnout. Your Notes administrator is an expensive asset to replace midway through a Notes deployment. If your small organization is deploying its first client/server applications, you have a wonderful opportunity to standardize on a single operating system and network protocol, typically TCP/IP. If you already have more than one network installed, you should make a case for standardizing the hardware and software throughout your organization, if at all possible. If you must support multiple protocols or operating systems, spend time testing the configurations you will support and developing standard operating procedures for each platform. As a minimum, develop standard procedures for installation and updates.

One area where it is tempting for a small company to cut corners is in developing naming schemes. Because you are likely to have only a few servers and one network, the effort required to recover from mistakes is small. On the other hand, because you only have a few servers and one network, it shouldn't take very long to write down some naming guidelines. Even if you can get away with not planning your network names, you should still plan the names of each of your servers, especially if you are using TCP/IP (administration is easier if the TCP/IP server name and the Notes server name are identical).

When devising a naming scheme for a small company, you may be tempted to skip the hassle of coming up with a hierarchical naming scheme. The reasons for a small company to use hierarchical naming are less compelling than for a large company. One of the main advantages of hierarchical naming—resolving ambiguity in mail routing—isn't a problem for small organizations. Nevertheless, you should use hierarchical naming. After all, if your organization grows, mail routing will become a problem. More importantly, if you want to extend Notes beyond your organization, odds are that you have to use hierarchical naming to do so. Starting from scratch with hierarchical naming avoids a costly and expensive conversion later. In the end, the primary reason you should use hierarchical naming is that Notes is a system designed to use hierarchical naming. If you use flat naming, over time your administration costs will rise and the number of features available to you will decrease.

Step 5: Create a Notes Support Organization


Creating a Notes support organization typically isn't a very difficult task within a small organization. The key decision is whether to train or hire Notes skill. If you decide to train in-house personnel, having a consultant help out part-time during the initial deployment can be cost effective for even small businesses.

Step 6: Develop Standard Operating Procedures


Small organizations can manage with few standard operating procedures (SOPs). When a single person is responsible for developing and supporting all Notes applications, communication among the support staff becomes a moot point. If you are going to involve your users in the development of Notes applications, write a one- or two-page "cheat sheet" specifying colors, fonts, and common field names. The primary benefit of SOPs to small organizations is to minimize the impact of losing key personnel. If your administrator leaves, you can continue to operate by using the SOPs. However, in terms of having a successful rollout, defining your standard operating procedures before the deployment of your first production application it is less critical in a small organization than in a large organization.

Step 7: Build a Pilot Application


The criteria for selecting a pilot application and first production applications are no different for a small organization than for a large organization. You still need to choose an application that's important to the business, but not time critical to the business. You still need to meet any internal return-on-investment guidelines. You need to push hard to get your application deployed within the first three to six months of your Notes project.

Not all companies should start with custom-developed applications. Some organizations can use off-the-shelf applications; others can implement e-mail as the first piece of functionality. Your organization may not need to start with a full-fledged application.

Step 8: Implementation and Training


Don't skimp on the training. Lack of training simply extends the learning curve for Notes. If you have goals for your Notes deployment, you need to train your end users and your administrators so that they can be productive as soon as possible.

Consultants can be cost effective during the learning phase. Although Notes consultants are typically some of the highest paid consultants, having one work closely with your IS staff during the initial planning stages and then again during the initial development of your applications can be a cost effective way to train your own staff and teach them a few of the tips and tricks.

Customizing Plans for a Large Company


The biggest issue facing a large organization is the culture within that organization. Will Notes be accepted? Will users try to control information rather than share information? Running a distant second is the difficulty of coordinating the Notes rollout. Let's examine each step in a deployment plan and see how these issues affect your planning.

Step 1: Form a Project Team


Your primary Notes team should have eight to twelve members with each of the following key rolls assigned to a member:

Chapter 8, "Preparing Your Organization," discusses each of these roles in detail.

The internal marketer plays a critical role in a large organization rollout. The technical issues won't kill your Notes rollout; cultural and organizational issues are far more likely to derail Notes. Notes changes the working relationships and information flow within an organization. Resistance both before and after a Notes installation should be expected. Enthusiasm, information, and close contact with the project team will help overcome this resistance.

The primary job of the internal marketer is communicating the advantages of Notes, generating enthusiasm for Notes, and generating some demand for Notes. The internal marketer adds a sense of urgency within the organization. The internal marketer helps deal with the cultural and people issues that arise during a Notes deployment.

A large organization will have more specialization among team members. While a small organization may have one person covering both the administrator and support engineer roles, a large organization will have multiple support engineers.

The administrative and support members selected for your core project team are likely to become team leaders in the later phases of your Notes deployment. They will be the ones in your organization with the most expertise in implementing and supporting Notes. During the rollout phases of your deployment, they will have to take on the role of training and leading the teams tasked with installing Notes throughout your organization. Ideally, the administrators and support personnel should have a combination of technical and supervisory experience. Choose these roles carefully. Your core project team should be the team that will continue to provide ongoing support after your initial rollout phases.

The project team for a large organization can grow quite large when all decision makers and implementers are included. When your project team grows beyond ten people, consider splitting into multiple teams during the deployment of Notes. Split the team into a management team and a technical team. The following sections discuss each of these teams individually.

Management Team

The management team is formed by key personnel from participating business units and the IS staff. The management team is responsible for

You should also have someone with some visibility within your organization on the Notes management team to sponsor an internal Notes newsletter. A dedicated newsletter is a great way to distribute information about the progress of the Notes deployment. In addition, a member of the management team should be assigned as a sponsor or Notes "coach" to each business unit participating in the initial deployment of Notes.

Technical Team

The technical team is responsible for providing input and making recommendations to the management team. The technical team's primary responsibility is setting up the architecture and designing the Notes network. The technical team also recommends all hardware and software platforms.

Step 2: Assess the Enterprise


Assessing the readiness of a large organization requires careful planning and timing. The hardware and network(s) in most large organizations are in a state of constant change. You need to coordinate your assessment of the installed hardware and software with the planned upgrade and installation of Notes in each business unit. Don't attempt to assess the complete installation for your entire organization and then install Notes one business unit at a time. By the time you want to install Notes, the installed network and workstations will have changed, requiring you to repeat the physical assessment step. Assess the network and workstations one business unit at a time (assuming that you are installing one business unit at a time).

When assessing the cultural readiness of a large organization to receive Notes, you need to plan for the expected changes that Notes typically brings to an organization. Installing Notes will result in the development of new sources of information within your corporation and make information more accessible in general.

You need to conduct interviews to determine the flow of information within your organization. You need to answer questions such as

Keep in mind that behavioral changes certainly won't occur overnight. If your pilot application requires a high degree of cooperation among users to succeed, make sure that the pilot group has a history of teamwork.

Step 3: Define the Scope of Your Deployment


While Notes often is purchased initially by a single business unit, its true value is when it is adopted by an entire enterprise. Although you probably won't have a commitment for an enterprise-wide deployment at the very beginning of your Notes deployment, you need to plan for radical growth in both the number of users and the number of applications that you need to support. One of the primary difficulties large organizations face is rolling out Notes fast enough to satisfy business demand, while still providing adequate support to continue to generate successes and enthusiasm. When charting the geographic and organizational scope of your Notes deployment, plan big. If your organization is international, plan to support international organizations and contact them early in your planning to see if there is any initial interest. Contact other divisions and departments early.

Step 4: Design Your Notes Network


What is true for a small organization in this case is also true for a large organization. That is, the fewer the network protocols and the fewer the operating systems, the better. A large organization is more likely to be constrained by an installed base or intransigent business units than is a small organization. A reasonable goal for most large organizations is two network protocols, two desktop operating systems, and two server platforms. Of course, you need to staff your support organization from the beginning with the expectation in mind that you will have multiple protocols and multiple operating systems running in multiple geographic locations.

You should at least gain some control over the configurations you will support by specifying a minimum configuration for each of your operating systems for desktops and servers. For example, if on the desktop you are supporting Macintosh and Windows, you should specify the minimum CPU, memory, and disk space required for both Mac and Windows. You should enforce your configuration restrictions by simply not installing Notes on deficient workstations.

When designing naming convention for users and servers, a large organization should use hierarchical naming.



TIP If you are upgrading from Notes Release 3.x to 4.x, now is a good time to switch your organization from flat to hierarchical naming. Lotus ships an application designed to ease the transition. Detailed steps on switching to hierarchical naming are in Chapter 18, "Administering Notes Security."

When creating domains, a large organization should create one domain for production use, at least one domain for developers to use, at least one domain for testing, and one domain for external communications—a minimum of four domains. You should create a developer domain only if you have a central development staff and the applications that you develop require changes to the Public Address Book. In this case, providing a developer domain enables the developers to play with the Public Address Book without endangering the production network. Some organizations can use the development domain as the test domain also. You can leave this decision up to the application developers. You should add more domains only if forced by limitations of the Notes Name and Address Book, or by test applications running on a service provider, such as CompuServe Enterprise Connect for Lotus Notes or IBM's Notes network.

The maximum size of a Name and Address Book is around 10,000 users. If you expect a domain to grow beyond 50,000 users, plan from the outset to have two domains. This scheme avoids changing the domain of thousands of users who have been certified already and are using Notes. Don't create multiple domains simply to have distributed management of the Name and Address Book.

Don't add extra domains simply to accommodate international users. Because one of the main goals of Notes is to break down the barriers of time and space, creating separate domains for your geographically dispersed users violates one of the main reasons to install Notes in the first place.

Large organizations need to pay particular attention to the strategy for remote access. You should weigh WAN (wide area network) costs against the costs of calling in over regular phone lines. WAN alternatives to consider include leased lines (T1, T3, fractional T1) and switched ISDN. You should

For additional information, see Chapter 19, "Supporting Dial-Up Users."

One key element of the Notes deployment plan for a large organization is e-mail gateways. Nearly every large organization today has installed some e-mail program. When installing Notes, you need to choose an e-mail system. Even if you don't want to use Notes e-mail, you need to integrate Notes e-mail with whatever e-mail systems you currently use. This fact requires you to implement a gateway that supports directory synchronization (directory synchronization is the process of updating address books). You must integrate the e-mail system in use at your company with Notes to take advantage of any messaging capabilities in your Notes applications. Without messaging capability, you may as well not implement Notes at all.

Lobby hard to reconcile users to one mail system. Supporting multiple e-mail packages requires increased administrative effort. Migrating to one e-mail system lowers costs and eliminates compatability problems for things like graphics, colors, and fonts. You should never move to a system where users have more than one "in box," although you can survive (with headaches) with different users having different e-mail systems.

Step 5: Create a Notes Support Organization


As we discussed already under Step 1, your core Notes team should become your core Notes support organization. However, when you are staffing up for your support group within a large organization, you need to take into account the need to support a large number of new users during the rollout phases. You may need to assign extra personnel to the support team during the rollout. When the rollout begins to wind down, these people can return to their regular jobs (the rollout can take as much as a year).

Step 6: Develop Standard Operating Procedures


Although it is tempting within many large organizations to develop very large guidelines and booklets, you should avoid overcontrol of the Notes environment. But you definitely need to develop standard operating procedures (SOPs) for these phases:

Keep your SOPs brief and to-the-point. Your deliverables should be detailed, step-by-step guides for each procedure, no more than five to ten pages in length. You should have a "Getting Started" guide for users that answers, within the context of your own organization, common questions such as, "Who do I contact if I need a new user ID?" The "Getting Started" guide should be published as a Notes database. You should have a guide for administrators describing the tasks required for each administrator's job, along with standard operating procedures for each of the tasks outlined in Part IV of this book, "Administering Notes." These tasks include maintaining a Notes server, maintaining Notes security, and maintaining Notes databases.

Step 7: Build Your Applications


If your large organization has familiarity with client/server development, you are well suited to begin development of Notes applications. Your IS staff can probably be trained quickly, using a combination of formal and on-the-job training. If not, consider bringing in consultants to help your IS staff. Consultants can show you the tricks not available in any training and help you avoid costly mistakes. There are good books available on developing Notes applications, but make sure that your developers have at least one morning of formal training before developing the pilot application.

Step 8: Implementation and Training


Here is where the sheer number of users in a large organization begins to affect the scale of activities of the deployment plan. You should plan for multiple rollout stages, the first being a pilot implementation of your first application. Seek to have your pilot application up and running within six months from the formation of your project team. If you're dealing with an application consultant who can't commit to having the first application up in six months, you are probably dealing with someone who isn't comfortable with rapid-application-development methodologies.

Following the pilot, you go into phase one production, where you attempt to add approximately 100 users per week. Of course, you should only roll out Notes to users who have something to do with Notes. If you don’t have applications for users, scale back the pace of activity. If you are implementing Notes e-mail across your organization, plan on installing Notes on every desktop even if no other applications are needed for that user. The purpose of your phase one production should be to test your Notes infrastructure, so choose applications that have a broad audience. You need to generate enough load on your servers and enough questions for your support staff that you can truly shake out the last few bugs that may have made it through your pilot implementation.

Phase two and three are when you roll out Notes to the entire organization. We split the remaining rollout into two phases to emphasize the importance of continually gathering feedback and updating your procedures. In phase two production, you attempt to add up to 150 users per week. In this stage, you definitely need multiple implementation teams, multiple training rooms, and multiple project managers coordinating their activities. In phase three production, you add several hundred users per week across wide geographic zones, including international users, mobile users, small remote offices, and the like.

Remember that the point of a phased implementation is to get feedback as quickly as possible. Don't forget at the end of each phase to pause and analyze what went well and what went wrong, and incorporate this feedback into the planning of your next phase. In addition to reviewing the experiences of the implementation team, you should seek feedback from new users during that phase, as well as from users who have been using Notes for some period of time. You should use a variety of techniques, including interviews, questionnaires, and Notes discussion databases to gather feedback.

Notes success stories can have a way of spreading through the organization on their own. You can get a tremendous amount of enthusiasm going within business units before they even have Notes installed. At this point, demand can often outstrip your IS ability to respond. In order to keep business units in line and retain the advantages of a coordinated rollout, you should communicate to all business units the advantages of waiting for the officially blessed Notes rollout. Most will be satisfied when they understand the dollars that they will save on Notes licenses alone by going with volume purchases. However, you can offer other goodies as enticements for Notes business units to wait their turn, including getting a personal Notes helper to help them plan their Notes applications. The fact that your feedback will help them avoid costly mistakes may be enough to help them wait. And as a last resort, you can consider moving them up on the implementation schedule. Of course, you will be constrained by the fact that every time you move someone up, someone else has to fall back. Rescheduling may become commonplace. In some organizations, it won't cause any problems; in others, it can lead to fighting. So take into consideration your own culture and plan accordingly.

Extra-Enterprise Deployment Considerations


Extra-enterprise applications include all applications to be used by many companies, not just your company or a few partner companies. You may be deploying your extra-enterprise applications over the Internet or use one of the services such as CompuServe Enterprise Connect, IBM’s Notes network, or WorldCom.

At the time of this writing, CompuServe Enterprise Connect and WorldCom had been in business for two years, and IBM was launching a service. These companies are offering services, not products. The recent surge of Lotus Notes and the World Wide Web have brought back the old idea of timesharing—renting time on a computer, CompuServe's original business more than 15 years ago. These new services also handle facilities management and security, major concerns for extra-enterprise applications. CompuServe can bill users of your database for the time they spend online. The use of these services is driven by cost and security concerns.

The bulk of extra-enterprise applications fall into one of four categories:

You can follow a modified version of the standard deployment plan when implementing extra-enterprise solutions. The following sections describe each step in detail.

Step 1: Form a Project Team


Several key issues arise when staffing for extra-enterprise applications. Customers using your applications form impressions of your company based on those applications. Any application aimed at customers should be considered part of the marketing message your company sends, even if customers aren't paying to access your Notes application. All your extra-enterprise applications should be consistent with the marketing message and materials that your company distributes through other channels. Consider whether you really even want your IS staff to develop marketing materials. On the other hand, having your marketers develop software isn't necessarily a good solution.

When staffing a project team for extra-enterprise applications, include members from your marketing and PR staffs. The team for an extra-enterprise application should be considerably more interdisciplinary than for other Notes rollouts. Content and presentation become much more important.

Just as most firms hire an agency to handle their advertising, companies are now farming out the development of extra-enterprise applications. Most advertising firms have already added the ability to develop Web sites. Consulting companies specializing in extra-enterprise applications also are popping up. If you need help developing extra-enterprise applications, look for a firm that combines marketing and Notes experience when developing an application aimed at customers. For inter-business applications aimed at distributors and suppliers, look for a company combining business-to-business communication skill and Notes experience.

Step 2: Define the Scope of Your Deployment


You must determine a target audience or market. Only then can you determine the likely number of users and their location.

Step 3: Assess the Enterprise


You need to have a target audience and goal in mind before you can identify the 'enterprise' to assess. You need to assess the willingness and capability of the application's target users (customers, partners, suppliers, etc.) to use Notes. A few organizations are in the position of being able to mandate the use of Notes for all external organizations that want access to data. You probably will need to survey potential users to determine if Notes is the correct platform. The World Wide Web is an alternative for many extra-enterprise applications. You don't need to choose either Notes or the Web; you can develop a Notes application and link it to the Web for minimal cost, using off-the-shelf software from the Lotus InterNotes suite of products. The InterNotes Web Publisher from Lotus now ships free with every Notes server and can be used to publish Notes databases to the Web.

Step 4: Design Your Notes Network


Consider hosting all extra-enterprise applications on a service provider's computer. A service provider can buffer your network from direct contact with external networks. Service provider personnel will be more skilled than your staff at handling security because they work with extra-enterprise applications daily. Service providers also can provide generic Notes support to organizations using your application, thus reducing the load on your support staff.

Be careful in naming groups and roles in your access control list in your extra-enterprise applications. Names that you choose must not conflict with names in your customer's Name and Address Book. To prevent conflict, you should prepend the name of your company or application to any name in the ACL. However, avoid names, such as "New England Marketing," that can give away your internal organizational chart.

Step 5: Create a Notes Support Organization


The quality of support that you provide for your extra-enterprise application will affect your customers' impressions of your company. Even if you release a reliable, consistent application, you still have to provide excellent support for an extra-enterprise application. Even though all of your customers (presumably) have installed and are using Notes, you can't assume that they have any Notes expertise. Your support requirements will go well beyond supporting your application. You should be ready to field general Notes support questions. Questions such as, "It's not replicating; what's wrong?" are common. The problem may have nothing to do with your application. Your application may just be the first place where the symptom appeared. Supporting Notes remotely can be an unexpected expense associated with extra-enterprise applications. Check with your service provider or consultant on the possibility of getting help with general Notes support. We don't recommend building an elaborate support structure to rival the Lotus support structure. Just make sure that your support staff will handle these questions with grace and forward the question to the proper support channel.

Your extra-enterprise application should include a way to submit questions regarding usage and bugs. We recommend having a general-purpose Help! form that customers can use to compose questions and comments. The form should be routed automatically to your support staff. You should provide an immediate follow-up to all submitted questions. If you don't have an answer, give an expected time for getting back to the customer with an answer. Return a "thank you" for all comments.

In addition to requiring a higher level of support than may be needed in-house, there are additional challenges in administering an extra-enterprise application. Consider the case of undeliverable mail. Your Name and Address Book may have been corrupted. The customer's Name and Address Book may be wrong. One of the intermediate servers may not be functioning properly. It's often quite difficult to resolve this type of problem and requires cooperation over the phone between your administrator and your customer's administrator (not easy for international clients). Because your customer's administrators are at varying levels of skill and experience, the administrator that you select to support your extra-enterprise applications should be able to debug a Name and Address Book problem over the phone. The administrator you choose to support your extra-enterprise applications must be a good people person with an infinite amount of patience and, if applicable to your application, an ability to understand virtually every spoken language in the world.

Since you'll be using hierarchical naming in your application, you'll have to become familiar with cross-certifying servers. For details on cross-certifying servers, see Chapter 19, "Administering Notes Security."

You'll also want to provide a single external contact from your support organization to support all of the extra-enterprise applications that you deploy. You should require each of your end users to provide a single point of contact for dealing with usage and support problems.

Step 6: Develop Standard Operating Procedures


Even if you don't enforce any restrictions on internal applications, you should develop and enforce standards for your extra-enterprise applications. You need to ensure consistency between your various extra-enterprise applications. Consistency includes the look and feel, button naming, colors, fonts, and so on.

Document and enforce a change procedure for making design updates to the application. You should clearly identify all sources of information for the application.

Step 7: Build Your Applications


Extra-enterprise applications differ technically from ordinary in-house applications. Your application-development methodology, testing procedures, application design, security precautions, and performance goals are all affected.

Rapid-Application-Delivery Methodology May Not Apply

The overriding key issue that you must consider when developing, deploying, and supporting an extra-enterprise application is that your users are external to your application. Most Notes application development follows a rapid-application-development methodology where you work intensely with the targeted end users. This methodology may not be possible for an extra-enterprise application. In this case, a marketing vision will replace user feedback. The phased delivery recommended in Chapter 5, "Building a Deployment Plan," may not be applicable for your extra-enterprise application. Releasing a constant stream of upgrades to the public may cause confusion among your end users. Less frequent, major upgrades are more manageable in this environment. The fact that your users are customers can have a dramatic impact on the methodology you use to develop your applications.

High Reliability Required

Extra-enterprise applications require extra testing resources. Your applications must be highly reliable. Releasing buggy applications on a service like WorldCom or CompuServe Enterprise Connect can have a detrimental effect on your company's image. This is true whether the audience is customers, suppliers, distributors, or joint venture partners.

Multiple Domains

The primary technical difference between an in-house application and an extra-enterprise application is the proliferation of domains. There are at least five domains in a typical extra-enterprise application. Figure 6.2 shows the domains involved with a typical extra-enterprise application.

Figure 6.2.
Typical domains in an extra-enterprise application.

The service provider has a domain, the customer has external and internal domains, and you have internal and external domains, for a total of five domains. The number of domains affects the role of replication and mail routing, and requires a special test configuration. Create at least a three-domain test environment to do basic testing of your extra-enterprise applications. You can save yourself time by performing this testing before even placing an application on your service provider's host computer.

There are two strategies for tracking the full e-mail address of anyone submitting information to your database. You can have each user fill out a form the first time he submits information, include this information in the submission, and replicate submissions; or you can have all submissions mailed to a central database. Because many users won't know the complete mail address, we recommend mailing submissions to a central database. The Notes router automatically maintains the full e-mail address as the submission is routed through the network.

An extra-enterprise application typically includes five domains. Thus, replication goes through four hops to get from your input server to the customer server, introducing a delay that may not be acceptable for your application. Even if you dial up your service host on a regular basis, you don't have any control over how often your end users dial in. Therefore, you need to plan on handling cases with a two-day turnaround from the time you put data out on your system to the time it actually reaches an end user. This situation can happen when a user who dials in once a day connects to the service provider just before your data reaches that host. His server won't get that data until the next day when it dials in again. Then, at some point during that second day, the end user will check the data currently on his server. In the worst case, this can be a two-day turnaround.

If you have particularly urgent data, you'll have to use high-priority e-mail. This only works if your service provider will dial out to end users to deliver mail. In order to dial out, you need a phone number for each end user domain. This is problematic for publishing and electronic commerce applications, where you may not even know the identity of your customers. E-mail notifications work best for extra-enterprise collaborations. To avoid cluttering personal mailboxes, provide each end user domain with a mail-in database to receive e-mail notifications concerning your application.

Multiple Client Platforms

You can't assume any restriction on the type of platforms that will be used to view your application. You must assume that every available Notes client will be used, and that users will have a variety of monitors, resolutions, and colors. At a minimum, you should test your application in each of the standard resolutions (VGA, SVGA, and 1280´1024) to insure that the screens are at least intelligible. You'll have to stick to standard color choices if you want to have them supported across a wide range of platforms.

Underpowered Servers and Clients

Your application must perform acceptably on a minimally configured server and client. You can't assume that every end user domain will be using a high powered server. If views take several minutes to open, users will stop using your application.

Slow Connect Speeds

As of this writing, you can expect end users of your extra-enterprise applications to be using modems to access your service provider's host. Even at 28.8 kbps with field-level replication, you need to consider the amount of data that you change on a regular basis. You also should put in place special procedures to avoid massive updates to a database. Update fields instead of whole documents. If any of your users are still using Notes Release 3, you'll need to organize your application to use many small documents rather than one large one. This makes it easier to distribute changes to your data without having to replicate extremely large documents. Because of the slow connect speed, most users will access your data by replicating it to a server of their own rather than sitting on-line, running up access charges. Therefore, your applications should assume that users will be accessing replicated databases in a different domain.

No Default ACL Entries

When designing your access control list, don't assume any default entries in the Name and Address Book. You need to set up the default access to enable end users to access all features of your application. At the same time, you must prevent information from accidentally replicating between customers.

It's best to avoid relying on any particular groups when building extra-enterprise applications. Other organizations may not be happy about the need to maintain groups in their Public Address Book just for your application. Keep your extra-enterprise applications simple. Because you can't rely on any specific group being present in the Public Address Book, you can't rely on any entries in the default ACL. This situation forces you to change the default access from the typical No Access to whatever is needed to run the application.

Customers May Replicate with Each Other

When your database is replicated around the world to many organizations, you run the risk that two companies will replicate directly with each other. When two companies, both with replicas of your database, replicate with each other, confidential information can leak from one customer to another, and they may not be aware of this problem until it's too late. This situation will reflect badly on your company, and could result in liability. If each company creates a replica of your database, when their servers call each other your database will be updated. This behavior may not be proper for your database. In fact, if this results in the sharing of confidential information between potential competitors, you may be getting a phone call that you definitely won't enjoy! Your database ACL should explicitly list the domains that can replicate the database. List your internal and external domains and the service provider domain. Your customers will want to replicate from their external domain to their internal domain. As you can't predict the names of these domains, you should provide details in the About and Using documents on adding entries to the ACL. Your default access should be set so that no information created at a customer site will replicate with any server other than your domains and the service provider domain.

You need to use ReaderNames and AuthorNames fields to control access to documents. All documents composed and submitted by users should have a ReaderNames field. The ReaderNames field should include the person composing the document, the server name of the service provider's server, your external and internal servers, and your default extra-enterprise administrator group.

Must Use Hierarchical Naming

Your service provider almost certainly will require you to use hierarchical naming for all servers and administrators that will access the service provider's host. This requirement doesn't mean that you have to convert all your internal users to hierarchical naming; it simply means that you need to set up a hierarchically named external server for use with your service provider's host. You may need to set up hierarchically named administrator accounts to directly access a service provider's host.

Restrictions on the Use of Agents

A service provider may impose some restrictions on your Notes applications. You may not be allowed to use all the design features that Notes provides. For example, you may not be allowed to run agents, or doing so may incur an additional charge. Your end users may not be allowed to create agents. Any restrictions need to be described in the About document for your application.

Must Use Notes Interface Only

You should design your user interface using only the capabilities of the native Notes application builder. Building additional interfaces on top of your Notes database using Visual Basic, PowerBuilder, etc., while possible, is an additional administrative burden that isn't justifiable for most extra-enterprise applications. Some method of distributing and installing your application would need to be worked out. If you are going to develop an application using Visual Basic, PowerBuilder, or C, and you want to reach as wide an audience as possible, you'll have to provide that application under Mac, Windows, OS/2 and UNIX. Providing a consistent look and feel across all these platforms is something with which most corporate IS staffs are unfamiliar, and which they're ill-equipped to handle. The application developers developing your extra-enterprise applications need to be more creative in their use of the Notes interface elements. You should strive for a distinctive look and feel and to separate your applications from the rest of the pack while still providing a consistent look and feel with your other marketing materials.

Step 8: Implementation and Training


Your only training concern is that users know how to use your application. You can write very detailed help screens, but users probably won't read them. You need to spend some time when developing the application, making sure that everything in the interface is clear. No amount of help screens can make up for a poorly designed application. If you deploy a poorly designed extra-enterprise application, your support costs will escalate quickly.

A key part of implementing an extra-enterprise application is getting the word out. If you are providing customer support through Notes, mention this fact in your product literature. If you are selling information on-line, advertise. You should contact your PR (public relations) department for more ideas. If your company has a Web site, contact the team responsible for maintaining the site and have links to your Notes application added.

Summary


In this chapter we have highlighted the key issues that you need to consider for each of several possible situations. Always follow the basic guidelines outlined in Chapter 5, "Building a Deployment Plan," when developing a deployment plan. However, you need to customize your deployment for each type of application and class of users for which you are developing. The customization can affect not only the deployment plan, but your application development methodologies, your standards and practices, the size of your rollout team, and the roles for the rollout project.

The remaining chapters in this part of the book provide the detail you need to execute the deployment plan. Chapter 7, "Determining Hardware and Software Needs," provides more detail on determining your hardware and software needs. Chapter 8, "Preparing Your Organization," shows you how to prepare your organization for Notes. Chapter 9, "Designing Your Notes Network," shows you how to design a reliable Notes network that minimizes support costs.

Previous Page Page Top TOC Next Page