By Ravi Ravishankar

In my last post (actually my first contribution as a blogger!), I discussed how for many small to medium sized equipment vendors, developing a good EMS/NMS solution is an afterthought. In trying to decide how to build it right, time and money are often sacrificed out of proportion to the actual task due to lack of domain expertise. Even if you disagree with that observation, I want to pick up on the last post by sharing some how-to on building a great solution based on what we’ve learned here at MapleWorks.

Let’s start with the main application screen. This screen should present a comprehensive view of the managed network. In a typical network this will include the list of all managed nodes, status of the nodes, fault summary, server status information, logged in user information, etc. In addition the most common/important detailed information can also be shown. In a telecom network this could the topology view of the managed network.

The layout of the screens is important as this is what gives the first impression about the application. The information presented here should be grouped according to relevance and mapped on the screen. Foremost is to show the nodes that are being managed, and this typically would be in a tree view on the left area of the screen. If groups features are supported then the groups should be displayed and the nodes under the groups can be viewed by expanding the group.

The individual nodes should display current status to the NMS server and both the nodes and the groups should display alarm summary counts. The main area of the screen should be used to view and configure functionality provided by the NMS application, like topology view, PM data, admin functions, error logs, etc. The user should be able to easily navigate between these views to access different functionalities while the rest of the screen displays real-time status information.

The colors and icons used in the GUI should be carefully coordinated so that the user is not confused when viewing the information presented. In general neutral colors should be used as much as possible making sure that the color coded alarm information is easily distinguishable. One of the areas where there is a lot of room for creativity is in the display of topology information. This is due to the number of nodes being displayed as well as the type of network connectivity.

Displaying mesh connectivity is not the same as displaying a linear network! Regardless, the graphics used to represent the topology (nodes and links) should be well designed and suitable for the entity they represent, otherwise the view can look a mess. This can be more challenging in applications that do multi-vendor network management. Some implementations have used photo images of the actual vendor equipment to distinguish the nodes but this can easily make the topology view quite an eyesore,

The information presented in your application should be clear and concise. The user should be able to easily navigate the screens and also be able to drill down to get more information.

In the case of the topology display there are several options to present the information. Among these are the use of expand/collapse capability for the node graphics, node annotations, layered view and/or drill down views, etc. The objective is to present the network topology in a clutter free form and at the same time provide the capability to delve further in to obtain more detailed information as required.

Let’s take the example of a long haul SONET network. In between the ADM nodes it may use optical repeaters (amplifiers) but the default topology view could just show the ADM nodes with the interconnecting links. There could be two options to show the components at the optical layer; one is to launch a dialog from the link of interest to view the supporting optical repeaters, and the other would be to give an option to expand the current view to redraw it showing the optical repeaters between the ADM nodes. This is an example of how the topology view can be managed as well as provides drill down capability to access information as needed.

A well designed GUI for a Network Management system should be pleasant to the eyes, provide easy to use features, and have well thought out functionality. In a crowded and competitive market space it could make or break sale of networking equipment.

(Ravi Ravishankar is a Senior Software Engineer at MapleWorks Technology Inc., the smart choice for onshore software development for networking and telecom companies.)