JSR Watch

This past month the JCP Executive Committees met in Nice, France, in concert with the TeleManagement World conference, where the worldwide telecommunications industry gathered to address technical, operating, and business issues related to the back office systems that they use to run their business with their networks and services portfolios. These back office systems are called Operation Support Systems and Business Support Systems (OSS/BSS), or OSS for short.

My guest this month is Philippe Lalande, head of the OSS through Java Initiative at Sun. Philippe created and drove the Java Specification Request (JSR3) under the JCP, and founded the OSS through Java Initiative, which he continues to lead today. You'll find it interesting to learn directly from the guy at the heart of it all how the level of complexity of OSS systems is driven down by an order of magnitude by Java technology, the JCP, and Java.net, all of which have been instrumental in reshaping an entire vertical industry segment, and in driving up these systems' level of agility.
- Onno Kluyt, chair, Java Community Process (JCP)

The OSS/BSS market is worth roughly $50 billion on its own, but directly impacts half a trillion dollars in operating costs. Owning an OSS is actually what characterizes a service provider. Traditional wireline operators own their networks, while MVNOs or mobile virtual network operators run their services on someone else's networks. But all service providers own their OSS. It's their tool to do business.

Successfully running a communications service provider business today requires simultaneously operating large network infrastructures and portfolio of services to cut operating costs, bring new services to market faster and drive customer satisfaction. This exercise is heavily dependent on software. Myriad applications are deployed across very large scale IT infrastructures to cover functional domains such as network management, service provisioning, fault correlation, inventory management, service quality monitoring, order entry, billing, or trouble ticketing. Business process automation requires integrating all these systems together, making sure they share some common information models across the OSS. Taken individually these applications aren't really exotic, and integrating any two of them isn't rocket science. But the devil's in the numbers.

On average, a tier-one service provider runs 1,500 different applications. Bell Canada runs 162 different billing systems, and BT recently inventoried 3,000 OSS applications across the company. Some of them were developed in-house, others were customized from commercial off-the-shelf products, and still others were inherited from mergers and acquisitions. Some of them are very modern, recently designed on the latest software technologies; others are over 20-years-old. All of them have to run 24/7/365 because every minute the network isn't costs several millions dollars. All of them have to deal in real-time with thousands of nodes, millions of customers, zillions of commercial transactions (such as a single phone call). If you've got the picture, welcome to the OSS integration nightmare!

This nightmare becomes hell with the increased complexity and competitive pressure that come with smart devices, with the convergence of voice, data, entertainment, and soon utility computing. To support IP-based next-generation networks, industry de-regulation and other major telco trends, service providers around the world are embarking on multi-year endeavors like Sprint's so-called "transformation journey," British Telecom's "21st century network," France Telecom's "urbanization," and BellSouth's "competitive survival initiative." The ultimate goal of these strategic programs is to rationalize the IT infrastructures, evolve to more flexible component-based OSS systems, harmonize security, user interfaces, and other non functional features, and reduce the market fragmentation that results from decades of operating network silos and services hard-coded into the network elements, building bespoke telco-specific IT platforms, and trying to define standards that remained paper specifications but never made it to real implementation and adoption.

The OSS/J Approach
The OSS/J Initiative was originally founded by Cisco, Ericsson, Motorola, NEC, Nokia, Nortel, Telcordia, and Sun to fill the gaps in the OSS standardization landscape and foster a market of re-usable OSS components. To address interoperability issues, it was decided to focus on technology specific implementation, on mainstream enterprise technologies, and on making the life of developers easier and more exciting.

Rather than attempting once again to create the next-best-telco-specific OSS integration middleware (there are already approximately 400 of those proprietary things polluting the industry), OSS/J chose J2EE to provide the underlying middleware and to share the risk and the investment with other industries.

Being relieved by J2EE of most of the typical framework issues, it was then possible for the initiative to focus exclusively on OSS functional APIs that implement existing telco OSS paper standards whenever possible and run on any compliant J2EE application servers. OSS/J has established pull-push relationships with a number of standards bodies, TeleManagement Forum being the cornerstone of that strategy. Rather than develop its own standards or variants, OSS/J had some of its members contribute resources to accelerate completion of some technology-neutral standards like TMF NGOSS and align with them.

Then, because the APIs address integration tax, interoperability, and other non-differentiating common pain points, we decided that each API should come with free-of-charge, near-production-ready implementation examples, as well as free-of-charge conformance test suites. Therefore, the next critical OSS/J decision was to adopt the JCP as its collaboration and process framework. OSS/J actually decided to enforce more demanding requirements above and beyond the JCP legal framework and created its own open collaboration and governance model. This enabled the initiative to impose active participation and measurable contributions from its members, create a consistent family of APIs, factorize design patterns across all APIs, and control the overall roadmap. It particularly wanted to avoid the useless proliferation of APIs that would be too specific for certain functions or network technologies.

The APIs are verified with real products, packaged, distributed, and licensed under a harmonized licensing and certification model that avoids possible differences from one API and spec lead to another. It also enables the initiative to substitute specification and maintenance leads when needed.

The initiative operates as a virtual company, with its own steering and decision processes and its own budget, although it's not a legal entity. The governance model is open and public. Interested readers can take a look at the master agreement and the operating guide.

Thanks to all these choices, OSS/J delivers open standards that are absolutely unique in the telecommunications industry:

• No other standard delivers publicly available, free-of-charge, testable, and certifiable implementations
• No other implementation solution is an open standard

What We Learned?
Recent OSS industry analyst reports like the one from Dittberner claim the middleware game is over. J2EE and its OSS/J plug-in are heading towards 80% market share by 2008. The JCP has absolutely delivered on its promises enabling the OSS industry for the first time ever to produce open, implementable, and certifiable standards. This process framework, extended with OSS/J governance model and associated to the J2EE design patterns practices, has helped us scope and design the OSS/J technology into a very small set of only 15 APIs covering a very large portion of OSS's functional space, and at the same time a broad spectrum of network technologies including wireline, wireless, broadband, and cable. The technology is now deployed in production across the planet, and the early adopters have achieved tangible benefits; DSL provider Covad recently said that it \completed an OSS integration project in four months that would have typically required two years - and their second project was done in two months.