A MODEL FOR ENTERPRISE APPLICATION INTEGRATION TOOLS EVALUATION

Please download to get full document.

View again

of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Magazines/Newspapers

Published:

Views: 0 | Pages: 8

Extension: PDF | Download: 0

Share
Related documents
Description
A MODEL FOR ENTERPRISE APPLICATION INTEGRATION TOOLS EVALUATION Rafael Silveira, Information Systems and Software Engineering Research Group, UPC - Technical University of Catalonia, Spain
Transcript
A MODEL FOR ENTERPRISE APPLICATION INTEGRATION TOOLS EVALUATION Rafael Silveira, Information Systems and Software Engineering Research Group, UPC - Technical University of Catalonia, Spain Joan A. Pastor, Information Systems and Software Engineering Research Group, UPC - Technical University of Catalonia, Spain Abstract Many enterprises around the world attempt to satisfy new integration functionality requirements. These are originated by issues such as the use of legacy systems and heterogeneous technologies, high communication development through the Internet that increases the business between enterprise and enterprise consumer, dynamics of business groups nowadays such as join ventures, organizational merges and takeovers. To carry out these requirements, enterprises have chosen to reconsider and eventually reprogram their computer applications, to implement other enterprise packages or to integrate disparate information systems via Enterprise Application Integration (EAI) projects. Factors such as the high cost in the development of new applications, strong trust on legacy systems, and the need to quickly integrate disparate information systems have made the decision of implementing EAI projects more attractive. The adoption and acquisition of EAI tools are often the starting point in any EAI project and the success of these are some keys for the overall project success. This paper provides a quality model for EAI tools evaluation that contributes to identify quality criteria, which can be useful in the evaluation and selection processes that an enterprise must make to decide which EAI tools are most suitable to implement. Keywords: EAI, EAI tools evaluation, Enterprise Application Integration. 1 INTRODUCTION Enterprise Application Integration (hereinafter, EAI) is defined as the unrestricted sharing of information between two or more enterprise applications. A set of technologies that allow the movement and exchange of information between different applications and business processes within and between organisations (Linthicum, 1999) For enterprises that decide to apply an EAI strategy, a new generation of software tools that attempt to offer solutions to enterprise applications and business process integration have emerged in the last years. With the growing number different EAI tools on the market also emerges the need to study and define processes for the adoption and acquisition of those EAI tools more suitable for the requirements of each enterprise and project. As EAI is a recent area of investigation and the EAI tools have a short history, the literature about EAI tools procurement is scarce. On the opposite, since more and more enterprises have the need to integrate their information systems, the most important software vendors of the market have begun to offer integration tools. Therefore, a scene appears where, on the one side there are enterprises with its integration problems and little academic knowledge in the area, and on the other side, there is a marketplace extremely complex with a diversity of EAI technologies and tools solving different kinds of problems (Themistocleous, 2004). In this paper we propose a quality model for EAI tools evaluation, circumscribed in an initial research about EAI solution procurement. This model allows for the evaluation of different tools available in 1 the marketplace, thus, the enterprise will be able to justify the selection of the best solution in terms of its fulfilment of the integration needs required by the business and its technological infrastructure. 2 EAI AND EAI TOOLS Below we present in Figure 1 an UML diagram where we describe the different types of enterprise applications that conforms the context of our study. To elaborate this model we took as reference the taxonomy proposed by Themistocleous and Irani (2002), where application integration is classified in three groups: inter-organizational application integration, intra-organizational integration and hybrid application integration. The integration of applications through different enterprises is referred to as inter-organizational application integration, attempting to integrate business processes between enterprises (B2B), such as Supply Chain Management systems (SCMs), or electronic purchasing processes (e-procurement). Intra-organizational application integration refers to the integration of applications within one single enterprise, and it attempts to integrate usually custom applications and packaged systems. While custom applications were designed with the purpose of solving some specific problem within an area of the enterprise (functional area or department, business process, etc.), most packages are based on requirements and generic business processes. Among custom applications there are legacy systems and among enterprise packages there are enterprise resources planning systems (ERPs), customer relationship management systems (CRMs) and geographic information system (GISs). Other more recent custom applications within an enterprise are electronic commerce applications between enterprises and consumers (B2C); in some cases, these applications can be considered interorganizational applications when they include services provided by applications of other organizations, such as electronic payment services (e-payment) from banks or credit card companies. EAI {overlapping,complete} Intra-Organizational EAI Inter-Organizational EAI {disjoint,complete} {disjoint,complete} Packaged systems Custom applications B2B ERP CRM SIG Legacy systems B2C Loose integration Tight integration Supply Chain e-procurement Figure 1. EAI Taxonomy In the market there is a diversity of EAI tools that combine different technologies from integration like adapters, Application Programming Interface (APIs), message brokers, web services, screen wrappers, or XML-based integration systems. The tools focused on intra-organization integration are based on the so called middleware technologies; these are connectivity technologies that help the applications to abstract the complexity and heterogeneity of the communication networks, as well as the operating systems and the 2 programming languages. EAI tools go beyond middleware, since they offer additional functionalities over the inferior levels of messages services transport and the translation services. Most of the EAI vendors are taking the responsibility of predefining libraries or templates that connect, for instance, an ERP package like SAP with a CRM package like Clarify. When any of these packages are upgraded with a new version, the EAI vendor must provide a new version of his libraries that assures the continuity of integration between these two packages. Table 1 shows a list of the main tools vendors that propose to solve different problems of enterprise applications integration. Vendors EAI Tools Microsoft BizTalk Server 2004 IBM WebSphere MQ BEA Systems BEA WebLogic Oracle Oracle Fusion Middleware TIBCO TIBCO BusinessWorks, TIBCO BusinessWorks SmartMapper and TIBCO Adapters Table 1. EAI Tools 3 PRIOR RESEARCH AND NATURE OF EAI TOOLS EVALUATION Puschmann and Alt (2001), by means of a case study, illustrate an example of the problems arising when a company decides to select a set of EAI tools to integrate systems, ERP, SCM, CRM, e- commerce, and legacy systems. To choose the tools that are most suitable to the reality of the studied enterprise, they used four types of selection criteria: Integrated vs. toolkit application, tightly vs. loosly coupling, individual vs. standard applications integration, intra- vs. Inter-organizational integration. Themistocleous and Irani (2003), also through the study of a real case, extend the frameworks proposed by Puschmann and Alt (2001) and Ring and Ward-Dutton (1999) by adding as evaluation criteria the consideration of the technologies used by EAI tools in each layer of integration. Losavio, Ortega and Perez (2003) establish a correspondence between the definitions of standard ISO and the terminology used in the description of the quality service provided by middleware. While the classic applications are constructed based on concrete business requirements, EAI tools must be built by also thinking about technical requirements, depending on the different technologies used by the enterprise. EAI tools attempt to connect the great amount of different types of software products and to maintain this functional integration in spite of the independent evolution that these products have. While acquiring a single business application depends on the evaluation of its own characteristics and the functional needs of the enterprise, including integration needs, the acquisition of an EAI tool does not only depends on the evaluation of its characteristics, this acquisition is highly constrained by the technologies and the characteristics of the enterprise applications that the organization has implemented. 4 A QUALITY MODEL FOR EAI TOOLS EVALUATION 4.1 Research methodology Figure 2 shows the research process that we have followed. The first step in this investigation was the extensive literature review related to the EAI area (publication pending). In that review we identified research issues where publications were scarce, and EAI tools evaluation is one of the issues least 3 explored. This paper is the result of the study of literature about EAI tool evaluation and our team experience of software selection by using and extending the standard ISO for other types of information systems and technologies. We aim at a validation model through of one or several case studies, while result analysis is also part of our further work. EAI literature review Identify research issues Study EAI tool evaluation Develop model Validation model Results Analysis Figure 2. Research methodology 4.2 Quality model Following prior research by our group and others about software selection processes, we propose the construction of a quality model for EAI tools evaluation. As in other cases, we have developed a model based on the norm ISO/IEC We have considered a series of inherent characteristics within EAI tools that help in the evaluation and selection of one or several tools that compose the best integration solution for a certain enterprise. For the construction of this model we have classified the evaluation criteria along the mentioned categories of Puschmann and Alt (2001) and Themistocleous and Irani (2003). From them we have derived a set of characteristics and sub-characteristics of the specialized ISO/IEC model and we have added additional new criteria to be considered outside the scope of those categories. The ISO/IEC based quality model is divided in six characteristics: reliability, functionality, usability, efficiency, maintainability and portability. Table 2 presents the criteria proposed to evaluate the reliability of the tool, where one of the subcharacteristics is the maturity of the tool which has to have a special care due to the short history of EAI tools. Maturity Evaluates the history of the EAI tool: Time in the market, quantity of versions, and patches for version, detection, publication and correction of errors. Evaluates the degree of the EAI tool operational robustness: average time between failures, average time of repair of failures. Fault tolerance Evaluates the degree of transparency when the EAI tool has a failure (automatic correction of the error). Evaluate the degree of tolerance (maximum number of attempts in the processes execution, average time between attempts) Recoverability Evaluates if the EAI tool supports backup and restore of workflows transactions. Evaluates if the EAI tool allows the system recovery. Table 2. Reliability characteristic 4 The functional characteristics are shown in table 3 and within these the suitability criteria that usually are the most important. We have classified these criteria by integration layer. Sub characteristics Suita Process bility layer Table 3. Functionality characteristic Efficiency criteria are shown in table 4, and they may be used to evaluate the required resources and the levels of performance offered by the tool. Table 4. Translation layer Transporta tion layer Connectivi ty layer Criteria description Evaluates if the EAI tool has suitable process services for Inter-organizations applications integrations. Evaluates if the EAI tool has suitable process services for Intra-organizations applications integrations. Evaluates if the EAI tool offers a suitable toolkit for the developed of workflows. Evaluates if the EAI tool supports integration technologies such as: Message Broker, Web Services, etc. Evaluates if the EAI tool has suitable translation services for legacy systems (IBM CICS, DB2, Siemens BS2000, etc.) Evaluates if the EAI tool has suitable translation services for standard business applications (SAP R/3, Oracle, etc.). Evaluates if the EAI tool offers a suitable toolkit for the developed of adapters. Evaluates if the EAI tool supports integration technologies such as: Adapters, Message Broker, and Screen wrapper. Evaluates if the EAI tool supports integration technologies such as: TPM (Transaction Processing Monitor Technology), MOM (Message-Oriented Middleware), ORB (Object Request Brokers), RPC (Remote Procedure Call). Evaluates if the EAI tool has suitable connectivity services for asynchronous data integration. Evaluates if the EAI tool has suitable connectivity services for synchronous data integration. Evaluates if the EAI tool supports integration technologies such as: ODBC (Open Database Connectivity), JDBC (Java Database Connectivity), CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model)/COM (Component Object Model), EJB (Enterprise JavaBeans). Accuracy Evaluates if the EAI tool provides accuracy services that allow confirming the reception or the send of data between applications and logs by transactions or events. Evaluates if there exists knowledge of results of own tests or tests published by third parties that indicate us the degree of effectiveness of the EAI tool. Interoperability Evaluates the capacity to interact with other EAI tools that are being used in other layers of integration or with systems of EAI in other organizations. Security Evaluates if the EAI tool has integrated access control of applications. Evaluates if the EAI tool has data transmission security. Evaluates if the EAI tool has systems of certification. Functionality compliance If the EAI tool supports standards such as: SWIFT, ebxml, UN/EDIFACT, XML. Time behaviour Evaluates the average response time, load balancing, message processing efficiency, multiprocess support. Resource Evaluates hardware resources required for EAI tool. utilisation Evaluates software resources required for EAI tool. Evaluates human resources required for the management of the EAI tool. Efficiency characteristic 5 Usability of the tool can be evaluated on the basis of the criteria shown in the table 5, in which operability and learnability can be emphasized. The first indicates if the tool facilitates the tasks of the developers and the second evaluates the training offered by vendors. Understandability Evaluates the level of understanding of the interfaces (standard graphical communication, predictability, support for different languages and characters set) Learnability Evaluates if vendor or third party offer training for EAI tool. Evaluates if the EAI tool has documentation online and tutorials. Evaluates if the EAI vendor has support to consumer for the EAI tool. Operability Evaluates if the EAI tool has graphical tools that facilitate the development of adapters. Evaluates if the EAI tool has graphical tools that facilitate the development of orchestrations. Evaluates if the EAI tool has graphical tools that facilitate the management of the security. Evaluates if the EAI tool has graphical tools for the system configuration (management of resources, management of messages between applications, management of ports and communication channels between applications). Attractiveness Evaluates if the EAI tool has attractive graphical design. Table 5. Usability characteristic Table 6 shows maintainability criteria, in where it is evaluated if the tool supports the deployment of components without stopping current and ongoing services. Analysability Evaluates the capacity of the EAI tool to diagnose deficiencies or failures causes in the integrations processes. Changeability Evaluates if the EAI tool supports modification of the processes without stopping the services. Evaluates if the EAI tool supports modification of processes without losing initiated and not finalized transactions. Evaluates if the EAI tool supports the update of the different integration components without stopping the services. Stability Evaluates if the EAI tool avoids unexpected effects caused by the updates of the system. Testability Evaluates if the EAI tool offers a toolkit for stress tests. Evaluates if the EAI tool offers a toolkit for trace of transactions and messages. Table 6. Maintainability characteristic Finally, table 7 describes the criteria of portability, which among other points, evaluates the capacity of the tool to coexist with other EAI tools. This can be important in cases where de EAI solution is composed by more than one EAI tool. 6 Adaptability Evaluates the capacity of the EAI tool to be adapted to different specified environments. Installability Evaluates the capacity of the EAI tool to be installed in a specified environment. Evaluates if the vendor has technical support and help online for the installation of the EAI tool. Evaluates if the EAI tool has documentation published for the installation and configuration of the tool. Co-existence Evaluates the capacity of the EAI tool to coexist with other independent EAI tool in a common environment sharing common resources. For example, other EAI tool can be installed in other layers of integration or in the same layer but for satisfy other kind of requirements. Replaceability Evaluates the capacity of the EAI tool to be used in place of another specified EAI tool for the same purpose in the same environment. Table 7. Portability characteristic In summary, based on the published case studies and on common sense, we may say that criteria classified within the functionality characteristic seem to be the most important in the tool selection. Among these we can highlight the suitability of the tool in each one of the integration layers, the interoperability with other EAI tools, and if it supports the technologies standards used by the enterprise. However, to obtain the best results we cannot forget the non-functional evaluation criteria, such as the average response times, that will be able to indicate the degree of efficiency of the tool, the degree of maturity, the solutions given by the vendors when new versions of standard integrated applications appear, supports given by the vendors and their partners to train technicians that manage and maintain the system, and if the distribution of new versions of components or integration processes affects the temporary availability of the services offered by the system. 5 CONCLUSIONS AND FURTHER WORK The selection of suitable integration tools is not a small problem; it is a critical factor for the success of EAI projects. This paper proposes an initial model that contributes to identify and organize quality criteria for such an important task, which can be useful in the selection processes that an enterprise must make to decide which EAI tools are best suitable to implement. The model was developed from a well-known quality norm and by considering real situations and empirical data derived from several case studies. The main advantage of this model is that it was built on base of a standard widely recognized and proven as a basis for software evaluation proposals, which was fed with e
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x