E-Biz Building Blocks

Give Tim Hilgenberg some new toys, and like any good IT leader, hell find a way to build a better e-business.

Just recently, Hilgenberg, chief technology officer of applications at Hewitt Associates LLC, has begun toying with the emerging concept of Web services. And already, he said, hes found just enough blocks to begin to build something really useful: an easier, less expensive way to provide the human resources outsourcers corporate customers with a more direct connection to their employees benefits information.

Even before beginning to tinker with Web services, Hewitt, of Lincolnshire, Ill., had already created multiple channels to allow employees of its corporate customers to retrieve account information by calling customer services representatives, using an automated phone system or logging in to Hewitts own Web site.

Hilgenberg is now developing a set of Web services that, by January, will enable many of the companys customers to display, for example, employees 401(k) balances on their own corporate portals without having to go through Hewitts Web site. And what makes Web services so tantalizing to e-business pros like Hilgenberg is that the deployment approach will be a relative breeze in terms of time and money. Indeed, customers will be able to easily access the new services and information regardless of the back-end programming languages and systems they may be using.

Web services, at their base, are built upon a set of still-developing industry standards—namely XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery and Integration). Using those blocks as a foundation, eager builders such as Hilgenberg can create software components that users can easily tap into over the Internet to fulfill business functions such as looking up retirement account balances.

But applications such as Hilgenbergs are just Web services first baby steps. As more Web services are created, the thinking goes, theyll begin to be shared among companies and linked to create more complex applications. One day, for example, a string of Web services could tie together the processing of a credit card, a product inventory check and a determination of available shippers, all at once, seamlessly linking requisite data from the companies responsible for each transaction, regardless of which back-end systems they are running.

The promise of greater integration among systems and business partners—not to mention a marketing push by major vendors such as Microsoft Corp.—has turned Web services into one of the most talked-about technologies of the year.

IT managers like Hilgenberg believe the savings theyll bring in development time and money will result from the fact that Web services can be endlessly shared internally and among business partners without the need to recode for each use. Eventually, proponents believe, a critical mass of companies will create Web services and publish them on public UDDI directories—such as the one formed by Microsoft, Ariba Inc. and IBM (accessible at www.uddi.org)—that can be shared by all.

For now, Web services remain a twinkle in the eye of most enterprises. Forrester Research Inc. projects that it will take until 2005 for Web services to reach full maturity and until 2003 before application vendors widely support them. Thats because issues concerning security and availability remain unresolved, and IT managers are waiting to see whether such rivals as Microsoft, IBM, Hewlett-Packard Co. and Sun Microsystems Inc. will adhere to their promises of supporting the open standards developing around Web services.

Despite the unanswered questions around Web services, enterprises shouldnt ignore the new technologies, analysts warn. This is the year for enterprises to begin investigating how they might use Web services and to begin getting experience with the earliest versions of the key standards. They should start trials internally or with business partners where they can control issues such as security, experts say.

"The reason for starting internally is to get a protected space in which to practice," said Frank Gillett, an analyst at Forrester, in Cambridge, Mass.

The electronic business group at Robertson Stephens Inc. is listening to that advice. It is developing a Web services platform internally so departments can share functionality across the enterprise regardless of the various server and client technologies used within the investment banking company.

"Its the innovation of this disruptive technology thats really going to allow us to do things we havent been able to do," said Dirck Hecking, technical architect for e-commerce at Robertson Stephens, in San Francisco. "One of these things is this cross- platform communication—the ability for a Microsoft .Net to communicate with a Sun Open Network Environment architecture. It really opens up the peer-to-peer world of communication in that any server process can talk to any other server process and any client can talk to any server process."

The need to better integrate vendor platforms was the impetus for Robertson Stephens to consider Web services. The corporate group, for instance, was running Microsofts Internet Information Services server to handle such Web initiatives as the companys internal employee portal. But the e-commerce group used BEA Systems Inc.s WebLogic server and Java to run transactional sites such as a portal for institutional investors called RS Connect.

So, about four months ago, a team composed of staffers from corporate IT and the electronic business group developed the idea of Web services—before realizing the term had already been coined, Hecking said. That led to Robertson Stephens in June deploying Cape Clear Inc.s CapeConnect software as the underpinnings of its Web services initiative. The software allows the company to expose software components such as Enterprise JavaBeans as Web services based on XML and SOAP. It is also used to build multiple Web services into a larger application.

Robertson Stephens plans to put Web services to the test this month by turning functionality already in the RS Connect site into Web services. RS Connect, for instance, already provides aggregated market research from throughout the company, but that aggregation is developed in Java specifically for the WebLogic architecture. By turning it into a Web service, the e-commerce group will be able to share the research aggregation functionality with any other business unit or partner, whether it speaks Java or not. So, for example, the application can be incorporated into sites such as the employee portal, Hecking said.

Hewitt has gone even further as it embraces the newborn Web services technologies. Hewitts Hilgenberg decided in June to use Web services as the foundation for building a platform to help the companys customers plug key benefits information into their internal corporate portals. The company also wanted to exchange more real-time information with third-party providers that offer such services as financial advice so they could directly access accounts and perform transactions.

What Hilgenberg wanted to avoid was spending an endless number of months and dollars custom-coding the connections to work with the wide array of Web platforms among Hewitts 250 corporate customers. Not only would it have been difficult to complete, but it would also have been a drain on development costs and maintenance time.

"We were kind of at a crossroads," Hilgenberg said. "We were faced with, Do we want to go a proprietary route or go along the route of leveraging whats out there today thats open? Thats why we have such an interest in Web services."

Web services allow Hewitt to develop a component—say, to look up 401(k) account balances—once and then share it among all its customers and partners without having to worry about whether one customer is a Java shop or another a Microsoft shop.

To create Web services, developers at Hewitt downloaded the Apache SOAP tool kit to run within the companys existing IBM WebSphere application server. That tool kit allows Hewitt to wrap Enterprise JavaBeans components with XML and SOAP, the two most critical standards for Web services. The JavaBeans interact with Hewitts IBM mainframe back-office system, where account and benefits information is stored.

Hewitt is planning to begin beta testing Web services with some clients by November and then to have four Web services generally available by January to check 401(k) balances, change 401(k) contribution rates and allocations, determine an employees eligibility for health care benefits, and check coverage from a health plan.

But although both Hewitt and Robertson Stephens are finding that Web services have the potential to solve some of their integration headaches, their use remains limited. Neither company is ready to exchange Web services among companies anytime soon because the technologies on which the Web services concept is based are in their infancy. They are waiting for a wider array of available Web services before using public UDDI directories, such as the one led by Microsoft, IBM and Ariba, which has been touted as the yellow pages of Web services. Hecking, for instance, would like to eventually share Web services with customers and third-party service providers such as suppliers of stock market data.

The problem is that few companies are providing Web services on public UDDI directories other than those with simple applications such as weather forecasts, Hecking said.

Top Web services proponents such as Microsoft and IBM, along with specialized vendors such as Cape Clear, SilverStream Software Inc. and Avinon Inc., say the day will come when enterprise developers become comfortable with the technology and its new standards. E-business platform vendors, from Microsoft and IBM to Sun and BEA, also have begun adding support of standards such as SOAP into their application servers and suites. Meanwhile, development tools in the works such as Microsofts Visual Studio .Net could make it easier to create Web services, experts say.

The four standards to emerge so far handle the basics of Web services. The way they interact is that, once a component is created, it must be wrapped in XML, providing it with a common language for transferring data and messages to another application or Web service. A WSDL file is created that describes what it does, such as processing a credit card transaction. That description is stored on a UDDI directory and published for use by others. An application then can access it by calling it through SOAP, the standard messaging protocol of Web services.

Those standards are only the beginning, though. Others are being proposed to deal with everything from managing workflow to improving the reliability of messaging.

Of gravest concern to most enterprises, though, is security. Most notably, enterprises need to be able to authenticate users of Web services to ensure that a legitimate employee or business partner is accessing a service. With no standards in place, companies such as Hewitt are exploring how to incorporate authentication technologies such as public-key infrastructure into the process themselves.

"Were focusing our energies on how do we basically secure the transaction so we know that if the transaction is coming through the Internet, it is from the appropriate client," Hilgenberg said.

At CSE Insurance Group, security could become the biggest obstacle keeping the company from widely deploying Web services.

The regional insurer, based in San Francisco, already has plans for Web services to allow its independent agents to get online quotes for its personal and commercial insurance products through an extranet site. But David Brinker, the insurers senior vice president and CIO, wants to eventually extend the offering so individual insurance agencies can plug a Web service from CSE into their own Web interfaces for insurance quotes.

"It has a lot of potential," Brinker said. "[But] exposing our rating engine Web service would [create] a major concern for us that we protect the security of that from our competitors and others."

So, for now, CSE has focused on adding Web services that are within its control. The project began at the beginning of the year, with San Francisco-based Avinon agreeing to provide a prototype of the Web service for furnishing quotations for commercial insurance rates online. CSE developed a Visual Basic program as the quotation rate engine, exposed it as a Web service and used Avinons NetScenario platform to create a Web application. The prototype was completed last month, and 15 agents are now piloting it, Brinker said. It should be available to the companys 400 California agents by the next quarter.

The next step is to create a Web services application for agents to get personal insurance rate quotes. For the past 15 years, agents have had to use a proprietary DOS application on their PCs and a dial-up connection to CSE. Brinker said he hopes to replace that system with one based on Web services accessed through the insurers extranet by the first quarter of next year. This rollout will go further than the commercial insurance rates project, tying in some 700 insurance agents in four western states.

CSEs move into Web services is part of its bigger goal of making it easier for independent agents to do business with the company. That is especially crucial because its agents arent exclusive and sell insurance frommultiple providers. At the same time, Web services could serve as the foundation for creating more real-time processes over the Web so one day agents can not only receive an insurance quote but also complete the entire transaction, which could cut what today is a five-day process to a few minutes, Brinker said.

Beyond the future benefits of Web services, companies are beginning to see some return on investment even in their early uses. Brinker estimated that the commercial insurance rate quoting Web service took about five weeks to create instead of what he would have expected to be a five-month project.

Few companies have yet to quantify cost savings from Web services, and for many the move to Web services will include some upfront costs. Companies will need to train developers on the new technology and standards and to invest in new development tools and upgrades to existing application servers, said Peter Urban, an analyst at AMR Research Inc., in Boston.

"The new Web services allow you to do more links more quickly, and maintenance costs are less because youre not creating a custom bridge," Urban said.

For The Thread.com LLC, of New York, using Web services to develop its Web-based supply chain software saved it about $4 million, said Gene Ostrovsky, executive vice president of operations and global development. The Thread based its offering for the apparel industry on Web services starting early last year using Bowstreet Inc.s Business Web Factory software. Developing with Web services allowed it to create components that could be shared and customized by each user, rather than having to create a custom-coded application without such flexibility.

Using Web services also allowed The Thread to develop its application with a focus on how the supply chain works within the apparel industry. Individual Web services match specific functions that are common in the industry, such as testing colors for a line of clothing or acquiring clothing samples, Ostrovsky said.

But Web services wont pay off for enterprises unless they continue to evolve within industry-accepted standards and not as competing vendor platforms, experts say.

Thats what Hewitts Hilgenberg is counting on. He realizes the company has taken a risk committing to Web services early on but believes its a well-calculated decision, given what hes seen in the market.

"IBM and Microsoft agree on very little, but they agree on XML and Web services," Hilgenberg said. "The industry has finally come to the conclusion that we cant continue to hurt the developers. We have to find some common ground for them to work on."