An Interview with Paul Atkinson, CEO, Solect Technology Group

Solect Technology Group is one of the first of a new breed of billing vendors focused on emerging internet protocol-based (IP-based) public network carriers. The company’s flagship product, IAF/3, is a component-based, billing, customer care and service management system. IAF/3’s rating engine is based on Bellcore’s Rater system, a rating engine originally designed for interactive television offerings, which Solect has modified to support any IP-based service. The system runs on HP and Sun Unix platforms and supports Windows NT clients. Solect boasts a number of major partners from both the traditional data and voice worlds, including Bellcore, Alcatel, Cisco Systems, Hewlett Packard, Microsoft, Netscape, Nokia, Oracle, Sun Microsystems and Xacct, an IP billing mediation system developer. The company also lists Ameritech, AT&T Canada, and Sprint among its 50 customers worldwide. Solect is a privately held company, based in Toronto, Ontario, Canada, with Cisco Systems and Technology Crossover Ventures among its investors.

Though IP voice technology appears promising, few seem to understand how the transition to a packet world will take place. There are those who still say it won’t happen, or at least not for many years. What will drive this transition, and how do you see it unfolding?

If you look at parallels in the computing industry, three years ago you could talk to a telecom manager at a bank, and he would look you in the eye and say he was going APPN and would never go IP, because of all the same arguments [against IP versus circuit technology]: the hierarchical nature, the manageability, the robustness, all of those things. Name me a bank now that’s not moving to IP.

If you ask, are things going to happen in the next year? I don’t think so. I think they’re going to happen in two to three years, and it’s going to be driven by people like Jim Crowe [CEO, Level 3 Communications] who totally redefine what it costs to send a voice call. Then it’s going to move beyond price. I read an interesting article on a study that abstracted out all the regulation. It said if regulatory costs were equal between a circuit-switched and a packet network, the IP network is still significantly less expensive. But I’m not seeing it as a cost savings thing. I think ultimately you’ll see (and it will be the Qwests and Level 3s initially, and the Covads) companies come out with brand new types of applications that utilize the fact that your voice is going over IP. So it’s going to be like Level 3 having a call center application that is a thousand times better than anything anyone else offers because it integrates instantly into your web site and price list. That’s going to blow people away. It’ll be a defining moment in this transition, and it’s going to happen in the next year. That’s how I think it’s going to happen.

Can you give a more specific example?

Let’s say [an on-line book seller] and [an IP carrier] do some partnership. [The book seller] has become the second most important commerce portal in the world by selling books and allowing people to write reviews of books on line-taking advantage of interactivity to sell a product. Then they buy a search engine for shopping on-line, and you know what they’re trying to be: They’re a single source for commerce. You hook them up with an IP call center that’s transparent, and look out. [A major Internet content provider] views [the book seller] as it’s biggest competitor, because it’s got 12 million credit card numbers in its database and [the book seller has] 6 million. That’s all they look at. So one of those two guys is going to say “hey we better integrate voice and commerce transparently,” and the abstraction factor is going to be IP. Then you’ll see the RBOCs and the CLECs falling in line.

Do you think demand for IP services will make the technology out pace standards such as the SS7-to-IP interconnection standards being developed now?

The analogy I see is, in Toronto they have these dial arounds that allow flat-rate long distance throughout the entire province of Ontario. These companies set up a circuit through a bunch of LATAs in the background. They make it all local calls. You dial a code on your PBX, and it sets that up for you. That was something that we had at Solect for years, because it was $20 a month for all the long distance in the province, and it was all done in the background. Now the monopoly telco has reduced its price to be equal, but it took three years. So I think you’ll see a lot of stitching in the background. Before there’s an SS7-IP transparent gateway, you’ll see things from a lot of companies out there that do SS7-type routing of IP calls. It’s not rocket science.

Why use CORBA, NT, and Java when these technologies are relatively new to telecom and perhaps unproven?

In our version of IAF/3, we are using CORBA quite extensively, but it’s definitely not a slam dunk in terms of telcos accepting it. We also use message-oriented middleware, advanced queues by Oracle, and we’re trying to keep our options open. As we architect our NT-based solution we’re looking seriously at COM as a native thing instead of using a COM-to-CORBA gateway, so I don’t think we’re religious about CORBA. We just think that components in general are a good way to go.

We think the whole industry is shifting fundamentally. I read the publisher’s opinion in your last month’s edition; I disagree with it. He said take your time because IP is a lot of hype and circuit switched still has a lot of value. I think his is the general view in the industry and is probably the prevailing view because a lot of people have been burnt before. We look at history and say look what happened to SNA and Decnet and OSI, just in the pure data world. They got overwhelmed by TCP/IP even though they were much more manageable and hierarchical and controllable. We think the same thing is going to happen [for voice] largely because of two things. One, the economics of being able to deliver in an open world have been proven to overwhelm proprietary worlds. So new applications are going to come out, such as the examples David Isenberg talks about with Stupid Networks. But I think even more important is the whole interactivity side of it. Your voice application is going to interact with your e-commerce application that’s going to fire off to an SMS (short messaging service) application over a global packet radio system (GPRS) or some mobile system, and it’s all going to interact with all of the data abstracted at layer 3. So IP becomes prevalent and then people can start adding value based on applications.

What we will see in the future are services based carriers as opposed to connection based carriers. We think it’s imperative that the services are going to be driven in these technologies. There are going to be IP-based services, component-based services, Java-based services, HTML-based services; so we feel that building a Windows-based application in Power Builder and using a client server architecture isn’t going to be appropriate to these new types of applications. That’s why we built our infrastructure software the same way we’re seeing services being built. It’s interesting because Xacct is very similar; our architectures are very similar. With our service management, we can dovetail perfectly into their mediation--and it’s a beautiful fit for one of these new services-based telcos. We’re talking to a lot of the new fiber-based CLECs, and some of them are saying emphatically that it has to be component based, it has to be CORBA or COM, because they don’t want to go down the track of a hierarchical application. Customer care and billing (CCB) has been far behind. We’re starting to see client server and relational database CCB applications, and that paradigm of computing is almost at the end of its life.

Do you have any concerns with these technologies handling telco volumes? How well does your system scale?

With our existing application, which used all Internet technologies, but earlier generation ones like HTML, Oracle and queues, we were able to scale up to 2.5 million subscribers relatively easily on a single ES 6000 from Sun. That was a benchmark we did in conjunction with Sun. So the cost per subscriber was negligible. As an example, we were able to do about 50 million rated CDRs a day. In our new application, because it’s component based, we can have multiple rating engines. So we’ve tested the rating engine, and we can get hundreds of millions of CDRs a day. We can have multiple billing engines and we can have service distributed, so we’re working very closely with the people at Oracle and Iona (that’s whose ORB we use) to make sure we can reach the scalability numbers we’re targeting. Right now, it’s a million subscribers, and very shortly, early in 1999, it’s 10 million.

With many new networks being built and peering agreements on the rise, are you planning to support interconnect or settlement billing, or are you going to stay with the end user?

I think we have to look at both settlements and end-user billing. Right now we are looking at the end-user part [which is most relevant given the current market]. In the day of peering agreements, a lot of things are going to fall off, particularly when the circuit rate tables start blowing up. So there’s going to be a lot of interconnection, very analogous to the circuit world. What we’ve done in our system, basically, we have a rules-based rating engine. We can put a terminating IP address into a CDR, and that terminating IP address will either kick off a rule or kick off an exception. So, if it’s somebody that we know about on an interconnect agreement, it could price it differently; or it might kick it out as an exception [and ask for a rate to be put in]. Architecturally we’ve accounted for that, but really you have to get [the termination point] from the routers through NetFlow or Xacct or whatever, and then determine where it [the usage data] goes in the rating engine.

Will you also look at things such as having a billing system make intelligent decisions for least-cost routing, where the billing system talks to a centralized server that runs a commodity-type market for transport? You’re stealing one of my vision statements, because I think that’s going to happen at some point in time. You’re starting to see that. At [an ISP trade show] there was a guy slipping brochures that said he’s a bandwidth broker into everyone’s hotel room. It’s kind of interesting, and it reminds me of things that happened in the plain old IP world three years ago, with guys starting up with great ideas. For example, someone gets paid a commission by MCI for selling bandwidth. He has a web site, and he holds a little auction for bandwidth. It’s totally possible that through the billing system you can, in real time, go to the network and do the least-cost routing, go to the auction, pick the circuit or the backbone provider and go out that way. Right now that’s way out there, but if you look at a billing system that’s entirely component- or software-based, then feeding those types of things in are very practical.

Perhaps in ten years?

I don’t think it’s ten years. I bet in three years you’ll have things doing that. That’s what I mean by way out there.

What’s your relationship with Bellcore, which helped develop your billing engine?

We met up with Bellcore a couple of years ago. They had a product, called Rater, that was originally designed for interactive TV. We took our expertise in the IP space and Bellcore’s expertise in carrier-class scalability and reliability and modified Rater to come up with IAF/Rater, a distributed, real time, rules-based rating engine based on Bellcore’s technology. Essentially, we took the scalability and reliability that Bellcore ensures, and then we built something called RML, which is a rules-based language on top of Rater that enables it to handle any type of IP-based service. So really it’s a great fit in terms of our capitalizing on Bellcore’s expertise in the telephony world and our five-plus years’ experience working with telcos to provide IP services.

Who do you think will be the major players in this billing market?

You’ll get us, and Portal coming out of the traditional ISP space. Kenan, of the convergent billers, is the one investing most heavily right now in IP, although if you look at that compared to what they do on the circuit side, they have twenty people working on their IP space. One or two [of the traditional telco billers] will probably get really serious about the IP space. Then I would guess you’ll see Lucent, potentially; maybe Nortel, though I doubt it; and Cisco, which we’re partnered with a little bit, but I don’t think they’re going to do too much. So probably Lucent will come out with something that competes in this space. Lucent’s billing strength is really in mediation.

What about the mediation space?

Xacct has an interesting position in the marketplace right now, because they’re the first guys that are looking at IP mediation very seriously. So I think they’re going to have the same successes we’re having against the legacy people, because their expertise level will be so far ahead of the legacy guys. Cisco has some very interesting stuff coming out, with NetFlow and UCP, and I could see them doing some mediation as well. I think the pure players ultimately are going to be the ones that people go to, because an Xacct is going to understand the difference between talking to a RADIUS server and talking to a 5E.

Does Solect offer data collection?

We have an architecture called the PDC architecture. PDC stands for provisioning data collector. It’s a bidirectional architecture that can go out and talk to services, elements or mediation platforms. The rub is that, in most cases, we prefer to work with a system that is mediated to a lot of things, so we don’t have to do as much work. But, there are a lot of things out there that we’ll have to go through ourselves, things such as a messaging server or NetFlow. A lot of systems that we’re going to have to talk to may not be in the scope of a mediation platform. We’ve given services vendors a software developer kit so they can write an interface to enable their software server to work with our billing engine out of the box. This is probably not to the level of complexity that a mediation platform would offer, but it’s a way to start. Also, because of the object technology, once that integrated service comes onto the network, it automatically registers itself with the billing system. So if a provider launches a new service, writes a PDC, the product manager instantly sees that service out there and can start building products from that service all through a GUI.

As a telco billing system identifies subscribers with phone numbers, how does your system work? We match a subscriber to a user ID or some identifier that’s in a directory. If you look at Cisco and Microsoft, they’re all going down and saying that the center of the universe is going to be DNS. We tend to agree that the center of the universe is going to be some sort of a directory that has an attribute for you, but that attribute might change depending on a bunch of different items. So, if you’re calling in on an ISDN line from work, you might have a different profile than if you’re calling in on a wireless line from home. You should be tightly integrated to a directory service that’s probably going to be some derivative of LDAP, most likely a DNS-based system sometime in the future.

Who will provide that directory service?

Standards are evolving out there. The telcos, I think, are going to run directories, but I think the technology providers--Microsoft, Cisco, Netscape, Oracle, Sun, Novell--are all in the directory space in terms of writing the technology. Hopefully, you'll end up seeing some level of consistency between the product offerings so that the telcos, the CLECs, the wireless vendors all have directories that can communicate. In the directory space, you’re now seeing a lot more cooperation between these companies.

Any final comments on Solect’s direction and strategy?

One of the things that we say is that we’re not interested in convergence. We’re not interested in putting your wireless on the same bill as your Internet. We’re interested in conversion. We’re interested in when wireless becomes wireless IP. We’re working on those things. We have partnerships with Nokia: Right now we’re working on the global packet radio system, and they’re using our billing system for that. We think we’ll have a competitive advantage because we’re gearing up for the day when IP overwhelms the circuit world.