Java-based Billing: Still in Its Infancy

Demands for simplified customer care desktops, Internet-enabled applications and improved methods of access to legacy billing systems have opened the door for Java technology. With all of the hype surrounding Java's strengths, such as platform independence, simplified object coding and portability, it might be easy to overlook Java's weaknesses.

The fact is that Java is basically in its infancy. While its strengths are on the desktop, the billing software community generally agrees that Java is not yet mature enough to provide the kind of reliability billing systems require on the back-end. Billing vendors such as LHS, Amdocs and AMS have, however, integrated some amount of Java into their systems on the front-end and are stress testing Java to determine its ultimate capabilities.

What Can Java Do?

Sun's immediate vision for Java in billing focuses on improving access to legacy systems. "These legacy billing systems aren't going away any time soon, and a lot of them are in the process of being enhanced with new rating engines or new customer care front-ends," says Tricia McWilliams, market development manager with Sun's Java Systems Group. "We see a lot of opportunity for a Java station running emulation software to act as a terminal to access the legacy billing system, yet also provide an environment for the carriers to develop new applications."

Customer self-service. "We picked [Java] for being able to get right to a customer desktop," says senior principle Chris Tatem of AMS. By providing browser access to billing information, services such as online bill analysis and inquiry can be enabled via intranets or the Internet. Providing online access to billing information improves overall customer contact by letting customers help themselves without waiting on hold for a representative. Eventually this sort of customer self-service may open the door to things like online service ordering, possibly enabling carriers to grab more of a customer's spending dollars.

Call center desktop. "We're saying, let's take some of the more traditional kind of customer care representative behavior and see if their next generation software can be enabled through the use of Java," says Tatem. Most care reps today must wrestle with multiple screens and terminal types to access a slew of back-end systems. This mix of environments creates training nightmares and unnecessary expenses, as well as inefficient customer care processes. A simplified, browser-based environment, possibly developed in Java, could potentially alleviate many of these problems.

Code reusability. Here we find an example of how feature overlap can benefit a developer using Java. A CSR and a self-service customer both, for example, might want to see last month's bill, suggests Tatem. "From a development perspective I may reach an economy of scale there by being able to provide that kind of function to two different types of customers," he says.

Because of Java's code reusability and simplified coding characteristics, experts tend to agree that as class libraries and toolkits mature, Java will continue to become more attractive to developers looking to provide feature-rich data access functions. "When [Java] is robust and it's proven itself, I think it's going to be able to provide that front-end piece to leverage back to the legacy systems a lot more effectively than any other tool that's out there...that's what everyone is asking for and no one can do that for anyone today," says Stuart Palace, vice president of research and development for Saville Systems.

Hardware independence. Amdocs has integrated Java into its Directories line of products "in those cases where a cross-platform client was required," says Sami Gajst, vice president of research and development for Amdocs. "Java is currently used in [customer care and billing] systems for building Internet-enabled applications like bill inquiry, bill analyzer, etc. [We've also] developed a set of server side Java Servlets that perform as an application proxy to overcome security issues."

What About Security?

Whether providing CSRs with access to billing data or Internet-enabling customer self-service applications, security is a major issue that must be addressed. One of Sun's selling points is Java's built-in security measures.

According to Will Bob, president of LHS Communications, the wireless billing provider modified its BSCS customer care and billing system with Java to provide secure, intranet-based access to billing information. Also, because the Internet is not a secure environment, LHS has brought in VeriSign to provide digital authentication and encryption services.

"There's security at many levels in Java; there's security at the language level, where as the code is interpreted it does virus checking," says McWilliams. "[There are also] firewalls and key encryption. The most strict model is the sandbox model where an application cannot in fact even write out of its own code space. So it can't harm anything on the system. Digital signatures even go further [so that] when you go out and access something your fingerprint is left there. There's a lot of traceability in terms of how you access and if you access."

One of the positives about Java as a young technology is that it is designed to address contemporary security concerns while building on the successes and failures of its C and C++ parents.

What Java Can't Do-Yet?

The fact is that Java is extremely new, and the experts, including Sun's McWilliams, all seem to agree that it's not yet ready to handle anything mission-critical, particularly on the server side. McWilliams says, "If you think about it, particularly in the billing area where performance is so critical and so data-intensive and the transaction throughput and the number of transactions is very high, certainly [vendors and carriers] have got to be cautious in how they move and embrace new technologies. They can't give up performance, they can't give up reliability, they can'' give up being able to maintain and manage large amounts of data." The key word here, however, is yet. Many developers are optimistic that Java will mature and eventually be robust enough to provide the kind of stability billing systems demand.

Here's what three experts had to say about Java's current limitations and its impact on billing systems over the next five years.

Chris Tatem, Senior Principle, AMS. "We are concerned with reliability, scalability and throughput and performance issues at this point. For all practical purposes [Java is] brand new, so we expect it will mature. If the development environment and the turnaround in fact work and it's quick-and it's not a silver bullet, that's for sure-but if it makes things quicker, faster and better to develop in, then I would expect that the technology would mature enough to handle larger volumes.

"I think [Java's impact] will start out as being small, mainly because it will be limited to the front-end. ...But I don't think within the next five years it's necessarily going to replace all the billing engines. There's too much else going on in the world for the telcos to focus just on technology."

Will Bob, President, LHS. "I don't see Java being used in mission-critical applications. Carriers want stability, they want applications run on industrial grade products, like Unix. Large companies are not going to force billing vendors to a one technology mindset. One of the standards for front-end applications will be Java, because a lot of the other products that you tend to integrate with are Java-enabled."

Sami Gajst, Vice President- R&D, Amdocs. "Java would appear to have considerable potential for enhancing applications in the customer care and billing area. Amdocs is currently moving forward with its R&D work on Java-based applications, examining areas in which Java technology can be used to enhance our systems. [We] believe that Java's impact on billing applications depends on acceptance of Java as a general purpose platform for data processing."

All three Sun partners, LHS, AMS and Amdocs, are currently testing and stressing Java in the lab to see what it can and cannot do.

Is Java Really Standard?

There appears to be a trend emerging, more of a tug-of-war actually, that suggests that standards, while perhaps the best choice from a technology perspective, are not always best from a sales/business perspective. There are always concerns over product differentiation issues, the argument being that if everyone goes standard, suppliers can't compete on anything but price, and "that doesn't work," says Tatem. Both Tatem and Palace express concerns that Java, though introduced as an open technology, may go the way of many of its predecessors and become indefinite; standard to some extent, but with enough proprietary versions to take away interoperability, reusability and portability.

Evolution of Java. This is Tatem's biggest concern. "It started out with Sun saying, 'here's a standard Java spec'," he says. "And then they've since upgraded it a number of times. To the extent that people stay standard, it will meet its goal. To the extent people start taking add-ons and blurring the edges of it, then you start getting into proprietary solutions and you lose a lot of major features." Tatem notes that while there are already Java class-libraries available for developers to reuse, there is a danger that they will eventually become non-standard, forcing developers to play a "mix and match game." Sun has said from the beginning that as long as developers stick to the defined specs, all Java-based systems should interoperate. Tatem worries, however, that "we'll invest in something or create something ourselves that isn't per standard and then have lost the big features."

Which version? "I think [Java's] going to become robust, I think there's absolutely a future for it," says Palace. "We just have to be very cognizant of the fact that it's critical that an underlying standard become recognized and it builds from that, as opposed to each vendor trying to get the market edge in having all these multiple vendors playing the game of 'mine's better than yours' and that's starting to happen already." Palace offers CORBA as an example of a standard that has gone astray, noting that Microsoft, among others, has its own version with unique extensions that can limit interoperability with non-Microsoft, Corba-based systems. He notes that the industry must keep an eye on Java, and never assume it is an infallible technology. "There's a big expectation out there that if you pick Java everything will work together. If you're picking Java, that's fine. But make sure that you're going down the path where you understand the complexities related to Java before you make that decision, and the potential that vendors are going to start off-shooting their own versions."

The Bottom Line

So what's the verdict? Will Java make the cut? Of course no one knows for sure, although as LHS' Bob says, "Sun has deep pockets-they're going to make it work." Certainly, with Sun's industry influence and the already widespread acceptance of Java, it seems likely that Java is here to stay in some form, at least on the customer and customer care desk-tops. As for the billing developer's immediate needs, it's clear that today Java is not mature enough a programming language for any serious billing system bets to ride on.

Watching and Waiting

Saville Systems is one major billing vendor that has yet to commit fully to Java, but has dedicated significant resources to examine the technology. While other companies have already developed new Java-based front-ends and integrated them into their existing systems, Saville remains cautious. Here's what Stuart Palace had to say:
Why wait? "A lot of times we see technical decisions based on new wave or knee-jerk reactions. Whatever the buzz word is of the era, people tend to think that that's how they have to go in order to be successful... As opposed to picking technologies we pick functionality and requirements that we think are appropriate for our customers and what they told us they need. We have people here focused on emerging technologies and we have spent some time looking at the Java programming language... It's certainly good, I think, for a smaller environment currently. I'm not saying it's not going to [mature], but... the programming language is kind of the heart. You still need the entire infrastructure to be able to support a programmer with tools and abilities for debugging, integration with the database... and reliability is a key factor in that. We're not jumping the gun at this point in time... I want to be able to build whatever it takes functionally through generations as opposed to development. That's why I strongly push the [fourth generation] tools as a way of getting there. We're looking at the vendors that can provide us with the ability to generate code. Is it appropriate to start with something brand new, or why not go with something that's built over the years and can do what you need to get done?"

What interests you the most? "We want to focus on things that are easy to implement. I think that's the key... Also distribution over multiple sites is something we've been focusing on. That's becoming more and more valuable and certainly Java has some strengths in that. Open is obviously one of the biggest concerns with most architectures. Making sure that products are open and platform independent, which Java is very strong in... The telecoms are moving towards building intranets within an organization and the key is usability with respect to that. Having a common desktop for all of the products and having a common look and feel and functionally performing the same regardless of the application they're in."

What makes Java attractive to developers? "There's two kinds of tracks here. You've got the individuals that really have that very strong C background. They developed their product set using C, C++, they migrated from C to C++, and they've got that huge amount of investment and knowledge. It's an obvious progression to move to Java because... Java has taken away a lot of the complexity that C and C++ have. Everyone knows that memory management in C is very dangerous, and a lot of that has been removed. I see that there's a lot of improvements in that track. To me, C is a 2 1/2 GL. I want to see programming languages move in the direction that the experts have said it would, and that is let's make it simpler, easy to use, have people focus on business, and have the vendors of programming languages worry about technology.

Why is a mature toolkit so important? "We've come from that kind of path where we've moved from 3GLs to 4GLs and in that what we're trying to do is bridge new technologies from a 4GL direction as opposed to bridging from C to a programming language like Java. Code generators play a big part in that you learn about the tool that generates code as opposed to needing to know the code."

In the meantime, Saville is covering its bets by using more mature Oracle Web-server technology which will allow them to migrate to Java relatively easily if needed. Palace notes that Oracle is moving toward Java code generation, and says if Java proves to be right for Saville, it will pursue the technology. As was mentioned earlier, however, Palace does believe that Java will eventually prove to be the best tool for single-point access to back-office systems.