Open APIs Mean Anything and Everything

Ask billing vendors about the code for their application programming interfaces (APIs) and you’re likely to hear a declaration that it’s “open.” But how they define “open” affects the way you’re about to do business with them. APIs, which link OSS and billing components, ensure that applications can talk to each other and complete the tasks asked of them. When a billing vendor says its API is open, or published, it doesn’t necessarily mean you’re going to get all the documentation you need.

Some companies hold their API code close to the vest, like sea captains hug logbooks detailing their course to the New World. Other billing vendors do the opposite: they share their APIs in the public domain, in hopes you’ll use their ship to get you there. Some vendors give you just enough API information to get you started, yet hold back on documentation so you need them again when you upgrade or make other changes to your system.

Muddy ground

This is the muddy ground of integration code sharing, a game where there are few rules, a place where what you see is not always what you get. There are the basic players, of course: the telco looking for a new billing or OSS application; the billing vendor, whose APIs are crucial to the integration of the telco’s new functionalities; the enterprise application interface (EAI) provider—the middleware vendor that provides the glue between the APIs; and of course, the integrator, who must work with the telco, the billing vendor and, when the architecture warrants it, the EAI vendor to get those APIs to fit and make the systems sing. The result, one hopes: seamless, flow-through integration. But even with all these parties working in concert, that ideal remains elusive. Says one integration expert: “It’s like sex in high school. Everyone’s talking about it, but nobody’s doing it.”

There are several aspects to a good, open API, says John Yin, chief technology officer for Daleen Technologies. It should be well-defined and complete, and it should be standards-based, so programmers don’t have to learn a new language when the system is installed. An API must also have good documentation so customers can follow the coding. “It’s important that the API contains enough diagnostic information so the customer will know what they did wrong, so they don’t call you all the time,” Yin says.

APIs and competition

How much API detail should a telco expect a billing vendor to share? At what point does the billing vendor lose its competitive edge by handing out too much API information? What about the middlemen, the EAI vendors who rely on APIs to tie systems together? They run into technical headaches when API data is incomplete or missing.

The answer to each of these questions depends on which side of the API one sits. “Vendors look at it differently,” says Liz Lockerman, a senior manager at Ernst & Young LLP. “The vendors that tend to be more open with their APIs see them as a competitive advantage. If vendors think other applications can be easily integrated with theirs, [publishing their APIs] makes their application more acceptable to their customers.

“When vendors aren’t open with their APIs, what they’re really trying to do is protect their licenses and revenue,” she says. “In terms of APIs, they’re generally published items, so integrators sign confidentiality agreements when working with them. The telecommunications industry is very incestuous—everybody knows everybody, and every company is afraid of their competitors learning about their unique business strategy.”

Saville: Fewer holding on to API data

“We don’t make our APIs available to the standards bodies,” says Rich Aroian, vice president of alliances at ADC/Saville. “It doesn’t give us a competitive edge [to do that].” But to Aroian, publishing APIs doesn’t necessarily pose a risk of losing proprietary information. “Initially, people held on to their APIs in the communications industry. Companies that consider APIs 100 percent proprietary are more and more in the minority. People don’t buy customer care and billing applications because of the APIs. They buy them because they need a system that works.”

But, he admits, issuing APIs can help smaller companies attract buyers. “Publishing APIs declines, depending on the value and complexity of your application,” he says. “If you’re talking about an application that costs half a million to a million dollars, putting your APIs in the public domain isn’t going to help you in the selling of your system.

“Exposed APIs only get you part of the way there,” he says, “but you [still need] to have an understanding of the underlying data models and business processes the data supports. What companies are doing is layering; they have a business objects layer, which embodies the data and the business rules that are inherent in the application you are revealing in the API. For instance, if people want to look at their usage information through customer relationship management [CRM] functions and move it back into billing, the business objects layer makes it easier.”

When there’s too much API data

One aspect of the API availability debate is that the more API information a telco has about its billing and OSS, the more work it can do on its own. If the billing vendor chooses to hand over only limited API data, the carrier will be that much more dependent on the vendor for system work.

“There are reasons why they might not want to share it,” Yin says. “Some legacy billing systems don’t have a complete data model. So if a customer wants to write a report on revenue, receivables or usage, and the vendor hasn’t given him a complete data model, you have to rely on the vendor to do the reports.”

“I want to control as much as possible on my own side,” says Linda Gimnich, a principal at TMNG. “I don't to have to get on someone else’s priority list to get the information I need; because my priority might not be their priority."

For instance, she says, when billing directors see a glitch in the system, they want it fixed yesterday. “Should I have to keep going back to the vendor for this? Should I have to get in line before they get back to me? If I’m a director of billing at a carrier and I need to know the impact of an error condition, I need to have control of that immediately, within an hour or two.”

In fact, the availability of API data is part of the puzzle when analysts evaluate a billing company, says TMNG principal Ed Shanahan. “Overall flexibility, whether it’s the APIs or not, is important,” he says. “There may be inflexibility in the business relationship with the customer. Is this a company that’s going to pull you out of the ditch when you need pulling out of a ditch? There are some companies that say, ‘It’s our way or the highway.’ There’s also modularity, scalability; can you set up your own catalog, introduce new services, or use relationships between products to create new products? APIs are a key piece of the puzzle, but not the whole puzzle.

"Many vendors are trying to address this gap by educating users on ways their product can be used to address such problems as product catalog changes, bypassing the need for customization requests," he says.

On the other hand, telcos can be hard to please, Shanahan says. “No matter how flexible the vendor makes the APIs, the customer will always want more flexibility. I’m not sure you can have 100 percent satisfaction. You, as a billing vendor, won’t be able to do what everybody wants.”

Protecting integration dollars

The use of the API as a competitive tool is by no means uniform in the industry. Some billing companies simply sell it all in one package—software, published APIs, technical manuals, training—and let it go at that.

But giving your customer too much API data can ruin chances of future integration work with that customer. Given enough documentation and sample code, developers at the telco can take that information and do the work themselves, which translates into lost revenue for the billing provider down the road. “If you do order management, but you also want to eventually own the desktop [at a telco], overexposure of your API can hamper that, even though it’s your client,” says Ernst & Young’s Greg Douglas.

The CLEC-ILEC model

An open API is the model of choice when it comes to CLECs interconnecting with RBOC back-office systems, says Robert McCausland, vice president of regulatory and interconnection for Allegiance Telecom. Allegiance interconnected with Bell Atlantic last year. “We purposely selected vendors that wouldn’t consider their APIs proprietary,” he says. “If they made them proprietary, the ILECs would be less willing to share their resources. ILECs are motivated to work with parties with open, available interfaces rather than one-time proprietary systems. The ILECs knew they would save themselves time and effort when other CLECs would come to them for similar interfaces later down the road.”

Connect not always direct

EAI (middleware) developers have their own hurdles when it comes to API data availability. One chief complaint: Although billing vendors are highly motivated to give enough API data, the APIs often don’t expose all the applications’ functionality, making it difficult to get the middleware to interact with the various systems. “Billing vendors are forthcoming with the information,” says Malcolm Lewis, director of marketing at Vitria Technology Inc. “But a particular vendor may expose only 30 percent of the functionality of an application in the API. So if you want to access their application—such as to change the status of an order in the underlying application—you’re going to run into trouble. They haven’t built a rich enough API to support all of our customer’s requirements. Most have rich APIs, and the ones that don’t are working hard to get there.”

Older telcos built standalone legacy systems that weren’t designed to link to newer systems applications. In such cases there may be no API at all. “The alternative is hand-coded interfaces, which adds to the expense, because when it’s written in custom code, it’s more difficult to maintain over time and it’s less flexible. Or you have to connect directly to the underlying database,” Lewis says. Connecting directly to the database without an API is not a good idea, he says, because APIs usually provide integrity-checking logic. They can act like a screen, verifying a certain event such as the creation of a new order. “So if you bypass all that logic and go directly to the tables, and don’t move the data into the tables correctly, you can corrupt the database.”

Bidirectional is optimal

Another problem that crops up is that the API may be unidirectional, either outbound or inbound. All of the applications assume that they are the center of the universe, so it’s easy to move data into the application, Lewis says. APIs with outbound capability can indicate when something has changed within the application, such as when a telco customer has just created a new order. “So if they only have an inbound API, the EAI’s software connector has to continuously poll the inbound API for changes in the application the connector cares about,” Lewis says. “With bidirectional APIs, it’s much easier to track changes in the applications.”

But the tables can turn, so to speak, when the middleware provider can’t read all of the functionality in the API. The API may provide 100 percent of the application’s data, but the middleware vendor’s connector may only be able to read 30 percent of it. “Vendors will say they have a connector when they have only rudimentary functionality,” Lewis says. “They can access 1 percent, and they say they have a connector.”

Billing vendors charge EAIs for API data, albeit indirectly. “If I’m going to build a connector to a vendor's billing system, I might have to pay to join their partner program,” he says. “Typically you’re not going to be a connector to these partners without joining the partner program.” Such programs can cost between $10,000 and $20,000, Lewis says.

Moves to standardize APIs

Some believe the OSS integration world would be a better place if the industry could agree on a single standard for APIs. When billing vendors or integrators talk about standards-based APIs these days, they refer to several available common architectures, such as CORBA- or COM-based programming. Some vendors even use such programming languages as PERL, or telcos develop proprietary programming to build the interfaces.

Such proprietary or non-published APIs can be a headache for integrators, Ernst & Young’s Lockerman says. “Most APIs are difficult to work with in the first place, and the customer’s IT team has to have some very specific training to be able to use that API. They have to keep those APIs updated as new versions of the [billing] software comes out. If the API’s not built on some common platform, the customer’s the one that’s in trouble.

“It’s very technical, and the more standards-based the APIs are, the easier it is to perform that integration. There is the concept of ‘reusable mileage.’ If you’re doing CORBA interfaces between two applications, you can take the CORBA knowledge doing that integration and use it again for another two applications using CORBA more easily. It’s better for the customer, because the integration can be done faster, and faster equals cheaper.”

XML: Is it the future?

Lockerman believes the industry is heading toward eXtensible Markup Language (XML) as a standard, and Telcordia Technologies’ chief architect, Mark Effinger, agrees. “We prefer to do XML,” he says. “There is quite a bit of energy toward XML, and we believe that the telecom industry should adopt it.” XML’s greatest advantage, in Effinger’s words, is that it is “release-independent,” which means developers don’t have to upgrade all the API code at one time when a new billing software version is released.

“There are other schools—like interface definition language [IDL], including CORBA IDL and DCE IDL—that people use,” he says. “But IDL, in all of its flavors, has the drawback of having structured messages. A lot of telecom providers are stuck with IDL, and they are saying it’s just too hard to manage systems with structured interfaces,” he says. "Structured APIs have rules such as limiting messages to 20 bytes. If one side of the API is upgraded, you have to flash cut both sides of all the APIs to the new version at one time.”

Vitria’s Lewis says that although telcos are moving toward XML behind the firewall for internal systems, most middleware integrators don’t use CORBA IDL or XML, but instead rely on internal proprietary formats. “The EAI vendors who don’t speak XML natively [rather than through a connector] won’t be able to take advantage of a customer’s formats,” Lewis says. “A lot of companies are saying, ‘We’re using HTTP as an internal transport, why don’t we use XML as an internal data format? We eliminate translation steps when we move data from within the firewall to outside the firewall.’ ”

Not quite ready for prime time

You get more flexibility with XML, Effinger argues, because the markup language uses tag values. Every piece of data is tagged and addressed, and flows through to the other side of the API without intensive code rewrites. “You don’t tightly couple both sides of the interface. With IDL, it’s all lock-stepped together. XML provides the customer a much easier way to administer the environment with a lot of systems,” Effinger says. There’s another reason he likes XML. Bell Labs (now Telcordia) in 1971 invented flexible communications interface format, which he considers an early version of XML. The Telcordia legacy systems—used by the RBOCs—use tag value technology. “That’s why we don’t want to go backward to IDL,” Effinger says.

But there are drawbacks to the tag value technology. “XML is the wave of the future, but the future isn’t here yet,” Lockerman says. “I know other companies are thinking XML is the way to go, but first companies have to build out their applications to make them XML-ready.”

Although XML is used in Web-enabled software such as electronic billing presentment and payment (EBPP), there are very few examples of using XML for end-to-end flow-through, says Saville’s Aroian.

“The industry needs to put some energy into defining the logical data models of the XML interfaces,” Effinger says. “We need to agree on how the billing component speaks to the network management component.”

The cost can be high

Then there’s the cost factor. “A lot of telecom providers are stuck in IDL; and some of the smaller OSS suppliers are afraid of the cost it would take to change their interface technology.”

Whether or not the industry decides on a single API standard, billing vendors realize that it’s better to include than exclude. Emerging telcos are learning to purchase billing “application packages,” which can easily be linked to new systems. So, the more you share your API and data models, the more customers you can win. And there are bound to be more customers. “Think of the number of applications that are required in each of the layers of the TMN,” Lockerman says. “There’s no vendor that does every one of those things. I don’t think anytime soon there’s going to be a vendor who can provide a complete solution, so the need for APIs and openness will continue.”

Nor would a single, industry standard reduce the workload for integrators.

“Quite frankly, I think there’s a lot of work for integrators, because that work always needs to be done, whether there’s a standard interface or not,” Lockerman says. “In the billing and OSS space there are so many applications that are required to operate the business, and the applications have to work together seamlessly with the end user. Has seamlessness become a dream? Yes.”