AN INTERFACE INTERVENTION

Despite, and perhaps because of, the number of independent software vendors that sprouted dandelion-like across the telecom landscape over the last decade, a solution for service providers' most basic back office need — a process for end-to-end flow-through — goes unfulfilled. It is ironic, and a little humbling for the salesman that must pretend otherwise, that the cause is one of communication. Applications still don't talk to each other.

The boom in the late 1990s turned the need acute, and the subsequent bust has made it desperate. But thanks in part to initiatives such as OSS through Java, or OSS/J, 2003 could be the year software vendors get their interoperable acts together and topple the proverbial Tower of Babble that has been OSS interoperability (see below for a glossary of the terms used in this story).

GLOSSARY OF TERMS
API	Application programming interface
JCP	Java Community Process
J2EE	Java 2 Enterprise Edition
OSS	Operations support system
OSS/J	OSS through Java
QOS	Quality of service

As is often the case with scientific or technical challenges, solutions often come from attempts to solve other problems. The OSS/J initiative was born of companies using Java 2 Enterprise Edition technology to solve application interface problems for the enterprise and e-commerce arenas. J2EE was adopted by Java Community Process members who wanted to get out in front of promising 3G opportunities.

The technology translates well to wireline OSS. “The fundamental proposition of Java is compatibility,” said Philippe Lalande, Sun Microsystems' OSS/J program manager. “The paradigm is extremely useful in an OSS context because one of the main challenges the OSS industry is facing is the amount of integration needed to make systems compatible.”

In September 2000, some of those members — Ericsson, NEC, Nokia, Nortel Networks, Sun and Telcordia Technologies — founded OSS/J with the idea of creating application programming interfaces for trouble ticketing, 3G wireless service activation and quality-of-service solutions.

Their labors are beginning to bear fruit. By the spring of 2002, some vendors were shipping those APIs in their products. Service activation was the first to be adopted; companies such as BEA, Cygent (now part of Convergys), Digital Fairway (gaining ground through EDS), Ericsson, MetaSolv, Motorola and Telcordia were by then shipping products with OSS/J service activation APIs. The QOS and trouble ticket APIs also started shipping, and OSS/J turned its attention to building APIs for inventory and IP billing.

That's all well and good for vendors, but with OSS/J going into its third year, the more important stage of bearing fruit is in its picking. Carriers such as T-Systems, a division of Deutsche Telekom Group, is a showcase for OSS/J and a feather in the cap of German OSS integration startup IP Value, which has based its entire business plan and its Service Creation Factory platform around the low-cost implementation of OSS/J enabled solutions.

Thomas Schmal, IP Value's chief architect, said in a statement, “Using standardized APIs for automating the service provisioning process reduces the integration costs for our customers dramatically.”

Most OSS vendors have conceded that OSS/J interfaces are becoming the de facto standard, and developers and service providers have now downloaded more than 25,000 final versions of these APIs from the OSS/J Web site for free.

These small examples hardly qualify as the bells that will ring in the year of OSS, especially because vendors have touted open end-to-end solutions from the outset. However, it seems vendors are beginning to get the message on OSS/J.

“One year ago, carriers were asking about OSS/J in general. Then they began asking for it in their [requests for information],” said Brian Dueck, senior product manager for MetaSolv. “They are not making it a mandatory requirement yet, but this year most [requests for proposal] will include OSS/J.”

While OSS/J is still not a do-or-die requirement that eliminates a vendor from contract bids, “carriers absolutely want to know your road map for it,” he said.

There also are requirements for vendors to ensure they meet the proclaimed compatibility of OSS/J. OSS through Java is more than sets of interface specifications, and the driving force behind the initiative is the Java Community Process.

The JCP established the methods and best practices for developing and certifying the application interfaces used in OSS/J. “JCP is a very crucial component in the OSS/J initiative,” Lalande said. “None of the founding members would have invested so much into this initiative without something like the JCP.”

The JCP developed a do-it-yourself certification process. It requires that vendors finalize their product through the use of a Technology Compatibility Kit, which is a test suite that verifies full compliance with OSS/J interoperability standards. To be certified, a vendor must post the results of its test so that potential customers can see how well the vendor complies.

The growing interest in OSS/J by the community at large is a welcome sight. However, the potential driver that coalesces the industry around this standard may not not be good for everyone. That driver is consolidation.

As larger, more stable or cash-rich vendors grow confident that, with open interfaces such as those of OSS/J, they can quickly integrate the functionality of independent solutions and make them their own, the pace of consolidation will accelerate.

MetaSolv's acquisition of Nortel Networks' OSS assets late last year could almost be a blueprint for how OSS/J can make the acquisition process less painful. Nortel, a member of the JCP, acquired Architel within months of joining the OSS/J initiative. Service activation was Architel's specialty.

Nortel never did make a go of its acquisition, but the easily integrated technology that resulted was one of the more important assets that came to MetaSolv when it subsequently acquired the OSS business from Nortel.

MetaSolv itself was one of the original members of OSS/J. “We reviewed the importance of our involvement in OSS/J and determined that it was more important than ever,” Dueck said. “We had significant demand from our customers that we had to make the integration of our products more competitive.”

The move has helped MetaSolv become a global competitor, according to analysts. “MetaSolv is definitely getting some visibility, especially in wireless and in the EMEA with their more flexible, standards-bases solution through Nortel and OSS/J,” said Sharon Ballard, analyst with The Yankee Group.

In addition to increasing its market share and broadening its geographic footprint, MetaSolv is making major changes to its Telecom Business Solution platform in favor of solutions based on this type of integration. “We have a number of ongoing implementations now that will go live in the third quarter using these APIs,” Dueck said.

The successful integration of Architel through two acquisitions is an OSS/J byproduct that could entice more companies to take the plunge. It also could help ease the fears of service providers as they face their own potential consolidation. The Architel example is very small compared to the melding of two (or more) Tier 1 telecom company OSSs, but with key, open interfaces in place, the task may seem like only a bad dream and not quite a nightmare.

If demand for OSS integration takes off because of large-scale carrier consolidation, companies adhering to the most accepted form of open APIs will be the winners. For vendors that subscribe to OSS/J, though, it may take a few more success stories to convince their carrier customers that theirs is the solution that will work with the hundreds of other systems carriers already have in place.

“On one hand, carriers can benefit from standards. On the other hand, standards come and go, and sometimes with not a tremendous amount of value, so there is a healthy caution by service providers,” Dueck said. “They don't want to bet the farm on something the first time around, but as they see these early successes, they will realize this is solving problems they need help with.”

Some of that success can be seen in the growing number of companies that have written case studies detailing their success in integrating applications using OSS/J APIs. They include BEA Systems, BTexact, ILOG, Lumos, British Telecom, Motorola and Sun. Also, Nokia will be adopting OSS/J APIs for the NetAct OSS it is building, and IBM is using JSR-90, the QOS API for its Mobile Workforce Management OSS/J Solution.

With the key APIs in place and others soon to be completed, it is now time for service providers to begin making technology choices and intervening to solve problems instead of suffering with them.