Different types of vendor software products present their own kinds of challenges to the software designer and architect. Some products require excellent representation of the business processes they automate; others concentrate on data analysis of the business information required. EAI products touch on both issues, but have specific concerns in the following areas:
- Layers of code add to complexity.
- EAI products execute in between other systems. They introduce layers of complexity by handling retrieval, clean-up, and conversion tasks on data, functionality, and metadata stored in legacy systems. Therefore, these systems experience a high need for encapsulation of error-handling procedures and tasks performed, so that the integrity of existing systems environments is maintained, and problems are resolved quickly.
- Need for non-linear modeling techniques.
- Not specifically process-oriented, EAI products are often self-referential, and therefore can be difficult to model. Just as data warehousing employs its own style of modeling that addresses non-linear functionality in programs, the middleware-style EAI product set requires special modeling techniques. EAI modeling techniques must enable integration of data, compartmentalization of function, and accurate handling of events.
- Interfaces and metadata.
- EAI systems often generate no distinct or original data at all, providing instead the ability to manipulate data from legacy systems by providing a unified interface to those systems. UML architecture models can introduce the use of specialized classes to model these front ends.
- Customized reuse of product components.
- Performing the same function for divergent systems, EAI products lend themselves to reuse through customization of product components. Modeling architectures must supply the ability to develop and manipulate reusable components to accomplish specific tasks.