NETWORK DESIGN MANUAL Designing a Client/Server Electronic Messaging System by Barry Gerber 1. Assess Your Organization's Needs You should always start any MIS design process with an assessment of what your organization wants to do with a new technology. Here you are interested in who needs what, when and how you will provide what is needed. You will want to get a handle on the programming, software, hardware, MIS systems and training resources that will be required to satisfy user needs. Remember you are planning for an e-messaging product, not just an e-mail product. Users may need specific electronic messaging-enabled applications. Depending on what they have in mind, application development could be a real resource hog. Also, remember that, in some cases, hardware and software may include new workstations, not just new servers. Be prepared to give users a clear idea of what is possible with e-messaging. You do n't need to get technical with most users. Just give them a view of e-messaging from the end user's perspective. One of the biggest mistakes most people make when implementing any system is to ignore or give only passing attention to the user-needs assessment step. Knowing as much as you can about user needs upfront means you will have an easier time during implementation. For example, imagine that you don't know from the get-go that your organization could benefit significantly from some custom programmed electronic messaging-enabled application. You would just go ahead and implement e-messaging as an e-mail system with the resources such an implementation requires. You would get your system up and it would be perking along just fine, when suddenly, maybe three months later, some user comes up with this great idea for an electronic messaging-enabled app. Boink! Suddenly you have to tell management that you need a few programmers and maybe some more hardware to implement this "er, um, idea nobody thought of four or five months ago." You can imagine the rest. Suffice it to say, a user-needs assessment is the single most important part of the e-messaging design process. Because it is, we will cover it in more detail than any of the other 11 design steps. Questions to Ask There are a number of specific questions you will want to answer during your user needs assessment. The major ones are: 1. What kinds of user groups (for example, managers, sales people, clerical people, lawyers, doctors) does my organization have? What do they think they want from the new e-messaging system? 2. What sorts of e-messaging services are different groups of users likely to need, (for example, e-mail, calendaring and scheduling, public forums or folders, specially designed applications)? 3. Which specially designed applications can be developed by users? Which must be developed by MIS personnel? 4. Do all users ne ed every capability on day one or can implementation be phased in some way, maybe based on user groupings from question number 1? 5. What sorts of demands are users or groups of users going to put on your e-messaging servers and network? a. How many users will there be per server? b. How many sent messages will there be per user per day? c. How many received messages will there be per user per day? d. How frequently will users send messages: 1) to others on their server? 2) to others in their site? 3) to others at each of the other sites in your organization? 4) to others outside your organization? Be sure to break this down by the different kinds of external connections you will have. See step 10. e. How often will users read messages in their mailboxes? f. How often will users read messages in public forums or folders? g. How often will users move messages to personal folders stored locally/on the network? h. How often will users move messages to public forums or folders? i. How large will the average user's message be? For example, what percentage will be 1 KB in size, 2 KB, 4 KB, 10 KB with attachments, 100 KB with attachments? 6. What level of message delivery service are users going to want and need? This should be stated in hours or minutes between the time a message is sent and received. You will need to specify this for both internal and external communications. 7. What sorts of hardware and software resources, for example, computers, operating systems, e-messaging client licenses, will different groups of users need to implement your e-messaging system on the client side? 8. What sort of training will be required for users or groups of users? 9. What types of MIS resources will be required to support user needs? User Workstations: 133-MHz Pentiums With 64-MB RAM "Yes, I know our users are working on ancient desktop computer systems, but, we just don't have the money to buy them what they really need." Ever wonder why companies that have money to burn on fancy cars and trips to expensive and often useless meetings and seminars for their employees can't find the two or three thousand dollars it takes to upgrade a user's workstation? The 486 systems with 8 MB of RAM don't cut it, and no, adding another 8 MB of RAM isn't the answer. To take serious part in the coming e-messaging revolution, your users are going to need an NT system with a 133-MHz Pentium chip and 64 MB of RAM. Yes, 64 megabytes of RAM. When you run Windows, including the '95 flavor, on one of those old underpowered 486/16-MB sleepwalkers, it's all a user can do to keep a word processor and an e-mail client open at the same time. If the user opens anything else, the machine starts thrashing around so much between RAM and virtual memory that it slows to a near useless crawl. Only with a 133-MHz Pentium/64-MB NT machine, can users expect to do word processing and sophisticated e-messaging (e-mail, calendaring and scheduling, and so on) together without waiting a month to switch between tasks and, more importantly, without the machine crashing at the most inconvenient time. With a hardware setup like this, users will still have plenty of horsepower left for all the tasks they used to do on paper, because they couldn't bring up other applications fast enough when they needed them. At will, users will be able to open or keep open such apps as an accounting package, a to-do list, specialized address and contact lists, and applications customized to your organization. With all that computer power, they'll also no longer be reluctant to run other key programs at the drop of a mouse. This includes things like, Internet web browsers. Maybe all of your users don't need a 133-MHz Pentium system with 64 MB of RAM and NT. However, as you start asse ssing user needs, don't let the dismal state of your organization's stable of workstations stop you and your users from reaching for the stars as you think about potential applications for e-messaging. Who knows, you might just come up with the next generation business-computing model for your organization. That might get you a corporate car or a trip to Hawaii for that conference on the role of DOS and the 286 PC in modern corporate computing. 2. Assess the Geographical Distribution of Users, Computers and Networks in Your Organization You need a list of all of the geographic units in your organization. Here you should think not only cities, states and countries, but also in-city and even in-building. Start at the top and work your way down. At this point, diagrams are very important. Draw maps and building layouts. Throughout this article, we'll use an example based on a fictitious corporation, GerCom. Here is a very broad geographical view of GerCom's corporate sites. This is a building-by-building view of GerCom. This is the time to gather information on the workstations and servers in each location. You will want to know how many run each of the different kinds of operating systems in your organization. Operating systems you will want to watch for are Novell NetWare 3.x and 4.x Servers and NetWare IPX/SPX on workstations, Windows95, Windows 3.1x, Windows NT Workstation and Server, MS DOS, Apple Macintosh, Unix workstations by type of operating system and workstations used remotely. If you have hardware and software inventories for these machines, your job will be a lot easier. You can use all of this information to determine who is ready for e-messaging and who isn't and what types of clients you need to suppor t. As you gather information in other steps, begin to look at it in the context of your geographic profile. For example, you will want to meld geographic information with what you have found out about user groupings and needs. 3. Assess Your Organization's Existing Network Here you just want to know what your network looks like now. This isn't the place to get into the kinds of networking you will need. That comes later. You need to answer two key questions here: What is connected to what and how? How much bandwidth do we have on each network? What Is Connected to What and How? Generally, you will want to start at the top of your organization and work down to the site and the server level. For each link, name the physical connection, the networking topology and the networking protocols running on the connection. For example, physical connection = local hardwire, networking topology = Ethernet, networking protocols = IPX/SPX, TCP/IP, SNA. This information, especially when combined with the information you have collected in steps one and two, will prove invaluable as you start to plan for the e-messaging connectivity you will need. In looking at your organization's network, don't forget connections to the outside world. Do you have an Internet connection, connections to X.400 messaging systems, trading partners? If you have such connections, pay particular attention to existing naming conventions. They may limit your choices in naming the key entities in your e-messaging environment. Here, wide-area networking information has been superimposed on GerCom's corporate map. The following diagram shows where GerCom's servers are located. It also shows basic wide area network connections and includes information on intra-building links. How Much Bandwidth do We Have on Each Network? To assess the bandwidth on each of your networks you will need some help from a network monitoring tool. For NetWare systems, try one of the software-based network traffic monitors out there. If your networks are NT-based, you can try using NT Performance Monitor to get a handle on traffic. Similar tools are available for most Unix nets. If you are flush or can borrow one, go for a hardware monitor, like Network General's Sniffer. What you want here is a chart that tells you an average of how much of each subnetwork's bandwidth is available during every 24 hours. You must take several samples to get reliable data, but it's worth it. A warning light should go on in your head if you are already using more than 60 percent or so of the available bandwidth on any network during daytime hours and you are not already running a heavy duty client/server e-messaging system. With that kind of scenario, you might just have to make some changes in the network before installing your e-messaging system. We will talk about those changes later. For now, be sure to collect this data on available bandwidth and incorporate it into your organizational maps. 4. Ensure E-messaging System Security Security is essential if you are going to build a serious e-messaging system. Whether your system will be handling simple e-mail or complex e-messaging enabled applications, if it's not secure, it won't survive. You should be concerned about three levels of security. The first has to do with client access to the messaging database. The second level of security involves protecting messages in the e-messaging database and as they cross internal and external networks. The third level of security involves ensuring the integrity of messages, that is, that a message indeed came from its alleged author. Client Access Security Many messaging systems are totally indep endent of computer operating systems, such as Lotus Notes and Oracle Office, for example. Users must log into the operating system and then log into the messaging system. Sometimes the second login can be made automatic. These sorts of systems also make it a bit harder on system administrators. They have to deal differently, both conceptually and in terms of user interfaces, with operating system security and e-messaging security. The positive here, of course, is that you are not tied to a specific operating system choice when making an e-messaging system choice. Other e-messaging systems are tied closely to specific computer operating systems. Microsoft's Exchange, for example, is intimately intertwined with Microsoft networking and networking security, all of which is based in Windows NT Server. Users log into a Microsoft networking domain and, assuming they have proper rights, that gives them automatic access as an Exchange client. They don't have to enter multiple passwords. General user administration and e-messaging administration are closely linked conceptually. The administrative interface for one can also be used for the other. Whether your operating system and messaging system are coupled or not, you should build some basic policies into your e-messaging system in the design phase. Set minimum password length; require regular password changes; and caution users against posting their passwords where others might see them. Message Security More than anything else, message-level security involves data encryption. If data is safely encrypted and difficult to decrypt without possession of the encryption key, it is going to be much more secure both stored in the e-messaging database and as it crosses over internal and external networks. Shop for message security carefully. Some e-messaging products offer good security options, for example, RSA encryption, but only apply these to messages between users of the product on a single orga nization's messaging network. These products neither encrypt messages bound for other e-messaging systems nor decrypt messages from other systems. Message Integrity Security Most e-messaging systems allow one user to send a message so it appears to have been sent by another user. Digital signatures help to guard against this sort of trickery. If your e-messaging system is used for casual communication, you need not worry about digital signatures. However, if you plan to do serious business, internally or externally, treat digital signatures with the same respect as you do controlling client access or protecting messages from prying eyes. As with encryption, if you expect to do serious business with those outside your organization's e-messaging system, make sure your system supports inter-e-messaging system digital signatures. 5. Select E-messaging Software You now know enough about your messaging needs and existing environment to select your e-messaging software. Some might argue that you should wait to go through all but the final two steps of the design process before selecting e-messaging software. However, if you do that, you really won't get much out of most of the steps that follow, since they pretty much assume that you have some specific e-messaging software in mind, if not installed. For a comprehensive comparative review of eight client/server e-messaging systems, see "Client/Server Electronic Messaging: Delivering the Enterprise" in the November 15 Network Computing, page 68. The same issue contains a sneak preview of Microsoft's coming Exchange Server on page 40. The January issue of the magazine includes sneak previews of Lotus' now-shipping Notes 4.0 and Novell's GroupWise XTD, which is due to ship some time in the first quarter of 1996. Pick software that will let you meet user needs in accordance with the size, geographic distribution and networking environment of your organization. I f most of your users just want e-mail and you expect that will be all they want for some time, go for a product that does that well. If you need to develop applications around a specific database or other product, determine if the vendor of that database makes a messaging system and if that system is right for your needs. If you are a large, distributed organization, go for an e-messaging system that scales well vertically (by moving to powerful server hardware) or horizontally (by adding more servers). If you want to use existing networking protocols, look for e-messaging software that supports them. If you are willing to change networking protocols, look at the range of options available and pick the one that makes the most sense in your environment. If you need to develop applications or communicate outside your organization, start thinking about e-messaging protocols (SMTP, X.400, MAPI, Lotus Notes API, Common Mail Calls and so on) and look for e-messaging software that supports the protocols you will need. 6. Establish E-messaging Naming Conventions E-messaging naming conventions determine how e-messaging addresses will look. To some extent, your naming options will be determined by the e-messaging package you choose. Most packages give you at least three levels of naming: organization (for example, corporate name), site (for example, geographic location or department) and user mailboxes. You have to be very careful in establishing naming conventions. Most e-messaging systems let you choose almost any naming convention you like. However, most systems don't let you change the names you select without reinstallation or deletion and recreation. Even if change is easy, it's bound to bend users seriously out of shape. To put it mildly, users don't like to have their e-messaging addresses changed. Addresses are on user business cards, other people have entered them into their personal e-messaging addre ss books--the whole nine yards. Bottom line: Get your naming conventions right ASAP. Get users to buy into them and then don't change them. You and your users will both live longer. Naming the Organization and Sites Here's one easy and usually safe naming convention you can use: organization = master company name site = a geographic location Try to avoid segmenting your company on the e-messaging side. If possible, don't create multiple organizational entities, for example, Acme East, Acme West, Acme South, Acme North or Acme Sales, Acme Manufacturing and so on. Not only can this create unnatural boundaries, it also can make it more difficult to administer your entire organization's messaging system from a central point-of-view. You might want to equate sites with departments instead of geographic locations. That's fine, though, with certain e-messaging systems, if the departments in your organization are geographically disperse, you might find it difficult or expensive to link effectively some of the users in a department to the remote e-messaging servers that support them. Most e-messaging systems permit names of 64 or more characters. However, it's better to limit them to around 10 characters out of respect for people outside your internal messaging system who may have to type in these names as part of a recipient's e-messaging address. Most e-messaging systems allow you to use almost any character in constructing the equivalent of organization and site names. However, it's best to use only the 26 uppercase and lowercase letters of the alphabet and the numerals zero through nine. Don't use spaces, underscores or any of the accented letters. Naming User Mailboxes You will need some criteria for naming user mailboxes. This is one of the most overlooked areas in e-messaging system design. Don't forget it. E-messaging systems generally have several different names fo r user mailboxes: 1. The mailbox's administrative name, which is used to make it easier to find the mailbox so you can administer and manage it. In most cases, the administrative name is just the mailbox user's first and last name. 2. The displayed name, which users see when searching for a specific mailbox in an e-messaging address book. The displayed name is also often used to construct internal and X.400 e-messaging addresses for the mailbox and is usually the same as the mailbox's administrative name. However, unlike the administrative name, it is important that the mailbox user's first and last name be entered into separate fields to allow for ready alphabetization and address construction. 3. The alias name, which is used to construct addresses for systems that can't easily handle full names. For example, many systems set Internet addresses using the mailbox's alias. Some e-messaging systems let you determine how names are displayed in an address book, for example, "John Smith" or "Smith, John." They also let you specify how aliases should be constructed from first and last names, for example, "JSmith" or "JohnS." Some systems even let you enter custom rules for the creation of displayed and alias name construction. Whatever you do, think through recipient naming conventions carefully. Though you can usually change the options you choose, it's not always easy and, again, you are very likely to bend at least some of your users out of shape. November 15, 1996 Print This Page E-mail this URL