IS integration options

many other IS (Hanseth & Braa, 2001). The aggregation altogether makes up an uneasy manageable arrangement where standards are developed, replaced or excluded along with technological progress and inclusions of new components into ever-changing environments where ongoing integration and disintegration becomes normality. The later technological developments that build on the logic of an ever-evolving installed IS base includes approaches, such as Electronic Data Interchange (EDI), EAI, EI, ESB and SOA, which are expected to increase in use during the forthcoming years. These and the many other flourishing abbreviations invented and nurtured by software vendors in collaboration with the business press and integration consultants, all have specific advantages and disadvantages.

Conceptually speaking, paralleled by the ideas of specialization and responsiveness, integrated systems are systems that work together even though they never were intended to do so by relating them to each other by some kind of interface. In more practical terms, there exists a number of ways of making the systems work together. The different possibilities do not permit summarization in one or two defining sentences, but the following section attempts to account for the different approaches as described in the literature and then relates them to the business needs that they should fulfill.

2.4.1 Levels of IS integration

Theorizing the concept of IS integration, several authors have approached the subject with the conceptualization of integration possibly taking place on different infological levels (Al Mosawi et al., 2006). Doing so reveals common characteristics between specific integration solutions that may become the basis for addressing advantages and disadvantages of the specific technologies.

Several authors have made efforts to sort the creation of bonds into different categories. The identified conceptualizations are summarized in Table 2.3, which also relates the conceptualizations to each other.

The three main levels: business, application, and technology map roughly to the different levels of IS presented earlier in this chapter. In the same way as the organizational level of IS was explained, the major focus of this thesis as presented in chapter two, the business-level is where primary interest lies. Nevertheless, although the level of analysis is organizational, the underlying levels cannot be ignored (Orlikowski &

Iacono, 2001). Integration on technical and application level have consequences also on a business level.

Table 2.3 Conceptualizations of IS integration levels¹

Level Sublevel References A. Technological

Data (Linthicum, 2001; Pushman & Alt, 2001; Gerring, 2007; Star

& Ruhleder, 1996; Samtani et al., 2002) Object (Pushman & Alt, 2001; Gerring, 2007)

Function (Linthicum, 2001; Star & Ruhleder, 1996; Samtani et al., 2002)

B. Application

User interface/Presentation (Linthicum, 2001; Samtani et al., 2002) Application interface (Linthicum, 2001)

C. Business

Intra-organizational process (Pushman & Alt, 2001; Gerring, 2007; Samtani et al., 2002) Inter-organizational process (Gerring, 2007)

Integration on a technical level can be made either through integration of data, objects, or function. Data integration implies the migration of data between multiple data sources. The shared data can be used by many organizations, applications or resources (Al Mosawi et al., 2006).

The advantage of data integration is its relative inexpensiveness. It

1 The table is reworked based on Table 1 in Markus (2000) and Zhu (2005) in

renders consistent data by a minimum of changes to source or target applications. However, as all integration taking place at the technological level, it ignores application and business logic. Bypassing the application layer implies limited real time transactional capabilities (Linthicum, 2001), and bypassing the business layer means that the coupling may not support the business needs.

The other two technological integration approaches, object and function integration, face the same limitations. However, the object integration has an advantage in its reusability, and a downside in its complexity. Function integration tries to solve the integration problem by streamlining and standardizing application functions and methods (Al Mosawi et al., 2006).

The most primitive form of application level integration, sometimes not even considered as a form of integration, is user interface integration (sometimes also referred to as presentation integration).

Basically, the interface towards the user is developed to present data from several non-integrated systems (Linthicum, 2001). Web-based portals are typical examples of presentation integration. The advantages of user interface integration include easy development, as it requires a minimum of changes to existing IS and IT systems. The disadvantages are that no actual integration is taking place, systems become difficult to maintain and are unscalable and tightly coupled (Al Mosawi et al., 2006).

Application interface integration is more complex than user interface integration, but invokes application functionality. Through sharing of common logic, packaged or custom built applications are arranged to support business services (Al Mosawi et al., 2006).

On the business integration level integration work is carried out with the use of common abstractions of business processes. The approach has an imperative in the alignment of IS and business strategy. Business level integration can be divided into intra- and inter-organizational integration. It is noteworthy that the synergies related to the M&A are mostly of intra-organizational character (Lubatkin, 1983) and thus the choice to focus on intra-organizational IS integration in this thesis (see section 1.3.1 on level of analysis).

Process integration is more advanced than technological, and application integration as the logic for conducting business is included.

Integration by business process level offers the most benefits, but is complex and expensive (Al Mosawi et al., 2006).

2.4.2 Integration structure

In practical terms, integration of IS involves the creation of some sort of linkage between different IS (Markus, 2000). This section of the thesis addresses the architectural options of how to actually undertake integration. According to Markus (2000, p. 10), “Systems integration refers to the creation of tighter linkages between different computer-based information systems and databases.” The term “Information systems” is used by Markus in a technical sense as she describes four conceptual solutions to the integration problem, based on connections between applications and databases. Figure 2.3 presents schematic pictures of these alternatives. Although Markus has a technical perspective on IS, the conceptual approach can be used to emphasize differences in the way integration needs are fulfilled. A fifth approach to integration structure is not mentioned by Markus, due to its recent appearance on the scene. The service-oriented architecture is mentioned by, for example, Zhu (2005) to provide several advantages including flexibility and reusability.

The first solution that Markus presents is a point-to-point (P2P) alternative, where a software bridge, also known as interface, connects two applications directly to each other. Data from one application, A, is

more or less automatically transferred to another application, B. If there is a need to integrate a third application, C, two new interfaces have to be built connecting to A and B, respectively. If a fourth application, D, needs to communicate with A, B, and C, three new interfaces need to be created, and so on… It is easy to imagine the complexity of such a system if many entities need to communicate with each other.

The first integration initiatives, ad-hoc in character, naturally conformed to a P2P integration strategy. The architecture has its benefits in its simple and straightforward approach where setting up one connector demands relatively few resources. The main disadvantage

Pont-to-point Middleware Enterprise-wide

C

M E B

A

Meta-level

D

SOA

S S S

Figure 2.3. Five approaches to IT-integration (Markus, 2000; Davenport, 2005;

Zhu, 2005).

is, of course, the complexity derived in larger systems with more connectors between systems.

To decrease the complexity, an approach that uses an intermediate layer between applications and databases called middleware can be used. Applications are modified to call, the middleware, M, instead of calling each other directly. The middleware, in turn, calls targeted applications or databases. As a consequence, each unit only needs two interfaces, one outgoing and one ingoing, to the middleware.

The third alternative is to adopt an enterprise-wide system, E, that is often referred to as an enterprise system or ERP (enterprise resource planning) system (Markus, 2000). In these systems the different applications employ a shared database. The result is that all applications’ data are updated simultaneously, since they actually are using the same data. Numerous articles have been published on the advantages of enterprise wide systems, both in the business press and the academic journals (e.g. Duff & Jain, 1998; Gupta, 2000; Buck-Lew et al., 1992). Implementing enterprise wide systems can be extremely rewarding. By streamlining data flows throughout an organization, these systems could dramatically affect the company’s efficiency and bottom line. However, while promising tempting advantages, major risks are also lurking in the swells:

Not only are the systems expensive and difficult to implement, they can also tie the hands of managers. Unlike computer systems of the past, which were typically developed in-house with a company's specific requirements in mind, enterprise systems are off-the-shelf solutions. They impose their own logic on a company's strategy, culture, and organization, often forcing companies to change the way they do business. Managers would do well to heed the horror stories of failed implementations. (Davenport, 2005, p. 121)

The field of the enterprise wide system is maturing and we are beginning to see the consequences of the large initiatives of the late 1990’s whose predictions of the foreseen monolith-structures seldom came true. Instead, as explained earlier, complex and evolving information infrastructures still flourish (Hanseth & Braa, 2001).

However, although the reality shows exceptions to enterprise-wide structures, the idealized state may be pursued in M&A initiatives as exceptions do not compulsorily have to be found in the parts that are touched upon in the integration process.

Meta level integration works by extracting data from source systems into data warehouses (Davenport, 2005). The approach does not actually integrate existing systems with each other, but adds a meta-layer on which all forms of sophisticated analyses can be made (Markus 2000). The approach has, just like the other conceptual integration solutions, its advantages and disadvantages. Pros include the achievement of data integration without making changes to the existing systems or business processes and the potential to include external data, e.g., public statistic data or data from collaborative partners. On the other hand, incompatible and poorly designed data structures in the source systems are also reflected in the data warehouse. Meta level integration integrates data on a highly aggregated level which does not permit the integration of business processes (Markus 2000).

One of the more topical concepts that currently flourish in the integration literature is SOA. SOA is sometimes referred to as a type of software, sometimes as an architectural design, and sometimes as a concept for solving an integration need. Granebring (2007) differs between definitions of SOA that regard it as integration technology (Biernerstein et al., 2006; Duke et al., 2005) and definitions of SOA as an integration framework (Erl, 2005; Feng et al., 2005). The common understanding, however, is that SOA consists of a collection of functional elements called services. The services are software modules that are accessed by name via an interface, typically in a request-reply mode (Yefim, 2003). The services sum up reusable business functions that are loosely-coupled to other services, and are called upon through connection technologies (Wong-Bushby et al., 2006). This adds flexibility to the business process, and thus standardization and interoperability can be achieved (Lager, 2005). Feng et al. (2005) describe the characteristics of SOA as three levels:

• Operations: Computational units represent single logical units of work that are executable parts of a system. Examples for operations are instructions, basic blocks, routines, classes, compilation units, components, modules or subsystems.

• Services: Represent logical groupings of operations. For example, in a digital library system, User profiling is viewed as a service, and then Maintaining a user profile, Store search profile and Notify user of updates per profile represent the associated operations.

• Business Processes: A long running set of actions or activities performed with specific business goals in mind. Business processes typically include multiple service invocations.

The benefits of using SOA are characterized by the reuse of components, the potential of reduced IS costs and improved business agility that have resulted in many organizations deciding to start working with SOA (Knorr & Rist, 2005). SOA providing more reusable components means that IS apartments do not need to reinvent the wheel and thereby can decrease the development costs (Datz, 2004). Additionally, a well-designed SOA lets organizations deal with multiple smaller integration projects with less capital and resource investment, as opposed to the high investment and resource commitments associated with traditional solution development architectures (Classon, 2004). Finally, business agility can be improved with SOA, as with packaged software suites that for a long time were the standard and the company needed to accept whatever the vendor could provide (Lager, 2005).

Criticism of SOA is very limited in the existing literature. As organizations start to embrace SOA, the downsides of the approach will come into light. SOA most probably cannot be blamed for the riots in Kenya or the democratic crisis in Pakistan, but for the individual organization is such a paradigmatic change that SOA for corporate IS strategy logically comes with a comprehensive range of problems and obstacles. Based on the initial use of SOA, potential problems have been identified that include migrating legacy systems (Wong-Bushby et al., 2006), learning a new technology (Henningsson et al., 2007), and interoperability of services (Cohen, 2006). The idea behind SOA is that IS are decomposed into blocks that cover specific functionality. Today’s organizations are adopting SOA without any standardization body, such as the World Wide Web-consortium (W3C) or OASIS at present.

This could potentially create problems of interoperability and scalability of SOA based IS in the future (Cohen, 2006).