Here are a few major obstacles that might prevent you from achieving success in your first project:
- Not understanding the issues surrounding the business integration of different applications, such as the communication, coordination, and ownership issues for translation between different applications that are managed by different groups.
- Not understanding the semantic difference between data elements.
- Not understanding the semantics of different data elements in the context of different applications. For example, the notion of sales price in one application may differ from the notion of sales price in another. The sales price may actually be the same as the list price in the second application.
- Not identifying responses that have been delayed beyond "a reasonable length of time."
- Underestimating the complexity of business rules involved (especially with routing and context-based behavior).
- Data quality and integrity problems in one application clashing with the constraints and rules in other applications.
- A requirement to do reverse-translation may be complicated when unique IDs aren't provided in one application.
As you move toward implementing an EAI solution, you should be aware that the benefits of EAI aren't automatically realized by the use of EAI tools. Effective use of EAI requires the appropriate approach and business infrastructure:
- Understand the applications to be integrated along with the number of interfaces involved.
- Know which departments own the applications and seek executive support for the integration.
- Understand the information to be exchanged and how this information is used in each application.
- Evaluate the effort and risks when finalizing enterprise definitions and identify key executives as owners and mediators of the process.
Architectural guidelines
Given the above description of EAI and how to implement it, the next question might be: When should you use it in an enterprise architecture? The answer is: Not always.
When the integration requirements can be solved using only data movement and/or replication, the database-to-database integration approach makes sense. It's easy to implement and doesn't require additional technical expertise.
The main characteristics that would justify an EAI solution are:
- The integration involves third-party package applications.
- There is the need to transform data between different platforms.
- Business processes change quite often.
- Some kind of workflow is involved.
In such cases, message broker-based solutions should be considered.
Counterindicators would include the following:
- The source code of both source and target application is accessible.
- Integration doesn't involve third-party package applications.
- You need to integrate very few applications.
- You do not see the need to integrate more applications in the future.
You can bring in different message broker packages for evaluation, but you should decide on one package to implement as your enterprise EAI backbone. If you allow one department to implement its own EAI backbone you'll have to integrate the various EAI packages at a later date -- which should be avoided. Keep in mind that point-to-point integration and database-to-database integration are acceptable short-term solutions; when you architect these solutions, do so with the understanding that they'll probably be replaced by a more complete package later on.
Future trend
As more companies move to exchange information between business partners, the need for a common definition of information will increase. Business processes must be more integrated, both within and between companies, to achieve a competitive advantage. Companies that do this first will gain marketshare. A major limit to a business-process focus is the business-function focus of existing applications. Business-function-focused applications are turned into business-process-focused applications by integrating them along business-process lines, both within and across companies. So, high volumes of integration become a strategic business necessity. EAI packages make it possible to achieve this integration much more quickly than you could with "old style" integration. EAI solutions that include XML, in particular, are likely to enable cross-business integration. This is why numerous vendors have made public commitments to support XML in future product releases.
According to the Gartner Group's Gartner Research Note, by year-end 2000, 75% of Fortune 500 companies will be using XML in at least one prototype application integration project and 25% will be using XML in a production application integration project (0.7 probability). Support of XML in products will be an important factor in deciding which middleware you choose.
Conclusion
There are real business benefits to be gained from using brokered EAI software packages, as follows:
- Faster time-to-market for new products through an automated information flow.
- Increased efficiency due to consistent, accurate information available in realtime.
- Improved customer responsiveness due to automated self-service applications.
- Lower cost of operations due to streamlined infrastructure of e-business channels.
- Reduced cost and complexity compared to custom point-to-point integration.
There are also a number of architectural benefits to be gained by using message brokers to do large-scale application integration. The method replaces many point-to-point connections with a reliable, scalable solution that can more easily adapt to changes over time. The flexibility of the publish-and-subscribe paradigm used in many EAI systems decouples applications, allowing them to change independently.
EAI emphasizes the need for a common definition of information between applications. You should always keep in mind that the greatest problems in an EAI implementation arise from difficulties in ownership and meaning of business rules and data, not from the technology.
- ActiveWorks message broker middleware:
http://www.activesw.com/ - BusinessWare message broker middleware:
http://www.vitria.com - CrossWorlds software suite:
http://www.crossworlds.com/home.html - MQSeries middleware:
http://www.software.ibm.com/ts/mqseries/ - MQSeries Integrator:
http://www.software.ibm.com/ts/mqseries/integrator/
This story, "Enterprise application integration -- message broker style" was originally published by ITworld.