Empire District Electric Co.
The company: Empire District Electric Co., based in Joplin, Mo., is a mid-size utility with 140,000 customers.
The problem: Empire needed to replace a 20-year-old, non-Y2K-compliant customer information and billing system to be a competitor in today's deregulated utility industry, but it couldn't afford the high price tag of off-the-shelf products.
The solution: Using Java technology, the company built its own state-of-the-art, distributed component-based customer information and billing system, called Centurion.
n the electric utility industry, customer information and billing is the
bread-and-butter system for companies of all sizes. Not only do these systems house a myriad of information on the customer--they track service, record customer relationship history, orders, etc.--but they also act as a marketing tool for retaining and attracting customers.
Industry deregulation makes having a robust and flexible customer information and billing system a prerequisite to being a nimble competitor. However, these systems are big and complex, as well as costly--companies commonly spend upward of $50 million to build them. That leaves many industry players out in the cold, strapped with older systems in need of replacement.
Faced with just such a predicament, Empire District Electric Co., a mid-size utility, decided to get creative. The Joplin, Mo.-based company has 140,000 customers in a 10,000-square-mile service area covering parts of Southwest Missouri, Southwest Kansas, Northwest Arkansas, and Northeast Oklahoma. It had a dire need to replace a 20-year-old mainframe-based customer information and billing system that was not Y2K-compliant. But it didn't have the necessary cash.
"In the past, utilities often built their own systems, but the recent trend has been toward packaged solutions," says Ron Yust, Empire's director of information services. "However, if you can't spend millions of dollars, the [packaged software] vendors won't even talk to you."
Nevertheless, Empire still needed a customer information and billing system. Armed only with this need, the company in 1996 set out to build its own system. From the ground up, and for just about beans, the utility succeeded in creating approximately 2,000 reusable software components in the meantime.
Like companies in all industries scrambling to develop new systems that will give them better footing in today's business environment, Empire needed an application development architecture that was fast, reliable, and cost effective. It first began its pilot project using SmallTalk. Ultimately, though, Empire found SmallTalk limited in functionality. After reviewing Java, Yust says the company found what it needed. "Java proved to be a more innovative design that enabled us more development flexibility," he says. Yust also notes that SmallTalk was going away, and Java was the future.
Empire settled on Java and Enterprise JavaBeans (EJB). "We weren't interested in Microsoft's COM, DCOM, and COM+ because we wanted a less proprietary solution, and Java has interconnections with CORBA [from Object Management Group Inc. (OMG)] so it leaves the door open to using CORBA in the future," says Yust. He notes that Java offered a big umbrella with all the pieces to get the job done. In particular, he liked the benefits Java offered developers, such as auto garbage collection, which releases memory when it's not needed, and a built in GUI component to build screens on the client.
Called Centurion, Empire's customer information and billing system is based upon the Java 2 Standard Edition (J2SE) platform, Java Database Connectivity (JDBC) and Java Servlets application programming interfaces (APIs), EJB software components architecture, JavaHelp, eXtensible Markup Language (XML), and the SQL query language. Centurion went live in November 1999.
When paths converge
The company: Managemark Inc. of Sunnyvale, Calif., produces online, business-to-business Web applications for corporations and next-generation e-business portals.
The problem: The company's ExpenseAble application, for expense management, developed in Microsoft's Active Server Pages scripting language, ran into scalability and performance problems.
The solution: Managemark adopted an object-oriented approach and chose the Java 2 Edition platform, which met the firm's criteria for scalability, manageability, and reliability.
For years now, the software development industry has sung the praises of component-based software development. However, only in the past 12 to 18 months are enterprises seeing past the hype of this market to the reality of it.
Time-to-market is the key driver steering a growing number of information technology departments toward component-based software development. The Internet, in particular, has given a new imperative to rapid application development.
While building applications from scratch may afford companies tailored, customized solutions, those applications carry a big price tag and long development cycles that few companies can afford-not to mention the programmer shortages plaguing the entire industry. Packaged solutions, on the other hand, often do not satisfy a firm's need for differentiation; and if they do, they do so only after costly, often time-consuming customizations.
For these reasons, the time is ripe for component-based software development. "The market has gone beyond the 'testing-the-waters stage' to 'completing major projects,'" says Karen Boucher, executive vice president at The Standish Group International Inc., a market research company based in West Yarmouth, Mass.
In a recently completed report called "Objects of Desire," Standish studied 60 enterprises that have successfully built applications using object-oriented development. For those companies, component-based development was not a choice, but a necessity, says Boucher. "IS departments are under tremendous pressure to get applications out fast," she says, adding that component-based development is now a means to an end. Unlike 1998, when the firm conducted similar research, Boucher says the component market was considered bleeding edge and finding 60 companies doing component-based development work was a struggle. Not so this time around.
Empire's Yust reports that it took his IT staff two years to roll out Centurion at a cost of about half a million dollars, all labor related. That was a considerable savings--probably about a million--which represents the price the company would have paid to purchase a packaged system, according to Yust.
The timeframe was on target with industry benchmarks, Yust says, which indicated that it also would have taken two years to implement a customer-information and billing system, regardless of whether his organization bought or built it. So, in addition to a substantial cost savings, Empire reaped another reward of component-based development: a more flexible and adaptable system that allows it to make changes quickly.
Java vs. the competition
Java is not the only software development technology to provide a component-based development architecture. Both Microsoft Corp's COM/DCOM/COM+ and OMG's CORBA specifications provide component frameworks as well. But for some companies, such as Managemark Inc., of Sunnyvale, Calif., the decision to migrate to a Java software component framework from Microsoft's Active Server Pages architecture was based on the fact that Microsoft's technology cannot scale to meet the needs of a growing business.
Managemark produces business-to-business (B2B) Web applications for corporations and next-generation e-business portals. Its ExpenseAble suite of services is offered as an application service provider (ASP) service, and includes online, desktop, and mobile applications that process expense reports and streamline administrative duties. The solution targets small to mid-size companies as an alternative answer to traditional expense report management.
The company initially chose Active Server Pages for development because it was looking for a "quick and dirty" way to get its development effort going. Managemark used Active Server Pages to write the user interfaces and all of the business logic. But it decided to move its ExpenseAble suite when Microsoft's scripting language began to falter.
With hundreds of customers signed up for its service, Managemark realized its application wasn't properly scalable and that it was difficult to maintain. Worst of all, customer complaints about slow response times were pouring in. So in January 2000, the company shifted to Java and began to port its application in stages.
"We decided to go with an object-oriented approach for time-to-market and cost reasons. We went with Java because it has a high degree of industry support," says Satish Kamatkar, a Managemark engineering manager.
Since January, Managemark has completed three phases of component development using the JavaServer Pages (JSP) 1.0 API, the J2SE and Java 2 Enterprise Edition (J2EE) platforms, EJB, and the JDBC and Java Media Framework 1.2 APIs. Managemark developers have created about 20 reusable software components to date.
Java in the real world
To minimize risk, the first phase of component development using Java involved only a portion of Managemark's ExpenseAble application. "We picked parts of the application that affected some but not all of our customers," says Kamatkar.
The first phase of development included building a new product feature, called the corporate cart, which Managemark prototyped and deployed on a beta site before making it available to all customers. The new feature took about three months to build using Java Servlets and JDBC, according to Kamatkar.
The second phase involved porting a feature that enables users to submit expense reports. This database-intensive feature previously had been plagued with performance problems and was the cause of many customer complaints.