Financial Watch : Integration Costs Loom Over OSS Deployments

As service providers of all stripes continue to watch their cash flow closely, a source that’s often to blame for cost overruns in OSS is integration.

Generally, software licenses constitute a fixed cost to a provider while the services side tends to be a confusing quagmire of expenses that can include training, definition and design, installation, custom development and installation.

A recent RHK report entitled “OSS Integration: Costs Lurk Beneath the Surface,” states that between 21 percent and 74 percent of total OSS expenditure for any given project can be related to systems integration (see figure).

Conventional wisdom says that providers should take the cost of a software license and triple it to approximate the cost of integration.

While we may still hear about OSS integration projects that spiral out of control, for the most part budgeting and planning have improved.

But as providers take a more careful approach to spending, they are looking to standards, changes from the vendor community and changes in the overall business climate in order to keep integration costs in check.

Standards

As a whole, the OSS industry is moving toward component-based OSS architectures such as the TeleManagement Forum’s NGOSS and eTOM models and the OSS Through Java initiative, which has started developing OSS APIs. Other standards such as Microsoft’s .NET and Sun Microsystems’ J2EE are also gaining momentum as providers prepare their OSS architectures for next-generation services. (For more, see “.NET and J2EE: The Architecture War Heats Up,” p. 12).

However, these efforts are still in the early stages of adoption. “Everybody says they are open; proprietary is out,” says Leif Hoglund, OSS Director at RHK. “Even if there is no standard permeating the industry, certain principles are being followed to make integration easier and faster.”

Vincent F. Damasco, vice president of equity research at Janney Montgomery Scott refers to standards as the “Holy Grail” for OSS deployment but also mentions that everyone claims to have standards. “They work with CLECs where they are plugging in the latest and greatest, but if you walk into a CRIS billing shop and try to integrate next-generation software like activation, provisioning and CRM, standards might give you a Web-based GUI for end users, but at the operational level you’ll still be dealing with green screens,” he says. “Even if everyone adopts standards, it will take time for them to filter through.”

What seems to be gaining popularity is the concept of loosely coupled applications, according to Hoglund.

Vendors vs. Systems Integrators

The flexibility that goes along with loosely coupled applications will be even more crucial going forward, especially as billing and OSS vendors position themselves as integrators.

While most Tier 1 and Tier 2 providers rely on large systems integrators and internal resources to get a project up and running, OSS vendors are also presenting themselves as up to the challenge.

“The vendors claim that they are more proficient than the SIs on integrating their software/systems, which should be true,” Damasco says. “However, SIs generally have more knowledge and people capable of working with all of the underlying systems in use by the service provider. Also, given the size of the SIs relative to most vendors, they are likely to have more pricing power over the vendors on the services work.”

Several of the large billing vendors—Amdocs, Convergys and CSG, for example—have been pursuing a strategy of being a one-stop shop for the bulk of a carrier’s OSS needs. These companies may have a core billing system with additional functionality such as CRM, order management and data mediation.

In this type of situation, modules from a single vendor will be relatively easy to integrate. “If you’re integrating around the billing platform, it makes a great deal of sense to use this kind of model,” says Hoglund.

However, there are cases when a vendor acting as the integrator has run into trouble. Damasco points to Orange France’s use of Convergys’ Atlys wireless billing product as an example. “Convergys was acting as the sole integrator, and they needed to prove to the carrier that they can work on the integration and get it working,” he says.

The project started in 2001, and two years later it was shelved. This was partly due to questions about Atlys’ ability to support 3G services in this instance, but also due to Orange France spending millions of dollars without an end in sight.

There’s no guarantee that one of the large professional services firms would have done any better, however, and in cases where billing is the core piece of an installation the vendors may still be in the best position from an integration standpoint.

“For billing, it’s very, very complex,” Damasco says. “The technical know-how needed is far superior from other OSS areas.”

Another example of a vendor-driven project that fell short involves CenturyTel, a Louisiana-based service provider, which in 2000 selected Amdocs for convergent billing. This project has experienced delays due to the project going over budget.

According to a 10-Q that CenturyTel recently filed with the Securities and Exchange Commission, this project remains in the development stage and has required “substantially more time and money to develop than originally anticipated.”

The 10-Q filing states that CenturyTel expects to complete all phases of the new system no later than mid-2005 at a cost in excess of the previously disclosed estimate of $180 million. CenturyTel currently believes completion of the project may require it to revise its previously disclosed cost estimate by between $50 and $60 million. The company also states that “there is no assurance that the system will be completed in accordance with this schedule or budget, or that the system will function as anticipated. If the system does not function as anticipated, the company may have to write-off part or all of its remaining costs and further explore its other billing and customer care system alternatives.”

A Changing Attitude

Overall, OSS projects seem to be better defined today than just a few years ago. “People are spending more time to determine the processes they are trying to automate and exactly what benefit they might get out of it,” Hoglund says. He adds that integration difficulties don’t seem to be about the software or technology, rather it’s about understanding the operational environment where they exist. “Products have become almost a commodity; what seems to be in limited supply is an understanding of what needs to be built.”



Note: The information in this article should not be used as the primary basis for investment decisions. The information is based on sources BillingWorld & OSS Today believes to be reliable. The statements expressed are not necessarily those of Billing World & OSS Today.