The $25 Billion OSS Solution

 

Nov 2005
The $25 Billion OSS Solution

 
Providers spend nearly half of the $50 billion they invest in OSS on proprietary solutions that aren't reusable and are expensive to maintain. The solution may be Sun's Java Community Process (JCP) services.

Telecommunications companies have long discussed the need for interchangeable, interoperable, off-the-shelf business components for quick assembly into operations support system (OSS) solutions. In October 2000, the OSS through Java Initiative was established. Shortly thereafter, the Architecture Board produced the OSS/J Design Guidelines. Says Andreas Ebbert of Nokia, "That's what the excitement is about--developing interfaces that enable a whole new market."

Twenty-five billion dollars.

Twenty-five billion.

Think of that for a moment. Twenty-five billion.

That's a lot of money to throw down the drain. If any industry were to waste $25 billion a year, it would probably find itself in dire straits.

And that's exactly where the telecommunications industry was finding itself. For years, representatives of the top telecommunications companies had been talking about the same thing: interchangeable, interoperable, off-the-shelf business components for quick assembly into operations support system (OSS) solutions.

These solutions would be for service activation, quality of service, billing, trouble ticketing, and other key areas. To get there, and to move away from the pain of the current fragmented and proprietary OSS market, they wanted widespread adoption of an open, standards-based market that would be able to address their need for carrier-grade OSS solutions.

Yet, despite all the discussion, little was being done to solve the problem. Thus, nearly half of the $50 billion spent in the OSS market was for custom-made solutions that were painful to install, not reusable, and expensive to maintain. And with the economy slowing down while demand for communication services was skyrocketing, discussions took on a more urgent tone.

"The mission of the Architecture Board is to turn the OSS/J vision into concrete solutions that meet OSS market requirements and general software industry trends and patterns and to speed up the development of specifications and reference implementations."

Java Community Process Leads the Way

Enter Philippe Lalande of Sun Microsystems, program manager for the Java Community Process (JCP) services program. In October 2000, 15 companies that belonged to the JCP services program agreed to participate in what is now called the OSS through Java (OSS/J) Initiative. The original core OSS/J companies were Sun, Cisco, Ericsson, Motorola, NEC, Nokia, Nortel, and Telcordia . With Lalande as program manager, the OSS/J Initiative used the JCP services program to bring technologies based on the Java 2 Platform, Enterprise Edition (J2EE platform) to the OSS market.

The fledgling OSS/J Initiative recognized the need for an ongoing technical advisory committee to promote the vision and goals of the group. Led by Pierre Gauthier of Metasolv, this committee, called the Architecture Board, comprises representatives of the core companies. Responsibilities include determining how to structure OSS application programming interfaces (APIs), advising OSS expert groups, and deciding which OSS areas to address next. To encourage the implementation of OSS specifications approved by JCP services, OSS/J member companies create relevant tools and hold informational seminars and demonstrations of OSS/J technology.

Early on, the Architecture Board knew that it needed to base OSS/J technologies on common architecture guidelines and JCP services standards.

"We complement the JCP program," Gauthier says. "The mission of the Architecture Board is to turn the OSS/J vision into concrete solutions that meet the OSS market requirements and general software industry trends and patterns and to speed up the development of specifications and reference implementations."

Although an entire spectrum of APIs is needed, the Architecture Board first addressed those defined as crucial by the telecommunications industry. For an industry straitjacketed by proprietary solutions, OSS/J APIs were developed to enable the assembly of commercial off-the-shelf components, resulting in end-to-end OSS solutions for key functions such as provisioning and billing. Those end-to-end solutions have proved elusive until now but will deliver huge value to service providers

When the JSR (Java Specification Request) 89 OSS Service Activation API was submitted, for instance, no standard components existed for the service activation area of OSS. Each available product addressed only a tiny aspect of all the processes that had to be handled. These components could be purchased from many sources, but they were not interoperable. For a complete solution, customers had to write specific code to integrate the different components, a tedious, costly, and nonreusable undertaking.

Spec Lead Stefan Vaillant of Nokia expected JSR 89 to reduce integration efforts, by creating a set of standards that would enable the creation of a reusable software component market.

"The products we expect to show up are components that don't differentiate in terms of the proprietary interfaces but in terms of the functionality and quality they offer," says lead Andreas Ebbert of Nokia. "Then users can select components that match their needs best and plug them together with minimal effort or cost."

In the environment OSS/J technology is making possible, companies can develop new products.

"It's a precompetitive environment, because there has been no OSS component market until now," says Ebbert. "That's what the excitement is about — developing interfaces that enable a whole new market."

The Need for Consistency

For multiple JSRs that relate to a common vertical market, it is extremely important to overall productivity and efficiency to maintain consistency from one specification to the next. A developer who learns the concepts in one API can more easily understand and implement related APIs. To ensure that such consistency was built into all OSS/J JSRs, the Architecture Board produced the OSS/J Design Guidelines, a set of industry-accepted design patterns and component definitions for OSS/J spec leads to follow. Under these guidelines, specifications and reference implementations are easier to create and of higher quality.

The implementation process has only begun.

"In an economic environment where communication service providers (CSPs) are under increasing pressure to decrease operating costs and leverage existing software investments," says Yankee Group analyst Sharon Ballard, "standards initiatives such as OSS through Java are a means of helping CSPs achieve these goals.

Additional Information:

Learn more about the OSS through Java Initiative.

Read about Metasolv's OSS solutions.

 


 
Related Content/Links
 
»   A Smarter, Faster, More Profitable Communications Network
The TeleManagement Forum and the OSS through Java Initiative are working together to build the foundation for a smarter communications network.
 
 
Related Content/Links
 
»   Carrier Interoperability Feeds Service Uptake
Making sure mobile services work across carrier networks boosts revenue and cements customer loyalty. Sun and its partners are meeting this need by offering a variety of interoperable solutions.
 
 
Related Content/Links
 
»   Prop Up the Brittle Legs of OSS/BSS Systems
If communication service providers want to add new features to create new revenue streams, they need to do something about their crumbling OSS/BSS systems.