A NEW GENERATION OSS

Software may not make the world go round, but it does keep an increasingly networked world up and running. Operations support systems are the nerves and muscle of a networked world. The OSSs that carried us into the information age were complex and reliable, but we're already building and deploying a new generation of OSSs that is as different from its ancestors as a Boeing 777 is from the Wright brothers' first plane. It will have to be.

The past generation of OSSs has been left to us by the architects of a different communications age. Their mission was to centralize control of complex networks, mechanize manual tasks, ensure reliability and save money. They've accomplished that mission.

The next generation of OSSs is still taking shape, and we are starting to realize what the new systems must be like if they're to serve their owners and their owners' customers well. The new generation of OSSs will have to be much nearer to perfection than ever before.

It will have to be scalable, flexible, interoperable and designed for full service networks. Each of these attributes is crucial and worth a closer look.

The Q word Quality is basic. While the subject of quality causes some eyes to roll and some minds to wander, it is more important than ever. The fact remains that more rides on software now than ever before, and that means the consequences of making errors are greater than ever before. Anyone who doubts this should recall the summer of 1991, when telecommunications in several eastern states broke down over a tiny coding error in a software system. In addition to its immediate effects on the public network and its users, the error led to government inquiries, uncomfortable moments for the executives of telecom and software companies, and a general uneasiness about the reliability of high-end technology.

OSS providers must ensure their software quality is first-rate to stay in the market. Bellcore has found that the best way to do that is by making sure the method of producing software is uniform across various systems. A company that produces different systems with different methods will ultimately miss deadlines, lose customers and lack the ability to make things better.

Bellcore's corporate experience is instructive, mainly because so much of the public network in the United States relies on its OSSs. The company began by defining its quality method of operation for producing software. Initially, the company applied the method to 16 key projects, later expanding it to all of Bellcore. Last year, the company's entire Software Services Center received ISO 9001 certification and was assessed to be at Level 3 of the Software Engineering Institute's capability maturity model.

The bottom line, however, was that the company reduced the density of defects in its software products by 40%. That effort, of course, will never be totally completed.

OSSs must also be scalable. Originally, this meant that a relatively small company could buy computer platform architectures and scale them up as the company grew. Certainly, OSSs will need to fit this model. Relatively small telecom companies, for example, need to be sure as they buy their OSSs that those systems can grow with the companies' operations.

But the old model isn't enough. OSSs must be scalable in both directions-down as well as up. OSSs must be built to accommodate the largest, most sophisticated, most automated customers. But they also must be built to scale down in function and price to meet the needs of a full range of customers.

Smaller telcos may need less automation and fewer functions and capabilities, but their customers will demand the same levels of performance as the customers of large carriers. Functions are just as important for small carriers as they are for large ones. And small carriers need the assurance that their OSSs can grow with them smoothly.

The need for this kind of scalability is relatively recent. Legacy OSSs were built to mechanize manual tasks, and their designers necessarily focused on those issues. OSSs now are built with quality, scalability, flexibility and interoperability in mind. The engineers building them have all re-examined their software design and production processes, and they probably have no doubt that the companies they're serving need scalable systems.

Flexibility: The other dirty word It's hard to overestimate the role that the ITU-T and the Network Management Forum have played in making the new generation of OSSs flexible. Virtually all new OSSs are being designed inside the Telecommunications Management Network framework, and this greatly enhances their flexibility and interoperability. For example, new OSSs are designed in layers-a basic TMN contribution-which allows designers to isolate service management from equipment suppliers or changes in network technology.

Another result of TMN is that new OSSs can monitor network occurrences in real time, regardless of which vendor's hardware is used. They can diagnose problems quickly and accurately, and even point the way toward a solution-before any problems affect customers or service.

The intelligence in new generation OSSs is distributed; their designers assume that the systems' owners will have to respond to new information organically, without waiting for centralized authorities to OK every move. They also assume that networks will grow at varying speeds and that every network will use hardware and software from many vendors.

Unless they are real gamblers or terminally nostalgic, system designers will incorporate open system standards in their work. Their OSSs will be object-oriented, and the information in them will be changeable without too much trouble. Screens of dense text have given way to graphical user interfaces.

Interoperability is almost as important as high quality. Actually, OSSs have been interoperable for some time-they have been able to interwork with systems already in place in a network, even if other vendors provided those systems.

However, the interfaces have been proprietary, written either by the vendor or by the operator. A decade ago this was not an unreasonable approach. After all, network operators didn't see their OSSs as a means of competitive differentiation but as competitive necessities. Vendors sold them that way. The emphasis was on centralized control to ensure the internal consistency of processes, mechanize the manual tasks to reduce the network's labor content, and optimize digital switches and cross-connects, as well as coaxial and fiber optic cable.

But now there simply isn't time for a network operator to build its own interfaces because the market demands speed in assembling ready-made solutions. The emphasis now is on making money. The stakes being higher, network operators are also less inclined to entrust their time to market entirely to their vendors.

As a result, flexible, modular, TMN-based OSSs require open interfaces with easy-to-implement interface contracts. That way, a network operator can assemble a mixture of modules from whatever sources best fit the desired solution.

The newer OSSs must radically change processes and keep customers loyal by giving them some control over their services. Layered TMN-based systems make it possible to integrate processes inside the new OSSs, and that integration is vital for flexible systems.

Integration means that data entering the network can be used repeatedly without being re-entered each time the network needs to use it for some new purpose. For example, an integrated, TMN-based OSS would use construction specifications in service activation and service assurance databases (Figure 1). Customers asking for service from such a network would find that the network already knew a great deal about them and would be able to fill their requests in minutes, not days.

When trouble arose in the network, it could be identified, analyzed and addressed almost instantly-and the customer care systems would also know about them instantly and could inform customers immediately if necessary. The ability to respond to trouble as fast as possible will be a key means of differentiation in any new generation OSS-and it will be a necessity in a full service network.

A full service network should be able to provide its users with video, telephony, voice and data services reliably and gracefully.

Comprising many new active components made by many different vendors, a full service network will have more trouble to report. It's worth remembering that the standard of downtime for a North American telephone network is less than 53 minutes a year. That means that it's fully available to its customers 99.99% of the time. Given its character and expanded mission, the only way a full service network can attain that standard is by reducing the time it takes to respond to and fix problems (Figure 2).

Network elements have been getting smarter for years, and legacy OSSs now in place have helped network operators make the most of those intelligent network elements. TMN-based OSSs, with their layered architecture and open interfaces, offer network operators a chance to make the most of the network's intelligence.

The new systems must be very nearly perfect-scalable, flexible, interoperable-and must offer a means of competitive differentiation. Those OSSs, very different from their ancestors, are being designed, built and deployed now, and they will lead us to those networks.

Sanjiv Ahuja is President and Chief Operating Officer for Bellcore, Morristown, N.J.