Abstract
The close relationship between the concepts of information systems and information technology creates issues for researchers. Usefully distinguishing between the concepts is problematic. We investigate the use of the systems concept in practice, finding a pragmatic distinction between an information system (IS) and an information technology system (IT system). In a practice view, an IS incorporates an emphasis on both a technical and a social subsystem, while an IT system predominantly emphasizes the technical elements. This distinction becomes useful in practice because contemporary IS practitioners are often involved in acquiring and integrating IT systems into an organizational IS. This involvement leads to a viewpoint on the organizational IS (including the social subsystem) as a nexus of multiple IT systems. This nexus creates issues in practice for not only integrating IT systems into the organizational IS, but also integrating multiple IT systems with each other in the context of the organizational IS. These issues lead to research opportunities such as the need for new methodologies for IT system acquisitions and new theories that accommodate the social integration of IT systems and IS.
Keywords
Introduction
Over the past few decades, we have become inured to the confusion of the concept of an information system (IS) with the concept of information technology (IT). But, outside of academia, have these two concepts become truly synonymous or do they at least overlap? If the concepts are distinct, what do practicing managers regard as their distinguishing characteristics? As IS academics, we are not only entitled but also obligated to engage in a debate about the meanings, distinctions, and similarities between the two concepts. But given that ours is an applied discipline, we should also ask what is the meaning that IS practitioners attach to the relationship between their IS and their IT? After all, we may further confound IS research if we engage practitioners as our respondents when we do not understand how those practitioners distinguish (or do not distinguish) between IS and IT. In this research, we aim to answer the following question: “When practitioners say ‘information system’, what do they mean and what do they refer to?” This means that our research aims to question the meaning of the term IS as seen by practitioners. To answer this question, we have captured the views of practitioners who design and implement IS.
It is not surprising that our technical languages change over time. Like other forms of language, the meanings of words and phrases change gradually. Word meanings merge and divide. Expressions and grammar are emergent. Concepts and their related words hop from language to language in bizarre ways (McWhorter, 2001), that are often metaphorical and may verge on the catachrestical: who would have imagined the contemporary technical meanings of such mundane words as “cloud,” “bus,” or “mouse.” The technically specific meanings of these words were coined deliberately, yet these latter meanings are far from the original meanings. Moreover, language has different meanings simultaneously in different contexts (McGinn, 1997). We do not seek to define (or redefine) the term “information systems”; instead, we aim to capture an interpretation of the term’s meaning in current practice. This work enables a comparison between formalized expressions of IS and “ground reality”: the way practitioners use the concept today.
Our research reports on a qualitative study of IS practitioners in three locations (France, Hong Kong, and the USA) to learn about the practice-based shifts of IS as a concept. Rather than finding an assumption that IS and IT are equivalent concepts in practice, our results indicate that practice has transformed the IS concept in the presence of new information technologies and digitalization. These results could mean that IS researchers share a single outdated understanding of an IS in practice. Perhaps the understanding of what IS means for some in academia is aligned with IS practice in the past and now needs re-alignment. Perhaps it means that IS researchers share a diverse understanding, one as diverse as the one found in IS practice. But somehow researchers are skewed toward a traditional view while practitioners are skewed toward a revised view. Such findings are important for academic researchers who might otherwise misconstrue expressions by IS practitioners about IS and IT, and practitioners who might misconstrue academic expressions of IS.
Following this introduction, we review and interpret the ways in which the scholarly and professional literature conceptualize IS, IT, and systems. We then report our research methodology, the qualitative data analysis, the overall findings, and discuss these results. In this research, we identify a continuum in the concept of IS among practitioners. This continuum embodies a contrast between the emphases on two different kinds of components that are being systematized. At one extreme is a classic view of an IS that systematizes discrete technologies and people: Humans, computers, and devices that mainly serve to capture and transform data into information. At the other extreme is a nexus view about an information system. The term nexus, derived from Latin, is defined as a bond, link, or junction; a means of connection between things or parts (OED, 2015). We use the term nexus to refer to the process of binding, fastening, and joining. In the nexus view, an IS is viewed as an assemblage of commoditized IT systems such as platforms, commercial off-the-shelf software, and cloud services. We use the term IT systems to refer to the “computing systems used by an organization” (Turban and Volonino, 2011). These IT systems deliver packages of technology processes that produce the information that the IS nexus must repackage into the concise forms that fit the organization and its social and technical needs. In the nexus, there is a continuous process of binding and rebinding various IT systems to the organization. In practice, the human and social elements of the organization become fundamental elements in the process of this nexus. In practice, the nexus is the distinguishing characteristic of an IS (as opposed to an IT).
This finding is significant from the practice perspective of how the notion of an IT system has evolved in practice. More importantly, from an academic perspective, it forces us to revisit the role of the IT artifact from more contemporary ecosystem and platform perspectives. A platform is a type of IT system with which we could build an IS. Such a platform can also be called an “IT platform system.” When we build an IS out of these “IT platform systems,” then we are effectively taking a “find and bind” approach where an information system consists of an assemblage of applications that exhibits some or all of the following characteristics: simplicity, resilience, maintainability, and evolvability.
Further, it creates an opportunity for researchers to re-examine the constructs of several theoretical perspectives that have guided IS thinking. These include General Systems Theory (Backlund, 2000, Boulding, 1956), complexity (Schneider and Somers, 2006), organizational ecology (Chengalur-Smith and Sidorova, 2003, Hannan and Freeman, 1977), and resource dependence (Pfeffer and Salancik, 1978). Each of these theoretical perspectives relies upon a holistic systems viewpoint that needs to be reviewed to see what impact new and emerging forms of technology may or may not have on the systems view of information.
Theoretical and practical background
Information systems and information technologies
The distinction between IS and IT is problematic. Boaden and Lockett (1991), writing just as IT was becoming prominent, analyzed the usage and noted that IS usage seems to emphasize systems aspects (including the social system) while IT usage takes on a technical sense, and emphasizes devices, computing, electronics, and telecommunications. The Oxford English Dictionary (OED, 2015) defines information technology as: “The branch of technology concerned with the dissemination, processing, and storage of information, esp. by means of computers.” The concept has a long history, encompassing developments as old as, for example, the telegraph (Gleick, 2011). Orlikowski and Iacono (2001: 121) defined the IT artifact as “those bundles of material and cultural properties packaged in some socially recognizable form such as hardware and/or software.”
There are equally diverse definitions of IS. For example, there are different kinds of things that have been labeled as IS, such as organizations that deliver information to their clients; systems of active elements that deal only with symbolic objects (i.e., data and information); and the subsystem within any self-governing system that enables communication between the managerial or operational subsystems of an organization (Carvalho, 2000). Lee (2010) divided the IS into three interacting and constituent subsystems: the organization system, the data system, and the technology system. Alter (2008) identified more than 20 published definitions of IS most include references to computers or technology, and most refer to organizations; however, while some mention society or social aspects, a few entirely ignore technology, organizations, and society, taking, for example, a database perspective. In general, what agreement can be found in the literature suggests that IS are systems in which human participants and/or machines use information, technology, and other resources to produce informational products and/or services (Alter, 2008: 451).
As IS academic researchers, the actual practice of IS is one of our primary domains of interest. Within this domain of interest, IS in management and business is dominant. It is rather obvious that, in our domain of interest, the view of business practitioners has become predominantly focused on IT, not IS. We need only consider the presence of IS in the general business press. We regard the ProQuest/ABI Inform database as one well-known repository of the business press. While there are indications of the steady growth of IS articles in the business press, articles about IT, including IT artifacts, services, and solutions, have skyrocketed. Figure 1 provides an indicator in the business press of the 1980s, there were 21,008 articles mentioning IS compared to 3601 mentioning IT. In the second decade of the new millennium, there have been 410,970 articles mentioning IS; not bad progress unless we compare it to the 1,463,450 articles mentioning IT. Total number of articles in the business press referring to IS or IT (Source: ABI/I, including both the peer-reviewed and non-peer-reviewed press, August 2021)
1
One interpretation of this progressive disparity between interest in IT as a concept and interest in IS as a concept, is that IS has fallen out of fashion for managers and IT is now “in” (cf. Orlikowski and Iacono, 2001). An alternative interpretation, consistent with the results we will report below, is that there is a growing many-to-one relationship between IT and IS. We may have moved from an age in which there were fewer kinds of IT than kinds of IS to an age in which there are many, many more kinds of IT than there are kinds of IS.
This alternative interpretation of the disparity above is consistent with the recognition that the IT artifact needs attention in the academic discipline of IS. If there are many new kinds of IT available for practitioners to adopt into their IS, it seems reasonable for academic researchers in IS to develop a growing interest in such IT artifacts. Orlikowski and Iacono’s (2001) authoritative and widely cited “desperate search” for the IT artifact is an influential polemical example. A search of the ABI/Inform database shows that, before 2001, only a handful of refereed articles referred specifically to the IT artifact, yet over a thousand have been published since (1115 as of August 2021). 2 Another prominent example is the development of design science research within the academic discipline of IS (Hevner et al., 2004). This research paradigm foregrounds the development of IT artifacts as a central element in IS research (Baskerville et al. 2018). Even a cursory review of contemporary research and professional discourse shows how IS researchers are aligning with business practice/fashion, investigating big data, blockchain, Internet commerce, cloud computing, service science, wearable technology, and the waves of apps that flood our personal devices.
One conclusion might be that academic researchers in IS have now become overly absorbed with IT (Alter, 2015), and have neglected some of their primary subjects, such as information, systems, theory, organization, and relevance (Lee, 2010). But it could also be that the academic research field is growing, and the direction of our research growth is accommodating the massive expansion in the kinds of IT that can be incorporated by practitioners into an IS. Nevertheless, academic researchers should not overlook the possibility that the practices related to the IS itself may have evolved as a result of this massive rise in the available kinds of IT. One possible confound in the distinction between IS and IT is the notion that an IS is named as a system, and an IT is not. There are many variations of the terms IS and IT. We find management information systems (MIS), information management (IM), information resource management (IRM), and information technology and communication (ITC), inter alia. We can also easily blend the two terms, making, for example, IT systems. For the purpose of this paper and given the definitions of IS and IT, we conceive of an IT System as a subset of IS: The IT system emphasizes the devices, computing, electronics, and telecommunications, while the IS includes, in addition, an emphasis on the human components surrounding any IT system, namely, the social system, that is people, culture, and processes. Our use of the verb “emphasize” recognizes that the IT concept does not categorically exclude people, for example, user behavior is always critical. Likewise, the IS concept does not categorically exclude technology, but the distinction is a matter of emphasis. By conceiving of an IT system, both an IS and an IT system are, of course, systems. We eliminate a possible confound in the study below: system-hood per se is not a distinguishing characteristic of IT and IS.
System-theoretical concepts
The concept of a system is well established with a broad agreement on its general meaning repeated in textbooks. A system is an assembly or set of interacting entities or elements with relations between them (Backlund, 2000). In a system, the behavior of each element has an effect on the behavior of the whole, and these behaviors are interdependent. Elements can form subsystems, and these subsystems also affect the behavior of the system as a whole. However, the connectivity is such that subsystems cannot become usefully independent of the overarching system. Accordingly, a system is a whole that cannot be divided into parts that function independently of an overarching system. Interaction among subsystems is important: One element’s behavior is influenced by another. The relationships among elements in a system are defined by behavior, and such behavior means each element has significant properties that may change. For an element to be considered as being inside a system, the element must both have the potential to affect and be affected by other parts of the system (Backlund, 2000).
From an IS perspective, the systems concept is anchored in General Systems Theory (Ashby, 1991a, Boulding, 1956) and systems science (Ackoff, 1991, Klir, 1991). Systems theory was adapted early in information systems theory (Ackoff, 1967, Langesfors, 1977), especially in its “soft” variety that merged action research and systems science into a form of systems thinking and soft systems methodology (Checkland, 1981). Also thematic is the notion that systems, once created, have a certain autonomy and durability, meaning they can be self-organizing (Ashby, 1947, Varela, 1984) and self-reproducing (autopoietic) (Luhmann, 1986; Varela et al., 1974).
The conceptualization of IS may lie in the relegation of the systems concept into the background as part of the IS assumption ground. The systems aspect of IS is assumed to be ubiquitous, shared, and taken-for-granted when in fact it is likely that there are disagreements about which aspects of the systems concept are more dominantly valued in a particular IS perspective. Based on these systems ideas, there is one key dimension along which systems can vary: Exactly what is being systematized, and to what extent? (Ackoff, 1981, Klir, 1991).
The composition dimension is aligned with the distinction among the elements of a system versus the relations among, or interactivity of, those system elements (Backlund, 2000). At one extreme, an IS professional might dominantly value the discrete IT components that in part comprise the system. Such an extreme component-focused professional would find value in integrating the available IT components. We designate this extreme approach as an IT Component Integrating viewpoint in systems thinking.
3
At the opposite extreme, a professional might dominantly value the relationships and interactions among these technologies, the accompanying data, the business processes, and the people who constitute the system. Such an extreme relationship-focused professional would want to grow or nurture a healthy or sustainable ecology within (and perhaps in the outside environment of) the system. We designate this extreme approach as an IS Ecology Emerging systems thinking viewpoint. This dimension is illustrated along the horizontal axis in Figure 2. To an important degree, this dimension represents a contrast between an IT assumption and an IS assumption. Systems and technologies in different contexts.
The context dimension considers the behavior of system elements and the way they affect the relationship of the system to its context. At an organizational level, this dimension distinguishes between the ways in which the system interacts with the complex aspects of its environment (such as culture). For our purposes, this dimension helps us to distinguish between systems thinking viewpoints that range from the “controlling of complex situations” to the “conforming to complex situations.” At one extreme, a professional might dominantly value the importance of the system in controlling the complexity of its internal organizational environment. For example, there might be a need to prevent a diversity of cultural norms from affecting system performance. This view is consistent with Boulding’s lower levels of systems complexity and is exemplified by control mechanisms in cybernetic systems, such as a thermostat (Boulding, 1956). We will designate this extreme approach as a complexity-controlling systems thinking viewpoint. At the opposite extreme, a professional might dominantly value the importance of the system in matching and interoperating with the complexity of its organizational setting. At this extreme, the cultural context of an organization needs to be adaptable to the system, where the system does not deterministically control how work is done. This systems thinking view is consistent with Boulding’s higher levels of systems complexity and is exemplified by societal systems made up of communicating, autonomous human beings (Boulding, 1956). We will designate this extreme approach as a complexity-conforming systems thinking viewpoint. This dimension is illustrated along the vertical axis of the diagram in Figure 2.
Taken together, these two theoretical dimensions illustrate both the how and the why of systems thinking as represented in the literature. The horizontal dimension helps explain how a system is conceptualized in professional systems thinking. For example, an emphasis on the development of a solution that uses discrete components represents an IT-centric decision. On the other hand, an emphasis on the interrelationships between such components, as well as the data, models, procedures and people who use them represents an IS-centric decision. The vertical axis provides the systems thinking rationale for why systems professionals take various decisions, and the organizational cultural contexts wherein those decisions are made. The decisions may be influenced by a flexible organizational culture and environment where systems must be dynamically adaptable to the infinite variety of circumstances. In contrast, decisions might instead be driven by a corporate mandate to control the behavior of an organization (and its various component parts, including people).
Research approach
Research methodology and data collection
In order to investigate the contemporary practice view about IS, we undertook an interpretive qualitative field study using semi-structured interview questionnaires. The choice of a qualitative form of such a field study is driven by the exploratory nature of the framework. Because the systems concept is open to interpretation by the respondents, it was important to trap richer qualitative data at this stage of the development and validation of the theoretical framework (i.e., allow researchers to be surprised by the data), rather than incorporate an attempt to nail the study to a single conceptualization of the systems idea (Klein and Myers, 1999, Walsham, 2006).
According to the classification proposed by Sarker et al. (2019), we position this research as an exploratory case study as we collect multiple perspectives from practitioners to apprehend how the systems concept is represented in various real organizational settings. Following the guidance of Sarker et al. (2019), we design this study through an inductive reasoning approach, where data collected from our interviews are used as representations. We aim at building a “polyphonic” account 4 where different or competing views of the systems concept may occur (Sarker et al., 2019). Hence, in terms of data collection, this field study reflects the selection of firms and practitioners who assume differing roles in designing and managing systems. It is important to retain qualitative values for this study because a single actor may enact multiple roles. When this occurs, the researchers require the latitude to offer interpretations of the role assumed by a subject in relation to offering a particular reflection for the study, relying on cues that may be in the margins of the qualitative data. While we cannot experimentally manipulate the role assumed by the respondents, we can select respondents who naturally represent differing roles. Because this selection process involves interpretation, the qualitative nature of the study remains continuous (Walsham, 2006).
Similarly, the perspective of practicing IS professionals must also be captured qualitatively. This requires conceptualizations provided by respondents of (1) their system setting and (2) their focus given to either the discreteness of technologies or the integrated nature of systems. To derive these conceptualizations, despite using an inductive approach to this exploratory study, we did not begin the interviews with a “blank slate” (Thornberg, 2012, Urquhart and Fernandez, 2013). We provide an overview of the streams of literature that informed the development of the interview guide
We selected questions to prompt the subject to disclose their viewpoint in terms of the two dimensions. The intention was to provide a field of data upon which an interpretation may be anchored about the viewpoint. While using these concepts to guide the interview questions we deliberately kept the questions open-ended to allow new insights to emerge (Patton, 2005). There were two open-ended questions for each dimension, one asked in a positive sense, and one asked in a negative sense, with the intention of providing an opportunity for a certain degree of internal validity where the responses indicate similar positions on each dimension. One final question offers a further, general opportunity to confirm or disconfirm interpretations of the earlier responses.
Respondents, roles, and firm information.
Aside from homogeneity in practice realms and heterogeneity in culture, respondents were initially selected on a critical-case basis (Yin, 2009). We expected that individuals practicing in certain roles would constitute natural hosts for certain viewpoints about technology and the settings in which technology and systems are situated. For example, we anticipated that a CIO would be the ideal host for certain viewpoints, a consultant in another, and an architect in yet another. However, we did not detect this kind of alignment. We shifted our unit of analysis from the study participant to the statements made by the respondents. Our unit of observation remains as the individual respondent. Respondents were individuals working with multiple systems. This multiplicity means that an individual respondent might make one statement that characterized a particular system’s view, yet then make another statement that suggested a different system’s view.
We used a semi-structured interview guide that comprised four sections: we first collected simple demographic information to provide a sense for possible alternative explanations for the conditions; next, we offered the subject an opportunity to describe and explain their role in relation to systems and systems design, this section was explicit about the role enacted by the subject (the expected independent condition); next we offered the subject an opportunity to describe and explain their assumptions about the systems setting where they worked; last we offered the subject an opportunity to describe and explain their assumptions about technology and its relations. The last two sets of questions were intentionally less direct, as we intended to provide an ideal setting for the subject to reveal the presence of their attitude toward those systems in their systems thinking.
Prior to the interview, recording consent was obtained and we were fortunate that all of our subjects agreed to be recorded since the information that they were sharing was not confidential. This enabled us to transcribe the recorded interviews (and anonymize the transcriptions using alphabetically sequenced pseudonyms) which allowed the researchers to review the interviews multiple times for different analytical perspectives, to be able to identify quotes to support the analytical viewpoints, and most importantly, for the researchers to organize and analyze the data and to share their interpretations of the data with each other to arrive at consensus (McLellan et al., 2003, Walsham, 2006).
Based on Sarker et al. (2019), we summarize how the methodological elements of data, theory, analysis, and claims were used in this study. The data being analyzed was drawn from the representative views in the interviews. We used theoretical concepts from General Systems theory, interactivity of systems components, systems integration, and complexity to formulate our initial design of the interview guide and also referred to these concepts in the analysis of the data. However, the data analysis was iterative and through several iterations of sense-making using visual mapping and analysis of quotes, we found that the data led us to new insights rather than confirming the theoretical concepts, leading to our claim of IS as a nexus of IT systems and how the conceptualization of IS has evolved.
Data analysis
The data (statements) were analyzed in several iterations with the researchers working independently as well as in pairs. Samples of the data analyses can be found in Appendix 1. Although this was an iterative process until we reached theoretical saturation, we describe the four main iterations below.
The first iteration involved repeated readings of the interview transcripts and discussion of the evidence about the systems’ concept. Since data collection was undertaken in three different geographic regions, the first iteration comprised of analyzing the data from the US and Hong Kong, and then France. This analysis and interpretation of the respondents’ views were mapped to the four systems viewpoints, as per Figure 2 (cf. Baskerville et al., 2014), namely, (i) component view, (ii) ecological view, (iii) complexity reducing view, and (iv) controlling view.
However, we found that the data from the interview responses presented across multiple concepts and to varying degrees, that is, the same individual presented evidence that corresponded to more than one of the four concepts. The viewpoints did not neatly or exclusively fit into one or the other systems thinking viewpoint and could be mapped to different areas along the two continuums of component-vs-ecological systems and complexity-conforming-vs-complexity-controlling. Moreover, some of the respondents’ viewpoints could be mapped to more than one system-thinking theme. This indicated that our conceptualization of the IS and IT viewpoints needed to be revised.
The second iteration comprised the analysis of the interview data from all 18 respondents and suggested that practitioners have progressed from traditional systems thinking about information systems to a revised, reoriented form that integrates the old dimensions. This understanding is critical because it can be misleading if one expects contemporary IS professionals to share the orientation of those from decades ago. Essentially, contemporary systems thinking is “off-axis” when compared to traditional systems thinking. Interestingly, we did not detect any particular dependency of the interview responses on the location of the respondent. This lack of geographic bias suggests that we captured a current of IS viewpoints that operates across borders as well as across roles.
Based on this finding, the third iteration of data analysis consisted of organizing the “polyphonic” statements made by individuals into a consistent continuum that ranged between a classic IS view and a modern view about IS as a nexus of IT systems. Therefore, in our third iteration of analysis, we focused on the individual interview responses, going through each interview to extract technology related viewpoints of each respondent.
In a fourth iteration, we analyzed the data, this time to analyze if each individual’s responses indicated one or the other of these two themes. We found that it was difficult to align the data perfectly into either a modern perspective of IS as a nexus of IT systems or into a classic IS perspective. Most of the data lay somewhere along a continuum between these two viewpoints and so we conducted a graded mapping exercise where we found that most of the data congregated towards the IS as a nexus of IT systems viewpoint—the modern view. However, many respondents showed varying, even multiple viewpoints as opposed to one of the two extreme views. Therefore, while the technological architecture is certainly significant, most respondents’ discussions showed the increasing move towards a viewpoint where technology integration and a platform-based architecture become increasingly important.
Empirical findings: two views on information systems
In analyzing the data, we encountered two more-or-less distinct themes (which we will call views) about IS. The first view was expected and fit well with our textbook systems perspective in which the IS was structural: a framework that shaped and controlled the organization (see Figure 2). The second view was less well expected and described the IS as more of a continuing process, a nexus within which IS integrated an organization both internally and externally. What follows is our description of these two distinct themes built from the empirical dataset.
The Classic Information System View
In this section, we present the data that supports a more classical view of the organization-centered Information System. While there were fewer respondents who directly presented this extreme of the viewpoint, there were several respondents whose views indicate that the overall organizational culture is somewhat slower to catch up.
Trent (IT Manager for a large Insurance firm) provided the strongest example of the focus on the technology aspect of an IS: COBOL will never stop. They’re going to introduce more web interfaces but I don’t think they’ll ever change it because it’s stable.
He insisted on the controlling role of each component of the IS given the business functionalities, albeit at the expense of users’ satisfaction and responsiveness developments: We have to control things everywhere; it’s reassuring, but it makes processes heavier (…) Users moan because the solution is not suited to their needs, they don’t have what they need. We know that there are a lot of little things to be done to fit better with business specificities, but it’s not easy to integrate them with all our contingencies so typically there are some blockages at the moment.
While aligned with both views, Horace (CTO for a Manufacturing company) agreed with Trent about the system control. In this case, he talked about the value of ERP systems and how each business decision would necessitate going back to see how it could be aligned with the technology: The ERP system has to be very systematic. Whenever we have a new business flow, ... We constantly have these types of things for which we need to design a process in the ERP.
He described how the standardizing systems fit the business need for sharing information: The ERP is centralized. The reason to centralize is we want to share information, not because we want to control. A good example is we do internal transfer of raw materials. If we transfer fabric from one factory to another, the system will handle all the inter-company charges automatically. But if you use two separate systems, you need to build your own interfaces. Another example is we share fabric. So one customer has orders in both plants. And if we need fabric, plant A can check their inventory for plant B. So for technical reasons, we centralize.
The view emerging from these statements is indicative of the limited popularity of the classic system’s viewpoint. In the perspective of our respondents, the system is assumed to be the amalgamation of a set of discrete technologies and people. This viewpoint involves the assumption that the setting for the system is an organization that can be built and controlled. Despite the fact that this is classic, there was very little data to demonstrate its applicability in contemporary organizational settings.
Modern Information System as a Nexus of IT Systems View
In this section, we present the data that supports a more modern view in which an Information System is produced by various IT systems (e.g., platforms) that are packaged and repackaged into forms useful in organizational processes. The platforms are typically IT systems, not IS. As demonstrated in the verbatims that follow, many practitioners see the IS not only as a technical and social system, but also as a nexus of IT systems. Their issues revolve around stitching together information (not just data) obtained from various platforms into packages of information that are in a form that is useful to the organization.
For Carol (Project Manager for a Consulting firm), the IT system has to fit in with the organizational processes. If people cannot use the platforms, devices, and software, reconfiguring the technology alone will not be sufficient. The organization must re-articulate the nexus, adjusting the depth of coverage in its IT systems until the IS becomes usable and productive. When IT systems are not working well, replacing them is not a smart strategy. As Carol remarked: So it’s almost like a lack of recognition that technology is really there to support the business process, and without any different process for the technology to work, the project is not going to be a big part of implementation. You can’t implement technology for technology’s sake and then let it sit out there on its own separately. It just doesn’t work like that.
Similarly, Klassie (CIO for a Transportation firm) emphasized the need for a holistic approach to systems: Information systems support the business operations of an organization [and so] in order to get the most benefits out of information systems, I think we need to look from a holistic approach. … We plan IT and IS holistically using the approach of adopting an enterprise architecture. So, first of all, we identify the business function. And then look at the second layer, which is the information architecture. How can information be used to support the business? And what application is needed to support those businesses? It is not necessary to use the most advanced or the latest technology or the most expensive, as long as it is appropriate for the purpose of that organization.
Carol seemed to operate on the assumption that the setting for the system is an organization that can be built and controlled. The setting is complex, but the system can help organize and control this complexity. For Carol, compliance is a central control issue: I think the hardest part of change management is compliance. Nobody likes to be the mean compliance guy. When you define a process or implement a new technology, if people are not using it correctly, if they’re not using it the way it’s meant to be used, it’s not going to work well.
Leonard (IT Director for a Logistics firm) shared this perspective but was in the process of repositioning his view from a tendency toward a classic IS to a tendency toward IS as a nexus of IT systems. He recognized that adoption of an IT system triggers the re-articulation of other aspects of the IS. As he explained: In the past, they used their own system in their own country. So they could do whatever they wanted and we (in Hong Kong) didn’t know anything about their operations. So, every time there were hiccups, we needed to spend a lot of resources in investigations, queries, whatever to find out the root causes. We cannot control them [operations staff] through administrative command. So ultimately we determined to use an IT system to align all the best practices. When we try to standardize, that would impact their local efficiency. Of course the efficiency would be higher when they work with their local vendors. But when we added a lot of head office requirements, or global requirements, that created a lot of hurdles in their operations. But that is a must [even though it] will create a lot of inefficiency in the beginning. And we are in the process of fine tuning the system and also adjusting standard operating procedures so that they can go back to their original efficiency with the global standard. And I think that [it] would take years to achieve that.
When discussing new technologies and the consequent organizational change, Carol’s thoughts went to change management and particularly how to exercise control over the users in terms of making them use the system. A new IT system is a social problem. Carol felt strongly that training is the solution: I think your license to improve is significantly diminished if you don’t teach people how to use the systems, make sure they’re using your systems properly; communicate with the new tools, all those things. You can’t roll something out and not do all the stuff you need to do to make sure people know what they’re doing and they are complying. The thing is, I think for some reason the term “change management” is off-putting. So like, if you tell people we’re going to do training, they’re like, ‘Oh, yeah, well we gotta do training’.
For Klassie, organization change is a very sensitive issue because it involves corporate culture. He argued for the need to engage in careful re-engineering of not only business processes, but also corporate culture and indeed the whole operating environment. Re-articulating the IT systems cannot exceed the organization’s social appetite for change. He also noted that: Unifying processes is also standardizing them [since you don’t want to] end up with all sort of different processes within the organization. … Adopting some international best practices and standardizing business processes helps keep the processes within the scope of the organizational culture.
For Sybil (IT Manager for a Banking company), it was very clear that each IT systems had to contribute to the whole IS and its given orientation. She noted how, in her context, re-articulation of one IT system triggers re-articulation of others. For example, she explained that in her company it was decided that every component should be open-source and developed on a Java-based programming language for compatibility and evolution purposes: We made the choice of open-source technologies because there are connectors available and we do not want to be stuck in a technology where you need to have it all, like your messaging service, your office suite, your database servers, your website, your intranet portal, and so on. If you decide to go for such architecture when a module is being updated all other modules will have to evolve roughly at the same time. On our side, we’ve rather made the choice of Java because it’s free, and there are a lot of resources on the market to recruit for maintenance.
Mallet (CIO of a Public Service agency) had a more extreme view as he repeatedly mentioned that he did not even consider the IT systems when designing the IS master plan. The only criterion for inclusion in the plan was that the chosen solutions should address business functionalities: When I built the master plan, I totally ignored the technologies. We actually never talked about technology. What matters to me is that the functionalities expected by the business are covered, that the tool is solid with solid references, upgradable, not too expensive. Whether it should be in SAS or internal, I’ve got no religion in this field. I don’t want the IS to be hindering the business. If I take them into account, I will bring to the table some constraints that the users are not aware of and I feel it could bring confusion.
Frank, Dave, Leonard, and Walter also leant towards a systems nexus view with an appreciation of the technological underpinnings of the IS. Thus, the system is assumed to involve the amalgamation of a set of discrete technologies or people. We find their comments speak to both the IT systems as well as the new burden of interconnectedness between them. An example is Dave’s comment about artificial assemblies: We have the finance system; we have a plant maintenance system …we have time management systems, and…our HR is really outsourced, so I shouldn’t count that. We do have billing, ordering, and picking up systems—so that’s all in one area. We do have a data warehouse. There’s a lot of use of Access databases … So most of them are, let’s say, I want to use the word, artificially put together. What that means is we found solutions to transfer data from one to another if they are not originally directly compatible.
Similarly, Frank (Product Marketing Manager for a Technology provider) was prone to choose IT systems according to the information fit with the organization’s needs: My opinion is that it’s not an enterprise-wide operation. … you need to segment your users into different classes. You find the classes, you find the class based on whether my user is a mobile user or an office-based user or a remote user, what kind of information will they be accessing for their daily jobs, is it sensitive information, is it regulated or durable information, what kind of devices will they be using, what is their role, their level with the organization. Based on all of that you decide what kind of information they have access to and then you say, ‘okay, now, what is the right tool I need to provide for these people to do their job most productively’. So technology should not be looked at as an enterprise-wide solution that is based on the function of the job. What should be enterprise-wide is that you should have a standard.
However, Frank also indicated his assumption that the setting for the system is a changing, ecological environment that will operate more-or-less independently of control mechanisms. IT systems acquisition decisions must provide an avenue to cope with the evolving organization environment without a lot of re-articulation. Frank advocated acquiring IT systems that added flexibility into the organizational IS to adapt to unexpected change: … you’re buying something to fulfill your current needs, but it needs to be capable to grow as your requirements and your needs grow, and it’s flexible enough to change as your requirements change … A lot of time you’ll see companies that get into trouble because they looked at their current requirements as a snapshot and said, ‘let me buy something that fits this sort of environment perfectly’ not thinking that the moment their requirements were made, some of them became obsolete.
Walter (CIO for a Car Leasing company) also recognized the burden of re-articulation but regarded it as an inevitable way of making an IS by integrating IT systems He suggested that this approach could also be explained by a complete lack of control of its IS from a long-term perspective due to historical elements, including the empirical developments of the IT systems to meet ad hoc business needs as well as mergers and acquisitions, which may lead to the accidental acquisition of bits of IS from other organizations: Historically our IS was built from putting together things with hardly any strategic vision on IT. Applications have emerged and started to complement each other, and to get more complex. This was complemented by the fact that there were some external acquisitions; then of course there were bits of IS which came with the external acquisitions.
Jerzy, Erin, Oscar, and Gertrude provided more indications of this view. They assumed the IS to be the nexus of an interconnected set of IT systems and people. The individual capability of each IT systems is less important than its contribution to system activities as a whole. This viewpoint involves the assumption that the setting for the system is a changing ecological environment that will operate more-or-less independently of organizational control mechanisms. Jerzy (IT Manager for an IT Services company) particularly noted the tensions between people and the technology. These tensions moderate the way each IT system can contribute to the larger system as a whole: The information system helps us retain memories about previous projects. Ultimately, we want to have the system acting as the company’s memory on all existing and historical projects and help recall what we did in the past and facilitate reuse of previous works. This is just like a large search engine for the company.
Although a nexus of IT systems can operate quasi-independently, in a Small or Medium Sized Enterprise (SME) there needs to be a reasonably tight hold on the re-articulation of systems and procedures. Jerzy continued: However, management and control works are still there. We can’t pass that to the information system and people do not 100% trust the system.
In a similar mode of thinking, Erin (Enterprise Architect for a Manufacturing firm) assumed that the interconnectedness of the nexus of IT systems was paramount. She mentioned the very pragmatic nature of iterative re-articulation (tweak and see if it works). For example, when speaking of how the system can change, the notion of replacing an individual technology didn’t enter her thinking. She only considered holistic notions like tweaks to configuration of IT systems or core system changes: The thing is that any time there is a change in how the system functions, this can be attained through two very broad functions. You can change a system by tweaking it; by changing some settings; that can be done here and there to see if it works. The other big part is if it cannot be done by tweaking it, by changing some things here and there which we call configuration changes, they require a change to how the core system works which we call a core change to a program or a function that is written in the system.
But Erin did not see the drivers of such change as entirely controllable. She found it was not just the systems that impacted adaptability, but that the platform was also an important consideration. She described how factors outside of the organizational systems that were related to the ecosystem, affected adaptability: The adaptability obviously depends on a lot of factors outside, instead of the actual systems.
Oscar (Enterprise Architect for an IT Services firm) suggested the metaphor of the architect to discuss CIOs’ activities to highlight the articulation of different but replaceable IT systems as (functional) bricks. Articulation and re-articulation ensure the system’s necessary flexibility, evolutions, and conformity. The conformity of the IT systems components to the overall system avoids any collapse without necessarily requiring specific control: At the end of the day, the job of a CIO is very close to that of an architect. You have a lot of technologies and solutions that are fixed because they are historically embedded in the organization. Based on that, you have to compose your overall house with material in hand. You do not really know what will come out but you handle its dynamic and evolution on a continuous basis. But the emergence of users’ patterns is based on many incontrollable internal and external factors.
Gertrude (Director of Business Development for an IT Services company) classifies users, but then takes the argument a step further; the IS is about translating information, delivering information packaged in a format that the user can most readily comprehend. Her take is that the language must be adapted to the context, and hence she rarely mentions systems, which only serve to confuse people: IS is too generic: people don’t know or care what an IS is. What is being done is integration of software and processes so as to solve problems. We mesh software and people into services and solutions. Most customers don’t care how the solution is reached, don’t care what it looks like. It is purely a business perspective.
The view expressed by the statements above provide indications of IS as a nexus, where the generation of information is a result of the interconnected whole. The system is assumed to be a process, the interaction of the whole set of interconnected system technologies and people. Even though, historically, IT silos may have existed, the individual capability of each system element is now less important than its contribution as a participant in system activities as a whole.
The statements above illustrate the views we found in practice indicating a substantial shift in the meaning of IS in organizations. These statements led us to theorize about how these different views affected the practice of information systems. There were few statements that reflected the classic IS view while most statements reflected the modern IS view. This imbalance serves to emphasize the move toward a new meaning of the term IS in practice. This theorizing led us to propose that the concept of IS as a nexus of IT systems is rising.
Theoretical analysis
Contrasting the classic and modern views on IS
The results of our empirical analysis were unexpected. We initially expected the respondents to adopt systems thinking viewpoints that aligned with their roles (CIO, consultant, etc.). Our data did not support this expectation. Instead, we found that most of the respondents provided statements that fit a different interpretation of the meaning of an IS in current practice. The classic view represents interacting technical and social systems that transform captured and/or stored data into information useful in organizational processes. The opposite view shows a system in which information is produced by various IT systems. Many practitioners see the IS not only as a technical and social system, but also as a nexus of IT systems. Their issues revolve around stitching together information (not just data) obtained from various systems (or platforms) into packages of information that are in a form that is useful to the organization.
The fundamental issues confronting the practitioners at these two extremes are quite different. At the left-hand side of Figure 3, practice is concerned about systematizing devices, people, and complex software that ultimately generate useful information from raw data. This view is that of the origins of IS, but still present today (as are these kinds of systems). At a strategic level, the issue is developing a durable architecture and designing systems that deliver necessary information. Extremes in the practice view continuum of IS.
At the right-hand side of Figure 3, practice is concerned about systematizing information produced by IT systems. These IT systems are often platforms acquired from a marketplace as commodities that deliver information in more general forms, that is, useful to a broad marketplace of the platform’s customer base. A major issue for practice is the acquisition of the ideal platform and important add-ons. At a strategic level, both architecture and acquisition are important. Often the information from these platforms must be processed. Scripts reformat, merge with information generated by other platforms, or otherwise manipulate the information to make it more useful for the organization’s processes. Practitioners are still concerned both with the social system as a component of the IS and about devices and code. But the nature and purpose of the platform often determine the devices that are needed, for example, security platforms require universal second factor-compliant security keys. The programming is often simpler binding (or glue) code, mashups, or configuration settings rather than large, complex programs. Instead of generating information (which is done by the platforms), the issue is translating and reforming the platform information to maximize its usefulness to the organization. (There is also a similar, but reverse upward flow of data and information about the organization’s processes that is not shown in this figure).
Contrasting IS concepts.
However, while traditional/classical studies have focused more on organizational infrastructure comprising IT systems such as Enterprise Resource Planning / Customer Relationship Management (ERP/CRM), or with examining digital platforms, in practice, organizations have moved not only towards digitalization and ecosystems (e.g., Apple and Google) but also towards integrating the information from various systems and platforms. The migration of IT platform systems into the organizational IS is understandable. Their adoption is driven by digitalization of products, services, and business processes (Tiwana, 2014). They reduce operating costs and improve system maintenance, security, flexibility, and adaptiveness (Parker et al., 2017, Song et al., 2018). The constellation of systems’ issues confronted by practitioners who deal with an organizational IS shifts considerably as a result. Each platform adoption involves the platform’s ecosystem. The organizational IS binds not only to the platform but also to its ecosystem. This ecosystem includes tools, add-ons, and other platform adopters in its marketplace. Because the platform is a component in the organizational IS, the organizational IS is an extension of the platform ecosystem. As a consequence of adopting multiple platforms, the organizational IS becomes a nexus, an intersection, where multiple platform ecosystems overlap. When IS practitioners think about their systems issues, their system’s role as a platform ecosystem nexus is among the issues that shapes their view of the organizational IS.
Systems integration instead of system design in the modern IS view
The term nexus is an interpretive concept in our analysis under which we assembled repetitive statements in the data that consistently refer to this complex design idea. The term is our coding, it does not occur in the data. Constructing a nexus of multiple IT systems is not a simple matter. At a programming level, there are the mechanical aspects of configuring switches, hooking up interfaces, and writing glue code. At an architectural level, developing such a nexus depends on promoting the benefits of each IT platform and its ecosystem while jettisoning unneeded aspects. At a systems philosophy level, the nexus is a point at which systems practitioners must resolve any fundamental clashes between the design theories underlying these dissimilar IT platforms and their ecosystems (Pries-Heje and Baskerville 2008).
Carroll and Kellogg (1989) encounter similar complexity created by the use of multiple psychological theories when designing and constructing computer-human interfaces. Their conceptualization of a theory nexus explains how practice encounters multiple theoretical concepts and negotiates the construction of a pragmatic interface. IS practitioners must decide which features of each platform ecosystem to adopt, which to adapt, and which to discard. In such a theory nexus, the design and development process is one of articulation (Carroll and Kellogg, 1989, Pries-Heje and Baskerville, 2008). An organizational IS articulates its constituent platform ecosystems. The concept of being highly articulated suggests connecting with an ecosystem in ways that are more extensive and more pronounced. The articulation process is highly iterative since the adoption of a new platform ecosystem may trigger re-articulation of the nexus with previous platforms (see right column of Table 2).
Articulation is complex because each platform ecosystem may overdetermine its theoretical incorporation into an organizational IS. Because different platform ecosystems overlap, many organizations can integrate with only part of the platform ecosystem. The parts of the ecosystem that are retained in the nexus are called the leading features of that ecosystem. The decision about which parts to keep is made through an iterative process re-articulation of the nexus in a manner reminiscent of action research. Because articulation and re-articulation occur as an iteration of practice and use, they are inherently both social and technical. The nexus is often one that we should regard as socially rich re-articulation because people are deeply engaged in deciding what is working for them, and what is not working. Ultimately re-articulation should yield an IS that has a socially determined, use-determined coverage of the essential parts of any platform ecosystem (essential, i.e., for the particular organizational context). Consequently, each organization’s IS will have processes, features, and limitations that embody a varying depth of coverage with each platform ecosystem that is ideal for that organization.
For example, the right side of Figure 3 gives us the impression that the organization’s IS has a greater depth of coverage of the FinTech platform ecosystem than the CRM ecosystem, simply because its usage ranges across more processes (from Process 1 through Process 4) and a larger part of the IS. In the figure, suppose the CRM platform happened to be adopted after the FinTech platform. Suppose also that the new CRM platform had similar and more useful features for the organization, features that previously had been served by functions from the FinTech platform ecosystem. Turning on these CRM features and turning off the FinTech features involves a rationale of re-articulating the organization’s nexus such that the depth of coverage for the FinTech platform ecosystem is adjusted to fit the result of articulating the CRM platform ecosystem. Consequently, the extent and depth of coverage of the FinTech platform ecosystem and the CRM platform ecosystem would become optimized for the organizational situation.
We conceptualize modern IS as a nexus of IT systems that entails a socially rich, iterative process of re-articulation. In an era where the information system is assumed to be the interaction of a whole set of interconnected system technologies and people, two major practices are needed as inputs to the nexus processes: the integration of information from a variety of sources and the integration of various information systems, platforms, and ecosystems. These integrative practices are complementary and highlight the on-going shifts in the way architects and CIOs articulate how their IS nexus supports their development, operational activities, and strategic decisions.
In an era where the IS is assumed to be the interaction of a whole set of interconnected system technologies and people, two major practices are needed as inputs to the nexus processes: the information and system integrative practices. They are complementary practices that highlight the on-going shifts in the way architects and CIOs articulate their IS nexus and develop their operational activities and strategic decisions.
Information integration can be defined as the process where “complementary data are either physically (through warehousing tools) or logically brought together” enabling systems to be designed for an organization to make use of all the relevant data “even if the data are not directly under their control” (Jhingran et al., 2002). Systems integration can be defined as “the process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.” 6
Discussion: IS as a nexus of IT systems
This paper updates and extends our previous understanding of how systems thinking in the practice of information systems regards information technologies. We have been keenly aware of the need for more research that critically examines the role of the IT artifact (cf. Orlikowski and Iacono, 2001) in IS research. Our work suggests that this research may require a basic re-orientation of our assumptions about how IS professionals regard such artifacts in their context.
Our research suggests that the presence of fundamental IS concepts in practice may not have diminished to the degree it has in research (Lee, 2010). Rather they may have been reoriented for organizing new forms of IS. This shift is not only an abstract linguistic change “the use of the term IS” but also a change in the way practitioners think about IS in both a sociological and technological sense. Accordingly, we sought to discover the ways in which contemporary IS managers regard the IS concept. We began with the apparent conflation of IT and IS. In this area, we sought to discover the ways in which the IS concepts are currently used by information specialists/professionals, and whether this usage could be consistently distinguished from the IT concept.
By highlighting the emphasis on social systems, we identified a useful distinction between IS and IT systems. Surprisingly, the respondents were generally focused on how to organize and execute transitions from a current IS to a future IS. The notion of acquisition dominates these transitions. In designing future systems, the critical issue was how purchased platform IT systems could be integrated into the organizational IS given the constraints and affordances of current technologies and people. Based on the findings, we suggest new dimensions in the current modes of IS thinking, which demonstrate a re-orientation that advances our previous understanding of IS thinking.
Our results indicate that contemporary IS practitioners are indeed concerned with building an IS (including the social system), but they are less concerned with building IT systems. They acquire IT systems (such as platforms) and integrate them into the organizational IS. Concomitant to integrating these IT systems into an organizational IS, practicing professionals must integrate these IT systems with each other. The integration takes place in the context of the information needs of the particular organizational setting. We label this practice information integration. It is about translating and reformatting information so that it makes sense at the IS organizational level. In practice, this translating and reformatting is an outcome of the socially rich articulation and re-articulation of the organization nexus of IT systems.
Future research
In many cases, an IT system’s acquisition involves not only a platform, but also the platform ecosystem. This ecosystem can include a dizzying array of accessory commodities: add-ons and tools. Acquisition, configuration, and integration rarely constitute a simple process. In many ways, they require systems thinking of the highest order: systems integration. Such integration is problematic because the organization system is an IS (with an emphasis on the social system) and the IT system will often lack an emphasis on the human and social system. Integrating an IT system into a human organization means that the IS and its constituent platform ecosystems must be articulated and re-articulated in a nexus of (possibly contradictory) design theories. Such integration also suggests IS practitioners face soft kinds of systems problems reminiscent of soft systems methodology (Checkland, 1981). This problem raises new research opportunities from a renewed interest in a sociotechnical view of system integration. We suggest that the nexus view requires re-orientation towards a modernized version of Checkland’s soft systems methodology as one possible way of addressing issues related to the “nexus.”
For example, some precise attention needs to be dedicated to the acquisition of IT systems. With widespread digitalization of products and services, and equally widespread development and availability of IT systems (such as platforms and open-source software), acquisition has become an intractable systems problem. Exploring the general nature of IT system acquisition and methods for decision-making, in terms of which systems to acquire, is essential: which systems fill organizational needs while simultaneously fitting the existing organizational IS. We label this practice ecosystem integration. It involves selecting and intersecting multiple ecosystems to reach a fluid and dynamic nexus of IT systems.
We also found a potential for further research into how basic systems concepts have evolved in current information systems practice. There is a presence of venerable systems concepts among the reflections of information specialists. We can certainly recognize General Systems Theory in current information systems practice (e.g., Ashby, 1991a, 1991b, Backlund, 2000; Von Bertalanffy, 1972; Boulding, 1956; Flood and Carson, 1988; Klir, 1991). However, the ubiquitous presence of IT in the business literature may have caused these concepts to be revised along pragmatic lines. There may be a curious integration of systems concepts in practice: an integration of information systems, information technology, systems theory, systems thinking, and design thinking. Such an integration is not news. For example, when Thomas Haigh asked Charles Bachman about “systems people” in the early days of computing at Hewlett-Packard, Bachman replied: … they were certainly concerned with systems, but they weren’t generic systems people. They were functionally specialized. I guess they were all systems people, whatever they had to do. They were concerned with: ‘How to manufacture things?’ ‘How to ship things?’ ‘How to pay for things?’ People were specialists in ‘how to do it’. If that makes you a systems person, so be it. It was not specialized to information systems. It could be whatever, but it was a way to handle professional specialization. (Haigh and Bachman, 2006,:42).
We find that acquisition and integration of IT systems is a major issue for IS practitioners today. There is timely IS research underway into the development and marketing of IT platforms. This research is broadly writ in that it regards the platform as including lots of IT systems: digital services, software frameworks, open systems, cloud services, commercial off-the-shelf software, etc. However, one of the major issues faced in practice is integrating IT systems into an organizational IS, especially when there is a need to overcome conflicts with the social subsystem in the organization’s IS. IS research needs new theoretical and methodological work in the social integration of IT systems into an IS. In practice, the understanding of IS today is different from the earlier understanding of IS. Because of this evolution to an IS being more of a system of systems, future research needs to investigate how systems theory informs such an evolved view of IS. Alternatively, research may develop an evolved view of systems theory: perhaps even a form of General Systems Theory 2.0.
Similarly, IT systems acquisition is linked to the commodification and consumerization of IT products and services. Work is needed to investigate the communications practices of IS professionals in terms of how they learn about these systems, and how they develop knowledge about both functionality and even basic knowledge about availability. The technological problem can be viewed most vividly as integrating a cutting-edge new component (“a trendy new app”) into an existing plethora of existing IS components. The systems problem is most typically viewed as one of integration (“how can I add this trendy new app and keep my enterprise up”) in a more-or-less stable systems environment. This is the design focus of a nexus setting, making integrated systems out of commoditized components. IS as a nexus of IT systems is oriented to the ideal design of technological mashups (Gamble and Gamble, 2008). Each design decision involves delivering the desired affordances (positioned appropriately between autonomy and subjugation) or delivering the desired essence-of-purpose (positioned appropriately between compliance and appliance).
This broad-brush review of a new research agenda for IS researchers indicates a wide scope of new research questions. Possible research questions indicated by this broad-brush review include: How can social technical methods, like soft systems methodology, be adapted for designing and developing nexus-oriented information systems? In what ways do nexus-oriented information systems conform to General Systems Theory? How can General Systems Theory be adapted for explaining the evolution of nexus-oriented information systems? How do IS practitioners learn about the commodities involved in IT and IT systems? How do the markets for these commodities operate? How do IS practitioners learn to integrate such commodities into a singular, effective, and purpose-driven nexus-oriented IS?
Limitations
The results of the foregoing study have limitations. As an interpretive and qualitative study, it does not respond to typical positivist criteria such as repeatability and reliability. The respondents, their positions, and the firms represented were not randomly selected but were intentionally selected to provide a diversity of viewpoints on the systems dimensions. Our aim was not to study IS professionals per se, or the usage of the systems by the users; instead, we chose to focus more on managerial positions that involved significant levels of IS engagement. As we are generalizing to theory (Yin, 2009), our validity arises in the care in the design of this diversity, not from the limited quantity of respondents (Lee and Baskerville, 2003). Future research examining the viewpoints of professionals who are digital natives or from digital start-up companies may provide interesting insights.
Conclusion
This research reviews and seeks to address one of the most fundamental questions about the information systems field, namely, “What is an Information System?” The close relationship between information systems and information technology, especially the continued prevalence of the term information technology in practice, leads us to revisit and review these terms with the objective of finding a pragmatic distinction between these concepts. Based on an empirical study of IS professionals across three countries and cultural settings, we propose a modified view of IS. Contrary to the more classical view of the organization-centered information systems, a more contemporary view of information systems has emerged in practice. According to this viewpoint, practitioners see IS not only as a technical and social system comprising people, processes, infrastructure, and data, but also as a nexus of IT systems where the focus is on stitching together information (not just data) obtained from various platforms into packages of information that are in a form that is useful to the organization. This nexus viewpoint recognizes the origins of the classical viewpoint of IS, yet raises issues focused on developing, designing, integrating, and utilizing architectures, processes, and capabilities that can utilize and deliver information driven by the needs of an organization. This conceptualization is important in framing future IS research studies.
Footnotes
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
Notes
Author biographies
