The Concept of Modularity in the Context of IS Project Outsourcing

Introduction

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,

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’.

Background

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: