Chapter One. Approaching Application Integration

This chapter sets the stage for application integration concepts and introduces ways to view application integration solution patterns. The reader should focus on the concepts rather than the details. More technical details will come later in the book.

Application integration is a strategic approach to binding many information systems together, at both the service and information levels, supporting their ability to exchange information and leverage processes in real time. While this sounds like a pure technology play, the resulting information and process flow between internal and external systems provides enterprises with a clear strategic business advantage: the ability to do business in real time, in an event-driven atmosphere, and with reduced latency (see the tidbit on page 2). The business value of this is apparent.

Application integration can take many forms, including internal application integration Enterprise Application Integration (EAI) or external application integration Business-to-Business Application Integration (B2B). While each form has its own set of eccentricities, once you dig into the technology, you'll find that both inter- and intracompany integration solutions share many common patterns. For example, there almost always has to be transformation technology present to account for the difference in application semantics, routing technology to ensure that the information goes to the correct destinations, and rules processing to define integration behavior. However, there is much more to application integration.

Keep in mind that the application integration concept is nothing new. We've been dealing with mechanisms to connect applications together since we've had more than two business systems and a network to run between them. What is new is understanding the need for application integration solutions to support strategic business initiatives going forward, such as participating in electronic markets, supply chain enablement, Web visibility, Customer Relationship Management (CRM), and the real need to get all internal systems exchanging information and services. Indeed, as time marches on, we see the need to view application integration as a true paradigm, something that requires a great deal of business definition and architectural planning. Moreover, the application of new technology, such as integration brokers, to solve this problem brings more opportunity.

So, how do innovative enterprises leverage application integration? It's really a matter of understanding the need first, then the requirements, and finally how to solve the problem for their domain. Make no mistake: This is a difficult and complex process, but one you can handle when armed with the right information.

Moving to Real-Time Business Integration: An Example

Few examples illuminate the difference between the conventional (nonintegrated) method of doing business and an integrated business more clearly than the purchase of a new car. Currently, a customer walks into an automobile dealership and orders a car. That order is then placed with the auto manufacturer. The manufacturer, in turn, orders the parts and creates the car, while the suppliers order raw materials to create the parts. Paper purchase orders are sent to the suppliers, who ship the materials and send paper invoices to request payment. Only then, when all the parts are received from the suppliers, can the car be manufactured and sent to the dealer resulting in even more paper.

This process typically takes months, not weeks. It should only take days.

We need to think more comprehensively about how we capture and react to events. We need to recognize that all components of the integrated enterprise, or extended enterprise, affect the supply chain itself. For example, when a customer walks into our car dealership and orders a car, or when the customer orders a car via the Internet, that action is, in and of itself, a business event that is captured. Our system must react to this event by performing several tasks instantaneously: logging the event, processing the rules bound to such an event, and moving information to other interested systems or humans.

The event must be logged so that it won't be forgotten should there be a failure as it is being processed. We need to process rules bound to the event, such as price limits and credit requirements. The internal (e.g., inventory) systems and external (supplier) systems must be informed of the event. Finally, the information created by this event, in this example, customer and car configuration information, must move forward to the appropriate systems. Typically, this should be a second, subprocess.

What is of note here is that all relevant systems are notified of the event and are supplied with all appropriate information, in real time, so that they can, in turn, instantly react to the event. In our car purchase example above, the sales event captured by our manufacturer's system generates an instant requirement for parts to create the car. In turn, this information triggers a cascading series of additional events within systems owned by the suppliers, events such as notifying a supplier of the raw materials required to build the parts. A single, primary event could thus trigger as many as several hundred other events, which, in turn, could trigger several thousand more events. It is exactly this chain reaction of events events that serve a business need that we hope to create.

Remember, this real-time application integration scenario is an instantaneous process. Within seconds of the initial order, the suppliers are processing requests for the raw materials, the factory floor is scheduling workers, and the logistic group is assigning resources in order to ship a car to a particular dealer. There may be hundreds of systems involved with the sale, creation, and movement of this car, all exchanging event information simultaneously. Of equal relevance is that all systems participating in the event will be notified instantly should there be any change along the supply chain. That is, if demand changes (e.g., if car sales are down) or if there is a parts shortage. Instantaneous notification is a two-way street, from orders to suppliers, from suppliers to orders.

Simply put, application integration is a complex problem. The simple reality is that most application integration projects exist just at the entry level. We have yet to see the real-time coupling of thousands of applications. This should not necessarily be discouraging. As with any complex problem, once it is broken down to its component parts, the solution becomes simply the aggregation of a number of solution sets. In this case, it's a combination of a variety of approaches and several types of technology. This seems to fly in the face of those who want to oversimplify the concept of application integration, thinking that a simple standard, such as XML, or a particular technology, such as application servers, holds the answers to all of their problems. Unfortunately, it's just not that simple.

The world of application integration is no different from the larger world of technology it is advancing and changing rapidly. Ironically, as the technology changes, so does the problem it is designed to solve. The application integration problem is morphing from the very simple to the very complex, even as it moves from a departmental problem to an enterprise-wide problem, and, ultimately, to a trading community problem. Consequently, few companies have been able to get ahead of the "application integration curve." Without a complete solution, they remain short of discovering the full potential and benefits of application integration.

We are seeing that, as the problem grows, so do the potential benefits of the solution. The technology continues to respond to a perceived need. In this context, our pursuit of application integration is like chasing the tail of a growing beast. For now, that "beast" has remained ahead of us. A great deal of work remains ahead of us. But rest assured, a solution will be found and the once-unimaginable benefits of application integration will become an everyday reality.

As I've suggested above, as the problem domains become more complex, the application integration solution set evolves to address that growing complexity. No sooner is a "traditional" application integration problem solved (such as application-to-application and database-to-database integration), than the developed application integration expertise and technology is applied to more complex, but more rewarding, business issues.