EAI backround Organisations rarely have a single approach to implementing systems. Applications to be integrated are usually developed and executed in different technologies, some of them built in house, others acquired. Developers that are implementing new applications face a bewildering array of programming languages, interfaces, protocols and technologies that must be integrated. Some of these are: Common business infrastructure or back-office packages (ERP, human resource, financial management, etc); Front-office packages (customer relationship management, sales order processing, etc); Legacy applications (portfolio of existing applications built in-house); Newly built applications or 'off the self' packages; Third party services (information sources held or performed by third parties such as for example catalogue information, credit ratings, etc.) Lack of common architecturesThe root cause of the problem that arises in Application Integration is the lack of common architectures. Whilst it is usual to apply a single architecture and set of standards to an application, it is less common to find different applications conforming to the same set, even within the same company. Also acquired applications tend to have different standards and are more likely to be incompatible with in-house applications. Architectures and standards apply at different levels. Out of all the integration layers, the business architecture is the most challenging for integration. Insisting for example that all applications have Microsoft COM interfaces might remove the technology barriers to application integration but on its own it is not enough to reconcile the fact that one application (for example) considers currency information as an attribute of the invoice, while another maintains it as a separate entity. Integration issuesApplication integration is more complex that seems to be at first thought. The following highlights some of the considerations that must be made in integration tasks: What are the differences in interfaces, protocols? Are there differences in the platform technologies used? How are messages and data formatted? Are the data structures similar? What event triggers the action, when and how is it invoked? How are messages delivered? What guarantees of delivery are required? Is real time transaction integrity needed? Is two phase commit needed? Is it to be Web enabled? Are the business concepts the same?
EAI backround Organisations rarely have a single approach to implementing systems. Applications to be integrated are usually developed and executed in different technologies, some of them built in house, others acquired. Developers that are implementing new applications face a bewildering array of programming languages, interfaces, protocols and technologies that must be integrated. Some of these are:
Lack of common architecturesThe root cause of the problem that arises in Application Integration is the lack of common architectures. Whilst it is usual to apply a single architecture and set of standards to an application, it is less common to find different applications conforming to the same set, even within the same company.
Also acquired applications tend to have different standards and are more likely to be incompatible with in-house applications. Architectures and standards apply at different levels. Out of all the integration layers, the business architecture is the most challenging for integration. Insisting for example that all applications have Microsoft COM interfaces might remove the technology barriers to application integration but on its own it is not enough to reconcile the fact that one application (for example) considers currency information as an attribute of the invoice, while another maintains it as a separate entity.
Integration issuesApplication integration is more complex that seems to be at first thought. The following highlights some of the considerations that must be made in integration tasks: