Contribution of chapter 2

• 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).

of how the problem of IS integration evolved from ad-hoc creation of bridges between individual components to complex infrastructures that are essential for most contemporary businesses.

2.5.1 Summary of key concepts

The aim of the chapter was, apart from straightening out the confused vocabulary, to position the study in relation to prior research in the field and to elaborate upon potential theories for inclusion in the theoretical framework for IS integration in M&A. It was argued that a view of IS as fulfilling an organizational need was required and that inclusion of the human component as data interpreter was needed to capture the organizational need. In other words, that a working definition of IS should include not only the pure IT system, but also the human involvement in the information creation process, the processes it was supposed to support, and the context within which the IS existed. This conclusion, perhaps the most important drawn in chapter 2, has fundamental implications for the research design presented later, as it clearly affects how the boundaries of the study are settled and directs the focus towards the ability of IS to support business processes.

A review of existing research revealed that three levels related to IS integration were relevant to consider. Apart from the IS level itself, the Organizational Integration was relevant to understand the purpose of IS integration work and how it could contribute to organizational performance. Further, the IT system level, addressing in more practical terms how the enabling IT integration could be implemented also has significant implications on the IS level. None of these levels can possibly be ignored if one contends to approach the subject of IS integration comprehensively.

Thus far, the theoretical review has focused foremost on the levels of IT system, IS and organizational integration. Strategic integration has purposely to a large extent been ignored. This is because it is of little use to address organizational strategy in general terms. The concept is too complex and inclusive to account for generally in a productive manner. Instead, the next chapter has a distinct focus on the strategic issues of M&A, the strategic elements that are relevant for IS integration in M&A.

What has been established is the understanding that the term ‘IS’

does not refer to a homogenous phenomena. IS should be divided into subcategories based on distinct characters. As this thesis is concerned with the organizational implications of IS, IS should be divided by how it contributes to organizational objectives, i.e., by its functionality.

We also presented different architectural approaches to actually implement integration needs. The choices represent fundamentally different kinds of integration processes with respect to required work activities and technological use. Advantages and disadvantages of integration by point-to-point, middleware, enterprise-wide, and meta-level architectures were emphasized. The decision regarding which infological level to make connections is also an architectural decision that has to be made. It was argued that the integration decision showed a significant path dependency, meaning that existing systems and their history limited the alternatives for future integration.

The key concepts that are essential for the development of the next chapters are summarized in Table 2.4. The concepts can be group into three categories: Organizational Integration, IS Type, and Integration Architecture. Together, they constitute the essence of concerns regarding IS integration in contemporary business.

Table 2.4 Classification concepts in Chapter 2

Key concept Description Classification Indicative references Organizational Integration

Interdependency type

Organizational units with relations to each other can have three types of mutual

dependencies

Pooled, Sequential, Reciprocal

(Thompson, 2003)

Integrated Activity

Which part of the organization being object for integration is related to the amount of resources needed.

Operational, Functional

(Barki &

Pinsonneault, 2005)

IS Ecology

Function A contemporary IS base consists of several heterogeneous systems.

A typology based on supportive function is argued appropriate for this framework.

Infrastructural, Informational, Transactional, Strategic

(Weill & Broadbent, 1998)

Integration Architecture

Integration level IS can be integrated on several different levels, with individual advantages and disadvantages.

IT, Infological, Organizational (business)

(Al Mosawi et al., 2006; Iivari, 2007) Integration

structure

The actual linkage between two or more systems can be organized in several ways.

P2P, Middleware, Enterprise-wide, Meta-level, SOA

(Markus, 2000;

Davenport, 2005;

Zhu, 2005)

2.5.2 Key concepts and their mutual dependencies

In this chapter several models and concepts have been introduced that show the potential of explanatory power when approaching IS integration in M&A. What makes the subject complex and intricate is that the concepts naturally do not exist in a vacuum, but rather decisions and actions targeting one aspect have far reaching implications for other concepts. The dependencies are summarized in Table 2.5 and depicted in Figure 2.4. These dependencies are regarded as relations between two units, rather than an obligating dependency of some independent and dependent variable.

Table 2.5 Relational concepts in Chapter 4

Relation Description Indicative references Organizational Integration – IS ecology

Operational integration requires integration of the internal value chain, which requires heavy integration of Transactional IS.

Functional integration, in turn, is related to integration of Information IS. The more complex dependency of operational units should make integration in Transaction IS more demanding in terms of resources and time, compared to Informational IS.

(Barki &

Pinsonneault, 2005;

Weill & Broadbent, 1998)

IS ecology – Integration Architecture

If integration of Transaction IS, as suggested, is more demanding and requires deeper coupling than Informational IS then it have consequences for selection of integration architecture. Integrating a whole operational chain with point-to-point architecture should logically be to complex. In this case a single system, not perhaps a complete Enterprise-wide, but at least some sort of “process wide”

architecture can be claimed more suitable.

(Markus, 2000)

If the IS is business critical then integrating with point-to-point or middleware could be preferred in favor of an enterprise wide system. Implementing a new enterprise wide system is a highly risky and complicated process. Integrating existing systems is argued less difficult and risky than a complete transition

(Markus, 2000)

Organizational Integration

IS Ecology

Integration Architecture

Figure 2.4 Relations between key constructs

Organizational integration can be divided into operational and functional integration. This relates to the classification of IS, as some types of IS relate to operational and some primarily to functional.

Operational integration requires integration of the internal value chain, requiring heavy integration of Transactional IS. Functional integration, in turn, is related to integration of Information IS. The more complex dependency of operational units should make integration in Transaction IS more demanding in terms of resources and time, compared to Informational IS. What is meant by regarding this as a mutual relation, rather than a deterministic dependency from one variable to another, is that this can also be seen the other way around. If one, for some reason, does not want to pursue integration of Transaction IS (it is complex, requires recourses and competences etc.), it would be impossible to reach operational integration and the benefits related to that.

Further, it was explained that integration architectures have different advantages and disadvantages. For example, some are more suitable for heavy integration than others are. If integration of Transaction IS, as suggested, is more demanding and requires deeper coupling than Informational IS, then there will be consequences for the selection of integration architecture. Integrating a whole operational chain with point-to-point architecture should logically be too complex.

In this case a single system, perhaps not a complete Enterprise-wide, but at least some sort of “process wide” architecture can be claimed more suitable. As explained above, the different architectures are idealized conceptualizations and a real integration project would naturally contain elements of different architectures.

Chapter 2 has accounted for Integration and IS integration as general phenomena, without special emphasis on the specific context of M&A. The specified purpose and research questions have naturally been used as guidance of theory selection, but thus far, the properties of the M&A process have largely been left uninvestigated. The next chapter will, however, be devoted to the properties of M&A that can be used to describe and explain the relationship between IS integration and M&A.

3. Research on Mergers and