Visualising the Infrastructural Underground

In this letter, I am thinking about the idea of the Underground, which figures powerfully in history as a place of refuge, hideaway or discovery, treasure trove and transitions. From Ancient Greek katabasis legends and chronic deities to Dante, crime rings, Stalin’s torture dungeons, Dark Web and hacker labs, our imagination is captivated by the depth, complexity and obscurity. Underground is as a matter of relations and ecology - its meaning is contemplated by those located on the surface, while it is always present as a part of the environment, being implicated in the juncture of tools and methods, never fully separate from them. Underground is mundane and extremely complex, and is therefore opaque, mostly invisible and usually absent from most research agendas. Nevertheless, the abstract materiality of Underground disturbs and conditions the practices and patterns that appear on the surface. These properties make Underground similar to another complex and mundane substrata of our lived environment rich with computation - digital infrastructure. Locating the infrastructure as the underground is potentially fruitful because it brings forth the problem of invisibility. To study the Underground, it is necessary to make it visible. To do that, I have to go beyond the existing methods of visualisation because throwing light on the Infrastructure Underground involved with the institutions, individuals and technologies calls for the tools which are similarly implicated with the capture and assimilation of knowledge.

Software infrastructure presents a specific case in terms of its invisibility in this context, because it can be said to be invisible in the double sense: on the one hand, it is invisible due to its technical specificity, and on the other hand, it is intentionally kept out of sight by the third-party forces. Large software systems have been known to resist spatial representation from the early days of computing, due to the high heterogeneity and disparity of their components, and therefore always remain invisible in their totality. Furthermore, software invisibility is supported by the market disposition to valorise or to increase surplus value by expanding production and stimulating circulation. Here, invisibility is required, because it helps to conceal the secret expansion of the underlying structural complexity within the software abstraction stack.

Visualisation as technology of extraction

The sphere of operations deals with infrastructure directly by concatenating finance, logistics and extraction. As a goal-oriented activity, operations promote financialisation by employing logistics to extract value. Extraction in this context is the strategic valorisation of the flow of inventory and knowledge which is realised by operations and is brought to motion by the infrastructure as a circulation mechanism of the Infrastructural Underground. To extract, relevant parts of the infrastructure have to be revealed, which makes visualisation a key operations strategy. In a general sense, visualisation functions by creating new relationships and, as media theorist Orit Halpern observes, ‘produces new objects and spaces for action and speculation,’ (Halpern, 2014:21.) - in other words, establishes new layers of abstraction that present particular aspects of meanings ready for symbolic manipulation. Due to its great malleability, visualisation is applicable in a broad range of contexts and is widely appropriated as a unique extractive tool. Value extraction in operations is achieved by selective visualisation, for example, making the flow of finance and inventory transparent to the business, while the totality of infrastructure remains opaque to outside observers due to its cumulative complexity.

Approaching Infrastructure Underground with DevOps, however, reveals that the opaque and monolithic totality has seams along its functional partitions, or fracture planes, which greatly aid the visualisation efforts. Fracture planes are significant in that they not only trace the boundaries within the infrastructure - these planes simultaneously serve as conduits for the organisation’s communications. This structural coincidence between the business and the software resources it operates on was identified by the organisation theorist Melvin Conway in the late 1960s and is now widely used in DevOps. Conway’s Law states that ‘organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations.’ (Conway, 1968: 31.) To operations, it means that to get the most effective visualisation, organisational units have to be split in the same way as the software itself. In the context of this structural coincidence, visualisation provides the formal terms of engagement between the various elements of Infrastructure Underground, - human and nonhuman, software components and agents, - and creates the conditions for the assimilation of knowledge, the main objective of DevOps.

Logistics and DevOps

In his account of large software systems known as enterprise resource planning systems (ERP), media theorist Ned Rossiter observes that ERPs achieve their extractive capacity when they successfully translate data into information products and services. ‘As extraction machines, - he writes, - ERP systems are realised once the data accumulated through routine organisational practices is aggregated and packaged as tradable commodities to third-party clients.’ (Rossiter, 2016:128.) This means, however, that while ERPs play an important part in how relationships are forged within organisations and logistics, they act autonomously as tools for enforcing the divide between the organisation and its data. Here lies the difference between the approach that adheres to the discipline of logistics and the inherently interdisciplinary research that DevOps leans toward. Adopting the diffraction approach of philosopher Karen Barad, DevOps is queer because it takes the becoming of a software system as a performative event, and views software as something that arises at every moment, with its every deployment from the relation to its outsides - users and communities of practice, as well technical objects and components. The shift from looking at data, as in the study of logistical media, to looking at knowledge and the ways of knowing is important in DevOps because it considers more-than-human assemblages in their full complexity without having to divide between human and non-human elements. Once this divide is no longer relevant, we can recognise that the contingent properties of software allow it to operate together with the variety of human ways of knowing, and therefore, there is no single way of thinking about technology, and no one way of creating infrastructures. In other words, the infrastructures do not always have to be placed underground, out of sight and made visible only partially in a pre-assumed way.

Having seen the link between Underground and infrastructure, next time, I’ll take a look at the methods that could be useful when revealing those fracture planes, and what kind of case studies this research can be looking at.

References

• Conway, Melvin E. 1968. “How Do Committees Invent?” Datamation, April, 28–31.
• Halpern, Orit. 2014. Beautiful Data. A History of Vision and Reason since 1945.
• Rossiter, Ned. 2016. Software, Infrastructure, Labor: A Media Theory of Logistical Nightmares. New York: Routledge Taylor & Francis Group.