Selecting an EMS Platform

Feb 6, 2002 12:00 PM

In business, few truisms are more ironclad than "choose the lowest-cost solution, and everyone goes home happy." In this economy, cost savings are more important than ever as companies trim expenses at every opportunity. However, less capable platforms can rack up huge costs as IT engineers scramble to fix problems, add functionality and scale to meet demand. What frequently gets lost in the decision-making process is choosing an element management systems (EMS) platform to keep long-term implementation and maintenance costs manageable while delivering better solutions to end users.

What's in a name?

With the rapid growth of broadband and other data services, the definition of the term EMS has also evolved. To make sure that we're not talking apples and oranges, I've defined it simply as a software system to manage network elements. Traditional systems usually managed one or two elements, but they now are called upon to support multiple devices. Additionally, some of the functionality traditionally considered to be part of the network management system is now incorporated in the EMS. For the purposes of this article, a loose definition of EMS is sufficient since most of what follows also applies to domain and network management systems.

Using this definition, anyone can build an EMS--it's not rocket science. Just buy an embedded Web server, integrate an SNMP stack, find an out-of-work Java programmer and--voila--you can whip together a decent looking EMS that will provide a GUI front-end to your device. Sadly, the real world isn't quite this simple.

Successful management systems are more than attractive GUI browsers. Simple equipment in a simple environment may only need a simple browser--for example, my home DSL router has a simple HTML interface (thankfully, I don't need to talk CORBA to it). But for serious telecom equipment for service providers, I've identified four unusual design criteria that need to be (but frequently aren't) considered:

• Designed to succeed

• Designed to share

• Designed to change

• Designed to stand out

Designed to succeed

It's fairly easy to build an EMS to handle one or two devices, but equipment providers need to assume that they will sell tens, hundreds or thousands of devices to a service provider. They're not going to want to deploy a separate EMS for every device they've installed. Similarly, the EMS needs to be able to support many users, millions of events and months of data. The data collected by the EMS will be so useful that customers will need access to it 7x24.

All this implies a client-server architecture rather than something embedded in the device. Client-server architectures provide a great tool to aggregate data from many devices and scale to large networks while still handling concurrency and security issues for multi-user access. Client-server architectures also allow for different types of user interfaces, based on the needs of different types of users. Full-featured Java applications are usually appropriate for network operations centers, but simple HTML browsers tend to be better for remote access by service technicians or customers.

To support many users potentially doing many different things, the EMS should have multiple threads of execution to be able to do more than one task at a time and should have an asynchronous messaging structure to reduce dead locks.

Designed to share

It's unlikely that an EMS will be going into an environment where the customer doesn't already have a number of other systems. Very likely, they'll already have alarm or performance monitors covering some aspects of their network. The better the new application fits in with these existing OSSs, the happier the customer will be. Therefore, the EMS should be designed to share its information in a variety of ways.

Data sharing needs to be considered in a bi-directional manner. The EMS should be able to provide information to other systems and load information from other systems. While inputting device or customer information by hand using a spiffy GUI looks impressive at trade shows, inputting information for thousands of devices or millions of customers should be done in bulk as quickly as possible. An EMS that doesn't scale will end up costing a lot of money in the long run.

Service providers often push EMSs in creative ways that the designers never considered. This is especially true when the management systems have external data access or simple APIs, and the result (if done correctly) is a system that integrates well into the service provider's environment--and more importantly, into their business.

To support sharing, a good EMS should have a scriptable interface accessible from standard UNIX or PC tools. The scripting interface need not mimic the GUI, but it's important to make sure that it provides the same types of security checks. The EMS should provide for loose integration with other software technologies and products: unless one is embedding a third party system with his or her EMS, it can be risky to have tight integration with another provider's software product. Interfaces change with ongoing versions, and larger customers may also have a customized release of the third-party OSS, both of which can result in maintenance nightmares and higher costs. Management systems should work with adapters and flexible parsers to make field-changeable integration possible.

Designed to change

We all know that change will occur, so it's important to plan for it up front. What happens to an EMS when new hardware, such as a new line card or network interface, is introduced? Obviously, releasing a whole new EMS would be impractical. And even if network equipment doesn't change, industry mergers and acquisitions can play havoc with even the hardiest EMS. What happens when new capabilities are added to existing hardware months after deployment (or days before a trial)? The ideal solution is to ship only incremental changes to the EMS, rather than to create a different version.

If an EMS isn't flexible, any of these situations can be catastrophic regardless of the technical merits of the communications device. A good EMS must be designed to accommodate a reasonable amount of change, which can be achieved through modular or component-based design. Component-based design permits the isolation of dependencies on network elements and interfacing technologies, reducing the impact of a change in one device impacting the whole EMS.

Similarly, there needs to be "softness" on the server side of the client-server architecture. Softness has to do with the system's ability to change without recoding or recompilation. This is commonly achieved through the use of tables or configuration files to control some options, as well as scripts to describe common operations. This softness allows for a field upgrade of components within a reasonable tolerance. Changing the EMS to support new behavior of existing equipment may require only an updated script provided to the customer. A new piece of hardware may be supported by providing customers with a new component that models the new hardware's behavior, plus some graphics files to be used by the GUI. It's not necessary to make systems infinitely flexible, as major upgrades may still benefit from a new version of the EMS.

Designed to stand out

Sad to say, but no matter how good a network's hardware is, it's going to be hiding in a closet somewhere. If it works well, service providers will tend to forget about it. The EMS, however, will be seen and used every day. Even if network elements can processes millions of packets or thousands of simultaneous calls, an ugly and awkward GUI will create a bad impression--and potentially result in lost sales and unhappy customers. Similarly, if a GUI has someone else's name on it, that's the name that people will remember. Regardless of the platform used to create an EMS, it is critical for companies to customize the GUI as a positive branding tool.

The bottom line

The EMS is not typically regarded as a business builder, and yet its potential in today's environment of speed and change cannot be underestimated. In today's wobbly marketplace, the EMS has the power to be a competitive differentiator, a loyalty enhancer and even a cost-reducer. By considering factors other than the off-the-shelf price tag, equipment providers can reduce their long-terms costs while dramatically improving their offerings to customers and end users.

Peter Buckner is Chief Technology Officer of TCSI Corp.

Visit TCSI Corp. online.