An overview of Network Management

by Steve Broadhead

If an outsider looked critically at the world of networking, they might easily think that everyone involved in it was completely mad.

More often than not, the word chaotic sums up the state of the mish-mash of hardware and software which is laughingly called a network. Yet, as a solution to the restrictions of classic, mainframe-based computing, networking provides mostly the right answers. That it also causes a lot of problems along the way, is an acknowledged side effect. But it is one for which treatment is available in the form of network management.

But first to outline the management issues people are now facing. Foremost in the problems list is the way in which networks have been developed or, more accurately, been allowed to grow seemingly of their own accord. What happened in many companies during the '80's and early '90's was that they became networked on a departmental basis, often without any concurrence between departments. The result was - and is - the aforementioned mish-mash of different hardware, software and operating system platforms, networking protocols, networking technologies, cabling and - of course - applications. Of course, in a world where there is just one big computer - say an IBM mainframe - regardless of the number of terminals attached to it, the concept of managing such a system is within the grasp and capabilities of most individuals. For starters, the terminals are largely unintelligent devices, so they either work or don't work and if it's the latter, there aren't that many different things which can be wrong with them. On the host side, since all the processing power is in the central computer, stored within its own secure and customised machine room, the users can't do anything other than access the applications you provide them with. So, one host type, one client type, one protocol, one operating system... a truly manageable environment.

Heterogeneous Problems

The problem here is that you are talking about environments which existed 20 years ago. Nowadays there are few such sites. A more likely scenario is an increasingly complex network of mainframe and UNIX systems, local and remote PC LANs, probably running on two or more different network operating systems, as well as standalone PCs with different user interfaces from department to department, or even user to user, Apple Macs, UNIX workstations, stacks of protocols - even if TCP/IP is gradually winning the protocol war - dozens of different applications; the list goes on and on. If IT directors had been told several years ago that this would be the scenario they had to manage, networking would never have got off the ground. But it has and it is here to stay. Moreover it's still expanding at a rate of knots, especially in terms of remote (to central office) networking, which itself adds a whole new set of problems. So it's not as if the network you are looking to manage is even restricted to one physical location. The chances are that it's spread across 10's or even 100's of locations, especially if you are in the retail or commerce business. This combination of growth in remote networking and the evolution of client-server computing, with data distributed across several geographically independent but technically dependent servers, is changing the management picture once again. If companies are to realise the benefits of this kind of distributed networking they must have a strategy in place and this strategy cannot simply be technical. It has to include the human side and there are several different areas to consider here, such as the organisation itself, training staff, cultural implications any many other variables.

It is a complex situation which requires you to bridge between technical and human issues. One requirement is to successfully spread out the work involved in managing a large number of diverse and disparate systems. This, however, brings about lots of potential problems due to the interdependence of remotely located computers. Scheduling has long been important on the mainframe side but wasn't generally important in the distributed networking world, but it is now. This interdependence between remote and local machines means it is much more important to be aware of the status of a remote job. For example, if a process is being carried out on a remote branch network which then feeds back data to be processed centrally, you need to be aware of any problems at the remote site which may effect schedules for the centralised processing. So, tasks carried out on distributed systems are often inter-dependent on each other so the distributed, multi-platform scheduler is suddenly a critical requirement.

Centralised or Distributed?

This kind of sudden need for a management tool which, hitherto, has been deemed unnecessary is typical of the constant change network management is currently going through. There is also the question of which is better after all: centralised or distributed management?

In the same way that a mainframe system alone is easy to manage, so there are very clear benefits of centralised network management. You have real control of the users and can enforce company policy relatively easily. But to move back into the mainframe world takes away all the benefits modern computer technology has brought with it. So what is needed is to move back into a mainframe-style organisational structure, though not just managing mainframes but the entire network in a distributed fashion, but with an overlying centralised point of control.

Clearly a compromise is required wherein the remote users have less influence and control of the network than if they were completely "free", but are not restricted in their ability to take advantage of the technology. Ultimately, what we are talking about is service delivery to the end users, whether that "service" is an application or whatever. Users need those services to be available. So you have to remove the single point of failure problem in the first place and then provide a real means of escalating a problem in the event of one arising. The problem is that there often isn't one and therefore users are left without a service available for hours because the right people don't know there is a problem. This is especially the case now where companies have 24 hour computer-based operations. In this situation there has to be a hierarchy of support, so that problems can be dealt with in the right way by the right people at all times. In turn, this means giving the support staff the right blend of tools to work with. And there is no one magic product which does everything. The skill is in getting the right combination for your needs.

Summary

What all of this means is that network management should be one of the key components in the design of a network. Management must be thought of alongside the servers, routers, switches, operating systems and applications which it will be required to support. It should not be an afterthought. By then it is often too late. Look at network management as a key part of your overall networking strategy, then apply management products to that strategy, in the same way that switches and routers are chosen to deliver data in a certain way. Prove to the world that you don�t need to be mad to be involved in networking

Send mail to webmaster with questions or�
comments about this web site.
Copyright � 1991-2003 The NSS Group Ltd.
All rights reserved.