Applications Software Integration Architecture and ...



Criteria Based Software Product Integration Architecture

Frank Tsui

Southern Polytechnic State University

1.0 Introduction:

Various software architectural connectors [1,2,3,4] have been proposed for creating new products by coupling existing components. The software engineers can no longer stay within a self contained single architecture but will need the aid of these software connectors, preferably commercially available ones [5], to develop an integrated software product. In a global, commercial environment, a product family is often created through integrating disparate, existing products through various partnerships; thus a broader set of criteria beyond just connectors must be considered. In this paper a set of criteria is first introduced. Then a multi-leveled product integration architecture, in terms of the set of criteria, is discussed. The need for software connectors becomes evident as software products are integrated at higher levels of the integration architecture. The perspective presented here is one that champions the users’ and customers’ need for an integrated product family, not just a developers’ view of product integration.

2.0 Criteria and Rationale for Software Product Integration Architecture:

In today’s fast pace software industry and industry domain specialization, many of the software enterprises are forming global partnerships from simple sales alliances all the way to product line and business integration [6,7]. When the relationship of two software enterprises is to just perform cross-sales of each other’s software products, the software engineers of the two enterprises are not heavily involved. The product support personnel, however, will often face questions that touch on the various incompatibilities of the two “integrated” software products that were built under different architectural designs.

When two or more enterprises extends their relationships beyond just cross-sales, the software engineers and the issue of architectural compatibility and integration are now brought into play. Depending on the degree of partnerships, the following issues concerning the integration of two or more different software products will start to emerge.

1. terminology

2. packaging and delivery

3. aspects of applications’ user interface

4. products’ manuals and user guides

5. application components and functions

6. application flow and control

7. data stored, processed, and shared

8. systems, subsystems, and middleware platforms

9. support and maintenance

10. internationalization

These issues are considered by the software engineers when they are building their single product line. However, when faced with partnership formation based on business and marketing reasons, these same topics requires a clearer framework for software products integration. This set of issues may serve as the criteria upon which a framework for product integration architecture may be built. Without some framework of software integration architecture, the software engineers on both sides of the partnership are left with potentially a mismatch of interests and thus a high potential of non-integrated product family. The users and customers are usually left bearing the brunt of this problem. The next section will discuss an applications’ integration architecture that will help us move away from the integration of applications based on arbitrary, self interests of the partners.

3.0 A Software Product Integration Architecture:

In this section, a multi-leveled applications’ integration architecture is introduced. It is important to point out that many of the proposed integration of software applications are done after these products have independently showed success in their subject domain. An example would be a customer relations management (CRM) application that will be merged with a manufacturing application to form an enterprise resource planning (ERP) application.

While, in general, one is guided by the design principles of loose coupling and strong cohesion [8,9], the applicability of these principles will differ depending on the specific criterion under consideration of integration. At each level of integration, the items under consideration may be totally decoupled to tightly coupled. Similarly, the item under consideration may be non-cohesive to strongly cohesive. At the heart of applications integration architecture, is the desire to have the users feel that the different products are, in fact, from one product family. Criteria based, four-level software product integration, as shown in figure 1, is proposed.

[pic]

3.1 Co-Existence Level Integration:

At the lowest level of applications integration architecture is co-existence. In the co-existence stage, two different software applications are totally decoupled. The co-existence level of applications integration architecture addresses the rules of integration for the three areas:

- packaging and delivery,

- system, subsystem, and middleware platforms and

- internationalization.

First criterion is the packaging and delivery area. The two different products must be packaged together on a CD or in a downloadable file. There is a single medium of packaging and delivery, even though the contents are two separate sets of material (e.g. code, screens, text, etc.). When the products are packaged and delivered together it will provide an appearance of a single product family. The second area of integration is that the two different software applications must run under the same system platforms. That is, the applications systems and tools pre-requisites must be the same for the application products. For example, both applications utilize the same database sub-system, the same operating system, the same communications sub-system, and the same presentation sub-system such as the same web browser. This second criterion may seem a bit stringent and excludes the scenario of integrating an application running on a server system and another application running on a client system with totally different platforms. Relaxing this second criterion of common platform will be discussed later in the intermediate and strong levels of integration. At the co-existence level of integration, the platform pre-requisites are required to be the same. The third area is that both of the applications software must be of the same country language version. With today’s global economy, partnerships are formed across international enterprises. An English accounting application may run on the same platform as the Spanish retail application. However, it is highly unlikely that these two applications may be used by the same set of users except for those unique environments where the retail applications are utilized by the Spanish speaking users and the back-office accounting applications are utilized by the English speaking accountants. This third criterion may be relaxed for special environments. Otherwise, the two applications must be of the same language and internationalized version, whether it is English, Spanish, Japanese, French or some other language.

The rules for the three criteria are fairly straight forward. The applications must be of the same file format and delivered together so that they may be read and installed in the same fashion. The internalization criteria enforces that the application presents the same language version to accommodate for a uniform user or customer environment. The system, sub-system, and middleware platform commonality rule will ensure that the pre-requisites of the applications enforces no duplication of subsystems such as two similar, but different, databases.

3.2 Low Level Integration:

The software enterprises may present a higher level of integration to their users and customers by further integrating the major interfaces to those users beyond the co-existence level. The focus at this level is to present a more cohesive interface to the users. At the low level of integration, the applications continue to remain totally decoupled as in the co-existence level. In low level integration, the partnering enterprises need to consider four more criteria in addition to those described in the co-existence level.

- terminology

- applications’ user interface

- product manuals

- product support and maintenance

The first of the four is the terminology integration. The words, phrases, and icons used need to be the same and carry the same semantics. Note that even within the same language version such as in English, the term, error, and the term, problem, are often utilized interchangeably. If they represent the same concept, the two terms should be reconciled to one common term. The software products should utilize the same term to mean the same thing. This is not a difficult request if the two software products are initially designed together. It is very difficult to achieve when the products are already released to users who are just becoming acquainted and comfortable with the terms. One potential rule of integration is as follows. The software product with the larger user set will dictate the term conformity. A dictionary of vital, subject matter terms needs to be created, and the translation of terms needs to be performed on the software product with lesser user set to conform to that which has more users.

The next criterion is the actual user interface integration. There are several aspects to application user interface. The main concern at the low-level product integration is the looks. The user screens and the icons contained within the software products need to have a common look. Once again, this rule is not very difficult to enforce at the architecture and design steps of the software development cycle. However, for two successfully released products to be integrated with a common look is going to require one of them to change. The rule of integration may be the same as the one utilized above for common terminology.

The third criterion touches on the product manuals. These manuals should be similar in content and flow. For example, if one product manuals have table of contents, then the other should also have that. If one contains screen shots as part of the user example, then so should the other. Thus the manuals may have to be modified. If one product has manuals in English and Spanish, then so should the other. It is possible that two software products are both in only English version but have English and French user manuals. In a global economy, it is very plausible for a U.S. software enterprise to partnership with a Canadian software enterprise to jointly develop and market a software product family for customers in a dual-language speaking city of Montreal.

The fourth criterion at the low level of integration is to offer a common user support and maintenance interface. The two software products may internally have geographically separate groups of support staff. But to the users and customers, the products need to present a common product family support structure. Here, the rules of integration include at least a single support phone number or a single web-enabled, online support URL. The user may be directed to a different support staff organization once the initial gathering of the user information and problem description is complete. In order to present an integrated support interface, the product support organizations need to utilize the same call management system and problem resolution mechanisms. The problem fix and release policies for both products must be the same. For example, a high severity problem such as a problem that comprises the database is classified as a high severity problem and has a 24 hour turn around policy for both products. The policy for the cycle of releasing low severity problem fixes must also be consistent across the products within the product family.

The low-level product integration is focused on presenting a better interface to the users such that they will feel that the integrated products form a single family of products, even though they may have originated from different software enterprises. This is the level where product family cohesion starts to be emphasized

3.3 Intermediate Integration:

Further emphasis on presenting a cohesive product family to the users is emphasized at the intermediate level. The applications will be coupled through two areas:

- data stored, processed, and shared and

- application flow and control.

The applications are no longer decoupled as in the co-existence level and as in the low level. While each level of integration is built upon the previous level, one earlier criterion is relaxed at the intermediate level. That is, the two applications may reside on differing platforms and may have different system and subsystem pre-requisites. This criterion may be relaxed due to the introduction of applications coupling through data and control flow. The partnering enterprises need to consider two additional criteria and revisit one of the earlier criteria.

The coupling of data stored, processed, and shared is one of the criterion that is introduced at the intermediate level. The rule for integration is that shared data in the common database must allow both applications to access those data elements. This will require the applications to utilize common data element names and/or develop some data access connectors [4] to access the shared data in the common data base. For those data that reside on different databases, there must be some stream connectors [4] developed across the applications to transfer large amount of data or data access connectors for the two different applications to access each others databases. This criterion is quite complex whether it is imposed at the initial architecture and design time or at a post release time. However, it is probably more difficult to develop the connectors afterwards.

The second criterion is the integration of application flow and control. The integrating applications may transfer control among each other. The rule of integration is that there will never be a transfer of control that results in an error that will require the users to restart the system. Once again, software connectors [3,4] will be needed. The chance of these partnership applications needing a slew of software connectors is very high; for these are most likely post released applications.

The earlier criterion of common system and subsystem platforms is relaxed at the intermediate integration level. Decoupled applications residing on different platforms present the users with a relatively limited product family cohesion. In order to provide more product family cohesion, coupling among applications is introduced through the two additional criteria of data and of control flow.

3.4 Strong Integration:

This is the most robust level of integration. In addition to the criteria considered in all the earlier levels, the integration of applications’ components and functions is considered. The rule of integrating components and functions is more complex.

First consider a group of common functions such as the error and message processing function or the user help function. These must operate the same way across the applications integrated into an application family. For example, the users’ experience with handling a warning or an error message should be the same across the applications. Similarly, the level of help functions must be uniform. For example, if defaults are provided for input fields, then that feature must be uniform across the application family. This level of application integration may require some complex, fundamental changes if the original applications were not built with architectures that allow modifications and decoupling of these common functions within each application. Architecture connectors are of no help in this situation. On the other hand, for example, if the error processing functions are all designed and localized within a single component, then the modification or even complete replacement of the component is not as difficult. It may still be time consuming, though.

The second consideration addresses the group of different functions. Most of the partnerships are struck up because it is envisioned that the integration of these different, but complementing, functions in the two applications will provide more powerful domain coverage. The integration consideration is that if a particular function is offered by only one of the applications, then that unique function is integrated into the product family. If a module contains only that one function, then the integration process is considerably simplified. If the module contains several, but only the unique functions, then that module is integrated into the family. However, if the module contains some other functions that should not be integrated, then this module needs to be transformed and made into a more cohesive, single function module before integration. There are also cases where the function has duplicative coverage in both applications. Then a decision must be made to integrate only one into the product family. This rule is important not only for presenting a cohesive product family to the users, but also alleviates the product support effort when a functional problem is reported by a user. A further consideration is that in the global economy, one application may already be translated into multiple languages. The integrated functions from an application that has not been translated need to be translated so that the same product family may be presented to the supported set of countries.

In order to manage the integration of application components and functions across multiple internationalized versions, one would not only need software linkage connectors and adaptor connectors [3,4,5] but must also have a sophisticated system build mechanism. An automated configuration management system tool that allows one to uniquely label every version of every module in the partner-shipped applications would greatly aid this level of integration.

4.0 Concluding Remarks:

In this paper we have first proposed a set of criteria. Then a multi-leveled product integration architecture based on this set of criteria is proposed for applications that are brought together due to business partnerships. These domain specific applications are often successful products that already have users. Many of the integrations of applications, as a result of corporate merger and acquisition, are often performed without clear definitions, resulting in user confusion and dissatisfaction. Many times the user interface, along with packaging, is picked as the first level of integration. Then different aspects are picked for integration based on availability of funds or customer complains. This haphazard approach has lead many commercial software products to become very difficult to maintain. The proposed integration architecture moves the individual applications from decoupled and separately cohesive situation to a coupled and product family-wise cohesive condition. We have tried this proposed integration architecture on a well known ERP software and have experienced wide customer appreciation. An additional benefit we experienced with a clearly defined integration architecture was that the software partners, who develop add-on software, were able to follow and define their integration commitments. While the set of criteria and the levels of integration may change, a criteria based multi-leveled software product integration architecture is needed to provide some guideline to both the partnering software enterprises and their users.

In the future, we are investigating other sets of criteria for integrating software. We are also investigating metrics for success of integration architecture with commercial software organizations.

5.0 References:

1. Spitznagel, B. and Garlan, D., “A Compositional Approach for Constructing Connectors,” Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA 2001), 2001.

2. Lopes,A., Wermelinger, m, and Fiadeiro, J.L., “Higher-Order Architectural Connectors,” ACM Transactions on Software Engineering and Methodology, Vol. 12, no 1, Jan. 2003, pp. 63 – 104.

3. Egyed, A., Mehta, N, and Medvidovic, N., “Software Connectors and Refinement in Family Architectures,” Proceedings of 3rd International Workshop on Development and Evolution of Software Architecture for Product Families, Las Palmas de Gran Canaria, Spain, March 2000.

4. Mehta, N.R., Medvidovic, N, and Phadke, S., “Towards a Taxonomy of Software Connectors,” Proceedings of the 22nd International Conference on Software Engineering, Limerick, Ireland, June, 2000.

5. Hansen, m. and Mamorski, P., “Java Connector Architecture: The future of EAI?” Business Integration, , May 15, 2001.

6. Gold-Bernstein, B., “Developing an Application Integration Architecture,” , May, 2004.

7. Oracle Application Integration Architecture, , September, 2007.

8. Allen, E.B., Khoshgoftaar, Taghi, Chen, M., Ye, "Measuring Coupling and Cohesion of Software Modules: An Information-Theory Approach," Proceedings of Seventh International Software Metrics Symposium (METRICS'01),  2001

9. Tsui. F and Karam, O. , Essentials of Software Engineering, Jones and Bartlett, 2006.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download