When Soren Burkhart landed the job of CIO at Aloha Air Group a year ago, his marching orders were to quickly break through the constraints of the company's legacy mainframe system. The problem was serious. "Integration points to external vendors were very limited and very brittle. To extend the system to incorporate customer requirements was close to impossible," he says.

Burkhart began migrating applications off the mainframe onto Oracle databases and application servers. He used a Web service to "provide integration points to the old sources of data and feed our new Oracle architecture," Burkhart says. The project "took an order of magnitude less time" than it would have without using Web services.

Burkhart is one of a growing number of IT executives who got their feet wet with a Web services rollout, which involved application integration, and now are moving to more advanced projects that connect to business partners and streamline core business processes.

That's the key finding in an Ashton, Metzler & Associates survey of more than 400 global professionals. Sixty-four percent of 419 respondents said their company has deployed a Web service, while 36 percent said they had not.

The survey also found that once companies have established their basic Web services foundation, they are finding it relatively easy to deploy additional services. In the process, they are building toward a service-oriented architecture (SOA), in which overall application development and application integration is accelerated by the reuse of software components.

According to the survey, of those companies that have deployed a Web service, 56 percent used the Web service as an application-to-application interface within the company.

How sweet it is

Daisy Brand's first foray into Web services was a project designed to speed up an internal process, according to Kevin Brown, director of IS at the Dallas sour cream maker.

"Most of the world has looked at Web services as a killer application. We have taken a more pragmatic approach and have focused on using Web services primarily to improve application integration behind our firewall," he says.

The Web service let Daisy Brand take a batch-oriented system that forecasted demand for the company's product and integrate it with an ERP application to create a real-time order-generating system.

Before Web services, the forecasting system spit out a batch text file for each order recommendation. The customer relations team had to enter each order manually, which introduced an additional step and the potential for data errors.

The Web service, which Daisy Brand's IS team developed in 20 hours, uses an order description in XML format. The data then is transformed into an XML schema that is compatible with the company's ERP system.

The Web service then writes the XML output to a queue that processes electronic data interchange (EDI) orders. The Web service also maintains what purchase order is assigned to the order on behalf of trading partners. After the order is generated, an EDI document is sent back to the customer with the purchase order number and the ordered products.

Web services: part deux

According to the survey, 35 percent of respondents who have deployed Web services use them as an application-to-application interface with business partners.

At Aloha Airlines in Hawaii, Burkhart had an internal application integration project under his belt. His next mission was to improve Aloha's ticket-booking engine to make it easier for customers to find the lowest fares.

He used Business Process Execution Language (BPEL) to develop a Web service that connected Aloha's internal systems with the Electronic Data Systems Shares reservation system that the company uses.

Burkhart says one reason he likes BPEL is because it is an open standard that lets him hold his vendors accountable. He also says by using BPEL, his organization can model and store Web services in a way that makes it much easier to recombine services.

He says it used to take 500 hours of development time to make a typical change to the order entry system. Now that it has been exposed as a Web service, a typical change can be accomplished in 50 hours of development time. "The new booking engine will save Aloha over US$1 million," he says.

"Once you have a Web service developed for a given purpose, you can reuse it for another business process as needed," Daisy Brand's Brown says. "For example, the Web service we created to input orders into our ERP system can now be leveraged to support online orders for our other lines of business which have been traditionally paper-based.

"We plan to use the same interface to provide (electronic data interchange) like business processes for non-EDI customers,'' he says. The company is thinking about "how we can now support e-commerce for our food service business using a portal Web site or potentially using interactive voice response, as well," Brown adds.

He says his developers use the Microsoft .Net framework. "In particular, we take the (Web Services Description Language) definitions out of .Net and import them into directly into Tibco's Business Works," he adds.

Developing an SOA

Just more than 40 percent of the survey respondents indicated that their company began deploying Web services to solve a particular problem and then later began developing an SOA.

That is the approach Daisy Brand took. "We did not start off developing a SOA. However, we basically ended up with one," Brown says.

Burkhart adds, "SOA can mean many things to many people, but primarily you have to start at a high level and identify what are your key business services that you need to provide to your customers, and how do you want to leverage them across the enterprise."

Burkhart cautioned that starting off by developing a full-blown SOA has its risks. He says he has seen a lot of people try to "boil the ocean and not make any progress until they had solved all of the technical problems." He suggested that companies should start small, get some results and then build off of that.

Stumbling blocks

Of course, there are problems associated with Web services, such as poor performance and lack of management tools.

"We do not have the transaction volumes like some of the large e-commerce companies. As a result, we have not experienced the performance problems that are typically associated with Web services deployments," Brown says.

"One of the factors that may limit the widespread use of Web services is the lack of a comprehensive management environment for Web services," he says. "Basically, when there is not a problem, Web services work really well. When there is a problem, it gets chaotic quickly."

Burkhart adds, "Web services are a tool, not a panacea. To truly leverage Web services you have to continually ask the company's business leaders questions like 'How do you want to serve your customers?'"

With that in mind, Burkhart is looking forward to more use of BPEL and a lot more migration off the current legacy infrastructure.