Jonathan Sieg Co-founder, President and Chief Executive Officer, AP Engines

At the “Under the Radar” session at TeleStrategies Billing 2000, financial analysts gathered to scrutinize five start-up companies. Based on the companies’ objectives and direction, product, management team and partners, the analysts chose a promising company given the current industry needs. Companies considered in the session included AP Engines, eVergent Technologies, RateIntegration, Telution Corp. and Usha Communications Technology. All of these companies had unique strengths; AP Engines had the best overall showing.

Headquartered in Maynard, Mass., AP Engines was launched in 1998 and targets cable operators, ISPs, local exchange carriers and long-distance telephony providers as they migrate toward providing next-generation convergent services. The company’s four core products cover event collection, record keeping, broadband provisioning and bill mediation.

AP Engines supports DOCSIS-compliant cable modems, Cisco NetFlow devices and PacketCable network elements. Its partners also include CSG Systems, DST Innovis and Portal Software. Recently, AP Engines joined Tellab’s SALIX SoftLink partners program to interoperate its record keeping server product, which serves as a centralized collection point for billing information, with softswitch technologies used by other partners in the program. It secured $10 million first-round venture capital financing in February. Billing World spoke with AP Engines’ co-founder, president and chief executive officer, Jonathan Sieg.

BW: What are the current industry needs, and how has AP Engines focused its efforts around that?

Sieg: The bottom line is scalability, reliability and collectibility. Our difference is that we have designed our product on a financial-grade mediation fabric. We have a transaction-based workflow processing engine at the core of our design. The design is such that we can support millions to tens of millions of customers beyond that by extending over more equipment over more platforms. Everything that we have done at the company is designed at going after Tier 1 networks. We decided that if we went after the big players, if we went after the channel partners and the major equipment vendors, we could then always scale down.

We have focused on two markets. One is the traditional telco market, and the other is high-speed, next-generation networks—definitely IP-based. There aren’t a lot of solutions out there to satisfy those two markets today. The telco world is not going away. The enormous telco infrastructure will be with us for centuries. Likewise, the Internet is evolving so rapidly, there will be points where they will converge. There will be points where they do not converge. There is a big cultural difference when you work with the cable industry, the high-speed, non-cable industry and the telco industry—culturally there’s a lot of oil and water there.

BW: What is the most important capability your mediation product must address?

Sieg: The key thing is you have to preserve the existing infrastructure. Nobody goes in with a forklift. None of the larger carriers, the ILECs and CLECs are looking to replace their billing systems. They can’t. They can’t afford to mess with it. They can’t afford to affect the flow for even a couple of days. There are some network developers out there that think they are going to move completely away from existing structures to new systems. More than likely providers will end up with networks with new acquisitions that have completely different billing systems. We have customers with as many as five different billing systems.

BW: What are some of the current implementations of AP Engines’ product?

Sieg: We have CLECs that want to do IP bypass, meaning moving all that remote access traffic that ties up circuits for hours or longer. We are initially supporting the movement of that traffic through IP switches and softswitches using our mediation platform. The big concern in the telco world is how to get billing information that’s proprietary converted to traditional data record formats of the telco world. The other problem that particularly large ILECs have is that the overall system has the attributes of the existing circuit-switched world, and the circuit-switched people really defined the bottom line on ultra-reliable telco-class systems—meaning you always have your dial tone even if you lose your power, your bill is always correct, that audit trails exist, that technical and commercial validation exists. The industry learned what that meant from the telco people. The next-generation world is just beginning to think about it.

The second example is in high-speed data cable. The big drive had been self-provisioning and automatic service activation. Today, even where there are Web self-care systems in use, a customer service representative typically executes the provisioning task manually across multiple systems.

BW: If a company has multiple billing systems, how is AP Engines’ mediation platform incorporated?

Sieg: We have three component types in our software—and our software is object-oriented technology, using CORBA and Java. The three types of elements that we have are bridges, agents and engines. The bridges are our OSS connector. That’s how we link to different OSS systems and databases. We have a bridge design which we develop in different flavors for the popular OSSs, and when necessary our professional services can develop a bridge to a unique OSS system. Multiple bridges can run simultaneously.

Agents are the component used for linking to services, servers and devices. So an agent may run to an element manager provisioning system to determine what hardware needs to be configured at the network level. A specific agent could be involved with putting up mail servers, video services or QoS—these are separate agents.

Engines—the core of this—sit on our mediation fabric. Business rules can be popped in so that a company could set up the sequence of transactions or correlating events so that the agents and the bridges can work in concert. A company can run agents, bridges and engines on one machine and can explode the picture geographically and distribute agents, for example, for collection on the network topology near the devices they are collecting from. But this can be used over many different machines, allowing like agents to be replicated to cover an enormous base of customers. A company can have unlike agents side by side, providing different support service interfaces. The engines keep everything in lock sync and give the instructions to the bridges. The agents are doing the data enrichment to what ends up being some very enormous systems already.

BW: You referred to AP Engines’ “n-way” mediation at the “Under the Radar” session. Could you explain what you mean by that and why it is so important?

Sieg: This type of mediation refers to sending information in and out of the billing system. This is a new concept to the traditional flat-rate billing that is just now being adopted in customer screens and APIs equipped to handle it. A company needs to be able to move data in and out of the databases. The service provider’s customers are demanding it. They really need to have more control of their systems and the information especially critical to making business decisions. A company must be able to move data between OSS systems with the service ability database completely updated. A customer requesting service will kick off a whole group of systems in all directions, and then, ultimately, the billing system must be able to do correlation between the billable events coming out and the systems.

BW: You said that one of AP Engines’ key differentiators is the product’s revenue assurance capabilities. How does AP Engines address revenue assurance?

Sieg: When we talk about revenue assurance, we talk about the ability to build an audit trail that goes through the entire transaction. If a company loses certain servers that are necessary for video or for mail, it cannot charge the customers. The appropriate performance systems must also kick off for things like service level agreements, as well as to kick off a system warning that allows somebody to go fix the appropriate equipment as fast as possible, or for backup systems to go cut in. There is a strong need for audit trails in real time. You’ve got to do file retention. If upstream from you or downstream from you somebody takes a hit, you’ve got to be able to hold onto the files and to back up the transactions that lead to setting somebody up, so that you don’t get people half-provisioned—meaning they have charges, but they are not getting the service.

BW: What are some of the methods being used to tackle billing for next-generation services?

Sieg: When you work with cable and high-speed networks, companies are using billing systems of two types. One is the traditional flat-rate database billing and customer care system, which has been used in the cable industry for decades to keep track of their customers and their service. It’s largely handled non-real-time, with a file transfer to a service bureau of the billing company whose primary focus is generating a paper bill. The companies that use these systems tend to have lagged behind in technology. They are not development-focused organizations.

The second group includes companies who use systems like Portal that have put lots of hooks and structure in place to support a full suite of new services that are still unanticipated. Next-generation billing systems tend to sit on modern platforms and have modern code structures that allow them to be very extensible across platforms. They are not locked into old hardware and old systems that were developed in the ’80s or, in some cases earlier, and they are bi-directional. They understand that the user is going to want to go from the customer care APIs down to a system below them, as well as come up with collections of information, and they are a little more oriented toward real time.

BW: What capabilities are important in next-generation billing systems?

Sieg: A customer should be able to challenge the bill at a subscriber level, as well as challenge the total flow of the traditional settlement between carriers. Traditional systems don’t really have those capabilities. The next-generation systems are much easier to interface to, but, quite frankly, a company would have a hard time knocking out 100 percent of its existing billing infrastructure. Even the green-field opportunities—the networks that are committed to being clean and new, that have gone with these next-generation billing systems, sooner or later end up acquiring subscriber bases of other networks, of other service providers, through merger and acquisition activity, and they end up in situations where they don’t have a homogenous network. They have heterogeneous billing systems, and the people responsible for individual systems are not really going to risk shutting down their operations for even a few days to switch to one system. It’s very hard to justify. For those next-generation systems, we provide interfaces to the older billing systems and older OSS systems.

In addition, a lot of providers have Web self-care functionality, but they are not really integrated into a process that’s fully automated and that’s fully assured that everything will happen. Instead, there are often people checking, and there are lots of manual processes.

BW: Is the world ready for packet-based billing?

Sieg: The objection to packet-based, byte-based billing is that it is just such an abstract thing. A service is going to be measured on content—games, for example—and it’s going to be accepted in a mix of thresholds and events, not just that the customer used so many gigabytes of transfer this month and will be charged for it. That fights a customer’s ability to audit the bill.