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
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
Step 3: Make sense of the processes
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
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
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
Step 7: Map information movement
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
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
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
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
Step 12: Create maintenance procedures
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?
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 firstname.lastname@example.org.