interface: (the noun)

There are no final answers in telecom. As Phil Holmes, chief technology officer for BT Exact, said, “As soon as someone invents the perfect architecture, someone will invent a more perfect architecture.”

However, the OSS through Java Initiative (OSS-J) provides a standards-based application framework that offers this decade's best chance for solving vexing interoperability problems in the back office. Its adoption, or the lack thereof, may say something about operators' commitment to solve these problems.

It is sometimes difficult when discussing OSS-J to make clear whether one is talking about the technology or the group of collaborators who developed it. OSS-J, the initiative, is a group of technology leaders from the vendor, service provider and developer communities that work within Sun Microsystems' Java Community Process to develop standardized application interfaces (API) for operation support systems (OSS).

OSS-J, the technology, is a set of APIs that includes a specification, a reference implementation, a technology-compatible tool kit and source code that are available for no cost. Network operators can use these APIs to build the adapters they need for their specific systems.

OSS-J APIs are available for trouble ticketing systems, fault and performance management, inventory and service activation. In October 2004, OSS-J announced it would work with Covad, IP Value and Nakina Systems on three new APIs: pricing, discovery and order management.

Current APIs have been toyed with, tested, evaluated, tweaked and kicked for what seems like an eternity. They have been everything but deployed in most major operator networks to any standard degree, despite receiving a passing grade from those that have kicked their tires.

Granted, the three or four years that OSS-J has been around is no eternity, but why, since network operators have been voicing their frustration over incompatible interfaces for so long, haven't they pounced on this technology, if, as many have said, it is so good?

Maybe, like many mothers-in-law, they simply like to complain. But that's unlikely. More likely is that network operators have been bitten by this snake before. Middleware — the software designed to provide a single interface for software applications — and its associated protocols have promised much, delivered some, but have done little to eliminate the bugaboo known as the integration tax. Perhaps, as Dan Baker, Dittberner's director of OSS research, said, given the complexity of carrier networks, it will just take time for OSS-J to take off.

Baker projected that the $4 million market for OSS-J today would grow to $40 million in four to five years as part of an overall boom in the OSS middleware space, which he said would grow to $870 million by 2008.

The following companies, BT, Vodafone and Covad — the strongest proponent and user of OSS-J — may or may not help OSS-J reach those heights. Here's why.

BT is a carrier out on the edge. It is typically at the forefront of new technologies such as those being used in its 21st Century Network. And it has been among the first to give OSS-J a real workout.

The company put together a proof-of-concept project last year that included vendors such as Amdocs, Sun, MBT and Granite Systems (now part of Telcordia Technologies). Not all these vendors are deployed in BT's network, but they participated in the test.

The mission? “To determine whether OSS-J did what they said it would ‘on the tin,’” Holmes said.

“On the tin” is a British phrase used by a varnish company that claims its product would do exactly what it said it would do “on the tin.” That's a commendable slogan, but one that has been tough to demonstrate in the software world, particularly in middleware.

The results? “We were convinced that OSS-J is a sound engineering solution,” Holmes said.

Holmes also said many of the test participants were of the same mind, and some were strongly considering putting OSS-J into their development plans. Most vendors, though, are reluctant to recommend any particular interface.

“When asked for a recommendation, they just shuffle their feet,” he said.

BT has not committed to using OSS-J technology, but Holmes is convinced that it works. He also admits that there is no current alternative, unless you consider Web services an option. Web services is a method for binding applications that is built using XML, simple object access protocol, Web services description language and universal description discovery and integration. Some people do not. A spokesman for OSS-J said the group sees Web services as one of the interfaces for OSS-J.

The bottom line on why BT has not implemented an OSS-J API is this: “Our next issue is whether it makes business sense and gives us the business attributes we require. And we are still investigating that,” Holmes said.

Vodafone has taken OSS-J beyond the evaluation stage and has actually implemented the trouble ticket API. The company was working on getting a fault management API implemented by the end of the year and may have that working today as well.

“We also have had discussions for projects in 2005, which will use either the performance management or the inventory API,” said Joerge Frankenberger, head of OSS engineering at Vodafone Germany.

While common solutions and standards are of interest across Vodafone, it is Frankenberger's OSS engineering group that is interested in the standards-based APIs from OSS-J, particularly regarding the area of service management.

“I am very much interested that the whole industry adopt OSS-J, especially in service management, because it will only work if the huge vendors like HP, Agilent and others support the initiative,” Frankenberger said.

Like Holmes, Frankenberger has heard assurances from his vendors that they will incorporate OSS-J into their development road maps. Vodafone has no plans to change existing working interfaces such as those for its element management systems; however, all the interfaces currently in development for the service management layer are based on OSS-J APIs.

Frankenberger has been an OSS-J advocate inside his organization — and sometimes outside of it — and is starting to win people over.

“Everybody was a little resistant in the beginning, thinking it was just another new interface technology,” he said. “But when they looked deeper, they all came back with feedback that said it was a good technology.”

The advantages of OSS-J, Frankenberger said, is that it has all the advantages of middleware integration, it is flexible, can be expanded and the basic technology — Java — is well understood. The original hesitancy to embrace the technology was in part a result, again, of being snake bitten, particularly with Q3 and CORBA interfaces.

“CORBA worked, but you had to spend a lot of money to get it working,” he said.

While neither Frankenberger nor Holmes believes any more in the promise of true plug-and-play, they say OSS-J significantly reduces the time and cost of integrating subsequent APIs once the initial implementation is complete.

“When we did our prototype trouble ticket implementation, we had trouble in the beginning, but we learned a lot, and now have an integration cookbook on how to approach OSS-J integration,” Frankenberger said.

Holmes said that when you introduce a new component and need to integrate and customize it, the integration accounts for 80% of the cost of the component.

“I don't think you can reduce that by a considerable percentage,” he said. “But more standardized functionality could meet us halfway so we only had to customize half of what we do today.”

“We're trying to move from our first-generation homegrown OSS to leveraging more commercial products, but to be honest, what is discouraging is that the integration tax is pretty high,” said Paul Grantham, vice president of software and information systems at Covad.

Vendors make more money off the professional services supporting their products than they do the products themselves. “And I find that disagreeable,” Grantham said.

Covad has automated the process within its organization. The problem, however, is that it has to communicate with all the RBOCs, ILECs and other providers. And its customers pay the price.

“Our customers have to deal with the fact that we have one way of doing things, and [other carriers] has another way. They face the same thing we do,” Grantham said.

When it comes to the issues caused by a lack of standard interfaces, Grantham said, “We are all paying a high price for not agreeing on something that is pretty simple and is not a distinguishing competitive feature,” he said.

Because it does not have the clout of a BT or Vodafone because of its size, to influence standards, Covad has gotten involved in the actual development of new OSS-J APIs, something both BT and Vodafone said they are reluctant to do.

The company has built adapters based on OSS-J APIs for all of its commercial off-the-shelf software and has successfully implemented a complex CMIP-based interface with SBC Communications for trouble ticketing using OSS-J. The four-month project was much shorter than what Grantham said would typically take two years. And as is typical with OSS-J implementations, the subsequent implementations took only two months. Covad is actively promoting OSS-J's billing API and is helping develop new APIs for pricing, discovery and order management.

OSS-J helped Covad better understand the 90-plus attributes it needed for the CMIP implementation. From there, Covad added the process standards from TeleManagement Forum, including the eTOM, or telecom operations map, and the SID, or shared information/data model, to its own practices and is happy to give away the adapters it has developed.

“I don't see any reason this stuff should be proprietary, so we will open-source the adapters we built in OSS-J for anyone who wants to use them,” Grantham said.

If Dittberner's projections are correct, there will be a lot more people looking to use them in the next couple of years. However, growth will be gradual.

“OSS-J is not the greatest thing since sliced bread, but it is an approach that seems to be gaining some adherence. It will admittedly take a long time to move forward,” Baker said.

A new breed of software, such as that offered by a company called IP Value, could bring OSS-J along a little quicker. The company may be the only middleware provider today that is strictly OSS-J-based.

“An OSS-J-specific middleware is unique,” Baker said. “It leverages all the other middleware out there, but its unique twist in adding value is a major step forward.”

And that's a step in the right direction. If service providers are serious about solving their compatibility problems, they might want to consider taking bigger strides that step right over the snakes they have been worrying about.

(OSS-J APIs in development)

Title	Status	Spec Lead & Company
OSS Service Activation API	Final Release	Andreas Ebbert, Nokia Networks Oy
OSS Quality of Service API	Final Release	David Raymer, Motorola
OSS Trouble Ticket API	Final Release	Pierre Gauthier, MetaSolv Software Inc.
OSS Billing Mediation API	Final Release 2 (v1.1)	Takeshi Miya, NEC Corp.
OSS Common API	Final Release	Vincent Perrot, Sun Microsystems Inc.
OSS Inventory API	Proposed Final Draft	Pierre Gauthier, MetaSolv Software Inc.
OSS Service Quality Management API	Early Draft Review	Francois Gauthier, Watchmark
Pricing API	Expert Group	Gabriela Chiribau, Covad
OSS Discovery API	Expert Group	Sergio Pellizzari, Nakina Systems
Fault Management API	Expert Group	Dave Raymer, Motorola
Order Management API	Expert Group	Andreas Ebbert, Nokia Corp.
(Key)
Final release: API is listed as Version 1.0. Receives ongoing maintenance reviews as it evolves
Final Release 2: an API that has gone through a full maintenance review and is listed as v1.1.
Early Draft Review: an API in the midst of the specification process.
Proposed Final Draft: a completed early draft review for a current version
Expert Group: the group that defines and creates the API and helps maintain it, usually but not always an OSS-J member.
Source: The Os through Java Initiative