The following illustrates selected aspects of the procedure for the implementation of an EAI solution. The below remarks reflect both our own experiences, gained on the basis of the solution presented in the previous section with regard to its architecture, and also information from the literature. An essential requirement for the successful implementation of an EAI solution is the establishment of a corresponding project benefiting from comprehensive support from the management. ([Juric 2001] p.62) presents this as follows:
The primary tasks of such a project lie in the establishment of a suitable integration architecture, the selection/use of suitable technologies for integration and specification, and, in general, the documentation of integration. The last-mentioned aspect, in particular, calls for cooperation between the development departments responsible for the applications which are to be integrated, those responsible for the business processes (including the vision of what is to be achieved on the planning horizon) as well as the later users of the applications. The procedure for the integration of existing applications can be either of the bottom up or top down type. The bottom up procedure is more of a pragmatic approach which attempts to derive the interactions between the integrated systems from the communications needs of the individual systems. This approach leads relatively quickly to corresponding results, but it harbours the risk that requirements from the overall business process may not be covered. The top down approach derives the integration needs from the business processes lying above the individual applications. The last-mentioned approach, in particular, appears best suited for optimally meeting the needs of customers, but it also implies that the underlying applications may have to be adapted, something which, ultimately, raises the cost of integration. Furthermore, this approach is burdened by negative experiences from past decades, in which the development of company data models/company business models was difficult to map to the underlying system landscape. Figure 1: Procedure for the Implementation of an EAI Solution In our experience, it has proved worthwhile to combine both approaches. At the beginning of an integration project, the bottom up approach should predominate, while, as the integration project progresses, the top down approach should take over. This makes it possible successively to attain the next-higher level of integration and to reduce the complexity of the integration project (of a version). The principal levels of integration can be classified as follows:
Apart from these levels, it is also necessary to include the user interface (presentation level EAI) in the considerations. Once again, a gradual approach with the mapping of smaller functionalities, such as the use of portal technology, standardized web-based user access, the implementation of multi-channel capability through to content management, appears promising. The following provides a brief explanation of what we consider to be the essential phases of an integration project, use being made of experiences gained from the EAI solution presented in the following section: Business processes: When documenting the business processes, it is necessary to record the process-related organization of a company. Typically, this process is carried out in several abstraction phases, with the result that it is possible to navigate from a top level view to the detailed business processes. The business processes should provide a holistic view of a specific company, in which, usually, only selected processes are supported by corresponding software systems. Various notations can be employed within the modelling of the business processes. Examples are simple flow diagrams, event-controlled process chains (or EPCs for short) or the use of UML use cases. Requirements: Within the framework of the requirements analysis it is necessary to identify specific players, i.e. initiators of an interaction within the EAI solution. In the optimal case, the players should be able to be derived directly from the business processes. In reality, however, corresponding interrelationships are frequently lost owing to insufficient detailing of the business processes. A distinction must be made between the requirements to be met by the applications which are to be integrated, and the therefrom resulting requirements to be met by the integration overlaying those applications. The requirements can be modelled, for example, by UML use case diagrams, which can indicate interrelationships between the players and the use cases and which provide an external view of integration. Identification of interactions: In practice, it has proved worthwhile to use several abstraction stages for the modelling/specification of the integration. In the case of the top down approach, the analyzed requirements (e.g. use cases) are used to derive the corresponding interactions while taking account of the possibilities of the systems which are to be integrated. For the documentation of these interactions, it has proved worthwhile to use UML sequence/interaction diagrams. These diagrams indicate the chronological sequence of the exchange of messages between the applications which need to be taken into consideration within integration. These diagrams should include both performance requirements (as constraints) and also information on the communication load profile (as annotation). Detailing of data and functions: For each identified interaction, it is necessary, using e.g. simple tables, to record the attributes to be transmitted, the data types used, quantities schemes as well as potential routing and mapping requirements. The functional characteristics can be recorded by means of state diagrams, wherein the arrival of a message can be viewed as an event which triggers a state transition within the application in question. Interface specification: The interface specification lays down the sequence and semantics of the data to be transmitted. Also required is information for the control of communication, which is typically transmitted in front of the user data in the form of standardized header information. It has proved practical here to use a standardized specification, such as XML. XML permits the use of a standardized and self-describing message format. To guarantee the traceability of the executed interactions, all messages which pass the CIB must contain a so-called CIB header. Figure 5 shows the schema specification of this header. The header information controls the logic of the integration application and is stored in the form of a history within the reference database. Consequently, these data can provide information on the status of the particular transaction and the state of the workflow or process. Architecture and implementation: The tasks of this phase relate to the design of the integration architecture, the implementation/configuration of the technologies used (e.g. EJBs, database, application server, Web application, message bus), the performance of corresponding test activities and the preparation of introduction. The vision of "configuring instead of implementing" should be pursued when an EAI solution is being developed. New requirements or the integration of further applications should be able to be performed without changes to those applications which have already been integrated. Although, in the early stages of development of an EAI solution, it is possible to use technical interfaces, such as database links, these should be gradually replaced by standardized and self-describing interfaces, so as to be able to satisfy the initially described requirement of configuring. In addition to the already presented aspects, it is in particular the iterative procedure and the use of the "time boxing" process (limitation of development times and demand for a defined output) which result in a successful EAI project. References: [Juric 2001] Juric, M. B.; Basha, S. J.; Leader, R.; Nagappan, R.: Professional J2EE EAI. Wrox Press Ltd., Birmingham/UK |