A Digital Artifact Is Not Just Code

There is a line of thinking in IS research that treats the technology as one thing and the organization as another. The researcher studies how "the organization" responds to "the system," as if those were separable objects that happen to be located near each other. I used to find this intuitive. You can draw a box around the software and a different box around the people. The problem is that when you actually watch what happens inside organizations that use software, the boxes keep dissolving.

The question of what a digital artifact actually is has been taken seriously in IS theory, and the answers are more complicated than they look. Faulkner and Runde (2019) made a careful argument that my study materials confirm in the local library: digital objects are defined by having a bitstring as one of their components, and they can combine both material and nonmaterial components. Their identity and functions depend on social positioning. This matters because it breaks the simple dichotomy. A digital artifact is not purely material in the way a rock is material. It is not purely social in the way a norm or a rule is social. It is both at once, and the two dimensions are not separable without losing something important about what the artifact actually is.

The material dimension is real. Code runs on hardware. It executes instructions. It consumes electricity and occupies server space. A database constraint is a physical fact: when the system rejects an entry that fails the validation rule, that rejection happens because of material operations in silicon, not because of anyone's opinion. This seems obvious, but it is regularly overlooked in IS research that treats technology as purely a social construction, as if the material properties of the artifact do not shape what people can do with it. They do. Constraints are real. Latency is real. The structure of a database schema that forces a workflow into a particular sequence is a material force, not a symbolic gesture.

The semiotic dimension is also real, and it operates alongside the material dimension, not after it. A system carries meaning. The same capability that reads as "efficiency tool" to a manager reads as "surveillance infrastructure" to an employee. The ERP that the CIO describes as "enterprise integration" reads as "one more thing I have to enter data into twice" to the warehouse worker. These are not misunderstandings of a system with a single correct meaning. The system carries multiple meanings simultaneously, and those meanings are consequential. They shape how the system is used, which shapes what it actually does, which shapes the outcomes the organization experiences. You cannot derive the social meaning from the technical specification.

Orlikowski (2007) argued, and my study-hub materials confirm this citation in the context of sociomateriality, that the social and the material are entangled rather than separable. The claim is not just that social and material factors interact. Interaction implies two separate things that happen to influence each other. Entanglement is stronger: the social and the material are constitutively intertwined such that you cannot fully characterize one without the other. The practice of using a system is neither purely human nor purely technical. It is sociotechnical practice, and the distinction between the human part and the technical part is an analytical abstraction that does not map onto the phenomenon as it actually unfolds.

I want to be careful about how far I carry this argument, because some versions of it tip into a kind of analytical dissolve where everything becomes so entangled that nothing can be studied separately. That is not the practical position. Leonardi (2011) offered a more tractable version through imbrication: human and material agencies interlock recursively, but they remain analytically distinct. You can trace what the material agency of a system does and what the human agency of users does and how they become interlocked over time through practice. The analytical distinction is retained. The ontological priority is dropped. Neither humans nor technology gets to be the real cause. They constitute each other through interaction, and the research job is to trace how.

Faulkner and Runde's (2019) point about social positioning adds a layer that I think gets underappreciated. A digital object occupies a social position. A record in a medical database is not just a collection of bits. It is a legal document, a clinical record, a privacy-regulated artifact, a billing reference, and a patient history simultaneously. Its meaning and its function are not inherent to the bits. They come from the social structures, regulations, professional norms, and institutional arrangements in which the digital object is embedded. Change the regulatory context and the same bits become a different artifact with different obligations, different risks, and different uses. The bitstring is materially identical. The social positioning has transformed what the object is.

This has direct implications for how IS research should approach the study of digital artifacts. If you study "the ERP system" as if it were a context-free technical object with properties that hold across deployments, you will get results that do not travel. The same ERP in a German manufacturing company with strong works council oversight and a US financial services firm with a compliance-first IT culture is not the same artifact. It shares a bitstring. It does not share a social position. The outcomes will differ not because of implementation quality or user skill or change management practice alone, but because the artifact itself is different in contexts where its social positioning is different. That is not a confound to be controlled. That is the phenomenon.

The Gartner Hype Cycle, which the newsroom at https://www.gartner.com/en/research/methodologies/gartner-hype-cycle describes as a graphical representation of technology maturity and adoption, is an interesting example of what happens when technology is treated as separable from social context. The Hype Cycle plots technologies on a curve that runs from an innovation trigger through a peak of inflated expectations, a trough of disillusionment, a slope of enlightenment, and a plateau of productivity. The logic assumes that technologies have an inherent trajectory, that the arc from hype to disillusionment to maturity is a property of the technology itself. But that trajectory is not in the technology. It is in the relationship between the technology and the social expectations, institutional arrangements, and organizational practices that surround it. Different contexts would produce different curves for the same technology. The curve is a social artifact as much as a technical one.

This is not an abstract philosophical point. It is a methodological one. If digital artifacts are both material and semiotic, and if their identity and function depend on social positioning, then research that abstracts away from context to find universal properties of systems will systematically miss the most interesting sources of variation. The IS researcher who wants to explain why cloud adoption succeeds in one organization and stalls in another needs to ask not just about technical fit or user acceptance but about what the cloud means in each organizational context. What social position does it occupy? What institutional pressures shape that position? What meanings are carried by the decision to adopt it or resist it? Those questions are not soft add-ons to the real technical analysis. They are part of what the artifact actually is.

I keep coming back to a basic observation from my reading: IS research that treats the IT artifact as a black box almost always produces muddier findings than research that opens the box and asks what exactly the artifact is doing materially and what meanings it is carrying socially at the same time. The two dimensions are not competing explanations. They are two aspects of the same thing, and the field has been trying to figure out for a while how to study them together without collapsing either into the other.