Branch Office Deployment, Part 1: A Product Development Approach

Articles and Tips: article

ROB RAWSON
Senior Systems Consultant
Novell Consulting Services

01 Sep 1996

Presents a methodology for designing and implementing a branch office network, using the same approach software vendors use in developing products.

Introduction
The Six 'P's of Product Development
Planning Your Project
Proof of Concept
Prototyping
The Pilot Phase
Productization
The Production Phase
Conclusion

Introduction

The requirements for planning a deployment of a branch office network are significantly different from those for a local area network or a multi-campus WAN. Large networks are typically supported by an Information Services (IS) staff who can provide personal assistance to their users. High-bandwidth WAN links are justified by the large numbers of users that would take advantage of them, as well as the volume of data needing to be moved. In contrast, a branch office network may consist of hundreds of isolated remote sites, each with a small number of users. Transaction volumes and, subsequently, bandwidths are typically low. Financial and geographic constraints make it difficult to provide local support personnel; thus ease of use, system reliability, and auto-recovery are of paramount importance.

Despite these challenges, branch office projects are potentially lucrative because they offer you an opportunity to build a workable model once, and then replicate it many times. To derive the maximum benefit from this economy of scale, you must ensure that your initial model is very well designed and planned for.

This AppNote describes a methodology you can use to plan and develop a model for a branch office server, which can then be used as the basis for an entire branch office network. We'll take a "product development" approach which you can emulate when you develop, deploy, and support branch office networking using Novell products.

Of course, every customer's situation will be unique, involving a different mix of application software, different choices for WAN and LAN infrastructure, and different hardware platforms. The suggestions in this AppNote are intended as guidelines and are necessarily somewhat generic. A follow-up AppNote will present an example of an actual branch office deployment, along with specific planning suggestions.

The Six "P"s of Product Development

When planning the development of a branch office platform, you might want to take the same approach a software vendor uses when releasing a product. After all, you will be combining and testing products and components from different sources, just like product developers do with software modules from different engineers. By establishing professional standards and practices, you'll gain a reputation for credible work. You'll also be able to use your well-designed "product" over and over throughout the branch office network.

The product development cycle can be organized into six phases that we'll call the six "P"s. These phases are:

Planning
Proof of Concept
Prototype
Pilot
Productization
Production

Each of these phases will be described in detail, along with guidelines and suggestions that apply to developing a model branch office server.

Here are a few suggestions right out of the gate. First, give your project a name. Not only does this make it easier to refer to, but it makes the product "real," and puts your project team in a product release cycle frame of mind. When a configuration has been tested and approved, you can freeze it and assign a version number.

Second, in any large-scale deployment, you have an extra tool to help you get the job done: economic leverage. If you are working on a major project, contact representatives from all the vendors you intend to work with. Tell them about your project and solicit their support and advice. You are offering them the opportunity to participate in a multi-million dollar opportunity. If you maintain a relationship with them throughout the life of the project, you will probably find they can help you smooth out many problems.

Planning Your Project

The first phase involves assessing the customer's business and technological requirements and planning your product to meet those needs. For example, through talks with your client you may determine that the new system must be able to maximize system availability, minimize system maintenance, reduce user training time, and perform equally well or better than the current system. Your ideas and proposals to meet these requirements form the basis for your project plan.

Developing a Project Plan

In any project, the first step is to set your goals and develop a written project plan. This written plan serves three purposes:

It defines the functionality required at different stages of the project. You should identify the goals you will meet in the testing phase, what functionality the prototype must exhibit, and the full level of functionality that end-users can expect at product completion.
It helps keep project development on track and on schedule. Knowing what functionality is required at each stage will help you in scheduling tasks.
It can be used to promote your project within your organization. Your project plan represents your opportunity to really "sell" potential clients on the value of your product. Describe the various roles of users, and detail how your product will help managers, administrators, and other personnel to be more productive.

At the outset, you need to determine which server components will be required to support your applications. These might include such things as print services, databases, messaging, transaction controls, and host communications. Your plan should also include a workstation definition that lists any applications the users will need access to, what client operating systems will be in use, and similar information.

Making Technology Work for You

In developing your project plan, consider how you can best leverage available technology to minimize your work in implementing the applications. Here are a few suggestions:

Provide a user-friendly interface. This is particularly important in the branch office environment since, in many cases, users' computer skills are limited. If you provide an easy-to-use, intuitive interface, you can greatly reduce user support requirements. You might want to create a model of the user interface, incorporating drawings, non-functional menus, a simulated desktop, and similar examples. Include screen-shots of your interface in the workstation definition to provide a model for development.
Take advantage of the NetWare Application Manager. If your workstation base is primarily Microsoft Windows 3.x or Windows 95, consider using the NetWare Application Manager (NAM), a technology which is part of Novell's NetWare Client 32 client software. NAM enables you to manage accessibility to any application through Novell Directory Services (NDS).
Use the NetWare login script capabilities. Another commonly-used technique useful on MS-DOS and Windows platforms is to calculate workstation environment variables from system data within the system login script. For example, the login script might map the best location for particular files in the directory structure, then set a variable to equal that drive letter. You can expose nearly any property of NDS from within a NetWare login script in this manner. Another possibility is to look up a physical location and calculate a context based on the workstation's network address. You can use these variables in place of the drive letter in the Windows properties definition or in batch procedures.

Forming a LAN/WAN Infrastructure

Branch office networks often consist of many sites with small user populations. It is usually financially infeasible or logistically difficult to place a network administrator at each site to support these small user groups. Your plan should be to implement a centralized support system that allows minimum staff to work with a large number of customers.

Whether you select Ethernet, Token Ring, FDDI or ATM, the most important consideration is whether your LAN equipment can be remotely managed. In evaluating the potential of each of these topologies, be sure to consider the network management control, information, and alerts that are supported.

You will need some type of WAN to support the users, administer system security, diagnose problems, and respond with solutions. This need not be a full-time connection; you can use a part-time async connection, or piggy-back on an existing network based on X.25, Frame Relay, or SNA. Bear in mind that if you choose a part-time WAN infrastructure, you will probably be able to provide reactive management support only. If you want to take a proactive approach, you must include full-time WAN connectivity in your plan--and in your budget.

Advantages of WAN-Based Remote Support. You can use the WAN to access remote support agents such as NetWare Management Agent and the NetWare LANalyzer agent. These agents run on the server to provide alerts, and they can also perform diagnostics for troubleshooting. You can use the WAN for remote administration and server control. In some environments, the WAN can be used by a help desk organization to provide remote control of users' PCs. Help desk agents can observe users' problems from a remote location to provide advice, do troubleshooting, and perform similar tasks.

Bandwidth Planning. Capacity planning is an important part of the project planning process, especially when it comes to WAN bandwidth. Factors that affect the amount of bandwidth required include:

Traffic loads generated by applications that cross the WAN link
Network management traffic
Link maintenance traffic

In an existing network, you might have a baseline for traffic loads. If you do not, you'll need to do some testing to determine application loads. Network protocol background traffic loads are well documented. You can determine the requirements of other applications with the help of a LAN analysis device such as Novell's LANalyzer or Network General's Sniffer.

If you have many branches and relatively low bandwidth links, consider the feasibility of limiting unnecessary protocol traffic. For example, several possibilities exist to reduce Service Advertising Protocol (SAP) traffic across WAN links: static routes, SAP Filtering, NetWare Link Services Protocol, or NetWare/IP. You'll need to determine which method will work best for the particular customer environment.

Another factor to consider is link latency. Some types of links can introduce unexpectedly long delays across the WAN. This is particularly true when using encapsulation technologies such as NetWare Link/SNA or satellite connections. When you use packet burst technology, read and write performance is little affected. However, directory search times and keyboard response times in utilities such as RCONSOLE might be slowed.

Consolidating Components

Branch office networking offers a significant advantage by enabling you to consolidate functionality into relatively few components. In a campus environment this strategy creates a single point of failure, leaving a large number of users vulnerable in the event of system failure. However, when you use a single server for your branch, it means that there is only one device to troubleshoot. This can simplify and expedite the task of providing assistance via telephone to untrained users. It can also reduce the time it takes for response teams to get a branch back up and running by enabling a "black box" approach to service. In this approach, you replace the entire server, restore the branch to a functioning state, and then troubleshoot the problem offsite.

The ability to do remote troubleshooting is another advantage you gain when you consolidate components in a branch server. If your WAN components reside in the server, a LAN problem will not prevent the server from sending back diagnostic alerts and configuration information. You can gain maximum remote server management by grouping as many of the following as you can in the same box:

Routing components
Network management utilities
Applications support infrastructure such as database, communications, and messaging servers

You can gain additional remote management advantages by grouping out-of-band connections to data communications and the LAN hubs, or by using hub cards to collapse the LAN within the same box.

Weighing Management Control Against Fault Tolerance. Although a single server in the remote site can provide more controlled management, there is a corresponding trade-off in fault tolerance. You must evaluate--on the basis of risk versus cost/benefit--a single server serving multiple functions against multiple servers sharing the responsibilities. In other words, would multiple servers provide the necessary insurance against downtime? If so, does the strategy make financial sense when compared to the cost of an outage?

If you plan to employ sophisticated technologies such as NetWare SFT III, incorporate them into a system-wide fault-tolerant architecture. Evaluate other system components to determine which, in addition to the server, you should duplicate. A fully redundant server does you no good if your only network hub is taken out by a lightning strike.

Monitoring Alerts in a Fault-Tolerant System. When you design a fault tolerant architecture, make sure that alerts are monitored carefully. The fault tolerant features of NetWare often enable users to continue to operate after a failure, placing them in an unwittingly vulnerable state. Help desk agents must be aware of this potential. They should be prepared to react to these alerts, and, if necessary, to send a response team to repair the system and return it to fault tolerant status.

Planning for Novell Directory Services

There are some special considerations for NDS tree design in a branch environment, particularly with respect to partition and replica placement. Since branch offices are by nature remote WAN "tail" sites, you will need to create an NDS partition for each branch office to ensure that users have reasonable performance. The current rules of thumb for partition and replica placement (as recommended by Novell Consulting) state that every WAN site should be represented by a container within the Directory tree, and the container should be a separate partition. Partitions should be physically placed on a NetWare server local to the users. Every partition should have at least one and preferably two replicas, but replica traffic should never traverse a low-speed WAN link. However, it is impossible to meet all of these conditions in a branch with a single remote server.

The recommendation for a single branch server is to create only two copies of the branch's partition: a read/write on the branch server, and a master at a central or regional hub site. If you dedicate a Pentium-class server to the job of maintaining these master partitions, you should be able to store replicas for around 100 servers (the exact number will depend on the specific WAN, site and server configuration, as well as the characteristic of use of NDS).

By using utilities such as PINGFILT.NLM, locating replicas on opposite sides of a WAN link becomes more practical. PINGFILT can limit NDS synchronization traffic to non-working hours, thus reducing the impact of replica traffic on link utilization. The downside of this is that non-critical changes made centrally will not be propagated to the remote sites until after hours. However, this is usually a reasonable trade-off. (PINGFILT and the corresponding configuration utility DSFILTER can be found in the file FILTER.ZIP and can be downloaded from Novell Consulting's Online Toolkit at http://www.novell.com/toolkit.)

Alternatively, you might employ multiple, fully redundant SFT III servers at each branch. This give you a built-in backup of your NDS partitions. However, when developing your tree in this case, be sure to consider the number of subordinate references each of your regional or central servers will need to maintain. Since you won't have a copy of the branch's partition at the server maintaining its parent, a subordinate reference will be automatically created by NDS. Subordinate references are necessary to link the partitions of the tree together when they are stored on different NetWare servers. Each server that contains a replica of the parent but not of the child will contain a subordinate reference and therefore must participate in the replication of the child partition.

For example, say we create a single container with all 250 of our branches represented as sub-containers. Each branch is a partition which is stored on an SFT III server and therefore we have chosen not to replicate it anywhere. The server containing the parent partition will have 250 subordinate references-- one for each branch. This will require the parent server to regularly communicate with 250 different servers for each one to complete its NDS processing. This could make the parent server a bottleneck. Furthermore, if the parent partition itself is replicated three times (as it should be), 750 subordinate references will be created across the servers. Clearly this is not a desirable configuration.

Subordinate references can be minimized by simply limiting the number of branches placed in the parent container to a maximum of approximately 50. This can often be accomplished by creating an intermediate level of regional containers and making each region a partition.

Software Distribution Strategies

While software distribution products nearly always include features to update code on user workstations, a more leveraged approach to maintaining software is to store it on the server. This allows one copy of the code to support all branch users. This strategy dovetails nicely with the NetWare Application Manager included with NetWare Client 32. You will want to use an electronic software distribution tool such as ManageWise/Distribute to minimize the work involved in delivering updates to users. Since you still may need to distribute software directly to the workstations, plan your implementation to do so.

Developing Standards and Conventions

At this early point in the project, it may seem premature to start developing standards and conventions for final deployment. However, it is important to have standards and conventions in place as early in the development process as possible, because their design can directly affect the kinds of procedures you need to develop to deploy your configuration on a massive scale. Even if the standards you implement in the early stages of the project are not final, they offer a framework and provide guidelines for the remainder of the project.

If your project uses multiple designers, standardized design criteria help make integration of various designers' modules easy and seamless.

Naming Conventions. An important standard to define early is one for server names. One helpful tactic is to dictate the convention that every branch server name must be exactly the same number of characters in length. If you can assume that existing and new data involve a one-for-one character replacement, a simple binary file text substitution utility will often be able to safely manipulate unique data fields--such as the server name--in the configuration files of many different products. Although this may not be true in all cases (Windows 3.1x group files are a known exception), it is true in a majority of third-party utilities. You can use this knowledge to make the process of automating configurations much simpler.

Other Candidates for Standardization. You might want to develop other standards to cover volume names, directory structures, login scripts, user names, network addresses, and startup files. For example, if you make every server's volumes and directories identical, routine maintenance (including software distribution) is easier.

Providing Documentation

One of the most important--and most difficult--parts of any project is docu-mentation. Take the time to document every procedure, section of code, batch file, installation, and similar stages in the evolution of your project as you go. Documentation cannot be left as an afterthought.

Your project will need some or all of the following:

Design Documentation. Design documentation specifies the business goals and system architecture, and serves as an overall blueprint for the project. Itlays out the goals of the project and describes the methods by which these goals will be accomplished.
Code Documentation. Insert code documentation as development progresses to identify each module of code, including batch files and login scripts. Code documentation should identify each module's author, describe what the module does and how it fits into the overall system, specify what input it takes and output it generates, list any dependencies it has, and note any caveats.
Support Documentation. Develop support documentation to describe the various levels of support and explain what the support person at each level needs to know to support the users. You can document internal and external escalation procedures, including information about vendor relationships; for example, how to call for service when hardware fails.
User Documentation. Well-written user guides for the system can save you many personal support hours. You might have developed the best product in the world, but your potential customer base will not embrace the new system if they can't use it easily. Make sure your user guide includes accurate information that is appropriately comprehensive for your users. Resist the prevalent tendency to make a few modifications after your documentation has gone to press; this leads to inaccuracy. Be sure the guide includes information about how users can contact their first-line support representatives.

Planning for User Training and Support

Consider the amount of training appropriate for various levels of branch personnel. Naturally, you will have to train the users in how to use the business applications. However, you must also decide what additional training is required to accomplish administration tasks. If a fully centralized management infrastructure is in place, training needs can be minimal.

To help you evaluate training requirements, consider such factors as:

Employee turnover rates
Rate of employee transfer between branches
Employee skill levels
Amount of time employees can spare from their regular tasks

If the rate of employee turnover is high, or if employees frequently transfer between branches, it might not be cost-efficient to provide specialized training. If branch employees are not computer literate, you may have to provide additional training just to enable them to understand system administration training. Keep in mind that small branch offices can be busy places, and finding the time to help out with a computer problem can sometimes be difficult.

If these typical problems exist in your branch offices, do everything you can to minimize training for remote employees by creating an infrastructure that is, as much as possible, centrally supported. You can also reduce training require-ments by taking simple steps, such as labeling equipment plainly. This enables help desk agents to instruct users by phone without having to explain what a "monitor" or "CPU" is.

The size of a central staff to required to manage the network will depend on a number of factors, including the number and type of applications running at the branch, the services they rely upon, user counts, and the dynamics of the user population, among others. To get an idea of what it will take to support your intended user population, you can identify the typical support activities (such as creating a new user, unlocking a locked account, resetting a lost password, updating software drivers) and measure the time to complete them. Your help desk should also maintain a relationship with your systems personnel to pass along information about the most common user issues so that the system might be enhanced accordingly.

Service and Support Contracts. Another area for planning involves investigating external sources of support. Investigate your business carefully to decide what level of support you will need to provide. Many hardware vendors offer support contracts that have different costs associated with various response times. For example, if a branch can afford six hours of manual operation, it can realize a substantial saving when compared to a contract requiring a two-hour response time.

Discuss with the customer what the likely financial impact of various lengths of outages would be, compared to the costs of various levels of service. Gathering and evaluating this type of information will help enable you to suggest the most cost-efficient service plan that a particular business can tolerate.

Help Desk Planning. Plan your support system carefully. Define your first level of support and decide what tools to put at their disposal. Establish an escalation procedure that details how much time an agent should devote to solving a problem before escalating it, who the problem should be escalated, and what level manager should be informed under different types of circumstances.

Contingency Planning. Mission-critical systems should employ some level of contingency planning in the event of an unexpected outage or disaster. Prepare a plan that will enable a business to maintain operations if an outage exceeds a predetermined time. You might be able to use a number of different implementation strategies, such as:

Off-site redundancy
Manual procedures
A limited version of automated procedures (off-line processing)

Make your contingency plan a part of your escalation procedure. Develop parameters that specify when the plan will go into effect.

Note: You will need to provide appropriate user training to cover thecontingency plan. It will likely be a long time before this training isactually put into practice, so the need for clear and precisedocumentation is critical.

Software Version Definition and Change Control

Finally, plan your project's version numbering scheme, including a change control protocol to specify when the version number should be incremented. You might want to design a form to help you keep track of the progress of your total system as it moves through various releases. Implement a method for keeping track of levels of functionality and known bugs for each discrete release. Keep track of file dates and versions, parties involved, testing reports, special installation instructions, and so forth. Also decide on a standard for keeping track of which versions are installed at the various branches.

Proof of Concept

Once you have planned the necessary application and infrastructure components, you need to identify which components have to be proven. In a branch office environment, there are many components that must be integrated. You'll need to test each of the system's products individually, and then test together any modules that rely on other modules. Fortunately, you do not have to prove every one functional right from the beginning.

Identifying Components for Testing

You do not need to test every single component of a solution during the proof-of-concept phase. Through your prior personal experience, you will already know how many of the component parts operate. Therefore, the first task is to identify which of the many modules that will be used need to be proven.

First, identify any components that are new or untested. If you are not sure whether a particular component's functionality is suitable for your purpose, put it on your list to test. You should also consider proving never-before-tried combinations of well-understood technologies.

Identify any areas of the design where you expect do new development. If you plan to use new features contained in a new software release, plan to test them to be sure they operate the way you expect. If any areas of the design need improvement, consider what additional testing requirements will arise from the design revisions.

If you intend to use proven software on an unproved system, that will also require proof of concept testing. For example, you might have confidence that NetWare Link/SNA works, but if you have never used this product in your customer's particular SNA network, add them to your list.

Creating a Test Schedule

Whenever possible, plan to test components singly until they are proven. Once a component has been proven individually, you can use it in conjunction with other components. It is helpful to create a hierarchy of dependencies. This will help you plan the order in which to test various components.

For example, once you have proven NetWare Link/SNA works as required, and you know that ManageWise works for your purposes, you can test the two products together to be sure they work jointly as required. Thus one item on your proof-of-concept schedule would be to test ManageWise over NetWare Link/SNA.

To flesh out your proof-of-concept test schedule, estimate the amount of time you will need to test each of the modules and components on your list. Include the time you will need to create any infrastructure required to support your testing. Build in some time for fixes and workarounds. Schedule target testing dates.

Testing the Components

The type of testing that should be performed at this stage is called "Unit Testing". This means that your tests should, as much as possible, test one and only one component at a time.

For example, say that three items on your testing schedule are to test NetWare for SAA, the NetWare Multiprotocol Router (MPR), and Data Link Switching (DLSw). You could try to set up NetWare for SAA to use DLSw through an MPR to test all three at once. Resist this temptation. If it works, you will have saved a small amount of time. But if it doesn't, it will cost a great deal of time as you now have to troubleshoot three different newly-installed components.

Once a component has passed unit testing, you can then confidently use it in conjunction with other components in other tests. If components fail, either individually or when tested with other components, identify and implement fixes and workarounds.

Prototyping

Once the proof-of-concept phase is complete, you can move confidently to the prototyping stage. During the prototype stage, you weave the key elements of the design into the "first rough," manually joining the individual pieces into an assembly that simulates the actual configuration that will be installed into a branch office.

This phase is very dynamic. During prototyping, you will probably discover many areas where the original system design will not meet user expectations or administrator needs. The insights you gain during prototyping might cause you to modify the original design many times in order to address newly identified issues. Identifying problem areas is the primary purpose of the prototype phase.

A paradox of this stage of the project is that you should be working hard to cause problems. You want to discover any potential weaknesses in the design and in all the involved products. This enables you to document real or potential problems, and to make any design modifications that might be necessary to resolve them.

The necessity of resolving such problems lies in a statistical fact. If you have a problem which occurs randomly on an average of six month intervals, you might be able to tolerate it if only a single server were involved. However, in a branch network with 350 servers, that same problem multiplies to about two occurrences every day. This clearly illustrates the need to develop a strategy for identifying and resolving even seemingly small problems before they reach the field.

Doing Your Own Quality Assurance

It might seem like a waste of time to do your own quality assurance testing after a vendor has already done theirs. But as the IS world continues to embrace commodity hardware platforms and open software solutions, the number of system permutations is expanding to a point where it is impossible for any vendor to test every one. The key is to find a configuration that ensures that the combination of products used in your proposed solution is stable and reliable.

It is an industry maxim that any complex piece of software is never finished. As a software company, Novell is committed to continuously improving our products by actively finding problems and resolving them, and to continuously enhancing our products so that customers can do more with them. As a customer or a consultant, your responsibility is to make sure that the system you deploy adequately solves your business needs or those of your client.

Basing Your Test Plan on Performance Expectations

Identify a baseline expectation of the amount of activity the system will be put through on average. For example, in a bank's branch office, a teller is expected to perform one transaction every three minutes. From that, you can project that a teller working 8 hours a day, 5 days a week, 50 weeks a year will process approximately 40,000 transactions per year.

Accordingly, you might design a simulation program that performs twelve transactions a minute, 24 hours a day, for a total of 17,280 transactions in a testing day. In three days of testing, your simulation program will perform 51,840 transactions, exceeding one year of actual teller transactions. Using this example, a two-week continuous successful test will simulate over six years of expected operation. Of course, such a test plan does not take in to account every factor, and some problems might take longer to develop. But this type of stress testing can help you discover such things as subtle timing problems, memory starvation, and unanticipated system states.

In addition to design flaws, your stress tests will almost inevitably uncover integration issues. When you assemble a new permutation of software modules (whether new, existing, or a combination of the two), something will probably not behave as expected. This is a normal--in fact, desirable--result of the testing process, since your goal at this stage is to discover and circumvent potential problems before they get to the field. Regardless of whether the problem arose during stress testing or during integration, be patient and adopt a systematic approach to problem identification and resolution.

Keys to Problem Solving

Develop a system that will enable you to identify and document problems and their solutions. You might first want to classify problems. A problem that happens once during development of the prototype might never happen again. The problem might be the result of modules being loaded in an unusual order or at an unusual time. On the other hand, it could be the first occurrence of a persistent issue. As a rule of thumb, random problems are usually associated with hardware; recurrent problems are usually associated with software.

Apply the following questions to any given problem:

Does the problem seem hardware-related (random)?
Does the problem seem software-related (multiple occurrences)?
Can I reproduce the problem?
Is there a fix or patch available?

Document the Problem. Carefully record each problem, describing in detail what occurred. Include any information that the host operating system provides regarding the fault. Note any circumstances that you believe could have led up to or contributed to the failure--for example, a sequence of console commands or menu choices.

Try to Reproduce the Problem. If you can reproduce the problem, take extensive notes as the problem occurs. This will help you, or technical support personnel, to solve the problem. If you cannot reproduce the problem, it might never reoccur. Set aside any documentation you have already gathered and wait for at least a second occurrence before contacting support.

Check Your Own Problem Documentation for Similar Cases. Check each problem against those you have already documented. If a similar problem occurred before, especially if it is associated with common reported data (for example, the same running process and instruction pointer for an ABEND, the same module and address for a Windows GPF), it is probably software-related. Report such problems to technical support as soon as possible, giving them all the information you've been able to gather.

Check Online Resources. Before contacting support, check online information sources for updates or patches. For example, you can check NetWire on CompuServe (GO NETWIRE) or Novell's Support Connection at http://support.novell.com. For third-party software and hardware drivers, check the original product documentation, or try GO HARDWARE or GO SOFTWARE on CompuServe or the Internet. You can also use a search engine such as Yahoo at http://www.yahoo.com. You might find that the problem you are experiencing has already been addressed, and that a published patch will resolve the problem. Apply any patches you find, then attempt to reproduce the problem again.

Take notes of everything you try and what the results are. That way, if you are not able to solve the problem yourself, you will easily be able to relay the history of your problem to Technical Support. This helps eliminate repetitious attempts at problem solving, and will go a long way towards keeping your project on track and moving forward.

When to Call Technical Support. If you have exhausted all of the remedies described above and still cannot resolve your problem, it's time to call for tech support. When you contact a technical support organization, you will receive the most efficient service if you have all your documentation information ready before you call. Technical support personnel will probably need the following information:

Names and version numbers of the involved software modules
System configuration
Expected performance and exactly what is not working as expected
Any system messages
How much is affected (the entire system, or just one function)?

Is the machine still responding to keyboard input?

Note: To test this, press the Caps Lock key. If the associated light goes on, the system is still responding, at least partially, to keyboard input. If this is a NetWare server, try to get into a debugging mode for further analysis.

Be prepared to fax diagrams of the software, hardware and network topology if requested.

You might find it helpful to develop a procedure or form based on the suggestions above.

NetWare Server Core Dumps. In cases of severe NetWare server problems, you might be asked to send a core dump to Novell. A core dump is an image of memory that Novell Engineering can analyze. Although analysis of a core dump cannot solve every problem, it can often provide information that leads to an ultimate solution.

Every version of NetWare starting with 3.12 can place a core dump on the hard disk. It can only do so, however, if there is more free space on the DOS partition than the size of memory on the server. When you plan and build your server, try to make sure you have enough free space on your DOS partition to hold the core dump, in the eventuality that you ever need one.

Note: You cannot write a core dump to the DOS partition of a NetWareserver after the REMOVE DOS or SECURE CONSOLE command hasbeen executed at the server console.

If you find that you need to create a core dump on a server that has not been prepared with a large enough DOS partition for this purpose, you have three options:

Install another hard disk temporarily as a "D:" drive
Install another LAN card, but before starting the server, log the server machine in as a workstation to a second server. (In this case, you will need to use the NETALIVE.NLM to keep the NetWare watchdog timer from logging you off the second server.)
Put core dumps on multiple diskettes. (This is your only option if you are using a NetWare version earlier than 3.11.)

To minimize the size of the core dump file, try to create a ZIP archive before sending it to tech support. The NCS Toolkit CD contains a file called ZIP.NLM. When you run this file on a NetWare server, you will be able to read a core dump from the DOS partition and write a compressed version to the NetWare partition, where a workstation with a modem can pick it up to upload.

Note: If you are working with a NetWare 3.11 server, in anticipation of anABEND, you can install the HDUMP.NLM to allow you to write coredumps to the DOS partition on the server.

Elicit Vendor Support. You might have several vendors who are involved with the identified problems. In this case, try to catalyze relationships between the various vendor representatives. Initiate individual calls to each of the vendor representatives. Give each a brief overview of the problem and a description of any solutions you've tried. Let each representative know that you are in touch with the others and offer contact names, phone numbers and incident numbers.

If the problem is so involved that individual reps cannot solve it by working with each other or with you on a one-to-one basis, arrange a conference call. The conference call can provide a forum for the involved parties to discuss the issue, and arrive at a strategy to resolve it. Once the right parties are identified and have begun to work together, they often arrive rapidly at a solution.

Your job is to put the appropriate parties in touch and, once they've begun working on the problem, to monitor their progress and do whatever you can to facilitate the process. Do your best to understand any obstacles the respective parties perceive and to eliminate them if you can.

Refining the Design

As a result of your testing, you will probably discover that a whole series of design revisions will be necessary to support the proposed configuration. This is not an indictment of your planning or of the quality of the software products involved. It is simply a reality of integrating disparate systems developed at different times.

Be sure to document everything you have learned about file updates and operating system patches. The system you are building will become a monolithic unit, with an associated version number. This number help you track problems down to specific revisions of your system, and know with certainty which revisions of the component modules are in use when calling for vendor support.

The Final Prototyping Phases

During the early prototyping phases, all the testing is "white box", meaning that individual functions are tested by their implementors to insure that they operate as specified.

"Black Box" Testing. Towards the end of prototyping, the first "black box" testing is done. In this phase, users evaluate how the system is performing without any knowledge of how the product is constructed on a code or component level. This phase is sometimes called "pre-pilot."

Usability Testing. Plan to include some usability testing during this phase. These tests can be formal or informal. Make a list of the particular aspects you want users to test, and any questions you want to ask as testing progresses. Use this time to find out whether users are comfortable with the new system, whether they can use it relatively intuitively (or at least find answers in your documentation), whether they understand system messages they might see, and whether they feel that it is an improvement over what they have. Ask them for their input on how to make the system work better.

Assessing the Success of the Prototype

The most important success indicator at this time is whether the system performs predictably. If you are still finding problems that you don't expect and can't understand, you need to do more work before you can proceed to the next phase. The goal is for all problems encountered during usability testing to be easily understood and explained, and workarounds or fixes that are easily implemented. Any remaining problems can be fixed during the pilot phase.

When you identified your customer's requirements in your project plan, you defined specific goals and acceptance criteria for this, and other, stages of the project. If you have met all of the goals and requirements outlined in your project plan for completion of this phase, you can end the prototype phase and move on to the next phase--the Pilot.

The Pilot Phase

Your prototype testing proved that the selected technologies can work together as expected. The pilot phase represents the first time that your new configuration is actually tried in a real business environment. Going into pilot testing, you need to do several things:

Maintain your standards and conventions
Build the pilot system
Identify a pilot site
Plan pilot testing and support

Maintaining Your Environmental Standards

It is very important that beta testing continue to adhere to your predefined standards and conventions. These are the guidelines along which your product has been designed, developed, and tested. To ensure predictable and successful pilot results, you must be able to ensure continuity of environment.

Building a Pilot Test System

The pilot will require that you manually construct a system that emulates the intended branch configuration as nearly as possible. The more closely your test system resembles the intended business environment, the more reliable your testing results will be, and the more nearly they will be a true representation of what might happen when the product is put into actual use.

Identifying and Working with Your Pilot Site

There are some traditional rules of thumb to follow when seeking a pilot site. The more of them you can satisfy, the easier and more successful your subsequent relationship with the pilot site is likely to be:

Choose a site with which you have a good relationship. Leveraging existing good relationships helps ensure patience and tolerance on all sides if things don't go exactly as planned. The best way to insure user cooperation is by disclosure. Setting reasonable expectations will go a long way toward maintaining their willingness to work with you. Make sure users understand that this is a pilot, and that you would like their help. Often they will become excited about the opportunity to provide input into the new system.
Choose a site that is close to the supporting center. An ideal pilot site is geographically close to the supporting data center. You will be able to respond most quickly to problems if they arise. If you need more support or more equipment than you have carried to the site, it is easier and more expedient if your source is nearby.
Provide onsite support. Managers of the pilot test should remember they are working with a business unit which has graciously agreed to allow testing of your product to interrupt or slow their normal work. Although some impact is inevitable, onsite support can help minimize interruptions to the normal flow of work at the beta site.

In addition, having your own support person on site ensures that, if problems occur, someone is there to do accurate assessment of the problem, and if necessary, onsite troubleshooting. A user's report of some aspect of the application not working might indicate a bug, but can just as easily represent a lack of training. Although it is not strictly necessary for your engineers to be at the pilot site, they shouldat least be easily accessible and prepared to offer help if unforseen problems occur. If your onsite support person is not able to troubleshoot a problem successfully, he or she can describe the problem and any remedies tried to the engineers, then perform any remedial procedures or routines they suggest.

In exchange for their help and inconvenience, the pilot site usually receives something in return. Traditional trade-offs include lower cost on initial units, extended support packages, and similar considerations. The pilot site also gets the first chance to use the new and improved system, which, if it performs as intended, should improve their business productivity or bottom line.

Documenting the Pilot Test

Remember to document your pilot phase, just as you did in the earlier phases of the project. The implementors of the system will undoubtably identify some areas that are not currently addressed, but should be.

For example, you might realize that because of installation errors on your pilot system, you need to identify which workstations are hosting which remote printers. If you have documented this need, you might later create a batch file that both loads NPRINTER.EXE and sends a message to the server console, helping you identify unintended duplicates.

Testing the Process

At the same time you are testing your hardware and software components in the pilot phase, you should be testing the process in general. When you have installed your pilot system in the branch office, try to gather information that will help you assess the success of your project from a user's point of view:

Is their reaction to your product generally enthusiastic?
Is it fairly easy for them to learn the skills or procedures they need?
Are users able to understand system messages?
Do they know how to contact the help desk if necessary?
Is help desk response timely and appropriate?
Do technical support people seem well trained and familiar with the product?
Can support agents quickly identify a user's problem, then coach him or her to a resolution over the phone?

To determine the answers to some of these questions, you might want to plan to simulate some problems. For example, you might install a bad cable or install inadequate memory in a server. The practice drills that result can ultimately benefit both the help desk agents, who gain skill and confidence by solving actual problems, and the users, who learn how to obtain help and come to know that they can rely on your support system.

Testing Your Software Distribution Strategy

This is also the time to test and verify your ability to deliver software updates to the branches. A solid method must be in place, since software distribution can become critical in a pilot phase, when fixes and updates are likely to be necessary to finalize the system. Your software distributions should also pass through a change control step to ensure that any changes are reflected in the final system's configuration, as well as in the version number assigned to it.

Software distribution has three phases: delivery, installation, and verification. Ensure that your infrastructure will support all three of these functions for each area the software will have to be delivered to. This might include remote servers as well as all clients.

Part of your standard methodology for software distribution must be a contingency back-out strategy. For example, you might define that all downloads must be tested in a particular, geographically nearby location, before being deployed widely. You might also define that files will not be overwritten, but rather renamed so that a short downloaded job could easily back out the changes.

In your pilot deployment phase, create a list or a database to keep track of where to deliver software updates. You can do this procedurally by keeping detailed records during installation of each new system, or you can use a network service such as the NetExplorer process of ManageWise. It is always easier to do this as you install, rather than trying to create the database after the system is in place.

You will find that different distribution targets will have different requirements. In general, it will be easier if you can minimize the number of targets to distribute to. You may still need to send driver files, registry modifications or other operating system critical updates to individual workstations. Leveraging the common file system of the server for application files can greatly reduce the workload imposed by software distribution.

For example, say your branch environment has 350 servers and averages 40 users per branch. You could send out 350 copies of a word processor update to the servers, or you could send out 14,000 copies to the workstations. Either way, 14,000 users will be calling if something goes wrong. But you should be able to fix the problem a lot more quickly if you only have to recall 350 updates.

Evaluating the Success of the Pilot System

Evaluate your pilot phase to determine whether it meets the predefined technical and business goals of the project for this stage of development. If it does not, it is not the end of the project. It just means that the results need to be reevaluated and the goals readdressed. It is not uncommon to repeat a pilot phase several times, until the objectives of the project are met.

Once the pilot is accepted, the next phase is to determine how to deploy this project en masse. This part of the project can be called "productization."

Productization

Most software vendors use the term "productization" to mean the phase of software development wherein the technology is "hardened" so that it can be delivered to customers who might have a wide variety of systems that need to be supported. In a project such as we are discussing, productization involves the same issues, but with a much narrower scope.

Defining Your "Cookie Cutter"

In the early stages of productization, you develop a strategy that will enable you to deploy your software configuration across the entire network. You'll need a custom installation process that automates as much of the process as possible. This installation method is called the "cookie cutter" approach.

Your current software, beta tested and revised as appropriate, is the model for your cookie cutter. In turn, this cookie cutter enables your server factory to turn out servers of this particular "shape" or configuration.

While your cookie cutter defines the basic shape of your server "cookies," you might find that you have to make your cookies in several different "flavors" as well. This can occur if different areas of your customer's operation require different software components. The best way to deal with different flavors, if licensing will permit, is to create a single superset configuration, then build in different options to accommodate the different operations required in different areas. The advantage to this strategy is that you don't experience any "forking" in the development process; you are always working on only one finished product, not several.

Another advantage involves the observation that the different software needed for different regions might not stay the same over time, due to factors such as company mergers or other organization divisions. Frequently, it becomes desirable to move toward a more homogeneous configuration. Creating a superset of the desired software facilitates this.

Balancing Efficiency and Flexibility. As you develop the cookie cutter that will determine what your servers look like, and the built-in options that determine the server's "flavor," your options range from the fairly simple (which might be just a documented process) to the complex (an entirely automated procedure that uses business data to derive system configuration information).

Although a simple documented process offers the greatest flexibility, it introduces human judgement into the process. Therefore, it also allows for the introduction of human error.

A highly automated procedure, on the other hand, has the advantage of being more limited in scope, with a correspondingly lower possibility of configuration errors. It speeds up the deployment process, and automatically enforces standards and conventions. Once started, your automated system can run unattended for as long as necessary to build a server, leaving the installer free to go on to the next one, or on to other tasks.

Creating a comprehensive automated installation is not for everyone. You must weigh the expense of developing this type of cookie cutter against the number of systems to be configured to determine if the cost of developing such a system makes sense. A ten-server system would probably not justify creating automation to build the systems, whereas three hundred identical servers easily makes a good case for automation.

For some applications, a hybrid approach might offer the best compromise between efficiency and flexibility. This type of cookie cutter might require some manual steps, but most of the manufacturing procedure can be completed automatically. Although you achieve the greatest efficiency by automating as much of the task as possible, there is a trade-off in reduced flexibility. The more of the process you can automate, the fewer configuration variations will be possible. However, with reduced numbers of possible configurations comes reduced risk of error.

The Fully Automated Procedure. One approach is to automatically translate business data into network parameters; this helps prevent configuration errors. As a simple example of this type of system, suppose you need three IPX addresses for each of your branch offices: one for the LAN, one for the WAN link, and another for the server's internal IPX address. Your installation pro-cedure might query the user for a three-digit branch number and then calculate the addresses that need to be configured based on your numbering standards.

The "Database" Approach. Another approach might be to build a simple "database". This database can be as unsophisticated as a batch file or a menu containing a series of choices (such as the names of locations) and the associated data. An advantage to this type of system is that, if a problem does arise during setup, it can be easily tracked back to the database and manually corrected, if necessary. An example of a batch file acting as a database is shown below:

@echo off

If NOT "%1" == "" GOTO GETDATA

ECHO USAGE: CFIGSVR <mailstop<<
GOTO END

:GETDATA

GOTO %1

:OFC-124

SET SERVERNAME=STL

SET IPXPREFIX=0124

SET IPNETADDR=161.35.124

SET WAN=FR

GOTO STARTBUILD

:OFC-054

SET SERVERNAME=MIA

SET IPXPREFIX=0054

SET IPNETADDR=161.35.54

SET WAN=X25

GOTO STARTBUILD

:E-10

SET SERVERNAME=E10

SET IPXPREFIX=1010

SET IPNETADDR=161.37.101

SET WAN=NONE

GOTO STARTBUILD

:STARTBUILD

...

Being able to take advantage of such a sophisticated installation process requires much advance knowledge about the site that it is to be installed into. You might want to include within the project plan a step that you can use to schedule the gathering of this type of information.

Hardware Considerations

The fewer hardware platforms and configuration variations you must support, the simpler your task will be. To make this phase of development as easy as possible, try to standardize your hardware on a limited number of configurations, comprising a specific number of combinations of hardware and accessories.

If you try to support every possible IBM-compatible computer, and every possible configuration option, you will need to do as much development as a commercial software vendor to accomplish your deliverable. However, you will find that the number of possible configurations is naturally limited by your documented standards, by your predefined design criteria and tested product, and by the practical and financial constraints imposed by your client, leaving you with a more limited, and more easily manageable, number of options.

Most computer models undergo some changes, or even become completely unavailable, every 24 months or less. Your typical branch project may last three years from conception to roll out. Near the end of that time, the hardware you began with might be unavailable or obsolete. Keep this in mind as you decide on which hardware platforms to support.

The Four Phases of the Cookie Cutter Process

When a cookie cutter is used, the process passes through four distinct manufacturing steps, taking your system from raw materials (new computers) to finished product (a branch server). These steps are:

Installation
Testing
Interaction
Configuration

The Installation Step. During this step, you will physically install accessory hardware and your software on the system that will be sent to the client's site. Hardware configuration should follow strict standards, including which boards belong in which slots, as well as switch, jumper and other configuration settings. You can accomplish software installation via standard installation methods. However, a bulk file copy, programmatically controlled automated process, or a restore from archival storage are better alternatives since they will minimize the possibility of introducing human error.

The Testing Step. Computer hardware has a natural "infant mortality," meaning that, if hardware is going to fail, it usually does so within the first 72 hours of operation. Although hardware manufacturers test for this, they cannot anticipate what combinations of other hardware you will use with their systems. Each component you install statistically increases the likelihood of a problem occurring. Therefore, it is a good idea to set up a test bed for hardware stress testing before final installation onsite. This helps protect your investment in manpower to deliver equipment to the sites.

Testing also includes bringing up the hardware and software in a "test bed" environment--a simulated branch office. This should include simulated connectivity to central systems and simulated client activity. This implies that the software will be configured initially for the test bed and not for the actual branch it is destined for. The final configuration is handled in the next step.

The Interactive Step. Up to this point, the process has been an assembly line style procedure, where each server is built exactly the same way. During the interactive step, you or your installation staff will run a procedure which will present them with menus to enter data about the actual operating location for this system. In a highly automated system, this might ask for a branch number and calculate or look up the details. In a less automated system, it might get very specific about network numbers and addresses. If you have chosen to do a cookie cutter manually through documentation, the interactive step is the same as the configuration step.

The Configuration Step. Once you have specified the configuration parameters in the interactive step, an automated process takes over and completes the actual configuration of the server, in preparation for transport to the branch site.

After your testing is complete and you are ready to install the system at the customer's site, you will customize the installation based on the specific system configuration parameters for the operating location.

An Example of How the Four Steps Might Be Accomplished. A typical final assembly and testing process might go as follows:

An installation team assembles the hardware.
Through a tape restore, an automated system creates a server that is pre-configured for the factory test network.
The server is brought up on the test network.
After the server has passed all acceptance tests, the installation team runs a customized configuration process. This process asks business questions, such as the destination branch number, looks up the related communications information in a table, then automatically changes the system configuration parameters from those required by the test site to those matching the requirements of the operating site.
The system is brought down and transported to its final destination.

One Last Test

A wise step is to pilot the productized system. This final pilot offers an oppor-tunity to address any lingering issues before the system goes into production, and to assure that the installation processes are sound. Once any final issues are identified and addressed, the system can be approved for production.

The Production Phase

Once your technology has been tested, proven, and accepted, the next step is to develop a strategy for deployment of the production system. This strategy should include all the necessary steps to address the technical requirements of the customer site. We'll divide our discussion between pre-installation issues and final installation of the operational system.

Pre-Installation Issues

Meeting with the Site Manager. An integral part of the pre-installation step should be to arrange a meeting between your deployment manager and the branch site manager. You might need to give the branch manager an overview of the project, explain how it will benefit the business operation, and arrange for a site visit. Solicit information about branch needs and issues, either at this time or when you visit the site. Knowing any special problems or requests in advance will help you to satisfy the branch requirements.

Also solicit information about local requirements from the site manager. These might include union regulations, building and fire codes, asbestos abatement laws, and similar conditions. The site manager probably will not know these regulations, but he or she might be able to direct you to the appropriate local agencies.

Find out what level of contact and notification the site manager wants to have during pre-installation and installation. Ask if he or she would like copies of your schedules, lists of contractors, and so forth. Be sure the branch manager knows the name of the liaison officer and how to reach that person at all times.

Site Inspection and Preparation. One of the most critical phases leading up to installation is the preparation of the site. You will need to provide for certain physical and environmental requirements to ensure your system's optimal operation. Some of these needs might differ somewhat from site to site. In addition, you might find that the existing physical conditions vary considerably from site to site.

To provide for your system's physical needs, you should:

Draw up a list of known physical or environmental requirements.
Arrange with the branch manager to inspect the operation site (or delegate a qualified individual to do so) and compare existing conditions with your list of requirements.
Note, in detail, any changes that will need to be made.
Draw up a timetable for any pre-installation work that will be done.
Arrange for the appropriate contractors (or other qualified individuals) to perform the work.
Identify a liaison officer to provide communication links between the contractors, you, and the client organization while site preparation is ongoing.
After all site preparation work has been performed, inspect the operation site (or delegate a qualified individual) to ensure that all preparations are complete and correct.

Environmental Considerations. On your list of physical and environ-mental conditions to check and prepare, you might have items such as these:

Where is the receiving area? Is it adequate for your needs? Are there any special procedures (such as notification upon arrival) to consider?
Will the new equipment be stored in an area other than its immediate operating environment after being delivered to the site? If so, where will that be, and what modifications, if any, need to be made to that area to safeguard the equipment?
Where will old equipment and furnishings be stored until parallel operations are over? How will it be transported from its present location to storage?
Is any auxiliary receiving or transportation equipment (such as hand trucks or carts) needed? Is it readily available and in good repair?
Are any furnishings (such as tables, cabinets, media storage, etc.) required in the operating area? If so, will the client provide these, or will you be responsible for procurement? Is any carpentry work required?
Is any additional or auxilliary lighting needed?
Is an Uninterruptible Power Supply (UPS) unit part of this installation? If so, are there any additional physical support considerations arising from this? Can additional UPS space and power requirements be met? Where will the UPS unit be located? If remotely, what other considerations does this raise? Are there any special UPS cabling requirements (alarm interface cabling, shielded cable, flexible conduits, etc.)?
Is space adequate for all equipment and necessary clearances? (You might want to take a list of equipment sizes, a steel measuring tape, and a graph pad. Lay out your equipment to scale on the pad to make sure there are no unanticipated problems. Look for inconveniently placed doorways and door clearance, support beams, or other obstructions. Check current outlet positions and mark those on your sketch. Mark any additional outlet positions required, both on the wall and on your sketch. Be sure to differentiate electrical and telephone outlet markings clearly.)
Does the site require special or unusual cabling or wiring? If so, what kind(s) and of what length(s)? Remember, in most jurisdictions, fire department regulations approve power strips only for temporary use. You should plan for a sufficient number of outlets and enough electrical capacity for your equipment.
Are temperature, humidity, and air quality requirements within operating limits for all equipment? What HVAC considerations need to be satisfied?
Is power adequate for anticipated current draws from server and auxiliary devices? If not, how much additional power is required?
Is any electrical work needed (dedicated circuits, grounded outlets, voltage testing, and so on)? What impact do local building, fire, and asbestos abatement codes have, and how will you accommodate those?
Is there an existing WAN? If so, does it have sufficient bandwidth for the new applications? How is the existing WAN connected to the central site? If you reuse a circuit, does it affect your ability to back out a change if necessary? For instance, if you are currently using a 56Kbps digital leased line to connect to your IBM mainframe front-end processor and you change both ends over to a pair of routers, what will you have to do if the installation goes awry and you need to back out?
What kind of data communication devices exist (modems, DSU/CSUs, MUXes, and so on)? Are others required? Do any special requirements arise because of these devices?
Are any extra telephone or data lines required? If so, mark jack locations on your sketch and on the walls. (Be sure to differentiate electrical and telephone outlet markings clearly.)

This is not necessarily an exhaustive list, but it gives you an idea of some of the things you should be looking for when you inspect the site.

When you have your list drawn up, share a copy with the branch manager. If any action is required of the manager or of other branch employees, make sure the manager is aware of your expectations, and is in agreement with them. When you have identified your contractors and know when they are scheduled to perform their work, you might want to share that information with the branch manager as well. Be sure the manager knows the name of the liaison officer and how to reach that person at all times.

Developing a Time-Relative Schedule. A time-relative schedule doesn't contain dates, nor should it change from site to site except in occasional cases. Once you have defined your basic server "cookie cutter" and you know how long it takes to build your servers, you can develop a schedule that you should be able to apply to most branch installations. Your schedule might look something like this one:

Item	BeforeInstallation	AfterInstallation
Introductory conversation with branch manager	8 weeks
Initial site inspection and creation of "work required"list and schedule	7 weeks
Get commitment from all required contractors	6 weeks
Carpentry work begins	4 weeks
Electrical contractor begins	3 weeks
Heating, ventilating, and air conditioning contractorbegins	2 weeks
Telephone/WAN line installation	2 weeks
LAN wiring contractor begins	12 days
Server software installation and testing begins at staging site	10 days
New stock furnishings and cabinetry are deliveredand set up	8 days
Final site inspection and remedial work	1 week
Hardware delivered to site	2 days
Transition manager arrives	1 day
Physical installation of hardware and software	6 hours
Empty containers are removed	2 hours
System changeover	Installation Complete
Training team arrives		9 hours
Transition manager leaves		2 days
Legacy equipment is removed		2 weeks

Working with Subcontractors. Talk with your various contractors and briefly explain the work being done. This will enable the contractor to tell you whether his work has dependencies on any of the other work being done. This, in turn, helps you to schedule your contract work.

Your contractors will undoubtedly need to see the site before they can give you a time and cost estimate. You might have to make arrangements for more than one site inspection in order for your contractors to do this. You might want to be present to answer questions, or you could schedule the contractors to come in separately and provide you with a report later. When you draw up your schedule, be sure to allow more time than you think need. Many things can go wrong, from contractor delays to unanticipated site problems. If you are installing in an operating location, keep in mind that business in progress will probably slow down your pre-installation and installation work. Remind your installation technicians and your contractors to be sensitive to this fact. You might want to speak with the site manager about doing some of the more disruptive work during non-business hours. Of course, this might involve time-and-a-half or double-time pay for union workers. Be sure to have these figures available before you talk with the site manager. Make copies of your floor plan and distribute them to all contractors. Be sure the locations of all new equipment, carpentry, lighting, outlets, and so on are shown and labeled clearly, and that the contractor understands what is expected of him. In addition, recreate the floor plan in an electronic format if possible. This enables you to integrate the floor plans into ManageWise as permanent location maps.

Developing the Actual Schedule. After you have talked to your subcontractors and finalized your time-relative schedule based on their availability and estimate of time it will take to do the required work, you can draw up your actual schedule. Simply begin at your target installation date and work backwards, filling in the actual dates on which various phases of the work will be done, based on the time allowances in your time-relative schedule. In the early stages of deployment, be sure to allow more time than you expect things to take.

Plan to deploy the first 10 to 15 percent of sites as your initial roll out. After those sites are in place, evaluate the experience and findings of your installation team. Resolve any issues and incorporate those fixes into your process, then retest at the existing sites. When you are satisfied, you can start to deploy multiple sites at the same time. As your installation team becomes familiar with the system, you should be able to compress your schedule somewhat. You might want to create other installation teams so that deployment can be accomplished more quickly.

The Final Site Inspection. When all the contractors have finished their work, visit the site to make sure everything has been done according to specifications. Take your checklist with you, and make sure that all environmental requirements have been satisfied. Try to schedule this visit for a week or ten days before your installation date. In the event that any work has remained undone or is not done satisfactorily, this will allow you the time to address these outstanding requirements. Plan to reinspect the site after any remedial work is finished.

Building the Branch Office Server. When you have determined that all site preparation has been accomplished, your installation "factory" can build the branch's server. Take the time to do a burn-in test, ensuring that the hardware is past its "infant mortality" period. When you are confident that the hardware is reliable, you can repackage it to ship it to your target branch.

Putting the New System into Operation

Finally the day arrives that you have been working toward since the project's inception. Your system has been thoroughly tested, it has met all the predefined criteria that define its completion, and everything is ready at the site. Your system is finally ready to be installed on site and put into operation.

The Installation Team. The night before installation day, your Installation Team arrives and sets up the hardware. They test the system and verify that the configuration set up in the "factory" matches the actual location. When they have finished their installation, a truck arrives to pick up the empty containers and clean up the site.

The Training Team. The next morning, at a staff meeting, the Training Team is introduced. Training sessions begin and users are acquainted with the new system. Trainers or a Transition Manager remain onsite for a day or two to answer user questions and ensure that any unexpected problems are taken care of quickly and smoothly.

The Final Clean-Up. Arrange for pick up of the old equipment a few weeks after your new system has become operational. This is the last phase in the transition from the old system to the new. The branch has now been successfully converted to the new system.

Note: You might need to arrange for space to store the old equipment, orarrange for its disposal. Alternatively, you might be able to find a buyerto whom you can deliver the equipment.

Conclusion

This AppNote has walked you through the process of deploying a branch office network, following the same approach software vendors use to develop products. The discussion up to now has been mainly theoretical. To bring everything down to earth, Part 2 will present a real-world example of how this process can be applied in reimplementing the retail automation network of a major bank.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.