Developing a network architecture In this excerpt from Networking the New Enterprise, we give you the keys to designing a stable network architecture through analysis of your network requirements and management strategies and the evaluation of standards

September  1997

This month's column has been adapted from Networking the New Enterprise: The Proof not the Hype, by Harris Kern, Randy Johnson, Michael Hawkins, and Howie Lyke, Sun Microsystems Press, a Prentice Hall title, Mountain View, CA. © Copyright 1997 Sun Microsystems Inc. The authors describe the mandatory steps you must take in meeting objectives for proper network design. This includes comprehensive analysis of network requirements -- from your applications and services to your wide-area network requirements. Network standards and management strategies are also considered. (3,300 words)

Mail this article to a friend

etwork design never stops. After an initial requirements analysis, which leads to a basic design, you buy and deploy equipment. After the network is up and running, the organization discovers unforeseen uses for the network, which leads to design changes, new networking equipment, and new discoveries. The cycle goes on and on. The network architecture provides a framework for this continuing cycle of analysis, design, and implementation. Like the blueprints for a large building, the network architecture gives managers an overall view of how all the components of the network infrastructure -- technologies, people, processes and tools -- fit together. And it is a map of how to get where you want to go. An effective network architecture should define key strategies and objectives, network structure, standards, and methods.

Objectives for network design
Before designing the network, you need to establish objectives from two perspectives: designers' and users'. To the user a network should be just like plumbing -- reliable, efficient, safe, and invisible. It should perform well enough that when users are surveyed about your network, they should be unaware. People don't notice things that operate reliably. They expect devices or services to complete their tasks in about the same amount of time each time. If a replacement device operates twice as quickly, great! On the other hand, don't expect users to sing you high praises. If something suddenly takes twice as long to complete its appointed rounds, whether it be a computer, train, or coffee maker, users will complain.

Aside from the plumbing qualities, users also want:

• To work with other users regardless of the computers used
• The network to expand as they find other uses for it
• The ability to add and move users without bureaucracy
• To keep outsiders from reading their files
• The ability to manage their networked devices from one place

Service level objectives
To satisfy strategic business objectives and user requirements, you need to break these ambiguous notions into concrete service objectives. A service agreement, which you negotiate with users, is the criterion for quantifying how the enterprise network is satisfying key business requirements.

For example, you might measure functionality by the types of services that can be accessed across the network; performance by response times, or better yet, transactions in a period of time; and availability in mean time between failure (MTBF), hours of downtime, and time to restore. We list some service level benchmarks in Table 3-1.

Availability service levels, uptime, and mean time between failure are relatively straightforward analyses and can be evaluated quantitatively. However, performance-related service requires special consideration: you must define different types of service-level measurements for different applications. For example, response time is an effective way to measure simple transaction-processing applications. But you need to define exactly what "response time" means. A customary definition is the time it takes to start receiving a response after submitting input, such as pressing the Enter key on a keyboard. You call; I answer.

Today's client/server applications complicate the definition of response time, to say the least. One input stream from a client may set off a chain reaction of activity between several local and distant servers. In the real world, you need to think of measuring performance in terms of transactions per time, where each transaction may comprise several data exchanges between a client and servers. Depending on the nature of the applications, you might even need to measure transactions per minute or per hour. An example might be an insurance claims application where you may measure a series of complex tasks to process claims by the number of claims completed per hour.

For large data transfers, response time and the number of transactions per unit time aren't very useful. For example, when you execute a large file transfer, you are concerned mainly about throughput or the amount of data transferred per second.

Analyzing network requirements
After analyzing service level objectives, you next decide how to design a network that meets those service needs. The first step is to identify your organization's business requirements.

Where are you now? Where do you want to go? What are the available solutions and technologies? What can you afford? You need a network that will meet your organization's objectives -- strategic, operational, and business. When you decide what you can afford, it becomes a business decision to determine if your proposal offers more value than it costs. If so and if it satisfies your business needs, then your network becomes an asset rather than a cost center.

Unfortunately, because every enterprise network is unique and dynamic, there are no well-defined methodologies to help you identify and evaluate all requirements. Rather than focusing on details, take a big-picture approach. That way, you can refine your requirements iteratively and add more detail as you learn.

Partition your network requirements by broad categories, such as applications and services, facilities and cables, desktops, LANs, WANs, protocols, servers, and network management software. This is a simple guideline we will use to define requirements. Feel free to use another way to segregate your own business requirements.

Requirements for applications and services
Identify the applications, services, and information sources users need to access across the enterprise. These might include old mainframe and new groupware and client/server applications. You also need to consider other types of network-based services, such as e-mail, facsimile, and Internet and Intranet access. And don't forget multimedia -- many organizations want to eventually combine voice and video conferencing with their data networks, if they are not already doing so.

After you identify your applications and services, you will have a better idea of the types of information that will flow across your network. This is important because data, images, voice, and video require different levels of network performance, availability, and security.

Requirements for facilities and cables
In our experience, cabling accounts for many network problems. It is not unusual for organizations to install critical network components in exposed areas with poor power and ventilation. If you don't already have wiring closets and equipment rooms for your important network devices, you need to build them. If you use a mainframe, plan to use your data center for critical network components.

Desktop systems requirements
Most large organizations suffer from an incompatible jumble of desktop hardware and software. You need to decide which desktops you will connect to your network, which ones you'll discard, and which you'd best leave to a reclusive lifestyle.

Local network requirements
Where are your legacy LANs? Do they fit into your enterprise network plans? Evaluate the various types of networks such as Ethernet, Token Ring, Fiber Distributed-Data Interface (FDDI), and Fast Ethernet, and decide which standards are best for your organization.

Wide area network requirements
As with LANs, review your WANs and evaluate your options. WANs require special attention because of their staggering cost. WAN network components, in particular, probably account for the biggest chunk of your capital equipment budget. Also, various carriers and local telephone companies (called "telcos" in the trade), offer a variety of services at corresponding prices. Study your data traffic and predict its growth so you can evaluate your options intelligently. Another important consideration is Internet connectivity. What type of Internet access do you need? Is e-mail access adequate or do you need full access to the World Wide Web?

Protocol requirements
Pick a standard protocol for your network. If you have networks in place already, you will likely want to retain these protocols for some time. However, you might save money in the long run if you switch to a single protocol. Many organizations plan to migrate to TCP/IP, while predominately SNA installations often expect to migrate all systems to Advanced Peer-to-Peer Networking (APPN).

If you plan to use multiple protocols, you need to decide how you will distribute the protocol stacks and if you need gateways. Will you use nonroutable protocols? If so, will you allow them across the backbone, or will you imprison them in specific subnets?

You also need to evaluate routing protocols, such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), and find out how they might affect your network design.

Server requirements
Novell and Unix administrators commonly deploy desktop computers as file, e-mail, and printer servers. As these functions become more mission critical, you should upgrade the hardware to make them more fault resilient.

Do your servers offer the performance and reliability you need? The operating systems you choose will depend, to some degree, on your applications requirements. Your server hardware requirements, such as type of processor, memory, disk space, and fault tolerance will depend on their applications and operating systems.

Requirements for network management
Network management is the final and most important requirement. You cannot build a network with production qualities without well-defined requirements for network management. What network and systems management tools do you use today? What mainframe-based tools are you using that also would be useful for your distributed-computing environment? It is common for enterprises with mainframes to manage their SNA networks with NetView. If your enterprise is one of these, you will want to consider NetView for your distributed network. Many organizations will find SunNet Manager and OpenView meet their network management requirements.

We will discuss network management and security strategies later. For now, identify the key important network management requirements.

And don't forget about your support organization. What kind of processes and structure do you need? What kind of training is required to provide high levels of support for your network?

Sources for technology information
To plan, design, build, and manage an enterprise network, you need access to accurate and timely information. You need information about your needs, and information about the available software and hardware that may meet your requirements. Fortunately, we enjoy a variety of information resources, including text books, training courses, computer-based training, trade magazines, e-mail lists, and the World Wide Web.

If you haven't already done so, we recommend that you get personal access to the Internet now. Most of the popular network suppliers maintain Web pages and CompuServe forums. Users of popular products often start Usenet discussion groups and e-mail lists. Table 3-2 lists several Web sites with links to useful references for a broad range of network technologies.

Another enlightening source of technical information are Requests for Information (RFI). RFIs present, in a formal and consistent way, your requirements to different suppliers, which, in turn, respond with sales pitches for their products and services.

Standards for networks
Before you start building your enterprise network, you should evaluate and select your network standards. There are many to choose from. We recommend you select as few as necessary but adhere to them devoutly. You can't evaluate components if you haven't picked your standards.

We also recommend a conservative approach. Pick the popular, proven standards for no other reason than finding compatible equipment and management tools. If you are considering an emerging standard or one not popular, make sure it will satisfy a key business requirement in your organization today and in the future. You don't want to throw away an expensive new technology that works now but offers a short life.

Today's predominant network standards are summarized in Table 3-3. The Institute of Electrical and Electronics Engineering (IEEE) Society's 802.3 and 802.5 standards for Ethernet and Token Ring are two of the proven standards for networks. 10Base5, 10Base2, and 10BaseT are all widely used versions of IEEE 802.3. Another noteworthy standard is the American National Standards Institute (ANSI) X3T9.5 for FDDI. More recently, 100BaseT (Fast Ethernet), Asynchronous Transfer Mode (ATM), and 100VG-AnyLAN are rapidly becoming important standards for enterprise networks. Fast Ethernet is similar to your existing 10BaseT networks (just 10 times faster), whereas ATM and 100VG-AnyLAN are completely new technologies.

For many of the emerging technologies, standards are either nonexistent or incomplete, which means products from different suppliers may not interoperate. As we write this in 1996, products following the ATM "standard" are essentially proprietary. If you decide to use proprietary products, make sure they will satisfy your longer-term business requirements. If not, you may find yourself with an expensive short-term solution. For more information about the key network standards, browse the Web sites listed in Table 3-4.

Develop a logical topology
After you identify your network requirements and technologies and select your key network standards, you're ready to jump into the physical design, right? Wrong! Remember, network design is complex. The essence of a good design is to keep a broad view of the big picture and take a top-down approach. We find excellent staffs possessing outstanding technical skills with a keen knowledge of different technologies at many organizations. Alas, we rarely find visionaries with a broad view of the big picture.

Key methods
Although we focus on centralization as one of the key methods to maintain control over your network, there are other methods that are just as essential. In addition to centralization, you also need to distribute, consolidate, separate, and duplicate network components and processes to ensure that your enterprise network meets business requirements. At first these methods may appear contradictory. However, they are actually complementary. The essence of designing an enterprise network is finding the optimum mixture, which is a never-ending process. For example, you may build an enterprise network with a variety of components, such as routers and hubs, that are distributed across different locations. Some may find homes in secure wiring closets throughout a large complex, while others are left out in the open at branch offices. Hopefully, your critical devices, such as servers and backbone routers, will hum along undisturbed in your controlled data center.

For your network management systems, you need to centralize the applications in your data center where they collect information from management agents distributed everywhere your network reaches.

With your building backbone routers centralized in a data center, you can consolidate several small routers into one large multiport router to enhance manageability and performance. Then, you can duplicate this single backbone router to make your backbone network more reliable. You may also duplicate vital communications links in your wide-area network for better reliability and performance. For systems that are security sensitive, you can use separate servers on separate networks isolated by firewalls to ensure less secure systems and networks do not impose risks.

We discuss these concepts and the process of centralizing, distributing, consolidating, separating, and duplicating throughout the book.

Strategy for network management
Network management and control loom as important concerns. While many organizations build comprehensive network management technologies, the underlying processes for managing the distributed-network environment are usually insufficient. Processes, people, and technology combine under the distributed management and control umbrella. Any solution failing to meld all three will founder.

Network management introduces infrastructure that allows you to anticipate problems, identify their source, and start corrective action before the afflicted user starts to dial your help desk. Only a comprehensive management system that combines processes, people, and technologies provides an effective solution for active management.

Centralized control
We recommend a central point of control, a headquarters if you will, for your network management. But do not centralize all network management processes. Any process may be distributed to any point on the network, but all processes should be controlled from one place. Centralization maximizes the skills and knowledge of one of your most expensive resources-your staff.

Network management hierarchy
For networks that span geographical regions, you need to organize your network management domains in a hierarchy. We recommend that you define your network management domains "in the largest possible sizes, but no larger" to maximize the skills of your network management staff.

You face a number of network management domain issues, including how the domains are defined, who is responsible for each domain, what information should be available to each domain, and who has overall responsibilities for the network. For example, a logical way to divide responsibility is to define each country as a separate domain. Each of these logical sites is responsible for performance monitoring, and each forwards information to network headquarters only when there is a problem.

Network control centers
Create primary and secondary network control centers. The secondary network control center backs up the primary center. For example, the secondary center would take over if the primary center was disabled by an earthquake, flood, hurricane (typhoon), or power blackout. Since each country is an autonomous region, you might establish a primary network control center at each local headquarters. Each needs a backup. A control center in Hong Kong, for example, may serve as the secondary control center for the Asian region.

How you organize primary and secondary control centers will affect your network management platform and the way you configure your management database. Your network management system and its configuration database should support a distributed view of the network. The network management systems in different primary control centers need to share a common database that contains information about the entire network. Not all network management products do this today, but all are expected to do so soon.

Network security policies and strategies
Security is essential for business-critical systems handling sensitive transactions and confidential data. An effective network security strategy revolves around layered security countermeasures based on a well-defined security policy. Military planners call this layering defense in depth.

Develop a security policy that includes policies for network security. Before you write this policy, study and revise (or perhaps create) an overall IT security policy. A security policy identifies sensitive information and its value to your organization (and competitors), potential risks and their probabilities of occurrence, and the required countermeasures and controls.

No matter how many controls and safeguards are in place, total security is impossible. (Just ask Aldrich Ames, formerly of the CIA.) However, risks can be minimized to an acceptable level.

Security policies can affect your capacity to manage a network. For example, your policies will dictate the schedule for full and partial server backups, loading shareware on PCs, copying copyrighted software from application servers, and editing configuration files like CONFIG.SYS, AUTOEXEC.BAT, and Windows INI files.

You need other security-related policies for

• Taking hardware and software inventories
• Prohibiting shared passwords
• Expiration of passwords

You need to evaluate security policies in many areas. Start this evaluation in the beginning, as you will uncover key policy decisions that will affect your design and the products you buy. This is particularly important for network management, where you will want to identify management applications and tools that bring your policies to fruition.

Title: Networking the New Enterprise: The Proof not the Hype
Authors: Harris Kern, Randy Johnson, Michael Hawkins, and Howie Lyke
Publisher: Prentice Hall/Sun Microsystems Press
ISBN: 0132634279
List price: $38.00

Resources

• Networking the New Enterprise: The Proof not the Hype at Amazon.com Books http://www.amazon.com/exec/obidos/ISBN=0132634279/sunworldonlineA/
• Information about Networking the New Enterprise: The Proof not the Hype at the Sun Microsystems Press Books Web site http://www.sun.com/smi/ssoftpress/books/Kern3/Kern3.html
• Full listing of Unix Enterprise columns in SunWorld http://www.sun.com/sunworldonline/common/swol-backissues-columns.html#unix

Harris Kern (harris.kern@sunworld.com) is Sun's Open Systems Migration Consultant for NAAFO Market Development. Randy Johnson (randy.johnson@sunworld.com) owns R&H Associates, a full-time rightsizing consultancy in Boulder Creek, CA. R&H Associates helps people worldwide in implementing and supporting client/server infrastructures based on their proven methodologies. © 1997 Harris Kern and Randy Johnson. All rights reserved.

Harris Kern and Randy Johnson are authors of Rightsizing The New Enterprise: The Proof, Not the Hype and coauthors of Managing The New Enterprise: The Proof, Not the Hype, and Networking The New Enterprise: The Proof, Not the Hype. You can buy these at Amazon.com Books. Select the hyperlinks to learn more about each and Amazon.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-09-1997/swol-09-unix.html
Last modified: