.gif)
Open standard interfaces-OSS/J
Standard interfaces can put the purpose of an OSS application into crystal-clear focus, even before you develop or purchase a solution, says Doug Strombom
Let’s say you are a telecommunication service provider and want to offer a new service – a package of downloadable music, for example. To provide even this relatively simple service, providers must implement new service platforms and then integrate the service into their Operations Support Systems (OSS), the backbone IT infrastructure of all telcos.
The fact is, service providers have relatively few options: either build customised applications or implement commercial off the shelf (COTS) applications. Although some IT groups still create homegrown applications, COTS solutions have become more widely accepted in recent years.
Although integration costs are often hidden within other budget items, integration is one of the highest technology expenses that telecoms companies pay.
According to Mick Reeve, Group Technology Officer at BT: “OSS configuration costs are usually three to ten times as high as the systems' original purchase price. And integration is one of the hardest parts. It requires difficult mapping of data and functionality between applications, so project timelines often suffer long delays. As a result, the whole industry pays a very high 'integration tax' and a high 'configuration tax' that slows down service innovation and hurts the ROI of almost every OSS project.”
Over the last few years, a large number of leading telecoms companies have banded together to address this problem. They want to turn the traditional 'buy now and integrate later' IT approach on its head. The solution they propose is to mandate that OSS vendors support open standards for Applications Programming Interfaces (APIs). It doesn't sound too exciting – until you consider the costly alternative of continuing to do business as usual.
One obvious example of this phenomenon is the closely aligned work of the TeleManagement Forum (TMF) and the OSS through Java Initiative (OSS/J). TMF – the dominant standards body in the telecommunications OSS area – offers a blueprint called 'New Generation OSS' or 'NGOSS'. OSS/J offers a suite of downloadable APIs for gluing OSS applications together. The combination of these two efforts adds up to a powerful, implementable OSS standard. Together TMF and OSS/J have pushed hard for the widespread adoption of open-standard APIs by telecommunication service providers and vendors alike.
“The combined example of TMF and OSS/J, and the business value of what those standards do, is just becoming widely recognised by service providers,” says Doug Strombom, CEO of Tigerstripe and an OSS/J Steering Committee member. “As more and more service providers become aware of this business value, and urge their peers and suppliers to use the standard, it's inevitable that adoption rates will accelerate.”
Another benefit is that open interface standards help clarify why we purchase OSS in the first place. We call them 'information systems,' but how many times have we implemented one without ever getting any information back at all? Standard interfaces can put the purpose of an application into crystal-clear focus, even before you develop or purchase a solution.
Strombom refers to this as a 'contract first' approach to OSS management. “With contact-first integration, finally we have a way to explicitly state what a system does. Service providers know the value that each system will provide – or won't provide – and can make wiser investment and end-of-life decisions. Using clearly-defined, open interfaces eases the pain of integration – less time, lower costs, and better quality – and it allows the service provider to have more control over the development process,” he says. “It's the difference between merely administrating your OSS and managing your OSS.”
Although service providers tend to define value in multiple ways, a growing body of business experience indicates that open, industry standards deliver real value. Some service providers are motivated by business agility and time to market. IT has been a laggard when it comes to delivering support for the new services that marketing demands.
Incumbent service providers are under threat from agile new entrants – including Internet-based companies who are able to offer compelling services very quickly almost anywhere. This highly competitive environment demands that all players figure out flexible system architectures.
Still other service providers are focusing on reducing lifecycle IT costs. Wisely so, since IT directly affects overall profitability. IT budgets are decreasing or flat, but OSS departments must address the ever-increasing complexity associated with new network service offerings like 'quadruple play.' The management of these services is daunting, since enterprise applications need to handle all aspects including order handling, service activation, quality management, inventory, and billing.
Vodafone implements standards
Standards are clearly the answer – if they are implementable. And that's the catch according to Joerg Frankenberger, head of Network Management Engineering for Vodafone Germany. He clearly recalls the day he discovered OSS/J interface standards at an industry trade show.
For Vodafone, the big issue was not simply to launch new services, but rather to find better ways to manage the way those services are delivered and supported.
“Of course we can offer new services, but can we ensure quality?” says Frankenberger. “The complexity of network OSS architecture is increasing at a phenomenal rate. It's incredible how many networks and applications are involved in the support of new services... we face a huge number of technologies to manage. Linking each system point to point, is just not supportable because it's so expensive and time consuming.
“It was at TeleManagement World a few years ago that I first saw a catalyst project using NGOSS” he says. “It made a very academic impression on me. NGOSS would be the ideal OSS solution, but it seemed to be more theoretical than something I could actually use. I thought: good thing, but in reality hard to achieve.”
Once he discovered OSS/J, in many ways the fulfillment of NGOSS, Frankenberger realised that “someone had anticipated what we needed”.
“When I became aware of OSS/J, I had a good feeling that it could be the way to iterate towards an NGOSS enterprise architecture,” he says. “From my point of view, OSS/J is the USB plug for OSS.”
The Vodafone OSS/J initiative began with a feasibility study, then quickly became a proof of concept project. “The business driver for adopting OSS/J was our need to connect more and more OSS at reasonable costs, enabling us to spend our budget for application development instead of on integration,” Frankenberger said.
For Vodafone's proof of concept trial, they integrated service management systems used by Vodafone's Network Management Centre via OSS/J's Trouble Ticket (TT) API. From concept to completion, the proof of concept took approximately eight months; a period that he says was lengthened by Vodafone's decision to open the implementation to multiple parties. “We wanted to test it in a business environment involving software vendors, consultants – a lot of participants in a professional way.”
Frankenberger says: “We wanted to compare OSS/J versus an alternative based on a proprietary EAI implementation using Vodafone proprietary interfaces. Part of our feasibility study was to compare OSS/J and other middleware integration concepts against our business scenarios.” The result of the feasibility stage, he says, was that “OSS/J offered already-defined APIs and seemed to be more efficient.”
Vodafone's first OSS/J implementation was comparable in terms of time, money and manpower to an ordinary interface implementation. However, Frankenberger insists, the implementation represented a great deal more.
“Considering that this was our first contact with a new technology, and that we were also writing an integration cookbook for future OSS/J solutions, this was not a lot of time,” he says. “It brought much more value than just an interface and showed us the clear potential to save money using OSS/J. For the next project, we had estimated savings of about 20 percent. It turned out to be better than that.”
Those savings help to explain why OSS/J adoption is spreading from Vodafone Germany throughout Vodafone's other operating companies (OpCo).
“We use OSS/J for what we call cross-border business interfacing,” Frankenberger says. “This means we can effectively communicate between different OpCos within the Vodafone Group. The first step was implementing the Trouble Ticketing API, which connects the different trouble ticketing systems at the different OpCos to each other by means of OSS/J.”
In addition to the TT API, Vodafone is implementing other OSS/J APIs like Quality of Service (QoS) for Fault Management purposes. Frankenberger adds: “We have found that the benefits of OSS/J are cumulative. The more you do, the more you are able to reuse capabilities and achieve greater benefits. It's kind of a self accelerating improvement that you get.”
Start small
As the Vodafone case study shows, the best approach to implementing a new enterprise-wide architecture it to start small and add new functional areas in incremental stages. Many service providers begin by focusing on a specific high value areas that will get the attention of top management. Early success can help gain crucial executive buy-in and additional programme funding and support.
Often service providers turn to a middleware platform as a panacea for integration challenges. Middleware such as an Enterprise Services Bus (ESB) facilitates easy message transfer between all the enterprise applications. But middleware is a “blank slate” that can be used in many ways. The result often is a lot of unplanned expense, trying to figure out how to configure the middleware for specific business needs.
“The problem with proprietary middleware is that it's much more expensive and there aren't open standards behind it. So you either need to fund your own interface R&D or try to re-use proprietary integrations that have been done by others in the past,” Frankenberger says. “Either way it's proprietary and there's no cost sharing – there's no plug-and-play at all.”
So how is standards-based integration different? Standards like OSS/J provide a technical framework for integration. The standard APIs define an application-independent, or 'canonical,' form of the information that passes across the interfaces. The API also defines the behaviour of the interface, such as the notifications, queries, and other events. These standard transactions can be mapped to the proprietary databases and functions of each application. In short, the standards provide a cheaper, faster, re-usable and reliable way to do integration.
One of the critical success factors for adopting open standards is whether the organisation establishes appropriate policies and governance. Someone with authority must insist on using open standards. Otherwise, there may be too much resistance. OSS project managers often focus mainly on project costs and deadlines, and may consider open interfaces to be a luxury they cannot afford. OSS engineers often are most comfortable with their familiar, non-standard techniques. Project oversight by leaders who insist upon using open standards is needed to overcome this natural resistance.
It is imperative that the service provider take a very active role here – proactive management is really the only option. The productivity increase from better interface management can be impressive over time. This takes a commitment to acquiring the knowledge, processes, and tools that make open standards really perform.
A critical mass of adoption
Service providers and vendors are increasingly adopting open interface standards such as OSS/J. “A tipping point of adoption will occur when a critical mass of purchasers and vendors support open standards,” says Tigerstripe's Strombom. To encourage this to happen sooner, better collaboration mechanisms are needed. An ecosystem of tools, training, and consulting services are growing up around OSS/J to address this need. “The OSS/J ecosystem includes software like Tigerstripe's, which greatly reduces the learning curve about standards and increases the productivity of interface developers,” says Strombom. “We are encouraging adoption by taking the pain out of open standards support.”
Vodafone is convinced that the more service providers and suppliers support OSS/J, the more the industry as a whole will benefit. “We are encouraging service providers and vendors to support OSS/J,” Frankenberger says. “Some vendors resist the move to standards because they make money by providing integration services. The flip side of the coin is that their profit margins suffer because of the high cost of providing integration services. Looked at from the right perspective, open standards makes sense for everyone.”
“I'm certain at this point that OSS/J is not stoppable,” Frankenberger says. “It's not a question of whether or not the industry will adopt OSS/J. It's more a question of when. And we are doing what we can to make industry adoption happen faster.”
– Since this article was submitted, OSS/J has become part of the TeleManagement Forum.
• Doug Strombom is CEO of Tigerstripe and an OSS/J Steering Committee member. He can be reached at: doug.strombom@tigerstripesoftware.com
• William F. Wilbert is communications director for the OSS through Java Initiative and can be contacted via e-mail: ossj-pr@sun.com
Share this article with others
Post to del.icio.us
Printed from http://www.eurocomms.com/features/111234/Open_standard_interfaces-OSS%252FJ.html
Comment on this article
Skip to comments
We encourage users to analyse, comment on and even challenge European Communications's articles, including the one above - 'Open standard interfaces-OSS/J'
User reviews and comments that include profanity or personal attacks or other inappropriate comments or material will be removed from the site.
Additionally, entries that are unsigned or contain "signatures" by someone other than the actual author will be removed. We will take steps to block users who violate any of our posting standards, terms of use or privacy policies or any other policies governing this site.