Architectural Issues Related to Feral Information Systems

Introduction

Businesses exist in a world of change, and they must be agile in order to maintain their relevance. As a consequence, their information systems must be agile as well in order to maintain their business relevance. For example, new ways af handling customer relations in its market may force a business to change its business processes and its use of IT in order to maintain its competitiveness. The characteristics of changing information systems have been studied in terms of growing information systems and continuous redevelopment (Truex, Baskerville et al. 1999), emergence in systems development (Chae and Poole 2005), and in terms of drifting information systems (Ciborra, Braa et al. 2000).

A variety techniques can be used to obtain agility (Truex, Baskerville et al. 1999): Maintainable specifications, open interconnection architectures, prototyping, end-user development, communication with users, inclusion of users in IT organizations, emergent IT organizations, proper reward systems. Two of these are of particular relevance for the discussion in the present chapter: Open systems architectures and end-user development.

We focus on a specific type of information systems called feral information systems (FIS). We view a FIS as an IT artefact that is developed by users and that is used instead of the mandated enterprise system (Spierings, Kerr et al. 2012). A FIS can be seen as an add-on to an information system that is not controlled by the corporate IT function. For example, a FIS may take the form of a user-developed spreadsheet application or a personal database.

Businesses may focus on enterprise-wide architectures in order to create maintainable and effective IT systems (Ross, Weill et al. 2006). One purpose of such attempts may be to create and maintain a consistent and integrated database that can be shared by employees across departmental boundaries. Such data sharing makes it easier to integrate business processes at an enterprise-wide level. For example, data about a specific customer order can be accessed by employees from different departments when needed.

FIS development can be seen as a response to a need for a greater level of agility within an organization or as a response to a lack of technical support from the information technology department. FIS development may be carried out by individuals or small groups of users. The “savage nature” of FIS may represent a threat to the structure and consistency of an integrated, enterprise-wide architecture.

The purpose of this chapter is to discuss relationships between FIS and enterprise-wide architectures. We discuss some of the essential characteristics of FIS and the challenges such systems impose on enterprise-wide architectures. For instance, a FIS exists as an application silo that is not integrated with the core information system in a business. Consequently, the use and management of a FIS can be difficult and prone to errors in terms of, for example, inconsistent and redundant data. We propose a set of potential guidelines to handle such architectural challenges caused by the existence of FIS.

The chapter is structured as follows. First, we discuss FIS in a context of emergent information systems. Next, we identify a set of architectural issues related to the characteristics of FIS. Then, we propose a set of guidelines that can be used to handle the identified architectural issues. Finally, we conclude on our findings.