The High End of Service Delivery

Dirk Epperson is co-founder of Kabira, a software switching and services company birthed in 1996 primarily with expatriates of Sybase. But Kabira is not his first venture. Mixing a fondness for theater with a knack for engineering, Epperson got a master's degree from Yale University in theatrical engineering and soon found himself designing and building lighting control, sound control and acoustic systems for the stage.

His first company, Performance Arts Technology, was Epperson's introduction to the importance of real-time performance engineering. The company even designed a real-time box office system, which — after several acquisitive changes — is now known as tickets.com.

“It's surprising how much of that is relevant today, especially the real-time processes,” Epperson said.

It is the quest for solutions that fit large-scale real-time processing requirements that led to the founding of Kabira. While at Sybase, Epperson and Kabira co-founder Daniel Sifter, along with a quintet of other technologists, saw one too many examples of how difficult it was to build truly high-performance applications.

“The problem was getting the data and transactions and logic and connectivity in a single place,” Epperson said.

E-commerce had not yet become the rage back in 1996, but Epperson and company, although not yet a company, began to see scalability issues within industries, particularly in finance and telecom, which were dabbling in Web-based access and transactions.

Within a corporate enterprise, it was easy to determine the number of transactions a system would have to support based on the number of employees.

“But once you are on the Internet, you are not bound by that,” Epperson said. “You are bound by the size of the world population that happens to be awake at the moment.”

So Kabira, once called ObjectSwitch — a name that didn't survive the drive to go public back in 2000 because it was too technical — began to develop very scalable systems for switching and service delivery. The company never did go public, but it created what it calls an infrastructure switch, a transaction switch and a service delivery platform (SDP) and quickly rang up several customers. Still, the market, especially for SDPs, didn't quite mature as fast as expected.

“We hit that flat spot,” Epperson said. “Before the bubble burst, our client base was evenly split between the U.S. and European market. But in the U.S., 18 of those customers no longer exist. They went bankrupt.”

Things are picking up now, he said — not skyrocketing, but picking up.

The infrastructure switch can be considered the company's flagship product because it supports customers' application development as well as acts as the platform for developing all of its own applications. However, the SDP is aimed at helping carriers generate revenue from all that development, and it addresses a space that analysts say has a bright future.

In a word, Epperson said the marked difference in Kabira's SDP is performance.

“There have been a lot of trials with SDP platforms that work fine for twelve trial users, but when you turn the system on for 250,000 or a million subscribers, they don't work,” he said.

If expectations for revenue generation by thousands of new services hold true — and service providers better hope they do — SDPs will have to support millions of subscribers and thousands of applications or services. That's a serious scale requirement.

Much has been said about not really knowing what those thousands of services will be, but Kabira is supporting an interesting example of a new service in the U.K. The service is an example of how operators can cooperate with other vertical markets to create a unique application. Bank customers making a withdrawal using their ATM cards get a message on their cell phones within 5 seconds of the transaction that contains an ATM security camera picture of the person who made the withdrawal.

“That's immediate security feedback,” Epperson said. “It is one of my favorite applications because it is cool, it is live and we support it.”

It is also another example of scalability.

“If you have fifty people signed up for this, you could probably support it on any generic platform. But if you have millions of customers doing this, you better be handling it pretty fast,” Epperson said.

Besides scale, Kabira endeavors to make their SDP environment technology agnostic, acknowledging that most application developers have no clue about the communications infrastructures that support their products — nor should they need to.

Nor, as a matter of fact, do carriers really want application developers monkeying around with network layer protocols.

“Developers can build wowie-zowie Web sites, but they don't understand the complex telecom infrastructure, and carriers really want a firewall between them,” Epperson said.

To provide the scale and performance required by carriers, Kabira writes its core applications in C++ and uses Java and other interface protocols to communicate with various service applications. C++ is 100 times faster than Java, Epperson said, and getting Java to scale into an SDP is impossible.

Kabira also employs a lot of shared memory. The design strategy is to get as much of a single application into stored memory as possible to avoid having to continually access applications across the network.

“The more we can put in shared memory, the more we can reduce the transaction path,” Epperson said.

Although Kabira's SDP is built using C++, programmers do not write the entire system in that language. Kabira uses a UML model-driven architecture to better manage the more than 2 million lines of code required to build high-capacity applications that can handle 5000 to 50,000 transactions per second.

“A single human software architect can get their arms around 20,000 lines of code and a team can build something like that quickly, but to build two million lines of code and get zero fault tolerance every time is virtually impossible,” Epperson said.

The SDP is comprised of the following components: the Open Service Access framework, Open Service Access shared services, provisioning and service activation and convergent mediation for flexible service charging.

While many of its new carrier customers are quiet on the topic of their SDP deployments, Kabira has a good reference implementation with E*TRADE that exhibits it scalability. The online financial services company is using Kabira's infrastructure switch to develop and deliver its next-generation quote system.

Strapped with its own 150,000 lines of code for its application, E*TRADE turned to Kabira to help it streamline its financial services application and expand it into other banking-related services. The unified modeling language used by Kabira helped E*TRADE bring discipline to its own development, said Rikki Kirzner, an analyst with IDC, in a case study report on the implementation.

Kirzner concluded that “Kabira has created a unique, infrastructure platform that helps its customers develop and deliver sophisticated, high-performance, robust services and applications — fast.”

Initial results showed that Kabira's use of distributed cache memory, or shared memory, performed as advertised by reducing the number of times an application had to access the main quote application server. This resulted in a tenfold increase in performance. However, in service-provider deployments that, as said, will likely support hundreds of such applications, having a centralized SDP could present bottleneck problems where millions of subscribers are trying to access a particular service. To protect against this inevitable scenario, Kabira uses a shared services layer based on its infrastructure switch design. Shared services expose a large set of standard application interfaces, including as OSA/Parlay, Parlay-X, OMA, JAIN and SIP.

Kabira supports all standard application program interfaces, but like most vendors, it has its preference on which it would like to see the industry settle. The company is a member of the Parlay Group, a consortium dedicated to the development of open APIs, and so it naturally leans toward Parlay. However, even Parlay itself comes up short of the needs of an SDP provider. Currently there are two competing standards within the Parlay Group: Parlay and Parlay-X.

“Parlay does everything you could possible want to do, but it is too heavyweight,” Epperson said. “Parlay-X is lightweight, but it doesn't have a final security paradigm, and it needs it. So I would like to see Parlay-X with security.

To the winners go the spoils of war, however, and the protocol and standards wars will go to the company that gets the most deployments and drives the market. For the second coming of service delivery platforms, there will be plenty of ushers.

Kabira has some heavy competition in large established companies such as Alcatel, HP and Sun, in new start-ups such as Mobile Cohesion, in partnerships such as that between Aepona and Telcordia Technologies and specialized but growing providers such as LightSurf and LogicaCMG.

Epperson said it will be another year before the U.S. market is ushered down the SDP aisle in a serious way.