Fault finding
One of the primary uses of your performance management system is going to be troubleshooting, so has to provide real-time statistics. There's no point having a system that only tells you what happened in the past if you have an issue now. And if it's going to notify you of problems, it needs to incorporate an alarm system. You'll have to find out what's available in terms of gathering information on problems - does it poll devices, and if so can you configure vendor-specific MIBs, or does it act as an SNMP trap receiver? How easy is it to tune the problem thresholds, and can these be varied for the same device type in different parts of the network where the environment may be different? You should be looking for some form of correlation between alarms to group events together and reduce the sheer numbers of alerts you might have to deal with, and a hysteresis mechanism on rising and falling thresholds and link flaps.

You may want this system to include packet capture and decode capabilities, although you may also want to use dedicated network sniffers for this purpose, in which case you need the ability to move traces between the systems. If it is going to be used for packet capture, it needs a big enough - and fast enough - buffer for your network, and must offer filtering (pre and post capture) and analysis features.

Proactive monitoring
Ideally, you'll be using this system to proactively monitor network performance so you can plan for the future. Any new application should be profiled prior to widespread deployment, and to save you many hours of manual effort, a management system should provide you with an end to end session description, including packet types and sizes for each transaction type, the amount of data typically transferred and the other systems involved (DNS lookups etc), all timestamped within the time period of each transaction.

To monitor your existing network under normal conditions, the management system should be topology-agnostic in terms of network types. It has to handle multiple data sources (SNMP, RMON, NetFlow, analysers, probes etc), and understand things like ether-channels, load balancing, and redundant link topologies, for example. At a higher level, there has to be support for multicast, VLANs, DLCI IDs, and QoS settings, and you should be able to retrieve information based on any of these, as well as addressing and port information, packet sizes and traffic amounts.

Any performance management system should be able to recognise well-known applications - the differentiating factor is how they handle ones they don't recognise. Unless you have a very basic set of apps on your network, you'll want the ability to ‘teach' your management system about custom apps so it can provide useful information instead of just bundling anything it doesn't quite understand into an ‘Other' bucket.

You need to know how your network behaves under optimal conditions, so some form of baselining would be expected. The system should be able to run traffic profiles so that it can highlight the unexpected - and that profiling should include not just a daily traffic throughput average, but busy hour figures, including busy day of the week or of the month, so that if say, the third Thursday of the month is payroll day, it expects certain traffic patterns to be different on that day.

Long term planning
You may have SLAs that you monitor either for levels supposedly assured to you from your providers, or for levels you guarantee to your customers. So you'll need response time and latency figures in addition to the standard availability numbers, and again that might be dependant on packet payload or priority setting.

Capacity planning may be an optional add-on, but it's worth investigating what's available in terms of forecasting network utilisation at current growth rates, for instance, or simulation capabilities.

Reporting and administration
A system that provides lots of raw data is all very well, but how easy is it to create scheduled reports and run ad-hoc ones? Can you provide reports with different levels of detail for different audiences, and is there a facility for on-line reports that viewers can customise to suit themselves? You need the presentation to be clear and concise, and quickly produced, for the system to be useful.

You may also need it to integrate with your existing management and reporting systems, to pass on alarms to a manager of managers, say, or to let you export data to modelling programs or billing systems. Can the database be shared, so that it can be interrogated automatically rather than you having to export it?

Security and hardware
And make sure you find out how the system can be administered in terms of multiple users, different access rights, and security. This system will contain a wealth of information about your network that you don't want to be available to just anyone.

Then there's hardware support: it's all very well finding a package that does exactly what you need, but if it only runs on a Unix platform, and your company has no Unix hardware or expertise, is it better to pick the next-best option, rather than having to skill up or recruit staff?

Management systems all have their own strengths and weaknesses - decide which functions are most important for your business and how each potential option handles them and you'll find out which will suit you best.