Managing a network architecture Insights to managing your network By Harris Kern, Randy Johnson, Michael Hawkins, and Andrew Law with William Kennedy

February  1996

IT must change to meet new business requirements. This involves knowing how to manage a network architecture. In doing so, you must examine network requirements, methods, standards, and security -- all of which are detailed here. (4,000 words)

Mail this article to a friend

Make your network flexible for change, invest in personnel training, keep a broad scope, and carefully plan and manage your network -- these are the important guidelines for a successful and profitable production-quality network in your New Enterprise. The first step toward implementing those guidelines is to develop a network architecture.

At the very least, the architecture is the foundation for your network design. Wise network designers realize the architecture maps your computing enterprise: In a distributed-computing environment, the network is the computer. Accordingly, the architecture should capture your corporate computing philosophies, strategies, and objectives. It must define where your network is now, where you want it to go, and how you plan to get there. It must also describe critical success factors, design objectives, and a logical network topology, as well as your strategies for network management and security.

There are two guidelines that often outweigh all others when developing a network: Keep it as simple and straightforward as possible; set and adhere to standards and disciplined practices. This is where network manageability begins.

Analyzing requirements
Never forget (as corporate IT sometimes does) that the successful enterprise- computing system serves the processing and information needs of the entire organization. Because the network architecture maps the distributed-computing enterprise, it should reflect the current and future structures and activities in every part of the organization. We define six key areas for analysis to help you identify the structure and computing activities of your enterprise and develop a set of network architecture requirements: corporate structure, desktop configurations, enterprise applications and services, workgroups, existing networks, and data centers and facilities.

Key pieces of the network requirements puzzle

Corporate Structure
What are the organizational units and how are they related to one another? How many users are in each unit and where are they located? Much of this information is available in a simple organizational chart. Knowing the organizational structure helps you define the size and extent of the network. It also helps you define the general layout of the network and potential technologies. If the organization is small and limited to one floor of a building, you might want to consider a simple Ethernet or Token Ring network. But if there are many departments spread across many floors, you might want to consider a larger network based on a corporate backbone that connects smaller networks in different areas. If there are departments spread over a wide geographical area, you will want to consider different WAN (wide area network) technologies to extend the backbone network to remote locations. Knowing your organizational structure also helps you define potential information flows and workgroups.

Desktop Configurations
Although "dumb" terminals are the mainstay of legacy systems, distributed- computing environments typically place much of the computing power right on users' desktops, where it belongs, to best serve productivity needs. But these desktop systems tend to be a variety of personal to workstation-class computers from a variety of hardware vendors running disparate operating systems and applications. Bringing this heterogeneous collection of desktops into the enterprise is no cakewalk (the user is willing, but the platform is often weak). From the networking standpoint, you need to identify the various hardware and software configurations that currently exist: those you actually can and intend to connect to the network (Commodore-64s make great doorstops) and the network adapters, software protocols, and network operating systems needed for the connection.

Enterprise applications and services
You need to identify existing applications and services as well as future requirements. These include databases and related client/server applications, file and print services, e-mail, and groupware. It is important to define the scope of applications and services. Are there enterprise applications, such as a large personnel database, accessed by users in many departments? Are there departmental applications limited to the users in a single department? And what about personal productivity applications on the desktops, such as word processors and spreadsheets? Will they be stored centrally on servers or distributed across the desktops? This information is important because it will affect the layout of the network. For example, you may want to place enterprise applications on the backbone and departmental applications on smaller networks in individual departments. Also, review user requirements for special applications and user plans for future applications development. These may influence the technologies you need to evaluate. For example, transaction processing, multimedia, and client/server applications will likely require faster network technologies.

Workgroups
The meteoric success of so-called "workgroup" software, such as Lotus Notes, highlights the fact that inter- and intradepartmental working collaborations are not only encouraged but de rigueur today. These small-to-medium-size groups share resources and information unique to their group and project. Although some workgroups, such as a sales team, can be permanently established, they tend to be transient, comprising consultants who leave the company and regular employees who are reassigned once the project is completed. Applications development is a good example of transient collaborations among design and programming teams.

Workgroups have a major impact on your network because their computing needs regularly cross the common boundaries of your organization's political and physical structures. To manage network traffic and improve performance, we recommend a networking topology that enables flexible workgroups. Hence, you need to discover the various workgroups, what unique applications their users require, and how they access the software across departmental or even worldwide servers. You also need to identify any special characteristics of the data traffic over the various segments of the network between individuals in a workgroup and, in particular, desired response times for that traffic.

Existing networks
If only we could start with a clean slate! The reality is, like the wild revolution that brought the conglomeration of PCs through the back door, departments and workgroups in most organizations have already taken the step and created a crazy quilt of networks throughout the enterprise. Like the collection of heterogeneous desktops, if you intend to iron things out into a cohesive networking architecture, first you've got to identify and classify those existing systems. Then you must decide which are worth connecting and which are doorstops. Are they Ethernet-based, Token Rings, or something else? What type of cabling is in place? What additional cabling will be required? What network protocols are being used? We find that mainframes typically use SNA; VMS systems usually use DECnet over Ethernet; Unix systems use TCP/IP; and NetWare systems use IPX. Look, too, beyond LANs (local area networks) and identify the WANs. What types of WANs are in place, and what other options are available?

Data centers and facilities
Though we retain many of the concepts and disciplines of the legacy mainframe data center, we physically disperse the facilities in our distributed environments. In fact, just as the network enables a distributed environment, so too is the network infrastructure essential to the data center. The important issues are where to locate the facilities and how to build a WAN to support them. Are there sufficient conduits for cabling? Is there adequate power and air conditioning? And what about the wiring closets? Are they secure? Do they have sufficient power and ventilation? And what about racks and patch panels?

As you can see, there are a variety of issues to address in the network architecture for the New Enterprise. The issues raised here provide a good point of departure. As we proceed with refining the network architecture, there will be more detailed issues to address. After a series of iterations, we will eventually have a comprehensive design.

Design for success-they'll tell you
After all the effort you and your colleagues will expend analyzing needs and developing your enterprise network, of course you want your network to work. But what makes a successful distributed network, and how will you know when you achieve it? Do you take a poll? Believe it or not, yes! Positive user opinion is a key criterion for success. That's why we involve users in the design and implementation process from the beginning. You probably won't be able to buy or steal success at the polls; instead, you'll have to earn approval the old-fashioned way by building for success.

From the user's perspective, the criteria for a successful network are functionality (Is the network useful and easy to use?), performance (Is it fast and responsive?), and reliability (Does it do what's expected and when it's needed?). Does that all sound familiar? (Hint: We're RASing you -- reliability, availability, and serviceability. The fundamental disciplines for production-quality computing.)

Functionality, performance, reliability
Before you bend your designers and the network out of shape, remember: The simpler, the better. That's our number one design objective and why we use a structured architecture. It simplifies the network, thereby enhancing reliability, and supports new requirements and technologies without major modifications.

So, what exactly is a structured architecture? By structured we mean the network has some underlying order that is easy to understand and visualize. The network consists of many components. These components can be connected many ways, which add to the network's complexity. We can simplify the network by introducing order or structure. Simplifying the network makes it more manageable. For example, instead of connecting many networks in a disorganized web, we use a backbone network. The backbone provides a common way to interconnect the many smaller networks, which is easier to visualize and manage than a web of networks with many unorganized interconnections. A structure doesn't just happen; structures are planned, and they must be planned from the beginning.

Other critical design features that get users to pull the "yea" lever in the voting booth are connectivity, interoperability, and transparency. Connecting the best computing resources over the network, regardless of the origins, brings the entire enterprise to users' desktops. Do it in a way that hides the complexities and technical complications, and the network becomes comprehensible and easy to use. Hence, a network that is transparent to users and connects the various heterogeneous platforms throughout the enterprise enhances the critical-success criterion of functionality.

Once elected to office (by a landslide, of course), network scalability, flexibility, and manageability are key weapons in your war chest to ensure its incumbency and quell user uprisings. Be prepared to increase network capacity incrementally and dramatically when and where users demand it. Make sure the network can adapt to change; make sure it's easy to modify, upgrade, and expand. All of these things are needed to maintain and enhance performance. Finally, do everything in a controlled, responsive, and reliable manner. Management is the most essential design objective; you won't be able to achieve any others, let alone support mission-critical applications and control costs if your network isn't reliable, available, and serviceable (RAS, once again).

Key methods for the network architecture
Our network architecture depends on five methods, of which the most important is centralization. The others are distribution, consolidation, duplication, and segregation. Some of these methods may appear to be contradictory, but, in fact, they are complementary.

Centralization of equipment and services within the confines of a data center is a major feature of our networking strategy. It is the best way to simplify the network and maintain high levels of RAS-just as it's been successful in mainframe environments. For example, we put critical network devices, such as the local routers that make up the backbone network, within the physical confines of a data center and under the control of IT. That way, it's easier to install, monitor, upgrade, and repair critical network components. Obviously, you can't put all network components of a distributed environment into one data center; otherwise it wouldn't be distributed. So, distribute data centers. Even then, unless you are a major control freak and are willing to pay for the facilities and personnel needed to operate hundreds of data centers, you've got to disperse the majority of remote routers, concentrators, and other equipment for your distributed network close to users.

Wait -- how can you have centralization and distribution at the same time? There is a very important distinction between distributed versus traditional mainframe centralization: When we talk about centralized networking for distributed- computing environments, we talk about control, which is not necessarily where we put equipment. Centralized control means IT has the means to manage any component anywhere on the distributed network, whether those components physically reside in a data center or not. Centralization means we provide the same reliability, availability, and serviceability for distributed environments as we have in the traditional mainframe data center, but we do it over the distributed network. That is the essence of our claim: "The network is the data center!"

In fact, we use centralization and distribution to our advantage. Distribution, by its very nature, puts computing services into the hands of users, where it belongs. By centralizing certain devices in the data center, however, we often can consolidate components and functions.

That leads to savings and manageability, particularly when you must duplicate critical components to afford reliability. For example, reduce the number of routers to manage by consolidating several centralized routers into a single router. Although consolidation enhances manageability, it also leads to problems, such as single points of failure and performance bottlenecks. So our network architecture depends on other complementary methods that appear to be contradictory to enhance RAS.

In addition to centralizing, distributing, and consolidating, we duplicate and segregate, duplicating key components to add redundancy and bypass single points of failure. And we segregate functions to spread utilization across more devices and enhance availability and performance. The network architecture for the New Enterprise depends on an intricate interplay between centralization, distribution, consolidation, duplication, and segregation. The essence of network design is discovering the right balance.

Standards issues
At the heart of most arguments between "open" versus proprietary systems remains the issue of standards. System innovators don't want standards because they dampen change and often lock in a narrow range of solutions. Yet, it's difficult-if not impossible-to implement an enterprise network unless you adhere to some common conventions. The more heterogeneous the systems, the harder it is to manage the networks and (more importantly) to control costs.

Again, production-quality, distributed-computing systems are a balancing act between new technologies and traditional practices. In our view, standards are essential. We depend on them to introduce some order into an otherwise complex heterogeneous network. Fortunately, there are many industry standards that offer an array of solutions. But when it's time to implement your enterprise network, select and adhere to a few standards and choose one product from each. Even though two products are based on the same industry standard, there is no guarantee they are compatible. In our experience, compatibility often is the exception, not the rule.

Today, some of the industry networking standards we recommend include EIA/TIA-568 for cabling and connectors, SNA 3270 terminal-to-program and LU6.2 program-to-program communications for mainframes, and TCP/IP protocols for all other systems. We manage the network through the Simple Network Management Protocol (SNMP) standard. Media access is based on IEEE 802 standards. We use IEEE 802.3 10BaseT Ethernet and IEEE 802.5 Token Ring for the local area networking topology.

Once network standards are defined, it doesn't mean you're finished. New standards evolve as better technologies emerge. You've got to be flexible and take advantage of those new technologies, but be careful to select one for implementation that will avoid compatibility problems. And make sure the various departments and units of your enterprise adhere to those standards. Otherwise, do what we do: Refuse to support those maverick systems.

Survey technologies and trends
To develop a RAS network architecture, it is important to identify and understand the main technologies, issues, and trends. But don't do it as a "cramming" exercise: Education is an ongoing process, and we think it's the most important activity. Remaining well informed means solving problems, taking strategic advantage of emerging technologies, and saving money.

We use a variety of information resources to remain current, including technical magazines, textbooks, white papers, supplier presentations, conferences, seminars, and online information services.

The online information services, such as the Internet's newsgroups and World Wide Web (WWW) and CompuServe's technical forums are especially useful: Discussions of current topics are nearly immediate, and participants pool their collective expertise to answer others' questions. They're also good sources of information about specific products, although we recommend in-house testing for any and all products you may use in your network.

Logical network topology
After analyzing user requirements, setting critical goals, and surveying the technologies, it's time to develop a logical topology for your distributed network architecture. The logical topology revolves around a backbone, the central conduit between major network segments.

What about the remote locations? Subnets can be connected to the backbone network independently of location. This means you can connect the remote subnets in your remote offices as well as the local subnets in the building complex to the backbone. Do this by extending the backbone over a wide geographical area using the WAN.

Subnets and workgroups
According to our definition of an enterprise network, each and every connection ("node") on the network has access to all others. Our topology provides the internetworking means for enterprisewide services, such as e-mail, access to warehouse databases, and so on. However, why do we divide the network into smaller segments, particularly since the extra equipment is expensive and the increased complexity makes it more difficult to manage? Small organizations of fewer than 50 nodes can usually do without subnetting. However, for larger organizations, it's a performance versus complexity trade-off: Subnetting eases network traffic congestion. Most network-based data and services sharing happens among closely related workers-those workgroups we discussed earlier. Subnetting isolates local networking traffic to a logical working unit, so it does not contend for network bandwidth with other segments or on the internetwork backbone.

Subnets and workgroups often are assigned along physical or political lines; for example, by department or by corporate division. We take a different tack and decouple the workgroups from the organizational structure and physical network. Workgroups are distinct in their function, not necessarily location, even though their members most likely work close to one another. Networking for workgroups means we have the infrastructure to support dynamic workgroups across the entire enterprise network.

Defining workgroups and assigning users to subnets is not an easy task because workgroups are not static. Members and their tasks in a workgroup change in a dynamic organization; so will their network data traffic patterns frequently change. Workgroup data traffic is not always confined to users in a local area; it may extend across a wide area or several floors in a building complex. For example, a user may be a member of different workgroups for e-mail, file sharing, forms-processing, and mainframe applications. How does this affect our strategy? We separate the physical network from the workgroups. Our strategy is to base the logical network on a dynamic corporate view of workgroups, so any application or service can be accessed by any user, independently of location and time. As you'll see later, this will have a major impact on some of our design decisions.

Management and security
Manageability is the keystone of our networking strategies and a key design objective. We plan and plan and plan for network management right from the outset. It would be difficult and costly to do so later. Our network management strategy is highly proactive. We frequently monitor availability and performance of all the network components so we can anticipate problems and resolve them quickly and efficiently.

Our network management strategy has three key features. First, we manage the network from a central point. This does not mean we centralize all network management processes. We may distribute any process to any point on the network. But we control all processes from a centralized location. Second, all network management processes are based on a common network management platform. The common platform lets us build a centralized network management system by using a variety of third-party products. A network management platform provides a set of functions to collect and display information about the devices connected to a distributed network. We can use these functions directly to manage the network, or we can use them indirectly through network management applications that run on top of the management platform. Network management applications are supplied by a variety of third parties and usually enhance the functionality provided by the network management platform. Most network management applications are designed to run on the common network management platforms, which include SunSoft's SunNet Manager, Hewlett- Packard's OpenView, and IBM's NetView. And third, the network management system is based on a standard-SNMP because it is the de facto network management standard. All network components should be able to communicate with the network management system via SNMP.

We view network security as an important part of network management. With the proper checks and balances, your network, particularly one that supports mission-critical applications, can be secured against inadvertent or malicious acts that can compromise the integrity and confidentiality of your network and your systems, data, and processes. Like all other features in our network architecture, we plan for security from the beginning.

Overall, the prudent objectives for network security are confidentiality, integrity, and availability. Data and systems should be available only to authorized users, and they should not be exposed to accidental or malicious modification or interruption by users, errors, or failures.

We cannot expect to completely secure the entire network because of the difficulties and costs. We therefore set an acceptable level of risk. It takes some experience to do that, inasmuch as many of the common security countermeasures have weaknesses. The toughest offender (the password "attack") too often succeeds, for example, because it is difficult to force users to secure their passwords properly. It's also well known and easy to configure a notebook computer as a protocol analyzer and monitor data traffic without being detected on an Ethernet or Token Ring network. WANs are particularly susceptible to snooping because you can't easily secure the network "wires." (WANs use many types of channels, such as wires, optical-fiber, microwaves, and satellites.)

In the face of all this vulnerability to errors, failures, and disasters, can we implement a secure distributed network? Definitely, yes. But only if security measures and countermeasures are included as critical parts of the network management architecture and design.

About the author

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

URL: http://www.sunworld.com/swol-02-1996/swol-02-hrbook.html
Last modified: