Enterprise Evolution: Where EAI Meets B2B

Enterprise Evolution: Where EAI Meets B2B
An ebizQ&A with SAGA Software CTO David Linthicum

As the chief technology officer for SAGA Software, David Linthicum keeps a close eye on integration technology and market trends. Charged with product strategy and development for Saga and its Sagavista enterprise integration suite, Linthicum is a leading figure in the EAI and B2B technology circles and has authored over 350 articles and six books on middleware, application development and architecture. In this Q&A with Beth Gold-Bernstein, ebizQ's vice president of content, Linthicum explains how EAI and B2B integration differ, and what challenges vendors and their customers will face in dealing with future enterprise and B2B integration needs.

ebizQ: In the past few months, we've seen a merging of the EAI and B2B infrastructure technologies; a number of EAI vendors are adding B2B capabilities and vice versa. In your opinion, what technology requirements distinguish a true EAI product from B2B?

Linthicum: The problem domain that EAI focuses on solving is localized within the enterprise, so all of the EAI techniques and technologies are geared toward solving the integration problem between applications intra-enterprise. The B2B problem is very different. It involves integrating applications between organizations to solve a business problem. You can't necessarily force everything that worked in EAI into the B2B domain. You need to understand the unique requirements for B2B integration and be able to apply the appropriate technologies and tools to the various integration scenarios. That's how the game will be won.

ebizQ: What are the different requirements and technologies needed for EAI and B2B?

Linthicum: In EAI, it sometimes makes sense to become intrusive and change an application to integrate it. Within the EAI problem domain, the tools, technology and design patterns of the source and target systems require a mix of cohesive and coupled integration approaches and technology. For instance, you can use a mix of event-driven integration, method binding and transaction-based methods. In B2B integration you need to be non- intrusive, because you typically don't own the applications that exist within your trading partner's organization. B2B integration is non-invasive and loosely coupled or cohesive by definition.

The management requirements are also different. Within EAI you need to manage application semantics and the ability to move information between systems in short time frames. In B2B the information movement is more at a business-entity level, and you need to manage long-lived transactions over an extended period of time.

For instance, within the short transaction, you'll typically exchange information between two or more applications to support a discrete event, such as the addition of a customer in one system automatically updating another. An example of a long transaction would be ordering a phone line from the phone company. You place the order, your credit is approved, the work order is placed with a contractor, the line is installed, and finally the billing record is created on an outsourced billing system. All this could take weeks—sometimes months—and systems inside and outside the phone company need to communicate to support this transaction. Application integration technology needs to manage transactions that are durable over an extended period of time to support B2B application integration.

ebizQ: How do these different requirements affect the technical requirements of the solution?

Linthicum: Both EAI and B2B integration require transformation, routing, metadata management, adapters and connectors, and management layers, to name just some of the capabilities of integration technology. But in EAI the integration scenarios—how information is updated between sources and targets—are known within the organization. There is more control because the organization owns all source and target applications.

In B2B you need to define trading scenarios. The semantics are different for each of the multitudes of resources and information. The actual information flows are going to take place over a long period of time, typically. Moreover, there are other technologies you need to take into account, such as digital exchanges, RosettaNet and Microsoft's BizTalk. You need to manage information movement between enterprises differently than you manage information movement within an enterprise, and thus you need to approach information flow with different management layers.

ebizQ: In other words, in an EAI solution you can choose your architecture and the type of technology you're going to support, but in a B2B solution you have to be open to all technologies and standards. What do you see as the really tough problems in integration?

Linthicum: Scalability and non-invasive interfaces are the really tough issues to solve. Saga spends 50 percent of its R&D budget on adapters. The other 50 percent is spent on core capabilities, including scalability and durability. Today, most current EAI installations are small, connecting three to four systems. The limits of their scalability haven't been tested and won't be until they connect dozens of systems and process hundreds of transactions a second.

ebizQ: What makes an EAI solution scalable?

Linthicum: It needs to be architected for scalability. This means distributed architectures that support transformation and message processing clusters have to share a processing load between two or more servers, as well as provide failover through redundant services and dynamic switching. That's a tough problem to solve. Core services, as well as messaging, should be able to be spread across multiple machines and across processes within a machine.. You see, initially EAI products were monolithic, hub-and-spoke architectures. Now, especially in B2B, we need to support hundreds of systems connected into the same B2B middleware solution, and that requires scalability and reliability. These features need to be designed into the product before it's coded; they're not add-on features. I think we're starting to see a shake-out based on scalability. Some technology will simply not get you there.

ebizQ: Hasn't one of the biggest challenges of distributed architectures always been management?

Linthicum: Distributed management is a huge problem. In EAI, management is an afterthought. World-class EAI and B2B solutions need to provide a basic management subsystem, as well as hooks into existing enterprise management systems such as Tivoli and OpenView. That's what our customers are telling us they want.

ebizQ: But that's systems level management. If a transformation or routing rule changes, and the rule exists in multiple servers or distributed adapters, then the change needs to be automatically promulgated everywhere that's necessary. Some vendors are using directories as a solution to distributed management. Do you see directories becoming an important part of the architecture?

Linthicum: Directories are indeed becoming very important. Sagavista uses JNDI [Java Naming and Directory Interface] and links into LDAP [Lightweight Directory Access Protocol]. This is part of the management layer, and you've got to have it to support distributed computing. Other management features we feel you'll need for distributed B2B or EAI include business rules management, metadata management, communications management, load management, exception management, to name just a few. We support all of these management services within our distributed environment. Distributed products, such as Sagavista, bring a lot to the party as long as the management infrastructure is in place.

Considering our discussion of distributed architectures, there is a difference between distributed and federated architectures. Distributed systems are aware of each other and can move loads between the instances of themselves. Federated architectures are decoupled. They're not aware of each other and only support static processing. Most distributed EAI solutions are federated, where we support truly a distributed architecture.

ebizQ: Currently, Saga, Software Technologies Corp. and Active Software have products with distributed architectures, and Vitria Technology has a federated architecture. Most of the others have a hub-and-spoke design. While distributed architectures are inherently more scalable, we don't have any EAI benchmarks yet. This makes it difficult to measure scalability. What are the hard problems you see specifically in B2B integration?

Linthicum: First, you're correct that there are no accepted benchmarks for EAI and B2B solutions, and I for one would welcome them. Each vendor is taking its own approach to this problem, and using a variety of creative solutions. It would be nice to see which ones perform well, and not so well, under a variety of EAI and B2B scenarios. My guess is that we could end up with some surprises.

Second, the hard problem in B2B is to be able to communicate with a variety of systems without having to change any of them. There's a lot of confusion in the market over the variety of standards that exist. There are different points of integration, and managing all application and database connections over the Internet in a reliable and scalable manner is a very difficult challenge. We need to be careful to consider the lessons we learned from EDI.

ebizQ: What are the lessons learned from EDI?

Linthicum: For one thing, that EDI is not going away; it's still going to have a place in B2B. I think what EDI did right was to offer a common data format, security, verification and confirmation. EDI was simple and reliable, but it was also proprietary and expensive, and required customization of most sites using it. Now people are migrating to XML as the common format, but XML lacks security, verification and confirmation.

ebizQ: At the beginning of the conversation you said that EAI was designed to solve a different set of problems than B2B. What is missing from EAI technologies that prevent them from being used in B2B situations?

Linthicum: Security, reliability, scalability, verification and B2B-specific management layers are the short list. Don't forget about support for long transactions, adapters that don't require changes to applications, and tight integration with trading communities based on standards such as XML, RosettaNet and Biztalk. It's not just information movement problems to solve, but business process automation problems as well. It's a huge mistake to glibly state that, because your tool can connect applications together over the Internet, it's automatically a B2B tool.

ebizQ: What do you see as security requirements for B2B?

Linthicum: Verification, validation of trading partners, transactional control to make sure a transaction succeeds or fails and is not left in an unstable state, the ability to encrypt information over the Internet, and the ability to manage security among partners without changing applications at partner sites.

ebizQ: What about the notion of non-repudiation of electronic business contracts?

Linthicum: I think we need a way to provide legally binding information that electronically flows between partners. That will allow businesses to operate in a more event-driven environment.

ebizQ: Do you believe organizations need to provide integration between their B2B applications and their back-end systems?

Linthicum: Yes, and you need to do it non-intrusively. I see existing B2B players getting more into the EAI game, such as webMethods, and EAI vendors are extending their solutions for B2B, such as SAGA Software. Ultimately we need end-to-end, non-intrusive, B2B integration.

ebizQ: Do you think it's harder for EAI vendors to extend their solutions outward or for B2B vendors to loop in back-office systems?

Linthicum: It's harder on the B2B vendors, because they end up having to provide connectors for specific applications, such as SAP, PeopleSoft and Baan. That's not a picnic, believe me.

ebizQ: The problem with solutions comprised of disparate technologies is the inability to do end-to-end management.

Linthicum: In the future there's no reason why we can't work together in trading communities to deploy a variety of integration solutions. We just need to learn how to play together. Emerging standards will help that. Pretty much everyone has agreed on XML, and now we need to move on to other issues. For example, there's still no notion of a unified process or standard process scenarios. Eventually we'll get to canonical processes, something like ODBC for message brokers. Then we'll be able to manage multiple workflows from a single console. But that day is still a long way off.

ebizQ: What do you see as the future of EAI and B2B integration?

Linthicum: B2B gives us the ability to create a common trading community among different vertical markets without human intervention. The first wave is the exchanges. After that we will be able to share common processes and logic, all without involving humans. Then we'll get to a truly connected worldwide economy, where trade can happen instantly—without someone having to pick up a phone or use a Web page. It's really an exciting world, with tremendous benefits for businesses. B2B integration will enable companies to meet their customers' needs more quickly, and that's what it's all about in the end.