The Concept of Modularity in the Context of IS Project Outsourcing

The Concept of Modularity in the Context of IS Project Outsourcing

Shahzada Benazeer (University of Antwerp, Belgium), Philip Huysmans (University of Antwerp, Belgium), Peter De Bruyn (University of Antwerp, Belgium), and Jan Verelst (University of Antwerp, Belgium)
DOI: 10.4018/978-1-5225-7362-3.ch071
OnDemand PDF Download:
No Current Special Offers


Information systems (IS) outsourcing became a very common practice in developed and in emerging economies. Over 94% of Fortune 500 companies are outsourcing at least one major business function. Despite IS outsourcing's popularity, failure rates are high. Many remedies are proposed in the literature, but failure rate of IS outsourcing projects remains high. It seems these remedies turned out to be partially successful at best. This chapter presents an alternative, new perspective on how to avoid IS project outsourcing failures and explores the concept of modularity and normalized systems theory (NST) in relation to IS outsourcing projects. Such a new perspective, which originates from the system sciences, may add value to outsourcing risk analyses. A case study analysis of a failed IS outsourcing project has been conducted. This study illustrates how the concept of modularity and normalized systems theory can be applied ex ante in order to mitigate the risk factors in IS outsourcing projects.
Chapter Preview


Due to the globalization of the world economy and advancement in information and communication (ICT) technologies, information systems (IS) outsourcing became a very common practice in developed and in emerging economies. Over 94% of ‘Fortune 500’ companies are outsourcing at least one major business function (Modarress, Ansari, & Thies, 2014). Despite IS outsourcing’s popularity, failure rates are high. Premature contract terminations and frequent dissatisfaction with IS outsourcing results are commonly encountered. Many IS outsourcing failures are not even reported publicly due to the fear of negative consequences from the market and the stakeholders. Empirical research has attempted to quantify the high probability of IS outsourcing failures. For instance, a joint study in 2000 by Oxford University's Institute of Information Management and the University of Missouri, which tracked 29 major IS outsourcing projects over eight years, reported that more than 35 percent failed (Gay & Essinger, 2000). A second study by Martineau and Shumway (2009), which compared data from 2004, 2006 and 2009, concluded that by 2009, the percentage of failed IS outsourcing projects (i.e., cancelled prior to completion or delivered and never used), being 44%, had decreased but was still (too) high. In the same study, the percentage of challenged IS projects (late, over budget, and/or with less than the required features and functions) also decreased by 2009 but still amounted to 32% in 2009. It is implied that the success rate in 2009, being 24%, did increase over time but was still low (Ciric & Rakovic, 2010). In this paper the authors are illustrating an alternative and new approach, based on the concept of modularity, which may supplement other approaches in order to significantly reduce the high failure rate in outsourcing. The newness of the proposed perspective is clear from Fixson, Ro, and Liker (2005, p.167) who state,

in the past, modularity and outsourcing were investigated predominantly in separate research communities but more recently, however, a new research stream has emerged that links these two topics together.

Modularity is defined as a property of a complex system, whereby the system is decomposed into several subsystems (i.e., modules). Modules are the decomposed and nearly independent parts of a larger system; the modules are less complex than the larger system. The decomposition of a larger system into modules allows breaking apart or splitting up the complexities into smaller pieces (modules). The modules are still (mutually) compatible as, together, they work as a whole towards a common goal. The modules’ compatibility logically follows from the adoption of specific ‘design rules’ (i.e., a chosen design option; see later) using an interface as connector (Langlois, 2002). The interface should be ‘well-defined’ (i.e., leaving no room for ambiguities) as it describes the input a module requires to perform its (functional) task, and the output it provides to its external environment (which includes the other modules embedded in the system). The amount of dependent ‘design parameters’ between different modules determines their coupling. Good modular design requires low coupling as low coupling enables design parameters of modules to remain stable, that is any change in the design parameter of one module has no or limited impact on the design parameters of other modules. A good modular design therefore exhibits the following two properties: (a) if the design of one module needs to be changed, the change will have no or only a limited impact on the design of other modules, and (b) the function of one module can be studied more or less in isolation from the functionality of the rest of the system. In order for necessary intermodular dependencies to work adequately, all intermodular dependencies should be clearly defined / made explicit ex ante, that is no hidden dependencies are allowed for (Mannaert & Verelst, 2009). If all intermodular dependencies in a system are clearly defined, a set of prescriptive rules is obtained, which all modules of the system need to adhere to. This set of rules is referred as the ‘modular architecture’.



A pertinent question deals with how IS outsourcing failure may be avoided. So far, literature includes many suggestions (‘remedies’) offered by both scholars and practitioners. Peterson and Carco (1998) suggested to streamline operations and ‘fix the problem’ before outsourcing an IS. Various remedies were introduced; the interested reader is referred to:

Key Terms in this Chapter

Module: A module is a unit whose internal parts are powerfully connected among themselves and relatively weakly connected to other units.

Modular Dependency: Dependency is the degree to which a module relies on other modules in order to function.

Interface: An interface is a common boundary where direct contact between two modules occurs and where these two modules communicate with each other.

Modularity: Modularity is defined as a property of a complex system, whereby the system is decomposed into several subsystems (i.e., modules).

Design Rule: A well-chosen ‘design option’ (characterizing standardized operating procedures) should become a ‘design rule’. Compatibility among modules is ensured by “design rules”. Sometime modules are designed independently but at the end these modules should work as a whole. Standard dimensions and parameters or specifications (i.e., dimensions, tolerances, functionality, dependency etc.) constitute design rules.

Complete Chapter List

Search this Book: