Insights on network management software development

I have been engaged in the development of telecommunication network management software for most of my short working hours after graduation. During this period, I experienced companies of different sizes, I also had the honor to develop some large network management software from start to end, and even develop some network management development platforms.

My personal background is mainly in the Development of EMS (Network Element Management Layer) network management. I have some contact with the NMS layer and some contact with the development of devices, but they all belong to boots, although the methods and ideas mentioned in this article are mostly generic, some specific methods may not be suitable for other types of software.

In the traditional TMN, EMS network management is only a small part. Using the TMN methodology, the EMS network management itself is divided by interfaces. The network management has the following three interfaces:

G interface
: Man-Machine Interface (MMI) provided to O & M personnel by the network management personnel. Generally, there are BS-based web forms. Java swing, Delphi, and, CLI Based on command line is also a man-machine interface. This g word may need to be generalized.

F Interface
: Internal interfaces of the network management system, mainly interfaces between the Network Management Server and various clients. The network management system generally adopts the centralized deployment mode,
A Network Management Server generally acts as a manager for a device. Its clients have various forms, including the implementation of various G interfaces, you can even use the Northbound Interface between the network management and the higher-level network management as a customer.
The F interface is the interface between the client and the server.

Q Interface
: The interface between the network management and the managed device. It is a host interface.

The g interface represents the management requirements of the network management, and the Q interface represents the managed requirements of the network management ), the F interface represents the development requirements of Network Management (development requirements ).

I am engaged in the development of many network management projects. Due to the many developers in the team and lack of understanding of network management, there are some misunderstandings. in a general sense, they are:
1. Start with the F interface: In a developer-dominated team or a team with a deep development background, what everyone can think of most is the point of breakthrough in development, therefore, it is easiest to grasp the f interface first and design various models and services;

 
2. Ignoring the Q interface: there are many reasons for ignoring the Q interface and there are device problems. For example, if the device is not finalized, the device is out of control, and the device interface is not standardized, I can always find a lot of reasons, but ignore
Q interface is fatal. If a Network Administrator does not know what he manages during the development process, how can he become a "correct" network administrator, this product or project cannot be connected correctly.
The conversation is successful.

3. Specify the g interface as needed: the g interface is customized for multiple reasons.
The first is that demand management is not strict and non-standard. Many software companies in China can think about the demand for users by staying at home for three times, then design the interface and interaction process (g interface );
Second, there are also reasons why the current project team is too complex, from users to product managers, system engineers, designers, developers, various testers, implementers, an original requirement, after several departments and procedures, when the development process was passed to the real development process, it was completely beyond the control of the whole site, and the time also lags behind.

In fact, the above three interfaces have their own characteristics:
G interface: diverse forms and rapid changes in requirements. Although the network management interface requirements cannot meet the changes in the business system, this interface is intended for specific users, the demand changes are the most difficult to consider, but the reusability of various interface elements and processes is very high.
F interface: diverse implementation technologies (webservcie, Java RMI, CORBA... there are a lot of examples), and there are various implementation methods (various design modes can be demonstrated here), full elasticity, high-level network management and low-level network management, the design and implementation of its F interface are easily divided into cloud mud.
Q interface: it is relatively stable, regardless of the information of the slave interface or the Implementation Technology of the slave interface (SNMP, TL1, Q3, CORBA, private protocols of major manufacturers ...), it is usually relatively stable.

 
The main error of the network management development idea I mentioned above lies in the fact that the F interface should not be solidified due to a variety of implementation solutions at the beginning, while ignoring a Q interface that can be "Solidified,
Then, the development of the g interface will naturally lead to errors, and even some more incorrect methods are to first define various interfaces on the g interface, then define a set of services and models on the F interface for each interface. In my opinion
It is more like a procedural development idea.

Where are the good methods for writing so much? In my opinion, the good steps are:
1. Dig deep into the Q interface and sort out the information model, interface, and main business process.
2. detail the g interface and list all interfaces in advance through screen design and interactive process design, find the common interface components and interaction processes.
3. generalize F interfaces. f interfaces are essentially g interface services. When g interfaces are listed in detail, they share or share similar components and processes, the called F interfaces are often similar. These interfaces can be summarized without the need for every module. Each object has a new set of models and services.