Implement an enterprise service bus (ESB), and instead of worrying about integration technologies you can concentrate on improving your business operations.
| ||express delivery|
| print comment|
|The standards-based messaging of ESB lowers the cost and complexity of integration, so businesses can concentrate on process improvements:|
- ESB uses an open-standard message bus to link applications
- A bus architecture is well suited to connecting disparate systems
- Adapters are needed for systems that don't use web services or Java
- Vendors claim a tenfold cost advantage over conventional integration
- Simpler integration exposes a need for business process expertise
Glossary terms: ESB, EAI, JMS, asynchronous messaging, XSLT, lookup tool
That's the view of ABNA, a UK-based agricultural feed conglomerate which, with annual revenues of £1.2 billion ($1.95 billion), makes up a quarter of Associated British Foods, one of Europe's largest food companies. ABNA began implementing message routers the basic building blocks of an ESB infrastructure 18 months ago. It has now adopted ESB as the platform for all its business interactions.
ABNA is about to bring live a logistics optimization application based on the technology, which will allow it to replace its 38 distribution centers with three regional hubs. By incorporating upfront planning from at least four different systems, it expects to eliminate wasted journeys when trucks travel back empty from deliveries. With £65m ($105 million), spent each year on moving product, the anticipated savings will put ABNA on a fast track to triple-digit returns on its technology investment.
"When we look for streamlined, value-added business processes, we will use messaging as the glue," says Mysia Benford, IS and logistics director at ABNA. "People have spent too much time worrying about the technology parts of it in the past. The big advantage [from ESB] is in solving the complex business problems of aligning the needs of customers and suppliers, by making [the technology] simple."
ABNA's experience seems to bear out the enthusiam with which tech industry analysts have greeted ESB. IDC has called it a disruptive technology along the lines of the steam engine and telegraph, while Gartner Group predicts that a majority of large enterprises will have an ESB in place by 2005.
The big deal about ESB is that it doesn't have the hub-and-spoke architecture of traditional enterprise application integration (EAI) products from the likes of IBM, Microsoft, Vitria and Tibco, which feed all messages through a proprietary central hub. Instead, ESBs from Sonic Software (SonicESB), PolarLake (Jintegrator, which PolarLake dubs the first "universal" ESB), Kenamea (Web Messaging Platform) and Spiritsoft (SpiritWave) allow applications to pass messages to each other over a shared, standards-based messaging network. It's like replacing the centralized rigidity of a railroad network with the autonomous fluidity of a road transport system.
Steve Craggs, vice-chair of the EAI Industry Consortium, highlights the essential characteristics which qualify products as ESB platforms in a consortium white paper, Best of Breed ESBs. They include: services messaging, routing and transformation, definition tools, repository services, administration, management, basic connectivity and industry standards. Differentiators between competing ESB platforms include robustness, scalability, performance, security, tooling and broad connectivity.
Now an independent consultant with Saint Consulting, Craggs is an industry veteran in middleware the name given to software that links separate application systems. He instinctively warms to the bus approach: "From an architectural point of view, buses have always appealed to me. From a performance perspective, because there's more intelligence out at the nodes, if something goes wrong, you don't have to keep calling back to the hub."
The proponents of hub-and-spoke architecture argue that its single point of control makes it inherently easier to set up and manage than a bus. But Rick Kuzyk, senior technical evangelist for Sonic Software, counters that the flexibility of a bus wins out in today's highly connected environments:
"Hub-and-spoke is good when you are talking about applications in one territory in a specific line of business. When you are talking about a distributed architecture where you build composite applications from services in many lines of business in separate geographies and data formats [and] with different security methods, bus is better."
This was certainly the case for ABNA. Having grown by acquisition, it has a number of well-established but disconnected systems in its different businesses ranging from a laboratory application and a commodities trading app to a process control app for its nineteen grain mills. It saw a number of opportunities going forward in linking these different businesses together, such as in the logistics optimization project, which will allow them to pool distribution planning and production scheduling.
"We had a specific problem or opportunity when it came to integration," Benford says. "We could have deployed a single system across the entire business or standardized on one of the ERP solutions. But we discounted these first two because we already had very good best of breed software."
Rather than replacing the trusted functionality of these existing applications, ABNA wanted to enhance the supply chain activity that linked them, with one business unit potentially supplying the raw material input to another business unit, and the consumer at the end of the chain. "Visibility throughout the farm-to-fork supply chain enhances traceability," Benford explains. "[It] adds value to the consumer offer."
After considering a traditional EAI product a proposition that would have meant a tenfold increase in the cost of the project ABNA settled on a messaging bus as the solution, based on Sonic XQ (now Sonic ESB) message routers. The bus has now been implemented and the first major applications have been linked in, starting with those that handle the largest volumes to ABNA's major customers and suppliers.
With the ESB in place and functioning, ABNA can now move on to exploit its potential, says Benford. "What I say is, we should isolate the problem and integrate the solution. We have a beautifully isolated messaging platform. By itself it will not help me. But now we can look at the processes across the top of that."
The opportunities are not only within the business, but also include linking into external processes at suppliers and customers. ABNA is a leading participant in the First4Farming agribusiness trading exchange, and has adopted its message standards internally in preparation for linking up with other participants. "If people buy into the messaging internally, then they can go and play electronically externally," says Benford.
ABNA's implementation is more aggressive than many analysts are recommending. Gartner, for example, advises companies to hold off investing in ESBs until 2004, because of the relative immaturity of the concept. Even Craggs, despite his enthusiasm, admits vendors have missed out some high-level functions in their current products: "They've not quite got the functionality of some of the bigger integration suites. But you could argue whether that functionality is worth the extra investment."
He cites management tools as being a weaker component than those in proprietary solutions. ABNA plugged this gap by having integration partner CAL Software build its management console, although Sonic has since built management functionality into the product. Vendors will also offer connectivity to CA Unicenter and HP Tivoli to get round these problems, Craggs says.
ESBs also draw criticism for their reliance on standards that assume everyone is either exposing applications as web services or using Java Connector Architecture (JCA) for connectivity. Legacy applications or Microsoft environments that don't already have the Java or web services capabilities need third-party adapters to plug into the bus Sonic, for example, partners with adapter specialist iWay for this purpose.
ESB vendors retort that this can be a good thing, because it allows customers to take an incremental approach. "If you don't want to take a big-bang approach and most organizations don't you can put in an ESB and extend your current EAI set-up with adapters," says Mark Dunleavy, SpiritSoft's VP of business development for EMEA. "Then as budget and priority permits, you can retrofit [the bus] to older applications."
Retrofitting might mean simply wrapping up a legacy application as a web service. explains Rob Davies, the company's CTO. But SpiritSoft also offers its own JMS-compatible interface, which leading online broker E*Trade, having purchased the company's SpiritWave product, plans to use to connect all of its legacy systems to the bus. The tighter integration that this allows is more appropriate for trading information or real-time market data, says Davies.
Another SpiritSoft customer, Rabobanks, is beginning to put this piecemeal approach to work. "It has put together a framework where it can drop applications in easily," says Dunleavy. Having spent three months developing the framework and the first adapter, the Dutch bank has found it can roll out subsequent adapters in as little as three days. After having a team of 15 people initially, it now has just two supporting the entire infrastructure. "Once you've done it, 80 per cent of the code can be reused," says Dunleavy.
Proponents point to examples like these as evidence that, for many customers, ESB solutions are an order of magnitude cheaper and simpler than conventional EAI.
"ESBs are an important new development and they will have an impact on the EAI market, there's no doubt about that," says Craggs. "They will introduce the idea of a different cost dynamic in EAI, because the price point for an ESB is much less than a point-to-point, [hub-and-spoke] solution."
Sonic's Kuzyk estimates an ESB comes in at as little as a tenth of the cost of traditional proprietary architectures and that is before you take into account professional services, which can cost up to four or five times as much as the software license fees.
He says services costs will be much lower too. Since most organizations have XML and Java skills in house, finding developers who can work with XPATH, JMS and XSLT the core standards of ESB is far easier than finding the skills for proprietary products. "With our approach, because it's standards-based, we can drive down the cost of integration so you can do more projects in the same time, on a smaller budget. In an economic downturn, where there's less money or you want to look at less critical integration projects, that's a help."
The potential savings will spur many companies to investigate the suitability of ESB as an alternative to conventional integration technologies. But ABNA's Benford warns that the real benefits can only come afterwards, by refocussing attention on how the business works. "The issue is not and never will be a technical issue. The issue is having an understanding of business processes. In order to make messaging work, you need to take on both business processes and systems issues. That is the challenge."
More on this topic
Here's a compendium of links to recent articles about ESB ...
In the right conditions, service-oriented approaches deliver integration for far less ...
White paper by Steve Craggs, vice-chairman, EAI Industry Consortium, republished by Sonic Software (PDF, 578k)
Associated British Foods
, Saint Consulting
, Sonic Software