Designing Artifacts for Systems of Information

. This paper reports an exploratory study of information systems (IS) design professionals that offers insight into the evolution of the systems concept in systems design practice. The analysis distinguishes the current object of this design effort as systems of information (SI). SI differs from IS in that SI seeks to maintain the necessary degree of integrated systematicity while retaining or acquiring the necessary technology. IS, in the past, had an implied capacity to build a complete system from the ground up. SI has an implied constraint that certain technological components must be “taken as given” and the design problem becomes one of maintaining an ideal socio-technical system as the various technologies evolve within and around the system.


Introduction
Information Systems and Technologies should lie at the heart of both the research and the practice that comprise the discipline and profession of information systems. The elaboration of information systems (IS) with information technologies (IT) can perhaps be traced to Orlikowski and Iacono's [27] authoritative and widely cited 'desperate search' for the IT artifact in IS research. Many current researchers now seek to ensure that the IT artifact is so central to their research that the systems in which these artifacts should be embedded are simply omitted. Lee [20] listed system as one of the key concepts in the field of information systems research that has been taken-for-granted and has fallen into neglect (the others included information, theory, organization, and relevance). The extent of the problem can be readily perceived in contemporary discourse about cloud computing, service science, experiential computing, and the waves of 'apps' that flood our personal devices -for in all of this, there is little explicit regard for systems.
Where are the systems then? Taken for granted as a tacit assumption? Forgotten or abandoned? Shunted aside or obscured by the clouds? Socially deconstructed, recon-structed or transmogrified into something else? Or are they still here, even though ignored in much of our research and discourse and thus invisible to the audience? Further, what are the consequences of the disappearance or invisibility of systems? Does their absence empower us to new creative heights or impoverish our understanding of how the various components of what we used to call IS fit together? By substituting systems with seductively metaphorical terms like 'clouds' or 'solutions' [24], have we deliberately reinvented ourselves as purveyors of delusive simplicity even as we remain custodians of the complex [19]?
In this article, we explore these systems concepts and their entanglement with our current practice of IS research. We challenge the assumption that IS and IT are identical and instead assert that technology, including design science, technology artifacts and materiality, share the center of the field with socio-technical information systems. We first engage in a review and interpretation of the way IS is conceptualized in the literature. This material is organized into four views, which we term: design engineer, design guide, design gardener, and design therapist. These views, and the common role of designer in these views, resulted from a qualitative study where we explore the perceptions of IS practitioners with respect to the way technology artifacts and information systems are designed and developed. System design was not among the original assumptions when this research was formulated. The role of the practitioners as designers of systems and artifacts arose from the data as a central, shared and defining activity that contextualised widespread practitioner thinking about today's systems and artifacts. Through this process, we reveal current views of technology and systems that will help us to reconceptualize both the technology and the systems of information in contemporary practice. Through an extended discussion, we further reflect on the implications of these views for IS practice and consider future research directions that build on our assertion of the primacy of the system in IS.

Conceptualization of Information Technology and Information Systems
Wikipedia defines information technology as "the application of computers and telecommunications equipment to store, retrieve, transmit and manipulate data, often in the context of a business or other enterprise. The term is commonly used as a synonym for computers and computer networks, but it also encompasses other information distribution technologies such as television and telephones". Oxford English Dictionary [25] defines it 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 [14]. The systems concept is well established with a broad agreement on its general meaning. An analysis of the definitions for the concept finds that the most common textbook definitions are very similar. A system is an assembly or set of interacting entities or elements with relations between them [8]. 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. The connectivity is such that independent subsystems cannot form. A system is a whole that cannot be divided into independent parts. Interaction is important: one element's behavior is influenced by another. The relationships between 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, it means that the element must affect parts of the system and also must be affected by parts of the system [8].
From an IS perspective, the systems concept is anchored in general systems theory [6,9] and systems science [2,17]. Systems theory was quickly adapted as information systems theory [1,18], especially in its "soft" variety that merged action research and systems science into a form of systems thinking and soft systems methodology [11]. The application of systems theory as a means of coping with complexity emerged as a central purpose of the concepts [7,12]. Open, biological, and social systems concepts provide attractive explanations for behavioral changes arising in the social-technical nature of the use of information technologies in the workplace [32]. The notion that communication is the defining operation in a social system offers an essential justifying role for information systems [23]. Also thematic is the notion that systems, once created, can have a certain autonomy and durability, meaning they can be self-organizing [5,30] and self-reproducing (autopoietic) [22,31].
Despite the fairly broad agreement on the defining aspects of a "system", there are rather more diverse definitions of information systems. For example, there are different kinds of things that have been labeled as information systems, such as: organizations that deliver information to their clients; systems of active elements that deal only with symbolic objects (i.e., information); the subsystem within any self-governing system that enables communication between the managerial or operational subsystems of an organization [10]. Lee [20] divided the information system into three interacting and constituent subsystems: the organization system, the data system, and the technology system. A study of more than 20 published definitions of IS confirms this potential disagreement. Most include references to computers or technology, and most refer to organizations; and while some mention society or social aspects, a few entirely ignore IT, 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 [4, p. 451].
One reason for this diversity in the conceptualization of IS may partly lie in the relegation of the systems concept into the background as part of the IS assumption ground. This relegation can be useful when the purpose is to understand the consequences of the IS in its context, i.e., what the IS contributes or creates. As an example, Riemer and Johnston [29] explain the IT artifact as a kind of Heideggerian equipment that, while co-constituting practice and social identity, fades from notice as it is absorbed into use. Its role as the embodiment of a system or as a component of a system is lost to the preeminence of its consequences. It is mainly argued as either distinct from other components or hopelessly entangled with other components such that its role may only be to materialize social purpose without necessarily taking notice that a social-technical system exists. We see similar effects from the debates over whether social and material aspects of information systems are separable or inextricably entangled [21,26]. The latter position effectively black-boxes the social technical system as a somewhat impenetrable sociomaterial system in order to add clarity to its socially constructive consequences. For example, Pentland [28] employs the social materiality concept to help us more clearly observe the ability of a system to retain patterns of action.
The systems aspect of IS is assumed, at best, to be shared and taken-for-granted when in fact there may be some disagreement about just which aspects of the systems concept are more dominantly valued in a particular IS perspective. Based on systems theory, there are two key dimensions along which the systems perspective can vary [3,17]. One dimension aligns with the distinction between the elements of a system versus the relations between, or interactivity of, those system elements [8]. A designer might dominantly value the discrete information technologies that make up the system. Such a component-focused designer would approach a system design task as one of integrating available components. We will designate this approach as an integrating components viewpoint. 1 Alternatively, a designer might dominantly value the relationships and interactions between these technologies, the accompanying data and the people who constitute the system. Such a relationship-focused designer would approach a system design task as one of growing or nurturing a healthy or sustainable ecology within (and perhaps in the outside environment of) the system. We will designate this approach as fitting an emergent ecology viewpoint. To an important degree, this dimension represents a contrast between an IT assumption and an IS assumption.
The second dimension considers the behavior of the elements within a system in affecting the behavior of the system. At an organizational level, this dimension aligns with a design distinction between the ways in which the system interacts with the complex aspects of its environment (such as culture). For our purposes, this dimension is helpful in distinguishing between a 'controlling-the-complexity' design culture versus a 'coping-with-complexity' design culture. For the control perspective, a designer might dominantly value the importance of the system in controlling the complexity of its organizational environment. For example, the system designer might aim to prevent diverse cultural settings from affecting system performance. Such a control-focused designer would approach their design task as one designing a system where the system may help manage and control. 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 [9]. We will designate this extreme approach as a control the complexity viewpoint. Opposite this viewpoint, a designer might dominantly value the importance of the system in matching and interoperating with the complexity of its organizational setting. At this perspective, the designer would view the cultural context of an organization as one that is adaptable to the system, where the system does not deterministically control how work is done. This view is consistent with Boulding's higher levels of systems complexity and is exemplified by societal systems made up of communicating, autonomous human beings [9]. We will designate this approach as a coping with complexity viewpoint.
Collectively, these two dimensions provide indications of the "how" and "why" of systems designers. The vertical axis suggests why systems designers take various design decisions, and the organizational cultural contexts wherein those design decisions are made. The design decisions may be influenced by a flexible organizational culture and environment where systems must be dynamically adaptable to the infinite variety of circumstances. Alternatively, the design decisions may be driven by a corporate mandate to control the behavior of an organization (and its various component parts, including people). The second dimension helps explain how a system is being designed. For example an emphasis on a solution using discrete components represents an IT-centric design 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 design decision. These two dimensions help define four divergent design views of designing the systems aspect of information systems, which we discuss next. We consider these four design views first from the Complexity-Controlling aspect. Where there is a mandate to control organizational behavior, an emphasis on discrete technological components implies a system design view we call Design Engineer. An emphasis on the interrelations between these components implies a system design view we call Design Guide.
System Designer as Design Engineer: The system is assumed to be the amalgamation of a set of discrete technologies and people. Their ability to interact is less important than their discrete capabilities. This viewpoint involves the assumption that the setting for the system is an organization that can be built and controlled. Centralization is frequently a core attribute in this control setting, with the system helping organize and control the organizational complexity.
System Designer as Design Guide: The system is assumed to be the interaction of the whole set of interconnected system technologies and people. The individual capability of each system element is less important than its contribution to system activities as a whole. This viewpoint involves the assumption that the setting for the system is an organization that can be built and controlled. In order to achieve this, system designers must guide the organization in order to discover the strong shared-purpose in connecting technologies and people. The system is designed to organize and control the natural complexity of the organizational context, but is done through relationship-building (both within the technical system and the human community).
Where there is a design culture that places less emphasis on controlling organizational behavior and more emphasis on adaptation between system and organization, an emphasis on discrete technological components implies a design view we call Design Gardener. An emphasis on the interrelations between these components implies a view we call Design Therapist.
System Designer as Design Gardener: The system is assumed to be the amalgamation of a set of independent technological artifacts or people. Their ability to interact with each other or with other system components is less important than their discrete capabilities. Like a gardener choosing which plants to grow in which corners of a garden, this viewpoint involves the assumption that the setting for the system is a dynamic organizational environment that will operate more-or-less independently of control mechanisms. Design decisions must provide an avenue to cope with the infinite variety of circumstances in this environment. The goal of the system designer is to choose the right system elements that will best adapt to organizational complexities, rather than to control them.
System Designer as Design Therapist: The system is assumed to involve emergent interactions among interconnected sets of system technologies and people. The individual capability of each system element is less important than its dynamic integration in system activities as a whole. This viewpoint involves the assumption that the setting for the system is a changing ecological environment that operates more-or-less independently of control mechanisms. The goal of the system is to cope with and adapt to the natural complexity of the environment, rather than to control it. Like a therapist who helps a patient change holistically to a better state, this system design viewpoint is characterized by highly organic assumptions about both technical and human systems. The designer helps the system holistically to cope with change through emergence.

Methodology
We developed our theoretical framework using logic and analysis of concepts in the literature. In order to determine if it reflects design viewpoints held in practice, we planned a qualitative field study using interview guidelines. 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 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 [16,33]. The field study reflects the selection of firms and practitioners who assume differing roles in designing information 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 that represent differing roles. Because this selection process involves interpretation, the qualitative nature of the study remains continuous [33].
Similarly, the design views must also be captured qualitatively. It requires conceptualizations described by respondents of (1) their system setting and (2) their focus given to either the discreteness of technologies or the integrated nature of systems. In this sense, our respondents are selected on the basis that they constitute natural hosts for four viewpoints about technology and the settings in which technology is situated.

Research Procedure
We examined 12 cases, each representing a practicing IS professional involved in system design in the various roles described. We collected data aiming to assess three cases in at least four different roles (vendor, CIO, consultant, etc.). Three cases provide sufficient confidence that design viewpoints discovered would be present in multiple cases (i.e., more than one). Our objective is not to prove any universality, but only to detect cases of the four expected design viewpoints (design engineer, design guide, design gardener, and design therapist). Three cases in each category provide three opportunities to find the expected effects. Further, in the 12 selected cases, we examined cases in two geographic regions in order to reveal possible cultural differences. For each role, at least one case was examined in Hong Kong and at least one case in the USA.
We used a semi-structured interview guide that (1) collected simple demographic information to provide a sense for possible alternative explanations for the conditions; (2) offered the subject an opportunity to describe and explain their role in relation to systems and systems design; (3) offered the subject an opportunity to describe and explain their assumptions about the systems setting; and (4) offered the subject an opportunity to describe and explain their assumptions about technology and its relations. In the interview guide, section (2) was explicit about the role enacted by the subject (the expected independent condition), however both (3) and (4) were intentionally less direct, intending to provide an ideal setting for the subject to reveal the presence in their design thinking of their attitude about the two dependent conditions.

Examples from The Findings
The analysis of the interview data provided illustrations of the way our information systems practitioners conceptualize systems along the dimensions described above.

Design Gardener View
Dave, Business Intelligence Manager in a US Manufacturing Firm of some 21,000 employees, provided indications of this view. The system is assumed to involve the amalgamation of a set of discrete technologies or people. Their ability to interact is less important than their discrete capabilities. Dave described a litany of incompatible systems that were pasted together post hoc: 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 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.

Design Guide View
Horace, a CTO and Chief ERP Architect for a Hong Kong manufacturing firm of some 28,000 employees provided indications of this view. The system is assumed to be the interaction of the whole set of interconnected system technologies and people. Even though, historically, individual technology 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. For Horace, this is about the value of ERP systems and how the standardizing systems fit the business need for sharing information: 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.

Design Therapist View
The system is assumed to be the interaction of the interconnected set of system technologies and people. The individual capability of each system element 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 control mechanisms. The setting is complex, but the goal of the system is to cope with the complexity rather than to control it.
Jerzy, an IT services manager for a small Hong Kong IT services firm of about 10 employees, expressed opinions consistent with this view; particularly noting the tensions between users and the technology. These tensions moderate the way each system component 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 the system can operate quasi-independently, in an SME there needs to be a reasonably tight hold on systems and procedures: 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.

Design Engineer View
The system is assumed to be the amalgamation of a set of discrete technologies and people. Their ability to interact is less important than their discrete capabilities. This viewpoint involves the assumption that the setting for the system is an organization that can be built and controlled. The setting is complex, and the system can help organize and control this complexity. Alice, a CIO of a US manufacturing firm of about 30,000 employees, provided an indication of this view. She points out that technologies and people are entities that must be controlled. Systems provide the means for controlling these discrete elements: Major systems such as ERPs are the life blood of compliance within our organization and are on the critical path to management and control. In our business, the consequence of putting the wrong technology or people into operation can be catastrophic -it can lead to loss of face with customer, missing out on contractual obligations and missing on commitments to shareholders.

Discussion: Systems of Information
The data provided many further indicators of concepts illustrated in the examples above. Our positioning of the statements above should not be taken as instances of positioning each respondent neatly and holistically into one of the quadrants. Indeed, three of the respondents provided bifurcated perspectives. These comments can be interpreted as a respondent whose perspective is in motion, a possible transition from one viewpoint to another. Rather, we argue that the statements likely represent a momentof-reflection that fits the noted position. We are mapping these moments-of-reflection rather than mapping people. While these positions may indeed suggest a general orientation of the person who made the statement, it is quite possible that the mapping would be quite different if the individual reflected on a different situation. We are also investigating the presence of systems concepts among the reflections of information specialists. Such systems-oriented reflections are not the bailiwick of information systems alone. From the outset of the IS field, we have understood that systems concepts broadly inhabit diverse disciplines. 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. [15, p. 42] As a consequence, it is likely that the grid in Table 1 can also be used to map reflections from a complexity-control, complexity-coping, component-integrating, and ecology-emerging perspective across a diverse range of human occupations. Our particular interest however, was observing information specialists reflecting on systems concepts, as opposed to other kinds of specialists.
We sought to discover the ways in which IS management employed the systems concept. We began with the apparent conflation of IT and IS. In this area, we sought to discover the ways in which the systems concept was currently used by information specialists, and whether this could be distinguished from the technology concept.
We found indications that an entanglement between IT and IS was less of an issue than an entanglement of practice and design within current IS management thinking. Surprisingly, the respondents were generally focused on how to organize and execute transitions from current systems to future systems. They were designing future systems, given the constraints and affordances of their current technologies and people.
We distinguish the object of this design effort as systems of information (SI). SI differs from IS in that SI seeks to maintain the necessary degree of integrated systematicity while retaining or acquiring the necessary technology. IS, in the past, had an implied capacity to build a complete system from the ground up. Even if this capacity is not a necessity, SI has an implied constraint that certain technological components must be "taken as given" and the design problem becomes one of maintaining an ideal sociotechnical system as the required technologies evolve in and around the system. The reconceptualization of IS as SI reflects the reversal of field that is taking place in the practice of systems design. It involves the practice of experiential design, a form of design and redesign that is contemporaneously integrated with the lived experience of the object-of-design.
For example, the presence of an ERP (or ERP-like) system at the enterprise level is often taken for granted in the systems reflections of our respondents. Their challenge is to acquire new capabilities (i.e., new technologies) while maintaining systematic qualities such as efficiency, effectiveness, usability, etc. The problem, from the CIO level down, is how to satisfy new demands from internal stakeholders or external clients by acquiring and integrating new technologies without compromising the enterprise's essential socio-technical systematicity. They were thus engaged in the difficult design problem of getting from here to there without wrecking the overall system's benefits. The technological problem can be viewed most vividly as a cutting-edge new component ("a trendy new app"). The systems problem is most typically viewed as one of integration ("how can I add this trendy new app and keep my enterprise up"). This is the design focus of SI, making integrated systems out of commoditized components. SI is oriented to the ideal design of technological mash-ups [13].
The SI design problem is no less socio-technical than the IS design problem. IS designers focused on building usable information systems with ideal social and technical characteristics. The SI design problem is different in that it is more similar to architectural programming because of the mash-up constraints. Certain technological features are given and the population of users is given. The SI challenge is to program the entanglement between these people and that technology as well as the entanglement between that technology and the pre-existing system -and data.
As a consequence, the entanglement artifact is different from other kinds of artifacts. The SI designer is designing not only the typical artifacts, such as technologies, models and processes, but also the entanglement (programming the mash-up). This new kind of artifact, the programmed entanglement, presents a more complex systems problem to the designer, who needs to exercise not only considerable care and innovation, but also wisdom and contextual intelligence. The large number of predefined constraints and affordances that arise when programming (or reprogramming) a mash-up in the presence of a new technology or component constitute a significant issue. It appears that this new kind of SI design is being carried out at widely varying levels of the IS function within the organization.
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 in the cases were not random, but were intentionally selected to provide a diversity of viewpoints on the discrete complexity-control, complexity-coping, component-integrating, and ecologyemerging. Our aim was not to study designers per se, choosing instead to focus more on managerial positions. The validity of theoretical generalizability arises in the care in the design of this diversity, not from the limited quantity of respondents. While we were certainly successful in achieving an ideal spread of reflections, the data did not support classifying a respondent entirely in one quadrant or another. Rather, respondents appeared to situate themselves in whichever quadrant was appropriate for the moment at hand. Thus, given an infinite variety of organizational circumstances, each with its own technologies, problems and people, so an equally infinite variety of positions can be proposed in order to ensure optimal organizational functioning. The dynamic flexibility and contextual intelligence that this requires of the SI designer implies that any design space within the systems quadrant may be inhabited at any one time by the same designer, depending on the circumstances. The implication for IS researchers is that they need to be more sensitive to organizational circumstances (people, problems, technology) when they analyze either the behavior of designers or the artifacts that they design. A purely design guide perspective, for instance, cannot hope to meet the exigencies of all conditions. In different circumstances, and in particular as an organization evolves, so perspectives can shift. As Leonard pointed out, as his company has grown from a local to a global logistics provider, so his view of systems has shifted from one of gardening to one of guiding. Other companies may see the reverse, or something different: there is no ideal state that can apply to all companies in all circumstances. However, benchmarking against the competition can be a useful exercise.

Conclusion
Our research indicates that the conceptual conflation of information systems and information technology is misleading. Information specialists reflect differently on their work using these two concepts in distinctive ways. From this perspective, little has changed in the way IS and IT concepts are present in practice. However, we did discover that the way information specialists are conducting design in their work is quite surprising. Rather than designing information systems in holistic ways, information specialists are designing system usage programmatically, being very careful to preserve the systematicity of information practices, while acquiring the necessary current technologies. We term this new aspect of design practice systems of information to distinguish the particular practice of programming the entanglement of new technologies with old technologies and the entanglement of technologies with people. This entanglement is a reversal of field in the practice of systems design. Designers are experiencing their lives within an environment that is defined by previous systems designs while concomitantly experiencing their own designs as new technologies are inserted, appended, or overlapped with old systems. The need to maintain integrated systematicity while retaining or acquiring the necessary technology is central to SI. System design today only rarely evokes a capacity to build an entire new system from the ground up. That form of systems design is the "old" IS. Today, systems design operates on a platform constrained by a set of technological components must be retained in and for the new system. The design problem has become one of maintaining an ideal socio-technical system as the required technologies evolve in and around the system.