OSS Integration: Telcos Struggle To Connect the Pieces
Anita Karve
02/01/2001
As providers add automated, next-generation billing and OSS software into the mix alongside legacy applications, or take the best-in-breed approach to get to that elusive concept of “end-to-end,” they need to make sure these systems are communicating. There lies the source of frustration for service providers of every persuasion.
Vendors, for the most part, have taken a piecemeal approach to communicating with software outside of their own. Even in a green-field environment where a provider may choose to go with a single vendor for everything, the provider still gets into trouble if it wants to add another package in down the road.
Lost in the Translation
Providers that work with several different OSS and BSS vendors know all too well the challenges of getting these systems to communicate. “I’ll give every vendor out there full credit for trying to put a high-quality product in the marketplace, but every one of them builds their product as if they were the center of the architecture,” says Tom O’Dea, cofounder and president of the western region of Foxfire Consulting. He says this attitude toward product development can lead to inconsistencies in data.
“It’s really all about the data,” O’Dea says. “When you try to integrate these systems you’ve got to decide what your data source of record is, and you need to find some way to make sure all these different products aren’t working with different data. You have to make sure that the data is current, synchronized, and that everyone has the same view of the customer.” The product catalog synchronization between billing and order management is a common cause of data inconsistency. For more on the difficulties involved with product catalogs, see “ Product Catalog Inconsistencies ”.
Defining back-office architecture should be a major concern for providers as well. “They may get that enterprise architecture defined, and they may know what they want to tie together,” O’Dea says. “But are they building business processes in conjunction with that solution? Or is someone else off deciding how customer service is going to work, how trouble reporting is going to work and how the provisioning process is going to work? And, do you end up with inconsistencies between business processes and that system solution?”
Providers are doing all they can to capture order information, provision the service and let the billing system know about it all in real time. For more, see “Real Time vs. Batch,”.
In the past couple of years, that job of integrating back-end systems has been made easier. Today, several companies incorporate provisioning, order management and activation—or some combination thereof—in a single package. “That was a big departure from a more traditional point solution approach, where you had to go and find a best-of-breed for everything and stitch it together through an integrator or other means,” says Frank M. Fawzi, founder and CEO of OSS vendor CommTech. “Also, now billing products consist of multiple modules that have come together over time. It’s [about] reaching a sustainable bundle of the right components.”
In some instances, service providers will use open APIs published by their vendors; either through an in-house team or a systems integrator, they will create a connection among products. But working with APIs can bring challenges. “The more legacy systems around you and the more different technologies, the bigger the challenge,” says Doron Gover, director at Amdocs.
Another option for OSS integration involves middleware or enterprise application integration (EAI) products from vendors such as Kabira, Vitria and WebMethods. These types of products bridge different applications and find common ground among them. O’Dea is a proponent of bringing in a middleware package when working on a service provider’s site. In his experience, providers are on their way to a successful deployment if they know exactly what tools they want to integrate with their architecture and have a good EAI plan that includes some sort of middleware or object broker.
But even having this plan in place may not be enough. “Middleware vendors are having more success in other industries than telecom, because this market provides a challenge that’s a little beyond what the vendors planned for,” O’Dea says. “They have to mature a little and frankly, be able to manage more interfaces and more complexity than they planned for if they are to succeed in telecom.”
He adds that some vendors create the expectation that once their product is installed that everything will run smoothly. “The reality is that it’s not only how complex the telecom architecture is but how much of that is constantly changing because of changes in software, the product catalog and the company as a whole,” he says. “To think you can live without some kind of broker in the middle of that architecture to keep all the data flowing is naïve, but to think any of the products out there will provide the instant solution to that problem is equally naïve.”
Real World Integration
Yipes Communications, an IP optical network provider that delivers Gigabit Ethernet services to customers, is a fairly new entrant to the market and is still in the early stages of developing a robust back office. “Our challenge has been that we’re a start-up, and we got started thinking about what kind of services our customers would want to have control of,” says Sherrie Littlejohn, vice president of information technology at Yipes. “One of these was provisioning services, and the other is billing.”
The company recently installed Portal Software’s Infranet billing platform, and it’s in the early stages of implementing provisioning and order management software from Eftia. “Our expectation is that we will integrate Eftia and Portal,” Littlejohn says. She adds that Yipes has implemented its own middleware using Java, HTML and XML.
She also says that Portal had already been selected as the company’s billing package prior to her arrival at Yipes, so she had to work with what was already decided upon. “I’ve spoken with [other billing vendors], but since Portal had already been chosen as a product I thought it was necessary—given the investment—to make that work for us and to impress upon the vendors to get the right hooks applied quickly,” she says.
The company has already integrated products from Siebel and Remedy, and it is now working to get the APIs from Eftia and integrate them with Siebel and Portal.
“It’s a complex task, and we’re taking it one elephant toe at time,” Littlejohn says. She adds that most OSS and BSS software vendors understand the difficulties of integration. “Something I try to do when I meet with the vendor is to give them a view of what it is that we’re trying to accomplish up front, so they know our ultimate goals and our needs,” she says. “As we’re implementing their solution, I also need them to understand our environment so I get the right hook and we don’t lose any time.”
Littlejohn also says that for service provisioning, she can’t just bring in a canned solution and hope it’ll work. She adds that until the integration work is complete—expected by the third quarter of 2001—Yipes will continue processing orders manually.
Products Get Beefed Up
Perhaps as a reaction to such challenges and the sometimes awkward efforts involved in getting various OSS and BSS talking, many vendors are attempting to make integration easier by either partnering with each other or by adding functionality to existing platforms.
“You see several different behaviors among the vendors right now; there’s at least a small subset that’s trying to pull together the complete OSS and billing solution, [such as] Lucent and ADC,” says O’Dea. In 1999, Lucent acquired billing vendor Kenan Systems. In addition to Kenan’s billing platform, Lucent’s Software Products Group also offers OSS products such as activation, provisioning, service assurance, mediation and analysis tools. ADC plunged head-first into the billing space with its acquisition of Saville, but ADC also offers software for service assurance and network performance management.
“If you go with one-stop shopping, you’re not worried about integration challenges as much,” O’Dea says. He cautions, though, that if a provider chooses another vendor for any component of the architecture down the road, integration could prove to be difficult.
Other vendors haven’t gone as far as the one-stop shop model, but they are incorporating new functionality into their product portfolios. For example, Daleen has gone beyond just offering its BillPlex billing platform. The company also has a Web-based customer self-care product and a service activation package for voice and data services. Daleen added these products through its December 1999 acquisition of Inlogic Software. By the end of February 2001, the SwitchFlow activation/provisioning product will be bundled and completely integrated with BillPlex, according to Craig D. Vosburgh, director of global e-commerce marketing at Daleen.
Amdocs, aside from billing, has for the past couple of years also offered an order management module that works with the company’s Ensemble billing platform. “It’s part of the trend of removing the barriers within the telcos between the back office and the front office, or what used to be called BSS and OSS,” says Gover. “Traditionally, telcos had back-office people who set up the network and a front office that captured orders and took care of billing. That was fine until about five years ago, because [that model] was based on a limited number of services such as voice and leased line.” Gover adds that with today’s complex services (including frame relay and ATM), deregulation and increased competition, the barriers should be removed in order to provide services faster.
“Customers are asking for tighter integration between the ordering process and the billing process,” Gover says. “New services can’t be billed, and billing becomes the bottleneck in providing new services.”
“The hardest thing is building the connectors between the products we have, but the benefit of our integration work will be faster implementation and more accurately functioning features between these areas,” says Daleen’s Vosburgh. He adds that currently the middleware vendors don’t have connectors on the bus level (a common channel that provides a data transfer path among multiple devices) that can allow billing and order management/provisioning systems to function fully. “The only way people can do it is to write very detailed connectors between the two, and that’s what happens every day,” he says. “It’s a very lengthy process, and a lot of work goes into creating the connectors.”
Common Ground
OSS vendors today struggle with APIs, home-grown connectors and preintegration work with partner companies. What they and the service providers that actually install the systems could really use is a standard way to integrate.
“We’re talking about very heterogeneous environments in terms of vendors and hybrid networks,” says Amdocs’ Gover. “You have IP over SONET, IP over ATM, IP over frame relay, and frame relay over ATM. You need standards in the lower layers to allow network elements to communicate with each other. I think standards will allow telcos to provide these services.”
Currently, there are easily a half dozen or more different ways to connect up different OSS packages. “There is no gorilla yet in the connector space; none of them are really deep enough, and you end up doing direct connection work on your own,” says Daleen’s Vosburgh. “It’ll be interesting to see if products like Vitria’s can go deep enough, because they are very broad right now.” He adds that the industry is looking to see who will be able to build that elusive standard OSS connector.
Obvious choices upon which to base a standard connector are CORBA and XML. “Today’s connectors are flexible enough to accommodate different formats, so it’ll be a question of what’s easiest and what provides the most flexibility,” says Andrew Desbarats, senior product manager of Daleen’s SwitchFlow provisioning product. “I think XML will probably be a standard format across those systems because it’s flexible enough and everyone seems to be going in that direction; it’s almost becoming a standard.”
“From our perspective, the best standard right now is CORBA, but XML is emerging,” according to Martin Steinmann, vice president of marketing at provisioning vendor Syndesis. He adds that the TeleManagement Forum is probably the most likely body to work on OSS integration standards. The group’s Catalyst Project demonstrations often show order management and provisioning products working seamlessly with billing software.
However, just getting a uniform way to link various OSS software may not be enough. “The challenges of integrating OSS is not technical issues like CORBA vs. XML, because the physical layer and protocols are something you can resolve very fast,” says Gover. Instead, he says, once interfaces to all existing network elements are complete, there are always new network elements and technology introduced to the service provider’s network.
From the provider perspective, Yipes’ Littlejohn says standard APIs and connectors are only half the battle. “The other half of the work is how you’re structuring your business processes and ultimately the data that’s required to go between those applications,” she says. “That’s an internal business function that needs to be addressed before you even think about what applications you want to purchase to support it. All too often we buy solutions not thinking of the data flowing between those systems appropriately and in a timely fashion.”
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article