why do shadow systems fail? - Senacor

WHY DO SHADOW SYSTEMS FAIL? AN EXPERT STUDY ON DETERMINANTS OF DISCONTINUATION Complete Research Daniel Fürstenau, Freie Universität Berlin, Berlin, Germany Matthias Sandner, Freie Universität Berlin, Berlin, Germany Dimitrios Anapliotis, Freie Universität Berlin, Berlin, Germany

Abstract With the rise of cloud and end-user computing, business units find it easier than ever before to craft their own IT systems and extensions to existing systems, often considered as “shadow systems”. However, shadow systems frequently disappear and organizations often fail to harness their innovative potentials. To explore reasons, we conducted a qualitative study with thirty-one experts from different roles and industries. From these interviews, we distilled twenty-six biographies of shadow systems and categorized the systems according to their size regarding scope of use and functional scope. We identified challenges occurring throughout their life cycles and we linked these challenges with the observation whether the system was still operational. Our empirical data supports the argument that smaller shadow systems are more likely to disappear by exemplifying several small shadow systems that were non-critical for an organization and that became discontinued when challenges with the system itself or in its context occurred. Furthermore, we observed that often multiple challenges co-occurred when a shadow system was discontinued. The results shed first light on typical patterns contributing to shadow systems’ discontinuance and scrutinize what it takes to nurture robust shadow systems. Keywords: Shadow systems; IS discontinuance; End of life; Robustness; Expert study

1 Introduction In the beginning it’s a fantastic idea and it makes the work so much easier. Everybody is enthusiastic and the people that have done it are celebrated as heroes. Suddenly the heroes are gone and it becomes difficult. Dissatisfaction slowly increases. And, finally, nobody knows anything about the system anymore and what’s left is a crook and everybody rants: what if we had just done differently. – Extract from an interview with a former manager from a large telecommunication company The term shadow systems refers to autonomous software solutions or extensions to existing solutions that are neither developed nor controlled by a central IT department (Fürstenau and Rothe 2014; Zimmermann et al. 2014). Cloud computing (Haag and Eckardt 2014; Haag 2015), software-as-a-service (Winkler and Brown 2013), and end-user computing (Goodell 1997) stand exemplary for several recent IT trends that offer business users greater possibilities to fulfil their computing needs on their own. These trends have heighted the importance of shadow systems as they potentially allow users, easier than ever, to circumvent the central IT. This imposes new challenges to managers and others being responsible for aligning decentralized activities with organizational goals and imperatives. The current debate on shadow systems continues a long tradition of information systems research on the governance of decentralized systems (Sambamurthy and Zmund 1999). As an important insight from this research, the IT governance literature has identified a need to balance local responsiveness and scale effects in the provisioning of IT (Brown and Magill 1994; Weill and Ross 2005). Organizations often struggle to find a balance between allowing business units the autonomy and flexibility to develop and

Twenty-Fourth European Conference on Information Systems (ECIS), İstanbul,Turkey, 2016

1

manage their own systems and to leverage organization-wide economies of scale by centralizing and standardizing IT provisioning (Brown and Magill 1994). Local responsiveness without centralized governance and control may lead to redundant and incompatible solutions becoming decoupled from the rest of the organization (Tanriverdi 2005), whereas too little autonomy and strict standardization may block the agility to react to local demands of internal and external customers and to align with local business needs, goals, and priorities (Winkler and Brown 2014). Therefore, organizations need to carefully assess the level and type of autonomy granted to business units regarding their IT activities. Although several answers to the problem of scale versus responsiveness have been proposed such as “federated” or “hybrid” approaches to IT governance (Sambamurthy and Zmund 1999; Brown and Winkler 2014), the constant rise in attention to “shadow IT” in academia and practice (Silic and Back 2014; Raden 2005; Behrens 2009; Györy et al. 2012; Walters 2013) points to an important unresolved issue that potentially threatens organizational security, formal governance, and control. In recent decades, managers have begun to implement relatively strict governance frameworks and formal procedures (e.g. IT asset, IT security, and IT service management) to help minimizing these risks, partly in response to regulatory requirements and crises, e.g. in the banking or pharmaceutical industry. As the quote in the beginning of this section illustrates, especially the later phases of the shadow system life cycle are important as often challenges occur that cannot be resolved by the individual or workgroup implementing a shadow system. Whereas much of the literature has focused on the emergence of shadow systems, we currently lack a clear theoretical understanding of the interplay between such challenges and the discontinuation of a shadow system. In this article, we thus ask two research questions: (1.) which challenges occur and co-occur throughout the life cycle of a shadow system? And, (2.) how are these challenges linked to the discontinuance of a shadow system? To explore these aspects, we conducted interviews with 31 experts from different roles and industries from which we extracted 26 profiles of shadow systems. We coded the data to account for challenges occurring throughout their life cycles. We associated these challenges with the observation whether the system was discontinued or still operational. In doing so, we categorized the systems according to their size in terms of functional scope and scope of use. By constructing a fine-grained grid of different categories of shadow systems and by tracing the critical challenges surrounding them, this paper makes three contributions. First, the phenomenon of shadow IT is still lacking precise definitions (see e.g. Haag and Eckardt 2014). We give fellow researchers a taxonomy that they may use to better differentiate shadow systems and the occurring challenges related to them. Second, we show that different challenges often occur together which contributes to a more nuanced understanding of typical patterns that are related to discontinuation. Third, building thereupon, we conjecture on the conditions that improve shadow systems’ robustness so that they become more flexible and less vulnerable to challenging context conditions. In line with Behrens (2009), our aim is to encourage “good” shadow system, which we deem are robust ones, because we think they are an important driver of innovation. This article proceeds as follows. Section 2 presents conceptual foundations on categories of shadow systems, challenges potentially contributing to their discontinuation, and robustness conditions that potentially help to prevent discontinuation. Section 3 introduces the methods of this study. Section 4 shows results. In section 5, the results are discussed and limitations are outlined. In section 6, we conclude with theoretical contributions and introduce future research plans in exploring this area.

2 Theoretical and Conceptual Foundations Categories of shadow systems. We ground our discussion on the challenges related to shadow systems and their discontinuance in the broader academic debate on application IT governance (Winkler and Brown 2013). From this vantage point, we can list different properties that characterize a particular shadow system (see alternatively Zimmermann et al. 2014). We extract from the literature scope of use (Winkler and Brown 2013; Xue et al. 2008) and functional scope (Behrens and Sedara 2004; Markus et al. 2000; Strong et al. 2001) as two of them because of their relevance and distinctiveness.


2

Both dimensions are relevant because they represent system embeddedness. This is important because an empirical study by Furneaux and Wade (2011) underpinned the argument that those systems that are more embedded in an organization exhibit stronger continuance forces. According to Furneaux and Wade (2011, p. 579), the “extent to which the use of an information system is an integral part of organizational activity … begins to impose significant constraints on the formation of discontinuance intentions”. For instance, these systems may be distributed across many users, departments, and locations, and are used in many critical routines. As it is plausible that larger systems will be more embedded, it is thus credible to assume that these systems are also less likely to be discontinued. By functional scope, we refer to the range of functions covered by the system, e.g. one specific task or multiple tasks. Whereas some systems will be specific to one task such as file sharing or note-keeping, ERP systems and other enterprise-wide systems have a large functional scope (de Souza and Zwicker 2009). We contend that functional scope is important because shadow systems will often replace or extend the functionality of central systems such as ERP systems (Behrens and Sedara 2004; Strong et al. 2001). Thus, a shadow system with a large functional scope can directly substitute for an official solution, which can then become hard to abandon because it is critical for the organization. Scope of use refers to the breath with which a system is used within an organization (Winkler and Brown 2013), e.g. by single or multiple units. Scope of use is important because it shows the extent to which a system is distributed across multiple units, where larger distribution potentially produces “gridlocks from an interplay of structural and behavioural complexity” (Agarwal and Tiwana 2015, p. 474). It is therefore reasonable that systems with wider scope of use are less likely to be discontinued. Regarding the two defined dimensions (scope of use and functional scope), we conceptualize that systems can fall into four different categories. They differ in the way the two dimensions are applied. Figure 1 shows the categorization matrix with the two dimension axes.

Figure 1.

Categorization scheme for shadow systems (Source: own depiction based on dimensions that were extracted from the literature)

Personal productivity tools have a narrow scope of use and a small functional scope. This means that these systems are constructed for a specific and well-defined task within a single business unit. Most individual spreadsheets fall into this category. The difference to single-purpose platforms is the scope of use. Systems in this category are not restricted in their scope of use and therefore show platform characteristics. The functionality here covers only a single specific task. File sharing, note-keeping or collaboration tools are examples. We refer to systems with a small scope of use and a large functional scope as department-specific systems. They provide functions to manage several tasks within one system but are specific to a single unit and cannot easily be transferred to other units (e.g. simulation or trading systems).


3

If a system provides a large functional scope and a wide scope of use, it can be classified as a multipurpose business platform. This means that several functionalities can be handled within the systems and it can be used or transferred to several business units (e.g. ERP or CRM systems).

System level

Challenges. As shown in Table 1, many challenges potentially contribute to a shadow system’s discontinuation. In accordance with Markus (1983), we take as a starting point the distinction between system level and context level challenges. The former refers to the internal design of the system itself and the attitudes and behaviours of the involved people (e.g. users and developers). This means that we view shadow systems as sociotechnical systems and thus incorporate the people and tasks related to the shadow system into our analysis (see Winter et al. 2014). The context level refers to the broader organizational context in which the system is embedded. Shadow systems relevant here go beyond pure individual usage and will be (more or less) embedded in an organizational context. Challenge Architecture

Description Insufficiencies of the technological platform, database, data schemata, or core interfaces

Data quality

System includes errors that (may) result in poor decisions or cause serious harm to the organization by supporting wrong cues

Design & documentation

Bad code quality (e.g. inconsistent business logics or approach), lacking system capabilities, specification or documentation

Key personnel

Key persons such as developers or support personnel change, e.g. as they leave the organization entirely or are no longer available (“Hit by a bus scenario”)

Vendor

Vendor goes out of the market; stops support for a particular technology product that is used within the shadow solution; or takes advantage of lock-in by charging high prices

Greenstein 1997 Furneaux and Wade 2011 Markus et al. 2000 Tanriverdi 2005

Organizational restructuring

A restructuring of business workgroups or the entire organization may cause a shadow system to become obsolete or leads to the elimination of its purpose Large-scale IT transformation such as the migration of a core technological platform (e.g. Win 7 rollout) or migration of the enterprise to new core systems (e.g. ERP)

Karpovsky and Galliers 2015 Aier et al. 2009

Context level

IT transformation

Power balance changes

A change in control between business units and IT, or between business units themselves may cause that shadow systems are less tolerated or, conversely, stabilized

IT compliance program

Organization sets up rules or regulations that constrain or control the usage of business-developed systems (e.g. IT compliance, risk, security, or service management)

Table 1.

References Dreyfus and Iyer 2008 Fürstenau and Rothe 2014 Tarafdar et al. 2015 Panko 2006 Markus 1983 Raden 2005 Furneaux and Wade 2011 Markus 1983 Behrens 2009

Gregory et al. 2015 Behrens and Sedara 2004 Strong et al. 2001 Jones 2004 Xue et al. 2008 Markus 1983 Boeker 1989 Spierings et al. 2012 Panko 2006 Zimmermann et al. 2014

Challenges with shadow systems


4

Based on previous accounts on shadow IT (including “feral systems”, “rogue systems”, “workaround systems”, and “stealth adoption”; see for instance Kopper and Westner 2016 for an overview) and broader yet related IS research streams, we extended Markus’ list of system-level challenges. In Table 1, we added architecture, data, and vendor-related challenges to people and internal design challenges. The list accounts for different social and technical aspects. Social aspects are sub-divided regarding internal (key personnel) and external (vendor) contributions to the system. Technical aspects are subdivided by the architectural domain (platform/technology architecture, data, and application/design). The distinction between system level and context is important as it reflects the hierarchical nature of organizational systems (Simon 1962). It accounts for the observation that higher level developments often channel and constrain developments on lower levels (Lord 2015). Here, it means that a contextual change such as an organizational restructuring will potentially impact a shadow system and, in consequence, the system’s purpose or key persons may disappear. In turn, systems’ lower level developments usually need to accumulate over longer intervals to affect higher levels (Lord 2015). That is, the organizational impact of a single shadow system’s disappearance may often stay limited if it is not strongly embedded in the organization (see previous section). Thus, it is useful to differentiate system and context level challenges. Important contextual challenges are listed at the bottom of Table 1. Persisting shadow systems are robust. To discuss possibilities to cope with challenges, we start with Behrens’ (2009, p. 128) observation that organizations should nurture “good shadow systems” by making them legitimate without uprooting them. Then, firms will capitalize from a system that grew “from within”, which is more likely to hold the key for “true strategic and competitive advantage”. However, certainly not every shadow system will be “good enough” to enduringly move from individual to broader organizational usage and to remain in that state. As listed in Table 1, many problems can occur. To advance this idea, we dismiss the attribution of “good” or “bad” and instead turn to “robustness”. In organization studies and other disciplines, the notion of robustness has been used to denote a system’s capability to survive disruptions (Taleb 2012; Weick and Sutcliff 2007). By disruptions, one refers to fundamental changes triggered in a system’s external environment such as shifts in technologies or market conditions. Robustness is a property of a system to cope with such sources of uncertainty (Dueck et al. 2012). The system’s robustness potential can then be seen by its ability to survive disruptions or to even emerge strengthened from them (Taleb 2012). Robustness is one concept that is potentially useful to understand when contextual challenges lead to discontinuation. In the following, we take the shadow system as the unit of analysis and define robustness as a property of a shadow system. As shadow systems are (more or less) embedded in an organization, these systems become exposed to changes in the organizational context. As shown in Table 1, contextual changes represent challenges that potentially contribute to a system’s discontinuation. Accordingly, we define robustness as the ability of a shadow system to cope with contextual challenges. It follows that robust shadow systems would be better equipped to survive the many challenges occurring in their context. It is also plausible that these systems have higher chances to become accepted members of the organizational system once they are detected. By that, we do not imply that the ownership for a robust system will be transferred to the central IT. Instead, several modes of governance are possible (see for instance Blichfeld and Eskerod 2008; Hetzenecker et al. 2012; Tambo and Baekgaard 2013; Zimmermann and Rentrop 2014; Zimmermann et al. 2014). Plausible alternatives are ongoing business unit governance, centralized governance, or hybrid approaches (Sambamurthy and Zmund 1999). What is important to determine the robustness potential of a shadow system is to figure out whether the system remains operational in a changing context and that the organization learns from the knowledge and innovation that is boxed in the system, instead of discontinuation or replacement.

3 Methods As the literature on the discontinuance of shadow systems is sparse and consists mostly of narrative accounts (György et al. 2012; Silic and Back 2014), we conducted an explorative expert study to get a broad overview from respondents in different industries and positions related to shadow IT. We use the


5

term “expert” here in a broad sense indicating that a person has knowledge in relation to shadow systems as a specific field of action (see Meuser and Nagel 2009). Data collection. We conducted 35 interviews with 31 participants. Interviews were appropriate for this study for three reasons. First, they allowed consolidating diverse terminologies from different persons without degrading the potential richness of meaning (Alvesson 2003). Second, they were relatively efficient to explore a broad spectrum of systems, functions, industries, and roles without being tied to the peculiarities of one setting. Third, they enabled to condense the essence of a system’s life cycle into a single interview while maintaining the ability to reflect on and inquire new factors. We created a database with potential contacts (N = 114) from our own industry experience and public sources and contacted them. Interviewees came from diverse industries and positions. They included creators/developers, sponsors and users of shadow systems as well as IT control roles. IT control stands as a placeholder for IT security and governance officials, IT managers, as well consultants being concerned with the control, migration or discontinuance of shadow IT. Table 2 shows their industry background and their role with respect to shadow IT. Industry

# Interviewees (N = 31)

Role

# Interviewees (N = 31)

Banking

11

Developer

5

IT Services

5

User

7

Manufacturing

3

Sponsor

3

Technology

3

IT control

16

Transport

3

Insurance

2

Waste management Telecommunica-

2

tion Commerce

1

Table 2.

1

Interview partners by industry and role

All organizations referenced by the interviewees were headquartered in Germany. Their size ranged from medium to large. As a default option, we designed our study so that one respondent told the story of one shadow system (case). Following the same interview pattern, in ten of the cases we could consult with additional respondents to back-up and verify the individual case. We made sure that all interviewees had direct access to the shadow system in scope to foster the credibility of their statements (Madill et al. 2000). We confirmed this by asking respondents for specific examples and events indicating their involvement in the process of developing, using, or overseeing the shadow system. Interviews took place in a period between January and September 2015, performed by three interviewers. The interviews generally lasted between 45 minutes and 1 hour. Interviews were performed either face-to-face, via telephone, or via audio-video conferencing tools. More than 75% of the interviews were tape-recorded and transcribed. When interviewees did not agree on tape-recording, we produced field notes within 48 hours after the interview, replacing for the transcription. We asked the interviewees for additional materials on the discussed system. Whereas we obtained rich materials for some shadow systems (e.g. documentations, presentations, or even developer blogs), in most cases we could not obtain written texts because there were none available. If available, the materials were used to inform our analysis and to triangulate our results. While we were working from a positivist view, our interviews followed a narrative strategy that considered concrete stories and the interviewee's personal experiences (Clandinin and Rosiek 2007). We did so, because we expected that by focussing on specific cases which were perceived as "critical" or "revelatory" by the interviewee, also we as researchers could learn most from reflecting on these cases. We


6

had prepared an interview guide that tapped into three main areas: (1.) The “story” of one specific shadow system, the critical challenges therein, and changes in the system’s governance, and (2.) more general observations drawing on the interviewees broader experience with the topic area and further cases. In addition, we (3.) asked for descriptive facts (the interviewee’s industry experience, the interviewee’s current position and role, and descriptive information with regards to the shadow system). We treated the resulting data as “fixed”, seeking to identify patterns in the data that would be useful independent of the specific context (Clandinin and Rosiek 2007, pp. 60–61). Data analysis. We performed multiple steps to analyze the qualitative interview data. In an initial step, we distilled system biographies (Williams and Pollock 2012) from the raw data. To do so, we created a case database listing all solutions described in sufficient detail by the interviewees. As some interviewees referred to several shadow systems while others did not recall specific examples, the number of entries in our case database did not match the number of interviewees. Overall, we identified 26 distinct shadow systems that we could use to draw conclusions on our research question. Our database combined descriptive facts on the shadow system (e.g. user base, year of implementation, short description, technology base) with results from a case-internal analysis. In a second step we developed a coding scheme that centred on key topic areas and concepts of our interview guide and included the challenges as presented in section 2. We derived at these codes by using an abductive approach that combined datagrounded insights with theoretical reasoning from the previous literature. The coding followed a “consensus principle” to guarantee agreement among the three coders (Harry et al. 2005, p. 6). This means that the transformation of the raw data into the coding scheme was executed by reflecting on the content by the group of coders together. In a final step, we moved to a cross-case analysis by comparing the cases for commonalities and differences. We grouped solutions according to the observed outcome (continued or discontinued) and looked into the factors that occurred or co-occurred for continued and discontinued solutions, respectively. From this analysis, we could identify common reasons or patterns for the decommissioning of certain categories of shadow systems. The next section presents results.

4 Results 4.1 Larger Shadow Systems Persist More Frequently Figure 2 shows the observed outcomes for different categories of shadow systems, from peripheral ones with small functional scope and narrow scope of use to large enterprise-wide systems. We focused in our analysis only on the observation whether a shadow system stayed operational (was continued) or was discontinued. As can be seen in the figure, a frequently observed difference between continued and discontinued systems is the size of the system. In total, 26 systems have been analyzed. We found nineteen discontinued and seven continued systems. Most of the reviewed systems are categorized as personal productivity tools (12 of 26). In this category, the vast majority of the systems have been discontinued (11, compared to 1 continued system). This extensive difference would suggest that the personal productivity tools with their small scope of use and functional scope are comparably easy to decommission. For instance, we analyzed a board computer tool for GPS tracking in the waste industry, an algorithmic trading tool at the banking industry and a billing system in the telecommunication industry, which have been decommissioned. Six out of the seven continued systems are categorized as having a broad functional scope. This result indicates that this kind of wide-ranging systems has a high importance for the involved business and a decommissioning would cause large efforts. These systems contain for example a data revision system in the banking industry, an e-commerce platform at the retail industry and a simulation system in the technology industry, which have not been decommissioned. This suggests that a considerable fraction of these systems are “too big to fail” and have the potential to persist—given central IT governance or not. The following sections explore reasons and ground the finding in detailed examples.


7

2

wide

2

Scope of Use

3

11

4

discontinued

narrow 3

continued (still operational)

1

small

large Functional Scope

Figure 2.

Categorization and continuation classification of examined shadow systems

4.2 Most Frequent Challenges Table 3 shows the relative frequency of occurring challenges for discontinued systems. This analysis only examines the discontinued systems because continued systems were rarely subject to challenges and in the case of having challenges, they could be coped with (see section 4.5 for an example). Due to this filtering, the amount of analyzed systems is 19. The relative frequency of occurrence is defined as the times by which this challenge was observed in relation to the total number of analyzed systems (19). We classified challenges into system level and context level. The former contains challenges concerning the internal characteristics and the design of the system itself. In contrast, the latter contains all challenges concerning the broader organizational context and therefore goes beyond the system level.

Architectural challenges Key personnel changes

0.58 0.21

Vendor Data quality

0.16 0.11 0.05

Design & documentation Table 3.

Relative frequency

Type Challenges Context

System

Type Challenges

IT transformation Org. restructuring IT compliance program Power balance changes

Relative frequency 0.32 0.26 0.21 0.11

Relative frequency of challenges grouped by type

The frequency with which we observed different challenges varied. At the system level, the most frequent challenges are architectural challenges, key personnel changes, and vendor-related problems. At the context-level, the most frequent challenges are IT transformations and organizational restructurings. The following three examples illustrate the most frequent challenges. Board-computer solution (architectural and vendor challenges): This solution aimed at providing GPSbased location services to support tour planning and tracking in a waste services firm. The central ERP was missing this capability and the IT department was lacking resources to provide a solution. The


8

business unit turned to a local consultant who made a good offer and the business unit ran a pilot without involving the central IT. In a first project phase, the board computers were physically installed into the trucks. A local software agency was sub-contracted to customize the solution to emerging demands. The next project phase implemented interfaces to the central ERP. As by default only read-only permission was granted, the project had to make do by extracting data from the ERP and using “shadow tables” to process it. This created manual effort and first dissatisfaction. Meanwhile, the consultant used the firm’s growing dependency to profit from the vendor lock-in. A responsible IT manager summarized: “This firm put a gun to our head and told us that we have to pay their price or we are out”. It went on that the poor architecture made modifying the system costlier than expected. Algorithmic trading system (architectural challenges): This system was created by the trading department of a bank because it was considered an innovative solution that promised an edge over competitors. A special project team was established to implement the system. Yet, problems arose as the system grew. A developer stated: “The high amount of algorithms and frequent market data queries led to a server overload”. This architectural challenge was not investigated by the department team prior to the implementation. File service (IT transformation): This service was launched by a team of tech-savvy users in a business unit of a large technology company, mainly for users in one location. The involved IT manager recapitulated: “a parallel and self-sufficient system was implemented, used by more than 1.000 users”. The system grew in parallel to a standard outsourcing solution. When the data center where the system was hosted moved to another country, an IT architecture assessment was carried out where the system was detected and it was decided to decommission it. The users were migrated to the standard solution.

4.3 Frequent Challenges by System Category Table 4 shows the relative frequency of the observed challenges grouped by system category. In the table, the amount of analyzed systems is dependent on the category. Personal productivity tools account for 12, department-specific systems for 7, single-purpose platforms for 2 and multi-purpose business platforms for 5 systems. The relative frequency is defined as the amount of observed challenges in this category divided by the amount of analyzed systems in this category.

high

Singlepurpose Platforms Multi-purpose business platforms

Table 4.

0.09 1.00 0.25 0.25 0.25

Context

Power balance changes

0.09

Org. restructuring Power balance changes

0.25 0.25

IT transformation

0.50

IT compliance Program

0.50

IT transformation IT compliance program

0.50 0.50

Org. restructuring

0.50

Context

0.09

Relative Frequency 0.36 0.27 0.18

Context

Departmentspecific systems

Architectural challenges Key personnel changes Vendor Poor design & lacking documentation Data quality Architectural challenges Key Personnel changes Vendor Data quality

Relative Type Challenges Frequency 0.64 IT transformation 0.27 Org. restructuring 0.18 IT compliance program

Context

Personal productivity tools

System

Type Challenges

System

low

Scope Category of use

Frequency of challenges grouped by system category and type of challenge

The additional grouping by category reveals a shift from system-level to context-level challenges along the dimension of scope of use. For systems with a narrow scope of use, we find system-level as well as context-level challenges. Nevertheless, system-level challenges are predominant.


9

In contrast, for systems with a wide scope of use, we just observed context-level challenges. As we had the feeling that some factors were often present simultaneously, we performed an additional analysis tapping into the extent to which different challenges co-occurred.

4.4 Patterns from Multiple Combined Challenges Figure 3 summarizes the joint occurrence of challenges. All occurring challenges are listed on both the x-axis and the y-axis. The cells show the total amount of observed co-occurring challenges for one system. As in the previous chapters, we focus on discontinued shadow systems. Architect. challenges Architect. challenges

Key personnel

Vendor

Data quality

Poor design & doc.

IT transformation

Org. restructuring

IT compliance

Power balance

3

3

2

1

2

3

2

1

1

0

1

0

2

1

0

0

0

0

0

0

0

0

0

0

0

0

0

1

1

0

0

0

1

3

0

Key personnel

3

Vendor

3

1

Data quality

2

0

0

Poor design & doc.

1

1

0

0

IT transformation

2

0

0

0

0

Org. restructuring

3

2

0

0

1

0

IT compliance

2

1

0

0

1

0

3

Power balance

1

0

0

0

0

1

0

Figure 3.

0 0

Co-occurrence matrix

The following pairs of challenges were co-occurring most frequently: architectural challenges–key personnel changes, architectural–vendor, architectural–organizational restructuring, and IT compliance program–organizational restructuring. Subsequently, we exemplify some of these combinations. Board-computer solution (architectural challenges–vendor): It turned out that the system suffered from a poor architecture as the extensibility of the chosen mobile platform was limited. After months of struggle, the business unit refused to escalate the investments further and involved the headquarter IT. The interviewed IT manager summarized: “We had to stop the cooperation with the vendor. Still, the equipment which had already been integrated in the trucks was running on a specific platform. Therefore, we had to find another vendor offering a system which ran on a comparable platform”. In the following, the sub-contracted vendor ceased operations as it was strongly dependent on incoming revenues from the single project. Further enhancements of the system came to a halt. Eventually, the board-computer solution was decommissioned. The investment was lost. Algorithmic trading system (architectural challenges–organizational restructuring): After it was recognized that the server insufficiencies posed a significant risk, several solutions were discussed. Simultaneously, an organizational restructuring took place and the involved business department was integrated into another department. Consequently, these two challenges formed jointly the main reason for the system’s decommissioning. Beyond the co-occurrences, we also found isolated challenges where no other challenge was prominent in the analysis of the system. Isolated challenges are IT transformation (3 times), IT compliance program (1), organizational restructuring (1), key personnel changes (1), and architectural challenges (1). An example is the filesharing service. The predominant discontinuance reason was the relocation of the


10

data center. Whereas other factors and dynamics existed in the background, such as the firm’s strong compliance policy, the IT transformation acted as primary driver for its decommissioning.

4.5 Example for Continued Shadow System Here, we exemplify a continued shadow system that persisted despite considerable challenges. We refer to the system as “order book tool”. It was introduced by the treasury unit of a mid-sized savings bank to deliver and process market data from third-parties. The system was implemented without central IT involvement because of lower license costs, a higher performance compared to an existing solution, and a lack of specific knowledge of the central IT. It scaled up to more than 200 users and became used also within the bank’s back office. As part of an organizational restructuring, the investment bank was outsourced to another legal entity. In this context, the responsibility for the order book tool has been transferred to the central IT. The decision was influenced by a newly introduced IT compliance program. The order book tool stayed operational. It did so, because it was mission critical and several units depended on the system on a daily basis. Moreover, it was favorable that the system had an effective developer team and did not suffer from a poor design. One interviewee stated: “Because of the project team’s good performance and the thorough documentation … the system is still in use”.

5 Discussion 5.1 Discussion of Study Results This article addressed two research questions. First, we aimed for a better understanding of challenges occurring and co-occurring throughout the life cycle of a shadow system. Second, we aimed to shed light on the interplay between these challenges and a shadow system’s discontinuation. Regarding the first objective, we observed that while many challenges need to be considered, the most frequent challenge was architectural. More than half of the considered systems suffered from inconsistent data schemes, a non-extensible technical platform, instable server or hardware components, lacking scalability, or the like. This often interacted with other problems such as key personnel changes, poor design and lacking documentation. Regarding the second objective, we observed that often several challenges interacted when it comes to the consideration to discontinue a shadow system. The range of responses to challenges occurring throughout the life cycle of a shadow system are manifold. Some plausible reactions are ignorance, tightened monitoring, migration to central authorities or a federated governance model–or discontinuance. The decision is a complex process contingent on many factors. We argue that two main determinants are particularly important for discontinuation considerations. First, the size of a system–in terms of scope of use and functional scope–is a plausible representative to determine a shadow system’s organizational embeddedness that will help to understand its potential for persistence. Consistent with prior work on IS discontinuance (Furneaux and Wade 2011), our results indicate that shadow systems that are more embedded in the organization more frequently persist. This pattern in the data was observed in spite of the occurrence of all sorts of challenges. As shown in Figure 4, it suggests that increasing the size of a shadow system can potentially decrease its vulnerability to challenges as it becomes mission critical and thus indispensable for the organization. One option to nurture a shadow system may thus be to extend the functional scope to make more business units adopt until the system eventually becomes irreplaceable. To do so, one may better “fly under the radar”, a strategy suggested by an interviewee, until the system has gained a critical mass of users. Second, robustness matters. The larger a shadow system becomes, the greater the likelihood that it is discovered (see for instance Tambo and Baekgaard 2013 and Zimmermann et al. 2014). This implies that the system is likely to be assessed regarding risks and costs. Size also comes with an increased risk that the system will be affected by contextual changes. In contrast to the “order book tool” (see section 4.5), many shadow systems go down on their knees given a lack of internal defenses (see examples in 4.2–4.4). Thus, it is equally important to determine the robustness of a system to evaluate its potential for persistence. As depicted in Figure 4 and discussed in section 5.3, the presented system-level factors provide plausible entry points for considerations to increase a shadow system’s robustness.


11

Figure 4.

Facilitating robust shadow systems

5.2 Limitations Our findings are not without limitations. Firstly, we have mostly relied mostly on single respondents to reconstruct the biography of a shadow system. These respondents may be biased by their role or relationship toward the system. We aimed at consulting multiple sources of evidence where possible but future studies could be designed to consult each of the roles (user, sponsor, developer, and controller) equally for each system to avoid potential biases. Secondly, the trends and patterns observed in the data were described with respect to the observed frequency and do not necessarily transfer directly to the importance of these factors. Thirdly, we aimed at covering a broad spectrum of industries and systems. However, our view may be biased by our focus on “systems” and future studies may devote equal attention to other artifacts such as cloud services, hardware devices, and technical tools (see for instance Silic and Back 2014 and Zainuddin 2012).

5.3 Implications for Practice Regarding practice, we distinguish between what we saw many companies doing as an immediate response to shadow IT and what we saw more proactive ones doing to get most in the future. Regarding short-term measures, we found that organizations differ largely in the extent to which they have processes in place to monitor and control shadow IT. Some strict organizations draw on advanced practices that included (i) allowing specific types of systems (e.g. by whitelisting or by defining standard work places) or by restricting them (e.g. by blacklisting and blocking macros), (ii) strategies to register, assess, and regulate shadow IT, and (iii) strategies to discontinue or replace shadow IT. Especially in the banking industry, we found sophisticated frameworks on how to evaluate the risks associated with shadow systems, for instance, in terms of balance sheet impact. These measures may be useful to contain immediate problems but often times they fail to address the root causes relevant for to the emergence of shadow IT. Thus, it appears more promising to turn to proactive strategies that allow “shadow IT” to thrive in specific dynamic areas while increasing the systems’ robustness to make them good enough to enable them becoming organizational systems. Thereby, it is important that the central IT department is not hostile to shadow systems that are “not invented here” but that it embraces them as a chance for learning and innovation (cf. Behrens 2009).


12

We illustrate two proactive strategies that we have seen in a number of cases and consider useful. These strategies aim at increasing a shadow system’s robustness from within by improving its ability to cope with occurring contextual challenges (see expanding black circle in Figure 4). First, architectural choices on the system-level are frequently irreversible so that these choices do open and foreclose viable solution paths (Agarwal and Tiwana 2015). In consequence, a common reason for the discontinuance of (shadow) systems is their architectural inflexibility that restricts adaptation to changed situations. By incorporating architectural considerations early in the life cycle of a shadow system one can significantly better its chances of survival. To this end, organizations can implement liaison roles that think early of alternative usages of a system that evolved within a specific context to allow it to travel. They must not be technologists but business-IT people that aim at understanding the business problem and think of its specificity as well as potential implications for other units. Then, they support the business unit in designing a system that balances the need for responsiveness of the specific unit with the need for synergies of the larger organization. Second, it is important to accept speed differences within a single organization. Many areas of a business would be ill-advised to slow down their speed to the speed of a central IT unit. Shadow systems are thus an important mechanism to cope with the organizational need for responsiveness and to ensure a “dynamic fit” (Gerrow et al. 2015) between organizational capacities and environmental requirements. To avoid “under-the-radar”-strategies that circumvent standard ways of doing, formal organizations should, in turn, find ways to govern shadow IT properly. If systems grow beyond a certain size, they may hardly get back on track with the organizational goals and priorities. Yet, they may have become so critical that they are hard to replace. Stigmatization, denial, and prohibition are non-constructive responses. Instead, it may be better to decompose the organization into areas that require fact response cycles and harnessing the potential of robust “shadow systems” in these areas. The underlying IT platform should allow quick changes and the flexible accommodation of new purposes. For instance, we have seen one organization migrating to a micro-service platform to achieve this. Whereas liaison roles are a first step in developing robust shadow systems that scale up, some organizations have begun to form truly interdisciplinary teams that bring together developers, project managers, and business roles to advance a “bi-modal IT”, evolving with different speeds. Organizational readiness is an important prerequisite to achieve this.

6 Conclusion We added to the literature on shadow systems by shedding first light on factors contributing to their discontinuation. While the existing literature already discussed important challenges related to shadow systems (e.g. Behrens 2009; Behrens and Sedara 2004; Jones 2004; Raden 2005; Panko 2006; Strong et al. 2001), it did so in a largely undifferentiated and anecdotal manner. Our contribution was firstly to categorize potential challenges related to shadow systems and secondly to demonstrate the empirical relevance of these categories for understanding better the discontinuance of shadow systems. We have thereby, in accordance with the existing literature on IS discontinuance (Furneaux and Wade 2011), highlighted the role of a shadow system’s organizational embeddedness. Finally, we have emphasized the role of robustness to understand better why shadow systems disappear and why organizations frequently fail to harness their innovative potential (cf. Behrens 2009). In addition to validating the robustness of our findings, we see three particularly promising ways to proceed further. First, our work can be foundational for an empirical study testing the strength and interaction of the factors that we have proposed. Second, one could also conduct a qualitative study that delves deeper into specific cases and explores in more detail the industry and other context conditions in which these shadow systems prosper or die off. Third, future work may also aim at designing a theoryguided governance framework that supports in allocating task responsibilities for shadow systems between business and IT units. This presents important research challenges.


13

References Agarwal, R. and A. Tiwana (2015). “Editorial—Evolvable Systems: Through the Looking Glass of IS.” Information Systems Research 26 (3), 473–479. Aier, S., Gleichauf, B., Saat, J. and R. Winter (2009). “Complexity Levels of Representing Dynamics in EA Planning.” In: EMISA 2009 Proceedings. Alvesson, M. (2003). “Beyond Neopositivisits, Romantics and Localists: A Reflective Approach to Interviews in Organizational Research.” Academy of Management Review 28 (1), 13–33. Behrens, S. and W. Sedera (2004). “Why Do Shadow Systems Exist after an ERP Implementation? Lessons from a Case Study.” In: PACIS 2004 Proceedings. Behrens, S. (2009). “Shadow Systems: The Good, the Bad and the Ugly.“ Communications of the ACM 52 (2), 124–129. Blichfeldt, B. S. and P. Eskerod (2008). “Project Portfolio Management: There’s More to It Than What Management Enacts.” International Journal of Project Management 26 (4), 357–365. Boeker, W. (1989). “The Development and Institutionalization of Subunit Power in Organizations.” Administrative Science Quarterly 34 (3), 388–410. Brown, C. V and S. L. Magill (1994). “Alignment of the IS Functions with the Enterprise: Toward a Model of Antecedents.” MIS Quarterly 18 (4), 371–403. Clandinin, D. J. and J. Rosiek (2007). “Mapping a Landscape of Qualitative Inquiry: Borderline Spaces and Tensions.” In: Handbook of Narrative Inquiry: Mapping a Methodology. Ed. by D. J. Clandinin. Thousand Oaks, CA: Sage Publications, 35–76. De Souza, A. and R. Zwicker (2009). “ERP Systems‘ Lifecycle: An Extended Version.” In: Encyclopedia of Information Science and Technology. 2nd Ed. by M. Khosrow-Pour. New York: Info. SCI, 1426-1436. Dreyfus, D. and B. Iyer (2008). “Managing Architectural Emergence: A Conceptual Model and Simulation.” Decision Support Systems 46 (1), 115–127. Dueck, V., Ionescu, L., Kliewer, N. and L. Suhl (2012). “Increasing Stability of Crew and Aircraft Schedules.” Transportation Research Part C: Emerging Technologies 20 (1), 47–61. Furneaux, B. and M. Wade (2011). “An Exploration of Organizational Level Information Systems Discontinuance Intentions.” MIS Quarterly 35 (3), 573–598. Fürstenau, D. and H. Rothe (2014). “Shadow IT Systems: Discerning the Good and the Evil.” In: ECIS 2014 Proceedings. Goodell, H. (1997). End-user computing. In CHI ’97 Extended Abstracts on Human Factors in Computing Systems Looking to the Future - CHI '97. ACM. New York: ACM, p. 132. Greenstein, S. M. (1997). “Lock-in and the Costs of Switching Mainframe Computer Vendors: What Do Buyers See?.” Industrial and Corporate Change 6 (2), 247–274. Gregory, R.W., Keil, M., Muntermann, J. and M. Mähring (2015). “Paradoxes and the Nature of Ambidexterity in IT Transformation Programs.” Information Systems Research 26 (1), 57–80. Györy, A., Cleven, A., Übernickel, F. and W. Brenner (2012). “Exploring the Shadows: IT Governance Approaches to User-driven Innovation,” In: ECIS 2012 Proceedings. Haag, S. and A. Eckhardt (2014). “Normalizing the Shadows – The Role of Symbolic Models for Individuals’ Shadow IT Usage.” In: ICIS 2014 Proceedings. Haag, S. (2015). “Appearance of Dark Clouds? – An Empirical Analysis of Users’ Shadow Sourcing of Cloud Services.” In: Wirtschaftsinformatik 2015 Proceedings. Harry, B., Sturges, K. M. and J.K. Klingner (2005). “Mapping the Process: An Exemplar of Process and Challenge in Grounded Theory Analysis.” Educational Reseacher 34 (2), 3–13. Hetzenecker, J., Sprenger, S., Kammerer, S. and M. Amberg (2012). “The Unperceived Boon and Bane of Cloud Computing: End-User Computing vs. Integration.” In: AMCIS 2012 Proceedings. Jones, D., Behrens, S., Jamieson, K. and E. Tansley (2004). “The Rise and Fall of a Shadow System: Lessons for Enterprise System Implementation.” In: ACIS 2004 Proceedings. Karpovsky, A. and R. D. Galliers (2015). “Aligning in Practice: From Current cases to a new agenda.” Journal of Information Technology 2015 (30), 1–25.


14

Kopper, A. and M. Westner (2016). “Deriving a Framework for Causes, Consequences, and Governance of Shadow IT from Literature.” In: MKWI 2016 Proceedings. Lord, R. G., Dinh, J. E., Hoffman, E. L. and E. Burke (2015). “A Quantum Approach to Time and Organizational Change.” Academy of Management Review 40 (2), 263–290. Madill, A., Jordan, A. and C. Shirley (2000). “Objectivity and reliability in qualitative analysis: Realist, contextualist and radical constructionist epistemologies.” British Journal of Psychology 91 (1), 1– 20. Markus, M. L. (1983). “Power, Politics, and MIS Implementation.” Communications of the ACM 26 (6), 430–444. Markus, M. L., Axline, S., Petrie, D. and C. Tanis (2000). “Learning from adopters’ experiences with ERP: problems encountered and success achieved.” Journal of Information Technology 15 (4), 245– 265. Meuser, M. and U. Nagel (2009), “The Expert Interview and Changes in Knowledge Production.” In: Interviewing Experts. Ed. by A. Bogner, B. Littig, W. Menz. Basingstoke, UK: Palgrave Macmillan, 17–42. Panko, R. (2006). “Spreadsheets and Sarbanes-Oxley: Regulations, risks, and control frameworks.” Communications of AIS 17 (29), 647–676. Raden, N. (2005). “Shedding light on shadow IT: Is Excel running your business?.” Marketing Report. Hired Brains Inc., Santa Barbara. Sambamurthy, V. and R. W. Zmund (1999). “Arrangements for Information Technology Governance: A Theory of Multiple Contingencies.” MIS Quarterly 23 (2), 261–290. Silic, M. and A. Back (2014). “Shadow IT - A view from behind the curtain.” Computers and Security 2014 (45), 274–283. Simon, H. A. (1962). “The Architecture of Complexity.” Proceedings of the American Philosophical Society 106 (6), 467–482. Spierings, A., Kerr, D. and L. Houghton (2012). “What Drives the End User to Build a Feral Information System?” In: ACIS 2012 Proceedings. Strong, D., Volkoff, O. and M. Elmes (2001). “ERP Systems, Task Structure, and Workarounds in Organizations.” In: AMCIS 2001 Proceedings. Tarafdar, M., Gupta, A. and O. Turel (2015). “Special issue on ‘dark side of information technology use’: an introduction and a framework for research.” Information Systems Journal 2015 (25), 161– 170. Taleb, N. (2012). Antifragile: Things That Gain from Disorder, New York: Random House. Tambo, T. and L. Baekgaard (2013). Dilemmas in Enterprise Architecture Research and Practice from a Perspective of Feral Information Systems. In: 2013 17th IEEE International Enterprise Distributed Object Computing Conference Workshops, 289–295. Tanriverdi, H. (2005). “Information Technology Relatedness, Knowledge Management Capability, and Performance of Multibusiness Firms.” MIS Quarterly 29 (2), 311–334. Walters, R. (2013). “Bringing IT out of the shadows.” Network Security 2013 (4), 5–11. Weick, K. E. and K. M. Sutcliffe (2007). Managing the Unexpected: Resilient Performance in an Age of Uncertainty. Chichester: John Wiley & Sons. Weill, P. and J. W. Ross (2010). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results (Reprint.), Boston and Mass: Harvard Business School Press. Williams, R. and N. Pollock (2012). “Research Commentary - Moving Beyond the Single Site Implementation Study: How (and Why) We Should Study the Biography of Packaged Enterprise Solutions.” Information Systems Research 23 (1), 1–22. Winkler, T. J. and C. V. Brown (2013). “Horizontal Allocation of Decision Rights for On-Premise Applications and Software-as-a-Service.” Journal of Management Information Systems 30 (3), 13–48. Winkler, T. J. and C. V. Brown (2014). “Organizing and Configuring the IT Function,” In: Computing Handbook. (3rd ed.). Ed. by H. Topi and A. Tucker, Boca Raton, Florida: Taylor & Francis Ltd, 57.1– 57.14.


15

Winter, S., Berente, N., Howison, J. and B. Butler (2014). “Beyond the Organizational ‘Container’: Conceptualizing 21st Century Sociotechnical Work.” Information and Organization 2014 (24), 250– 269. Xue, Y., Liang, H. and W. R. Boulton (2008). “Information Technology Governance in Information Technology Investment Decision Processes: The Impact of Investment Characteristics, External Environment, and Internal Context.” MIS Quarterly 32 (1), 67–96. Zainuddin, E. (2012). “Secretly SaaS-ing: Stealth Adoption of Software-as-a-Service.” In: ICIS 2012 Proceedings. Zimmermann, S. and C. Rentrop (2014). “On The Emergence of Shadow IT - A Transaction Cost-Based Approach.” In: ECIS 2014 Proceedings. Zimmermann, S., Rentrop, C. and C. Felden (2014). “Managing Shadow IT Instances – A Method to Control Autonomous IT Solutions in the Business Departments.” In: AMCIS 2014 Proceedings.


16