Thursday, June 13, 2024

Java component development heats up

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

In 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

Managemark Inc.

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.

Although the volume of work required during the second phase exceeded that of the first project, it, too, took only three months to complete. “By this time we had the technical skills and know how, and we had already built the infrastructure,” says Kamatkar.

When all was said and done, Kamatkar reports application response times for this feature, which was well above the industry standard of eight to 10 seconds, was more than cut in half.

Recently, Managemark began working with Wireless Knowledge Inc., in San Diego, Calif., a joint venture of Microsoft and Qualcomm Inc. It delivers wireless Internet solutions, including software wireless data technology and services, to port its ExpenseAble application to a wireless device.

Development effort aside, Managemark believes it has also saved at least $100,000 in application maintenance costs alone since using Java. Looking at the total cost of ownership, Kamatkar estimates that his company is saving between 30% and 40% compared to the old Microsoft-based system.

The case for reuse

For some companies, component-based development is not a choice, it’s a necessity.

Of all the promised benefits of component-based development, perhaps the most hyped has been reusability. The promise is that a building-block approach to application development will provide developers with a cheaper, faster, and better way of getting critical applications up and running. According to, an online marketplace where users can purchase packaged software components, organizations that focus their component-based software development efforts around the notion of reuse realize these benefits throughout the software lifecycle.

At this early stage in the market for component-based software development, there aren’t many companies designing software with reuse in mind. “The reality of the component-based software market is that it’s rare to find a company not doing this type of development; however, if there’s still any hype in this market, it’s about reuse,” says Standish Group’s Boucher. “It’s happening to a degree, but not to the degree it should be.”

One place where software component reuse has been key to the business’ success is New York-based Firstborn Multimedia Corp., a creator of interactive Web presentations. A $3 million company with four programmers, Firstborn began relying on reusable components in January 2000. “We’re dealing with clients that have compressed development cycles,” says Robert Forras, vice president of technology at Firstborn, noting that many client projects include features and functionality that are “standard stuff.”

For Firstborn, reuse enables the company to leverage the same code across its client base, differentiating it for each customer by mapping in new fields. The company’s technology of choice is EJB. “The beauty of reuse is that the code has already been battle tested and doesn’t need to be retested, saving time and money,” says Forras.

The company has turned to several vendors for some reusable Java components, including BEA Systems Inc., in San Jose, Calif. According to Forras, Firstborn’s developers use more than half a dozen components that come as part of BEA’s WebLogic Commerce Server. The product contains a full suite of Java-based components for e-commerce, including an online catalog, shopping cart, inventory management, order entry, order management, and shipping components. Forras says he buys components from other vendors as well, but can’t discuss them at this time.

Adopting a reuse strategy for application development has put Firstborn 50% ahead of the game in terms of how much business it has been able to take on, he adds. The Standish Group’s Boucher notes that the ROI of reuse jumps to about 10% for second and third projects and to 60% savings by the fifth and sixth projects.

Uncharted territory

Because components are not quite a mainstream technology yet, companies doing component-based software development often feel like trailblazers. Their biggest complaints are a lack of industry standards and a lack of components.

“Instead of being touted as ‘write once, run anywhere,’ the motto for reusable components should be ‘write once, test everywhere,'” says Firstborn’s Forras. Forras finds the exceptions to the rule–or those companies that don’t adhere to standards–can make your life miserable.

While there has been a lot of COM development on the front end, for example, COM+ on the back end is still progressing. “The back-end server technology for Microsoft relies on multiple products, and they’re in different stages of development,” says Boucher. On the other side of the coin is Sun’s EJB standard, which is still evolving.

Regarding the lack of components, Forras says, “I often can’t find the specialized components I need in the EJB market, but that’s largely because it’s a market just getting off the ground.” However, he expects the pool of available components to grow over time.

That’s not to say that software components aren’t available, because they are. and are two marketplaces selling components from third-party vendors. Andrew King, vice president of market development at, an online components marketplace, says his company offers more than 3,000 components in its catalog. The bulk of the products are COM components (2,700) and the rest are Java components. offers JavaBeans, Enterprise JavaBeans, and COM components, with the lion’s share of approximately 600 being Java components, according to company president and CEO Charles Stack.

While both companies offer products and services and serve as industry evangelists for component-based development, other enterprises have mixed feelings about purchasing third-party components. “What the industry is dealing with at this point is a comfort level,” says Tracy Corbo, senior analyst with the Hurwitz Group, a consulting company based in Framingham, Mass.

For example, says Corbo, before buying components online, users want to know such things as: Who provides a guarantee of service? Is there a return policy? Is there source code? What about pricing models? And are the components downloadable, maintainable?

It’s an opportunity

Most users remain skeptical of third-party components. “I kept my eye out for third-party components, but I didn’t feel what I saw bought me enough to warrant the risk,” says Empire’s Yust. For example, he says he wonders about long-term vendor stability and the availability of source code.

Firstborn’s Forras, on the other hand, says he is always on the lookout for third-party components. “Being able to find the components is crucial to being able to deliver solutions to our customers on time,” he says.

That’s not to say that Forras has always been a satisfied customer buying from the third-party market. “We’ve looked in the marketplaces, but they’re not robust enough in the number of solutions available. However, we’ll look again as our needs grow. We have to,” he says.

According to the companies in Boucher’s research, most will buy components rather than build them whenever they can. Today, however, they’re doing more development work because the component suites aren’t out there.

Despite the bumps in the road, companies on the forefront of component-based development agree that there are more benefits than disadvantages. Besides faster time to market and lower costs, Empire District Electric reports that other utility companies are expressing interest in Centurion.

Says Yust: “We started our project as an act of desperation, and we’re seeing it turn into an opportunity to generate revenue.” //

Lynn Terry Haber reports on information technology and business from Norwell, Mass.

Subscribe to Data Insider

Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

Similar articles

Get the Free Newsletter!

Subscribe to Data Insider for top news, trends & analysis

Latest Articles