In-Depth

The enterprise gets on the bus

The enterprise service bus (ESB) is the latest evolution of middleware to integrate applications across the enterprise and the Internet. It’s a new way to enable a service-oriented architecture and drive down the costs of enterprise application integration.

Gartner, the market research company, estimates that by 2007, the majority of applications will use ESBs. Roy Schulte, a Gartner analyst, says organizations spent between $20 million and $30 million on discrete ESB systems in 2003.

“This is the enterprise nervous system people have been talking about,” Shulte says. “The ESB will have a huge influence on any company’s architecture, but the dollars spent will be hard to track because they will be part of the embedded value of IT projects developed with ESB.”

Getting to the bus stop Schulte believes the desire to move to SOAs is pushing the adoption of ESBs. “Most people have a mix of batch and online applications,” Schulte says. “They are looking for ways to make the applications more pluggable. People tried it with RPCs and had a lot of success. They tried it with CORBA and COM+ (Common Object Model) with moderate success. The third time is a charm, and Web services will be deployed with ESBs. We really will have pluggable applications and we will have widespread adoption.”

There’s no official ESB standard, and vendors are free to call virtually any messaging product “ESB-enabled.” Werner Gade, section chief for enterprise infrastructure for the State of Wisconsin, advises potential buyers: “Research the market, talk to different vendors, and understand what definition of ESB the vendor is using. They all use a different definition, and each of their products provides a different functionality.”

Industry observers such as Burton Group’s James Kobielus see ESB as a distinct set of functionalities built on top of existing message-oriented middleware. He says there must be support for reliable messaging for Web services, SOAP, and MOM (providing access into legacy systems), and flexible messaging patterns that enable communications via both hub-and-spoke and peer-to-peer networks. Other differentiating features include support for additional interaction services such as transformation, orchestration, federated identity, asset transaction, and Web services management.

The Promise of ESBs
ESBs are not for everyone. “There are probably 250 to 300 examples of people running commercial ESBs today,” Schulte says. “I think the success rate has been good, but the people that have been doing it are leading-edge companies with good technical staff.”

Provide Commerce, a Web-based provider of perishable goods, with 130 employees and $136 million in annual sales, is an early ESB adopter. The company has a number of Web commerce sites, including Proflowers, Uptown Prime, and Cherry Moon Farms. In 2003, it deployed Sonic Software’s ESB product to handle heavy holiday-related sales peaks. For example, during most of the year, sales peak at between 500 and 1,000 orders per hour, but just before Mother’s Day, the numbers can hit 13,000 orders per hour.

Bharat Gogia, VP of IT at Provide, says the company had to “develop a system that can scale to that level economically. We cannot afford to have a system whose cost is so high that it cannot economically sustain only 500 orders per hour on normal days. We needed a system that can be distributed so it can scale horizontally or vertically as we need without major changes.”

The ESB platform makes it easy for Provide to redeploy servers to handle anticipated peaks. During sales peaks, the company shifts servers from the testing and performance to mainstream commerce and then back with minimal effort.

Gogia says this approach enables his team to build applications as a service, and scale them quickly before a heavy load. He notes: “Although it was not a proven model, it still made a lot of sense” from a business perspective to go in that direction.

The ESB system makes it simpler to move orders and other data between queues. Gogia says, “The ESB ties between queues, and between queues and business processes. It is a simple solution; you just put the routing mechanisms into the ESB, and it will route [data] from one queue or business process to another.”

Provide was able to deploy the core Web services pieces within one calendar quarter, and the key components for the ESB and queues for the commerce platform in the second quarter. Since then, it has been adding more services to extend the supply chain platform.

Gogia estimates the reduced cost of IT and the enhanced ability to scale the system as needed yields a 12-to-18-month payback. The simplicity of having one programming model was a big component. “If we had not deployed the ESB, then we would have been stuck with several different methods of enterprise application integration, including CORBA, J2EE, and .NET,” he explains. “Every component would have [had] its own interface and its own application integration models.”

Plug in, plug out
The key advantage with ESBs is that organizations can plug, for example, an inventory management system into other applications without having to write another inventory management app. The ESB is useful for any kind of application that must be pluggable, such as record keeping, order entry, and accounting.

For example, the State of Wisconsin is deploying an ESB backbone from Cape Clear Software to take advantage of this capability. Gade explains: “We have a lot of applications throughout the state that calculate sales tax. Currently, whenever the sales tax changes, all of those programmers have to update their programs. If the department of revenue provided a similar service that everyone could use, you would only have to change it once, and everyone would get the same change.”

The state paid about $300,000 to get the ESB running and used it for a couple of applications; it then negotiated a license for $1.5 million over three years. Gade sees two ways to recoup the investment. First, the ESB reduces the duplication of work. For example, the state has added a Web interface to an application for address verification that several agencies can now use. This allows programmers to create applications that interface with the service without having to code the interfaces into the program. “While we invested in the IT infrastructure, the savings will be realized in the fewer hours required to code specific interfaces,” Gade says.

Second, the state is able to use the improved integration capabilities of the ESB to create new revenue. For example, the ESB enabled Wisconsin to improve data about the money spent on various programs for which they were entitled to receive federal reimbursement.

Recently, 15 state agencies wanted to know more about how to use the ESB system. For example, the justice agency is creating a system to improve the flow of information between law enforcement and the district attorneys on court prosecutions. The state is also using ESB technology to facilitate interdepartmental communication that can help speed qualifications of citizens for economic assistance.

Despite the promise of ESB, Gade cautions, “The ESB is not a silver bullet for all of the integration issues that IT faces, but is useful in a lot of the hurdles placed at the feet of IT shops. Just like a mechanic needs tools to fix a car, we need to make sure our people have the proper tools to do the job. From an integration perspective, ESB is a good all-around tool.”

It’s an easy case to make on paper
A company might spend $5,000 to $10,000 per server in licensing fees to run an ESB, and might start out at $100,000 for a full-scale enterprise deployment, according to Schulte, the Gartner analyst.

For an enterprise that’s trying to develop new revenue streams by launching new services, deploying an ESB today could make a lot of sense, Schulte says.

On the other hand, enterprises with many legacy systems and established business models may want to hold off until vendors embed ESB capabilities in their latest servers to avoid the potential of having to pay hidden costs for integration and training.

Natalio Rivas, manager of information systems at Duke Energy, has been evaluating SOAs and ESBs for more than three years. He decided to delay a major deployment of ESB technology out of concern over the learning curve and implementation costs. “On paper it is easy to make the case that you will spend $45 million over five years and save twice that much,” Rivas says. “In my practical experience with consulting fees, it is very difficult. How do you bring that skill set in house quickly? If you want to take advantage of this thing, you want to do them in the shortest time. Getting the know-how is a challenge and can be expensive.”

His other major concern is legacy integration. “If you build all of the marvelous messaging architecture, how do you get the stuff that really matters in your legacy systems,” Rivas asks, “which is what everyone is using today?”

Duke Energy’s move to SOA and ESB seems like an unnecessary risk at this point, and it makes more sense to wait until ESB technologies become standard features in upgrades to servers the company is using. “We have looked at SOA and made no progress whatsoever, although the technology has advanced quite a bit,” Rivas says. “No matter what anyone says, legacy systems are difficult to integrate with anything else. Just because you have the underlying technology does not mean you are there yet. With most of the older systems, the data structure was not designed to support XML and some of the neat things out now.”

Although the ESB is not for every organization, it will enter most organizations over the next couple of years on the back of the emerging generation of enterprise servers.

“Between now and the end of 2006,” Schulte says, “ESB is one of those competitive advantage things. If you are an ambitious company, your strategy should be to be doing ESB now. By 2007, you will be using an ESB whether you want it or not because your vendor, Microsoft or IBM will be shipping it to you.”

The five principles of highly motivated ESBs
Sonic Software, which claims to have pioneered the Enterprise Service Bus concept, says ESBs have five key principles:

1. Service oriented architecture. ESBs implement a SOA that supports service-based interactions among apps based on XML messages and enhanced Web services standards.

2. Enterprise-grade communications backbone. ESBs must have an enterprise-grade communications backbone to reliably connect applications across multiple geographic, administrative or security domains based on Java Message Server.

3. Support for standards. Standards such as WSDL, SOAP, JMS and J2EE-CA dramatically reduce the implementation time and total cost of ownership of integration projects.

4. Intelligent routing. ESBs automate business transaction routing based on XML document content and business rules.

5. Deployment flexibility and distributed management. ESBs have the ability to centrally configure, deploy, and manage services that are distributed across the enterprise.

Discussion Points

ENTERPRISE SERVICE BUS

• Most applications will use ESBs by 2007, says Gartner analyst Roy Schulte.
• Upside: ESBs can help you scale up a system quickly to handle spikes in demand.
• Downside: Your current programming paradigm may have to change.
• Bottom Line: Eventually, you will have to jump on the ESB bandwagon. For now, if it can give you a competitive advantage, grab an early ride.

Most   Popular