Service providers, not vendors, are driving the push to open up OSSs in an effort to free themselves from integration headaches that mar next-gen service roll-outs.
It seems service providers are really stepping up their efforts to push open standards and the concept of reuse in OSS development. Thought leaders like Vodafone, Cingular, BT, Covad and Cantv are chairing and leading steering committees in organizations like the TeleManagement Forum and the OSS Through Java initiative to make OSS standards more “implementable” so that they can ultimately free themselves from proprietary applications and interfaces that make integration a major pain point.
Covad, for one, recently released back to the vendor and operator community its adapters based on trouble ticketing and billing applications. “We also recently open-sourced our OSS/J adapter for the inventory API to the open source community on the Java.net site, because we want to build critical mass by encouraging the use of open adapters on top of COTS applications,” says Cornelia Pool, director of software engineering and information systems at Covad. She notes that Telstra in Australia recently employed the adapters to shorten the learning curve with its plug-and-play features. “As carriers use the adapters to buffer themselves from their inventory vendors, they will become flexible and loosely coupled,” says Sachin Kapur, manager of Covad’s architecture team.
Vodafone, which now chairs OSS/J, used its trouble ticket APIs to unify service management across its companies and partners worldwide. Vodafone Germany recently used OSS/J adapters based on that work to improve service quality management in its organization.
What’s more, Cantv (Compañía Anónima Nacional Telefonos de Venezuela) has worked with OSS/J to incorporate its APIs for integration of multiple customer care applications and systems for order management, provisioning, CRM, billing and inventory into design guidelines for future OSS/J APIs. That was done after the company launched its entire SOA initiative using OSS/J as its primary integration strategy.
This willingness by carriers to share what they learn clearly demonstrates that they want to move away from proprietary applications and integration headaches and move toward standards-based design principles. The fact that middleware tools from BEA and IBM support J2EE also makes it possible that the application server market will become much more standards-based.
Because of that momentum, and the fact that many OSS/J and TMF service provider members participate in open source projects, its seems natural that the principles of open source will carry over into the development of NG-OSS and OSS/J APIs.
For that reason, the OSS/J and TMF have joined forces under one umbrella. With more than 500 combined members, OSS/J will become a technical program within the TMF on July 1. The hope is that having a joint entity will allay confusion about OSS standards work and bolster high-level processes and models with interfaces and APIs that will make the standards easier to implement.
A Good Match?
With the merger of the two standards bodies, the OSS/J’s suite of Java, XML and Web Services APIs and adapters will be used to complement TMF’s New Generation Operations Systems and Software (NGOSS) standards. The OSS/J technologies are intended to add technology-specific components to NGOSS and TMF’s Prosspero program—an initiative for developing pre-packaged OSS solutions for carriers. OSS/J interfaces may help resolve QoS and management issues through service activation, trouble management and service assurance APIs defined in its broadening roadmap (http://www.ossj.org/downloads/roadmap.shtml).
With those APIs, developers can abstract order processing, service quality management, pricing and other variables traditionally dictated by the vendors.
For example, rather than get locked into a vendor’s interpretation of what a trouble ticket should look like, the service provider has the power to tell prominent vendors such as Clarify, Remedy or Micromuse what the “common target” is for a trouble ticket integration on the standardized map. Then all the vendor applications can be integrated according to the abstract view of the service specified in the API roadmap. That service abstraction becomes a buffering layer between the service provider and its vendor, so the former has the flexibility to change, swap or add dimensions to the solution down the road. Although data transformation must sometimes take place between vendors, the applications are loosely coupled so there are no longer an infinite number of point-to-point integrations that have to take place among all the related systems. Rather, carriers get a series of systems loosely coupled end-to-end.
Rather than have hordes of engineers familiar with either TMF specs or OSS/J specs working separately, the converged standards bodies will create a “wrapper of implementability” around OSS standards, thus enabling many fewer engineers to implement data models and processes with well-defined APIs.
Currently, all OSS/J APIs are being upgraded by the architecture group to include Web Services. “That means every API in its maintenance release will support WSDL to start off with,” explains CEO Doug Strombom of Tigerstripe, a lifecycle management company active in creating the OSS/J pricing and management APIs. (Tigerstripe is the OSS/J toolset for defining interfaces and supporting OSS/J APIs, the purpose of which is to eliminate manual coding in generating new APIs).
“The key to this partnership is the introduction of Web Services profiles so that all applications are available using Web Services,” says Strombom. “While OSS/J supported XML and J2EE profiles, which were great for application servers, it did not until now have the real power to enable companies interested in SOA and middleware to run WSDL.”
The idea the two groups want to push is “contract first,” where service providers define external interfaces to the systems before they decide to buy or build them. That’s a change from the current mindset of buying expensive systems with proprietary interfaces that are then painful to integrate during implementation.
By establishing joint procurement guidelines for vendors, the TMF and OSS/J hope to galvanize vendors to work more with open interfaces. “Carriers have the power to say, ‘I will buy your systems only if you support this integration point,’ ” says Strombom.
In general, the process of integrating a new service takes about nine interfaces, each of which takes an average of six weeks to integrate. “The shift to open standards takes out about 70 percent of that effort the first time you integrate, and as you change and integrate in the future, the loosely coupled nature brings on hundreds of thousands of dollars in savings per project,” says Strombom. “With multiple projects, the savings exponentially increase with every initiative.”
It’s possible the joint effort could be a win-win. Service providers suffer doing costly integrations, and the vendors suffer performing post-sale integration services that often are gratis.
That concept seems logical, but there is still a chicken-and-egg scenario that has to resolve itself. Even with a strong business plan, vendors are still somewhat reluctant to support openness out of the box, because they fear commoditization and loss of competitive advantage.
However, as evidenced in telecom models like Asia, where an NTT dictates to the vendors what the standards are, European and U.S. carriers seem to have an opportunity to gain more control over their OSS decisions.
