12 steps to EAI

Most professional service organizations have instituted some form of enterprise application integration (EAI) methodology, which they claim will assure them ultimate EAI success. These methodologies are most often found in a series of binders (each at least six inches thick) and outline as many as a thousands steps to reach EAI nirvana.

It’s a bit of overkill for most organizations. Most don’t need that kind of rigor to be successful with EAI. What they do need are some good architectural skills and a base of knowledge pertaining to state-of-the-art technology solutions.

The following activities aren’t the only ones you should consider when approaching EAI, but they’re among the most important. My strategy relies on a practical approach to EAI, reusing some of the elements and design patterns of traditional database design, application design, and development. I’ll draw heavily on familiar concepts and terms such as metadata, schemas, object-oriented modeling, object-oriented analysis and design (OOA/OOD), patterns, and “good old” requirements-gathering techniques.

Step 1: Understand the problem domain
You’ll have to work with many organization heads in order to get a handle on the structure and content of various information systems, as well as the business requirements of each organization—how they do business, what’s essential, and, perhaps more importantly, what’s not.

This process is a basic requirements-gathering problem. It demands engaging with paper, people, and systems to find the information that will allow the EAI problem to be defined correctly so that it can be analyzed, modeled, and refined.

Step 2: Make sense of the data
Most EAI projects exist only at the data level. This reality alone justifies the quest to understand what exists in the databases scattered throughout an enterprise. Ultimately, the implementation of data-level EAI comes down to understanding where the data exists, gathering information about the data (for example, schema information), and applying business principles to determine which data flows where, and why.

Step 3: Make sense of the processes
Once you understand the enterprise data, and you’ve created baseline information such as the enterprise metadata model, you must decide how to approach the enterprise business model. This decision will depend on several things. First, there’s your view of the enterprise at the process or method level. Your approach will also depend on how you understand and document business processes and the way they relate to each other. Last, the enterprise metadata model is also a factor.

Traditional process modeling techniques, such as object modeling with UML, are the best way to create business processes. Work from the existing processes to better understand what they do, and therefore how to integrate them at the method level. Approaching business processes from this angle is far preferable to working from a set of application requirements.

Step 4: Identify application interfaces
Interfaces are quirky. They differ greatly from application to application. What’s more, many interfaces, despite what vendors or developers may claim, are not really interfaces at all. So the time you spend validating assumptions about interfaces will always be worth it.

The best way to begin with interfaces is to create an application interface directory. As with other directories, this is a repository for information about available interfaces, along with the documentation for each interface. This directory is used, along with the common business model and the enterprise metadata model, to understand the points of integration within all systems of the EAI problem domain.

Step 5: Identify the business events
When something happens—a business event—then there is a resulting reaction. For example, a customer signing up for credit online represents an event. You may want to capture this event and make something else happen, such as running an automatic credit check on the customer. That consequence, of course, will kick off a chain of events at the credit bureau and return the credit status of the customer. The returned credit status will fire off still other events, such as notifying the customer if the credit application is accepted or denied. These events are generally asynchronous in nature, but can be synchronous in some instances.

In attempting to understand an EAI problem domain, you must strive to capture the business events that may take place within the domain. It is important to understand what invoked a business event, what takes place during the event, and any other events that may be invoked as a consequence of the initial event. The end result is a web of interrelated events, each dependent on the other. Currently, this web exists through automatic or manual processes. In the EAI solution set, all these events will be automated across systems, eliminating the manual processing entirely.

Step 6: Identify the data transformation scenarios
Once you understand the data and application semantics that exist within a problem domain, you can start to think about how data moving between systems will be transformed. This is necessary for several reasons. First, data in one system won’t make sense to another until the data schema and content are reformatted to the target system. Second, it will assure the maintenance of consistent application semantics from system to system.

Step 7: Map information movement
Now it’s time to map the movement of information from system to system. Map what data element or interface the information is moving from, and where that information will ultimately move.

For example, imagine the customer number from the sales database needs to move to the credit reporting system, ultimately residing in the customer table maintained by the credit system. You would note where the information is physically located, what security may be present, what enabling technology exists, and how the information is extracted on one side to be placed on the other.

You would also note the event that’s bound to the information movement. Or, if no event is required, what other condition causes the movement of information from the source to the target, such as time of data, real-time, or when a state changes.

This process is typically more relevant to cohesive systems than to coupled systems. Coupled systems are usually bound at the method level, which is where the data is shared rather than replicated. Mappings should be adapted to the EAI level that is used to integrate the systems.

Step 8: Apply technology
You’ve got a choice of a wide range of technologies, including application servers, distributed objects, and message brokers, to help you integrate applications. The choice of technology will likely be a mix of products and vendors that, together, meet the needs of the EAI solution. Very rarely can a single vendor solve all problems—not that that reality has ever kept vendors from claiming they can.

Technology selection requires a great deal of time and effort. Creating the criteria for technology and products, understanding available solutions, and then matching the criteria to those products isn’t exactly a piece of cake. To be successful, this “marriage” of criteria and products often requires a pilot project to prove that the technology will work. The time it takes to select the right technologies could be as long as the actual development of the EAI solution. While this might seem daunting, consider the alternative: picking the wrong technology for the problem domain. A bad choice practically assures the failure of the EAI project.

Step 9: Test, test, test
Testing is expensive, time consuming, and thankless. Still, if an EAI solution is not tested properly, then disaster looms large. Even absent any dire eventualities, you still must insure that the solution will scale and handle the other rigors of day-to-day usage.

For proper testing, establish a test plan. It’s a step-by-step procedure detailing how the EAI solution will be tested when completed. A test plan is particularly important because of the difficulty in testing an EAI solution. Most source and target systems are business critical, and therefore cannot be taken offline. As a result, testing these systems can be tricky.

Step 10: Consider performance
While most EAI solutions won’t provide zero latency, with today’s technology response times should still be under a second. What’s more, the EAI solution should provide that same response time under an ever-increasing user and processing load. In short, the EAI solution will scale.

The architecture of the EAI solution needs to provide the infrastructure for performance, as well as the selected enabling technology. You can make some adjustments before the solution is deployed using traditional performance models (namely, performance models from the world of distributed computing). Finally, run some tests to see if the system performs well under a variety of conditions. How well does it perform at 100 users, 500 users, 1000 users, and even 10,000 users? What about processing load? What happens to performance as you extend the EAI solution over time?

Step 11: Define the value
The hard part’s over. Now it’s time to determine the value of integrating systems. Consider two things: the soft and hard dollar savings. Hard dollars represent the value of the EAI solution as defined by the solution’s ability to eliminate costly processes, such as automating manual processes, reducing error rates, or processing customer orders more quickly. Soft dollar savings are more difficult to define. These savings include increased productivity over time; retention rate increase due to the ability to make systems work better together for the users; and customer satisfaction (based on ease of use) with integrated systems.

Step 12: Create maintenance procedures
Last but not least, consider how an EAI solution will be maintained over time. Who will administer the message broker server? Who will manage security? Who will monitor system performance and solve problems?

Document all of the maintenance activities that need to occur—and assign people to carry them out. An EAI solution represents the heart of an enterprise, moving vital information between mission-critical systems. As such, it is also a point of failure that could bring the entire enterprise to its knees.

With that happy thought in mind, this might also be a good time to consider disaster recovery issues, such as redundant servers and networks, as well as the ability to relocate the EAI solution should a disaster occur.

Method or madness?
My goal here has been to outline some of the activities you might perform on your next EAI project. Unlike traditional application development, where the database and application are designed, EAI solutions are as unique as snowflakes. No two are alike. But as time goes on, common patterns emerge which allow us to share best practices in creating an EAI solution. We still need to travel farther down the road before we can see the entire picture. But we’re getting there. We’re getting there.

David S. Linthicum is the CTO of SAGA. A portion of this column was adapted from the upcoming Enterprise Application Integration (Addison Wesley Longman). You can reach Dave at linthicum@worldnet.att.net.

© 1999 FAWCETTE TECHNICAL PUBLICATIONS, all rights reserved.