Turbulences of speeding up data circulation. Frontex and its crooked temporalities of ‘real-time’ border control

ABSTRACT

In the last decade, various information systems have been created to process data in ‘near to real-time’ across agencies to ‘improve situational awareness and to increase reaction capability’ at the external borders of the European Union. While the policing of mobilities is increasingly discussed in terms of instantaneity, speed, and real-timeness, little has been said about the temporalities of data mobility. This paper focuses on the socio-technical architectures that are generative of data mobilities and analyses the temporality of data circulation as the outcome of a contingent formation of various actors, sites, and materials. Based on an indepth analysis of the Frontex information system Joint Operation Reporting Application (JORA), it works out several sources of turbulence that turn data mobility into a ‘crooked’ process of patching multiple temporalities and paces together. It will show how the implementation of JORA faces data frictions, issues of data quality, the synchronization of multiple orderings, and the clash of temporalities of border control practices on the ground. Thus, the infrastructuring of data circulation has effects on interorganizational forms of collaboration and knowledge production as well as on border work in the field of European migration and border control.

KEYWORDS:

• Governance of migrant mobilities
• data mobilites
• real-timeness
• infrastructures
• turbulence

‘Real-time’ border control and its temporalities of data circulation

In the last decade, the European Border and Coast Guard Agency, also known as Frontex, has heavily invested in information infrastructures – namely the Joint Operation Reporting Application (JORA) and the European Surveillance System (Eurosur) – that gather, distribute, and assess data in order to observe, monitor, and intervene in migratory mobilities in the Mediterranean Sea and beyond in near to real-time. Although these two systems do different things (Tazzioli 2018), they both process data about ‘illegal’ border crossings from the EU’s external borders via national coordination centers to the Frontex headquarters. There, such data is enriched with other data about routes, smuggled goods, or ‘facilitators’, with pictures of boats and with satellite and drone images, and is put on interactive maps with multiple layers. The declared aim of both information infrastructures is to ‘provide a constantly updated picture of the irregular migration situation at the external borders of the EU’ (Frontex 2014, 35) in near to real-time in order to ‘improve situational awareness and to increase reaction capability’ (OJEU (Official Journal of the European Union) 2013, 14; Carrera and den Hertog 2015).

Current EU initiatives that drive the datafication and digitalization of the governance of mobilities make time a central issue. Through new technologies and the ‘effective control of information’ (Trauttmansdorff 2017, 116), instantaneity and speed appear to be the premise for the ‘possibility of projecting controls as quickly as possible at any given point’ (Jeandesboz 2011, 8). However, it cannot be taken for granted that data flows smoothly like a ‘global movement of weightless bits at the speed of light’ (Negroponte 1995, 12), making everything and everyone ‘always-everywhere available’ (Green 2002) through opaque algorithms and a gigantic mass of information (Berry 2011). Considering the complex and heterogeneous landscape of European border control, all the devices, information systems, sensors, platforms, and other technologies which have to be interlinked, and all the communication and information channels between authorities which have to be installed (EU COM 2013, 13), the project of a ‘common monitoring and information sharing environment’ (EC quoted in Jeandesboz 2008, 9) appears to be a complex and challenging endeavor loaded with overflows, frictions, and ongoing controversies (Sontowski 2018).

Quite some work has stressed the great impact of new technologies and data assemblages on the governance of migrant mobilities by studying reidentification arrangements (Haggerty and Ericson 2000; Adey 2012), the management and differential sorting of populations (Lyon 2002; Ruppert 2011), or the spatial and organizational proliferation of borders (Dijstelbloem and Broeders 2015). Yet, little research has been conducted on the creating of data flows across organizational and territorial boundaries, although this forms the basis of such data-intensive forms of mobility management (Tsianos and Kuster 2012; Pelizza 2020). Drawing on recent work from the realm of science and technology studies (STS), this paper problematizes the taken-for-grantedness of smooth, and real-time data processing, which all too often forms the basis of both enthusiastic and dystopian visions of real-time governance of migrant mobilities through technological means. Based on an ethnographical inquiry into the Frontex information infrastructure Joint Operation Reporting Application (JORA), it turns to the physical and organizational architectures that are generative of data mobilities (Lin et al. 2017) and decomposes real-timeness as an outcome of a ‘crooked’ process of patching multiple temporalities and paces together.

By studying the temporalities of data circulation, this paper contributes to recent work on the temporalities of the governance of mobilities. The discourse about situational pictures, situational awareness, and real-time data processing hints at a reconfiguration of the temporal logic of ‘state mobility’ (Mountz 2011). Through information systems like Eurosur and JORA, and the interconnection between control rooms and border guard units, the policing of migrant mobilities develops into something that Walters calls ‘live governance’ (Walters 2016). Instead of responding to and making sense of events after they have happened, live governance seeks to intervene in ongoing events while at the same time monitoring and evaluating them. Binding distant actors together in ‘synthetic situations’ (Knorr-Cetina 2009) thus makes border checks and surveillance one and the same and expands the state’s room for manoeuvre (Bellanova and Duez 2016). With the possibility of monitoring migratory movements and border crossings far from the authorized passage points via various surveillance technologies and of coordinating the distributed activities of border guard units, technologies, and devices from distant control rooms, state mobility becomes more agile. The control of migratory movements is carried out in other spaces, such as at sea, in the mountains, or elsewhere (Walters 2016, 802).

The datafication and digitalization of the EU’s frontiers also reconfigures the temporality of the production of state knowledge on migrant mobilities. In her study of JORA and Eurosur, Tazzioli points out that these information systems bind together the detection and interception of migrants ‘on the spot’ and the production of risk analysis in faraway coordination centers and headquarters. While ‘border crossing incidents’ are monitored in real-time, they are translated into compatible data that can be archived and merged together in order to produce future-oriented risk scenarios that open up spaces of intervention and make the state ‘prepared’ for potential migration threats and border stress (Tazzioli 2018, 273). Eurosur’s and JORA’s mapping functions are especially important in this regard, as they translate events at the margins of the EU into ‘border crossing incidents’ with a set of details and an assessment of their ‘impact’, that is, the estimated costs, resources, and technical difficulties involved in managing a certain migration phenomenon (Tazzioli 2016, 567). Hence, such mapping devices translate real-time monitoring into a spatial crafting of constantly updated border zones of intervention.

With regard to such border assemblages, which heavily rely on data infrastructures, Broeders and Dijstelbloem (2016) stress the importance of ‘centers of calculation’ and databases. While centers of calculation as intersections of communication and information channels store, combine, and distribute data and monitor and maintain the socio-technical set-up, databases merge and reassemble data from various sources as a ‘great information equalizer’ (Broeders and Dijstelbloem 2016, 244). However, those processes that are ‘all about [accomplishing] interoperability, combination, sorting and synthesizing heterogeneous sources and types of data from a multiplicity of sources’ (Tazzioli and Walters 2016, 453) produce data and infrastructural frictions.

Although often conceptualized as stable entities, data undergoes transformations when traveling from one site to another. Edwards (2010, 84) stresses in his seminal work on large-scale information infrastructures that ‘data from many locations, consistent across both space and time [requires] a lengthy chain of operations, including observation, recording, collection, transmission, quality control, reconciliation, storage, cataloguing, and access’. As Pelizza (2016) makes clear, ‘any of these translations – be it from one actor to another, or between two different materialities – constitutes an opportunity for data loss or corruption, that is, it offers an interface for data friction’. In her work on Dutch Kataster registers, she shows how the attempts to silence data frictions come with a price: they stretch the length of the circulation path and add steps of translation – which involves further data frictions (Pelizza 2016, 43).

Moreover, empirical inquiries in science and technology studies (STS) have brought data circulation down to earth by carving out the complex, laborious, and challenging work that holds a multi-linear ensemble of human and non-human entities together (Bowker and Star 1999). Analyzing infrastructures as an ongoing accomplishment – infrastructuring – emphasizes all the activities of storing, tracking, displaying, and retrieving information across a wide array of devices, tools, interfaces, and systems. Susan Leigh Star (1999) points out that a functioning information infrastructure emerges when different places, with local practices, situations, and specific personnel, are translated into one another via translocal chains, standards, formats, or categories and when larger-scale technologies are implemented in such a way that they are used in a natural, ready-to-hand fashion by actors at multiple sites. Such an analytical lens opens up ostensibly stable and technological information systems and makes visible the mediations between multiple social worlds, actors, and interests, which are flanked with tensions, frictions, and all sorts of tinkering and work-arounds (Star and Griesemer 1989).

Following such work, this paper will show how the temporality of data circulation is the outcome of a contingent, procedural, and heterogeneous formation of various actors, sites, and materials (Weltevrede, Helmond, and Gerlitz 2014). Drawing on an ethnographical case study between 2016 and 2018 on the Frontex information system JORA, it will work out some sources of ‘turbulence’ (Cresswell and Martin 2012) that turn smooth and real-time data flows into a crooked process of infrastructuring which not only faces multiple temporalities and paces but also various frictions and tensions. This article will demonstrate how the distributed activities of data collection, processing, and usage across various border authorities produce issues of data frictions (II) and data quality (III). These enact a pace of data processing with several validation steps and make data processing slower and, to some extent, unreliable. Furthermore, it will work out how the implementation of an information system in the social worlds of migration and border control produces problems of synchronization. Collecting data for JORA while carrying out border operations makes it necessary to adapt the temporalities of data collection to the design of the information system as well as to the temporalities of a border operation. This enacts a pace of a bit-by-bit data upload (IV). And it will show how data mobility is not the only matter in the governance of migrant mobilities but has to be orchestrated with other concerns and other orderings of mobility. This produces a clash of temporalities on the ground with the consequence of further delays in data upload to JORA (V). In order to make such patchworks of various paces of data upload and various temporalities of data practices with all its variations and contingencies manageable, centers of calculation endeavor to monitor, support and streamline the arrangement – albeit, at least in the case of JORA, with limited success. Yet, it finds a work-around by cutting validation short and making preliminary incident reports accessible to different Frontex personnel, especially to operational management (VI). The interplay of data frictions, issue of data quality, the adaption of a system to the ‘real world’, clashes of temporalities because of intersecting orderings of mobility, and work-arounds produce an ongoing de- and reordering of mobilities and thus not only shape the temporality of data circulation but also the governance of migrant mobility. In the last section, this article will sketch out how data infrastructures affect multiple sites and temporalities of governance, how they produce an EU-wide but heterogeneous data space through interconnection and replication, and how they produce their own ecologies in which they can operate and thus shape its users and their practices. In this sense, digital infrastructures are by no means non-political but produce new forms of power, and agency and reconfigure the field of the governance of migrant mobilities (VII).

The configuration of a centralized system and the displacement of data frictions

Since 2011, the creation and processing of ‘Frontex incident reports’ has been organized via the information system Joint Operation Reporting Application (JORA). It is set up to gather data on ‘border crossing incidents’ happening in the operational areas of Frontex border operations. In such operations, Frontex enlists border guards and assets from EU member state police and coast guard agencies. In Greece, for example, hundreds of guest officers, vessels, aircrafts, and helicopters from dozens of EU member state agencies have been deployed since 2013. In collaboration with Hellenic police and coast guard units, they carry out aerial, sea, and land patrol missions, detect boats crossing the Mediterranean Sea from Turkey to Greece in the Aegean Sea by thermo vision units, identify and fingerprint migrants at the registration and identification center in Moria, conduct investigations, and more.

By delivering reports from border guards not only from Greece but from all across the EU, collecting them at Frontex headquarters and converting them into ‘border crossing incidents’ which can be shown on an interactive map of Europe, Frontex seeks to ‘maintain situational awareness’ (Frontex 2014, 35). Such maps promise to provide insight to the ‘real-time situation’ at Europe’s external borders (Frontex 2016), which means that an event is registered as it occurs with little or no communications latency. But how to integrate various authorities and border guard units with their particular reporting routines, languages, and data systems into a common set-up of data gathering and processing? In 2006, Frontex published a study stating that among the eight EU countries along the Mediterranean seaboard, responsibility for maritime issues was shared by 30 government ministries and 50 different authorities. Georgios Vourekas, head of the Sea Borders Sector, pointed out that ‘there were no standard operating procedures regarding border control. The technologies used by the member states overlapped, or were incompatible. It was chaos – and it wasn’t sustainable’ (Frontex 2014, 55).

In contrast to Eurosur and other information systems which are meant to interlink different systems and make them interoperable, it was decided to design JORA as one single, centrally organized, and highly standardized information system. In this solution, only a few national police officers are selected and included in the reporting procedure by giving them a temporary account on a need-to-know basis. User roles are incident reporters, local and international coordination center incident verifiers, and Frontex Situation Center incident approvers. While the setup of one Frontex internal information system that includes only a few border guards minimizes interoperability problems and data friction, it comes at the price of making the process of data collection more complex.

As the few incident reporters cannot gather the data all by themselves, they rely on further border guards who collect data for them. To put it differently, minimizing the number of incident reporters requires bringing in additional reporters. This, however, turns the reporting of an incident into a distributed and hardly manageable practice with many more translation steps and other frictions occurring along the chain of data collection. As we will see below, this causes delays, waiting times, and a fragmented pace of data entry. It also pushed the incident reporters into the position of a coordinator. And indeed, most of the incident reporters we talked to were based in coordination centers waiting for data collected elsewhere.

In addition to incompatible information systems, another issue of data friction caused trouble: How to achieve compatible datasets while taking into account changing personnel from different authorities across the EU with differing reporting styles and languages? As Asseco, one of the leading IT companies involved in the design of JORA, made clear on their website, one of the main tasks was to ‘minimize mistakes caused by manual data collection and processing’. All incident reporters across Europe should gather the same information, and Frontex’s answer to this was, again, standardization. The Frontex development section designed one template for all operations and user scenarios and defined one extensive item list of the incident.

The Frontex incident report template consists of almost sixty items that give quite a detailed picture of the so-called border crossing incident. The items are packed into three different sections: ‘general information’, ‘specific information’, and ‘additional information’. While the first section gives details of which kind of incident it is, when and where it happened, if it was a search and rescue mission or which impact level it has, the second section asks for ‘person’s information’. What is the country and place of departure, how many victims of trafficking or even ‘death cases’ were found in the vessel? Which gender and presumed nationality does a person have? Is the person accompanied, and which (forged) documents does she have? The third data package entails details of the vessel. What kind of vessel is it, which flags or signs, how many engines, and what length is the vessel? Are the engines operational and is there a functioning GPS system on board, and which and how many goods have been smuggled? In comparison to shift reports, which also entail a very large free entry field for inserting a report about who was involved, when, where, how, and why, the incident report is almost completely standardized. The reporter clicks on predetermined entry fields in an online template, all of which require specific information.

The particular design of the template not only defines the datasets by a list of standardized and computer-readable classifications but also configures its user by ‘setting constraints upon their likely future actions’ (Woolgar 1991, 59). The template development section has also inscribed so called ‘mandatory items’ into the incident report template. These items are especially important to fill out. To make them visible to the reporters and to distinguish them from the other items, the template designers marked them with an asterisk. However, to fully ensure that such items are filled out, JORA developers added an interlock. This means that reports can only be finalized and sent to the next instance if all mandatory fields are filled out. When we compare the JORA incident attribute lists of the years 2013, 2014, 2015, and 2017, it is notable that more and more items are turned into mandatory ones. In just the ‘general information’ section, the number of mandatory items grew from nine in 2013 to fourteen in 2015 and to twenty-one in 2017, covering details regarding the operational area, date and place of detection and interception, and the incident impact level.

To put it in more analytical terms, in order to reduce data frictions and to make data compatible, the Frontex template developers prescribed an online template that strictly defines what to report. In doing so, they largely delegated a ‘program of action’ (Latour 1990) to a device that works successfully against a plurality of different habits and styles of creating shift reports by border guard officers from member state agencies all across the EU. The border guards’ task, to write a report carefully and to ensure the report has been written in the correct way and with all necessary information, has been substituted, step by step, by the reporting device. First, items were prescribed into the template. Then they were classified as mandatory and marked with a sign in order to ask the reporters to gather at least this information. Finally, this was replaced with an interlock mechanism that was independent of the discretion of the border guards. In other words, the ‘must-do’ articulations of what-to-report have been translated into ‘what-has-to-be-clicked’ through the technological design. In this way, the reporters have been disciplined to gather precisely the information the template requires, and the rigid design of the reporting template ensures extensive, standardized, and compatible datasets.

With this, Frontex addressed the problem of incompatible information systems and data gathering practices through a centralized information system (JORA), a strict definition of user roles and access rights, as well as through the creation of an almost fully standardized reporting template with mandatory items. In the end, extensive and standardized data can automatically be uploaded to a centrally organized Frontex database and be used by various actors for different outputs. The other side of the coin is that this infrastructural setup made data collection a distributed and complex practice. As we will see below, this produces frictions between data collection and bordering practices and slows down the reporting process substantially.

Data quality and the creation of a validation Chain

Although Frontex seeks to ‘maintain situational awareness’ (Frontex 2014, 35) and to get a grasp on ‘the real-time situation’ at Europe’s external borders (Frontex 2016), this is not the only agenda. The other is to enhance the possibility to gather and analyze data for different outputs and audiences. According to Tazzioli (2016), the core of ‘the (nearly) real-time mapping rationale’ of JORA lies in the quick reaction to migrants’ movements ‘by anticipating future migratory events through risk analyses’ (576). And indeed, the data from the reports is used not only for a situational picture in the Frontex Situation Center but also for detailed risk analysis by the Frontex Risk Analysis Unit (RAU) and the Frontex Risk Analysis Network (FRAN), or for ‘Tactical Focused Assessments’ for the operational management of border operations.

Recording and recoding the past in order to create a statistically constructed future (Broeders and Dijstelbloem 2016) requires reliable and valid data and brings issues of data quality to the table. Pelizza (2016) contends that there are different notions of data quality. Data quality can for example mean producing a universal application of data across various information systems achieved by objectivization and standardization or defining ‘authentic’ or official data hosted by a state agency being appointed as a warrantor (Pelizza 2016, 44). In the case of JORA, we find two different approaches of data quality entangled with each other. The following section will work out how a reversible validation chain both ‘hardens’ data and produces a European-wide data pool with data shared across national police and EU databases. This, however, stands against the circulation of data in real-time.

Frontex made a great effort to institutionalize a Europe-wide validation process. JORA developers inscribed a validation procedure into the technological set-up of the information system. Instead of forwarding emails, the system automatically delivers the finalized reports to the validator responsible. After the incident reporter has finalized the report, she clicks on the ‘send incident’ button and the report is automatically sent to a validator at the local coordination center, then to a validator at the international coordination center, and finally to an incident approver at the Frontex Situation Center in Warsaw. Data thus becomes valid step by step through a number of attestations that have to be given by different personnel (Figure 1).

Figure 1. JORA validation chain 1

Crucial for the performance of valid data is the reversibility of the validation procedure. There are two options inscribed into the script: either to accept the report and to forward it or to reject it and send it one step back within the chain. The system not only enables going back and forth in the validation procedure but also re-initiating it from the very beginning. For example, an incident reporter told me that it happens that police investigators, also called ‘debriefers’, contact the incident reporter one day after the incident has been finalized and give new details concerning particular persons and their presumed and claimed nationality (Incident Reporter 10/04/2018). In such a case, the incident reporter can open up an already finalized report again and modify it, which means that the validation procedure starts from the beginning.

The validators also crosscheck the content of an incident report with other shift reports. The local and international coordination centers receive all shift reports from the border guard units involved in an operation. Each unit produces two reports: in the case of the sea, aerial, and thermo vision units, one report comes from the commanding officer and one from the Hellenic liaison officer; in the case of land patrol screeners and fingerprinters, one comes from the Frontex team leader and one from the Hellenic police team leader. Basically, data is accepted as valid when the two shift reports of a border guard unit state the same thing and when all the different shift reports correspond to each other and to the data entries in the JORA incident report. In this sense, JORA validation is grounded in a reversible ‘chain of reference’ (Latour 1999), which starts with the border guards in the field who then write their shift reports, whose data is then cross-checked and replicated in JORA, which is then again squared with the shift reports by different personnel. In cases of mismatches, the inquiry goes back step by step along the chain: if the incident reporter finds a mismatch, she comes back to the field officers; if the validators find a mismatch, they contact the incident reporter.

Yet, the reversible validation chain produces not only ‘hardened’ data but also a European-wide shared data pool. The work of the incident reporter basically is to crosscheck shift and mission reports from border guard units coming from various national police and coast guard authorities and then – if data is the same – to replicate particular data sets in the Frontex incident reporting template. Also, the validators especially check if replication has been conducted properly. In other words, this replication procedure makes various EU and national databases host the same data – which is especially important for the exchange of data and the collaborative creation of statistics, for instance via the Frontex Risk Analysis Network (FRAN). In this sense, data quality is also achieved in the sense of a universal application of data. This implies not only the standardization of reporting templates and classification sets but also the active manual care work of Frontex officers who keep data in various reporting channels the same.

In this section, we have shown that risk analysis requires valid data and makes issues of data quality germane. By the implementation of a reversible chain, data quality is achieved in two different ways: Data is ‘hardened’ and data is kept the same across various EU and national databases. Both are crucial for the exchange of data and a collaborative production of risk analysis. Yet, the implementation of reversible validation steps thwarts a speedy data processing to Frontex headquarters, as reports may be sent back or validation may be re-initiated from the beginning.

Synchronizing multiple orderings of mobility: data collection for JORA while carrying out a border operation

In the following section, we will work out how the gathering and processing of data turns out to be a distributed, scattered, and hardly manageable practice that enacts a pace of a bit-by-bit data upload. The border guards, who collect the data, need to adapt the prescribed and mandatory items from JORA to their practices of reporting while carrying out a border operation. To put it in more analytical terms, the temporality of data collection is shaped by turbulent processes of description and interference: Akrich (1992) emphasizes to study the ‘descriptions’ of technologies, that is, the multiple, and often surprising ways of how ‘real users’ interact with technologies and produce overflows, frictions, work-arounds or tinkering. Moreover, when information systems are descripted, they interfere (Law 2004) with other orderings: In the case of JORA, the policing of migrants’ movements with its own policies, routines, and urgencies on the one hand (border operation), and the control of data collection and processing with its constraints by technological design and its reporting practices on the other hand (border monitoring). As we will see, the description of JORA and the interference with other orderings produce problems of synchronization and ongoing activities of reordering the temporality of data collection as well as the pace of data-upload.

The incident reporting template requires more than sixty items and asks for details of the ‘detection’ of boats/migrants, the ‘interception’ of boats/migrants and ‘smuggled goods’, as well as details of the vessel and of the intercepted persons. The incident reporter can only finalize and forward the report after she has received all the ‘mandatory’ pieces of information regarding detection, interception, examination, and identification. As we see in Figure 2, these pieces of information are scattered throughout the whole course of a border operation. In this sense, reporting has to adapt to the course of the border operation, which is the result of distributed activities and paces (Figure 2): Frontex thermo vision vehicle units, Frontex and Hellenic coast guard sea units, and Frontex and police aerial units watch out for incoming boats. When a boat with migrants is detected in the Aegean Sea, sea and land patrol units are informed. In case a sea patrol unit intercepts the boat, the migrants are brought to the port of Mytilini. After a first count and a preliminary screening, the migrants are transported to the registration and identification center in Moria. In case a land patrol unit intercepts the migrants somewhere on the island, they prevent them from leaving the area, secure the work of medical services, provide necessary help for migrants in need, and start with a quick screening. After that, they arrange bus transportation to Moria. There, the arrivals’ identities are checked and authenticated, fingerprints are taken, basic medical checks are conducted, and official papers are handed out (Pollozek and Passoth 2019).

Figure 2. Synchronizing incident reporting

These activities take place partly in parallel, partly one after another. The operation can develop quite differently depending on the number of arrivals, their state of health, and if there are young, pregnant, or old people on board, and depending on the routes and landing of the vessels, the weather and the waves, the conditions of gravel roads, or depending on the time of the day. This is why joint border operations do not and cannot have a fixed schedule but rather develop step by step and in a contingent way. Consequently, the collection of data falls apart into a distributed, scattered, and hardly manageable practice.

This is also because most of the reporting practices and the data to be collected are not in accordance with the relevancies and urgencies of a border operation. Some data can be gathered right away during an operation. When a boat with migrants is detected in the Aegean Sea, the commanding officers of aerial and sea vessels radio the coordinates and some details of the boat, the number of migrants on board, and their condition to the international coordination center. After approval, the international coordination center delivers the information to the local coordination centers, where, at least on Lesvos, the incident reporter is based and inserts this information into JORA. On this occasion, the data is relevant to both JORA and the border operation. It is of utmost importance to inform the other border guard units immediately as well as the control rooms including the center for search and rescue operations and to coordinate the operation instantly. Other information however, for instance on the examination of vessels or on the intercepted persons, is mostly delivered after a mission in the form of a shift report. This is not only because details about a vessel, or about smuggled goods require some sort of examination, but also because they are used by police investigations which will be initiated later on. Consequently, there are other more pressing tasks.

The temporality of data collection is also hard to estimate because it is the border guards who determine its unfolding to a great extent. They assess the relevancies of a situation and negotiate between border and reporting practices. They decide how and when to do the reporting. We were told of border missions where only a handful of police and coast guard officers, together with NGOs, were thrown in messy situations with a lot of people in distress arriving all at once on Lesvos’ shores. As the first priority is to provide basic help and to secure the site, there was neither time to report continually nor to check on all the items required for the report. The pace of reporting thus varies and reporting practices are often put aside. While the border guard units on site are the pacemakers of data collection, the incident reporters can only adapt to their paces – which often means simply waiting.

But it is also the nature of some of the datasets that they require a laborious and time-consuming practice of data collection. This also affects the temporality of reporting. ‘Person’s information’, for example, asks for aggregated data from migrants (e.g. gender or presumed nationality) and for details about their identification documents. Such data can only be delivered after migrants have been brought to the registration and identification center and gone through the whole registration procedure one-by-one and after Frontex screeners and fingerprinters have processed, collected, and aggregated the cases, entered the results into a report, and finally sent the report to the incident reporter. In this respect, ‘person’s information’ requires the gathering, summing up, and grouping of data. It can only be delivered at the very end of screening and fingerprinting.

Taken together, the description of a rigid information system and the interference between data and border control practices produce several problems of synchronization. The interplay of a rigid information system, laborious processes of data collection, scattered and distributed practices of reporting and diverging relevancies between reporting and border operation turns data collection into a fragmented and crooked practice. This enacts a pace of a bit-by-bit data upload to JORA, which can take eight to twenty-four hours, or even longer.

Clashing temporalities on the ground: the struggle for the identification procedure at the registration and identification center in Moria

While the last section has outlined, how the temporality of data gathering and data processing has been shaped by the rigid design of JORA as well as by the temporalities of governing mobilities, this section will carve out how different temporalities clash on the ground. In the following, we will zoom in on the registration and identification center in Moria and show how Frontex screeners, fingerprinters, and their supervisors conflict with an acceleration of identification and fingerprinting. A closer look reveals that the practice of identification and fingerprinting intersects with three different orderings of mobilities. While the first is concerned about the regulation of circulation of migrants within the center and favors a speedy identification of migrants (Hellenic Police), the second seeks to achieve a systematic data upload to the Eurodac database and thus calls for a thorough practice of identification (EU Commission), and the third is concerned with a speedy but thorough (enough) data transfer from Moria to the incident reporter for a data upload to JORA (Frontex). This brings multiple, and conflicting enactments of identification into being.

After migrants have been arrested by the police and coast guard, they are brought to the registration and identification center in Moria. It is around ten kilometers away from Lesvos’ capital Mytilini, where migrants have to go one by one through a screening and fingerprinting procedure. When valid travel or identification documents cannot be provided, a so-called screening takes place, in which a screener and an interpreter interrogate each migrant to find out their ‘true’ identity. Of particular importance for the further procedures is to establish a so-called ‘presumed nationality’, that is, from which state the migrant is presumably coming. If the migrant can show valid identification papers, the procedure can be over in ten minutes; if it comes to questioning, it can last more than an hour. Then, the generated data is uploaded into various databases. The creation of a valid identity for the migrant is the first step of any following procedures.

Screening and fingerprinting are highly political issues that both the EU Commission and Frontex pay particular attention to. Uploading the fingerprints into the Eurodac database is one crucial element of EU-wide migration management (EU COM (European Commission) 2013). An entry into that database not only states that a person has applied for asylum within the EU but also which member state is held responsible for this asylum case. However, Greece has refused to insert datasets systematically into Eurodac for years. In 2015, fingerprints of only 8% of the arriving migrants were taken, as the EU Commission complained (EU COM 2016). As a response, Frontex has explicitly pointed out in the Operational Plan for the Joint Operation Poseidon – the binding agreement between Frontex and the Hellenic state – that Greece should ‘focus in particular on systematic identification, registration and fingerprinting’ (Frontex 2016, 27). In 2016, Frontex equipped the registration and identification center in Moria with fingerprinting machines and additional personnel, provided containers, and deployed Frontex officers to take care of proper identification and fingerprinting.

The conflict of identification plays out on the ground as a clash of temporalities. In 2016, when a large number of migrants were stranded on Lesvos and hundreds of people had to be identified and fingerprinted at Moria every day, the Hellenic police team leader wanted the Frontex screeners to speed up the screening. The registration and identification center was overflowing with arriving migrants and its capacities were too small to process this amount of daily incoming cases. Frontex screeners were expected just to fill out the identification forms as quickly as possible. However, Frontex screeners understood this order as an affront to their profession as policemen and to the agenda of Frontex and the EU Commission. Were they to become mere ‘registrators’ and not investigate if the statements were correct and if there were false documents circulating?

Frontex officers framed the attempt to speed up the screening procedure as an antagonism between a ‘quick and dirty’ and thus ‘bad’ policing style proposed by Hellenic police and a ‘slow and thorough’ and thus ‘good’ policing style conducted by Frontex. They were upset not only because a quicker screening would be deficient but also because it would subvert other border practices at the site. The screeners’ task is also to check if the screened had been victims of trafficking crimes and to stay in contact with police investigators on site – the so called debriefers. In some cases, migrants could also become part of a police investigation as witnesses, which would have severe consequences for their lives and fates. Screeners should also inform migrants about the procedure and their fundamental rights and to watch out for vulnerable groups. From their point of view, the attempt of the Hellenic Police team leader would produce ‘bad’ police work and thwart the Frontex mandate.

The Frontex officers refused when the Greek Police team leader tried to bring them in line by placing a Hellenic Police officer in the screening container to monitor their performance. However, the Frontex officers’ stand was backed up by the Frontex Operational Plan and by the Frontex Operational Coordinator (FOC), the head of Frontex operations on Lesvos. For the FOC it was important that screening is done thoroughly and that the migrants are treated politely and are informed about what is going on. As the guest officers’ stay is fully taken care of by Frontex, who provide money, personnel, equipment, the workplace, housing, and a contact person on site for the daily administration, they had enough to mobilize and to refuse to support Hellenic police team leader’s attempt at conducting a quick screening.

This story tells us that seemingly boring practices of collecting and processing data can become a highly political issue. It also tells us that border practices cannot be reconfigured at will since they are related to specific legal and normative rules and routines and are interlinked with other border practices and procedures. Furthermore, the competing concerns of the parties involved hint to different, and intersecting orderings of mobilities on the ground. While the Hellenic police team leader was concerned with the regulation of migrant mobilities within the registration and identification center Moria and tried to deal with its adverse conditions, Frontex personnel was concerned with the regulation of data mobility, that is with a systematical and careful data upload to Eurodac in order to fulfill the EU Commission’s and Frontex’ vision of a genuine European form of border management. The reordering of identification thus becomes a temporal matter (Pelizza 2020, 271). Speeding up practices of data gathering plays out as a clash of temporalities which also affects other sites and procedures of border control, not least JORA incident reporting.

The story finally shows us how the circulation of data through JORA intersects with other orderings of mobility, which requires the orchestration of differing priorities (Pelizza 2020, 271). In order to receive data on ‘person’s information’ from the screeners at the registration and identification center, JORA incident reporting has to take conflicting temporalities of border control into account and to work them into its data processing infrastructure. This produces a dilemma, which is articulated in terms of time: When a large number of people are screened in a slower way, then the data upload to JORA may be delayed by hours – which is not favorable for the JORA reporting process. On the other hand, ensuring systematic ‘data capture’ is crucial both for Eurodac as a central component for a European data assemblage of reidentification (Dijstebloem and Broeders 2015) and for JORA as a crucial component for the monitoring of the external borders of the EU. In the end, JORA incident reporting has adapted to the temporalities of screening imposed by Frontex officers. It waits for the report on screening, fingerprinting and document checks, which is crafted at the end of a shift and after the whole cohort of migrants has been screened and fingerprinted.

Managing the crooked process of reporting: scheduling and fast-track data transfer

In this light, generating and processing incident reports to Frontex headquarters in ‘almost real-time’ after a border crossing event occurred seems to be most unlikely and the time frame of that process almost unpredictable. But how can one build ‘situational monitoring’ on such unreliable ground? In the following, we will outline how the Frontex Situation Center deals with those uncertainties by implementing schedules and work-arounds. Two data channels are installed: one that schedules finalized datasets and their path through the validation chain, and one that processes preliminary data in near to real-time to different actors.

Frontex implemented a schedule for the different steps of the reporting process (Figure 3). As soon as an incident has been saved in JORA, several time markers are activated. When an incident has been created, it has to be finalized and forwarded to the validator the following day by 11:00 at the latest (Frontex 2016). In most cases, this is enough time for the patrol, screening, and fingerprinting units to end their task or shift, to create a report, and to deliver it to the incident reporter. The subsequent validation steps are then to be finalized within a few hours. The incident is supposed to be mapped onto the JORA dashboard by 17:00 at the latest.

Figure 3. Timeline JORA reporting and validation

The schedule seeks to produce a reasonably stable and expectable pace of data upload and data transfer, while at the same time framing the temporalities of data collection and validation. The schedule takes the uncertainties and idiosyncrasies of the work of the patrol, screening, and fingerprinting units into account. The deadline is loose enough and allows the border guards to finish their operations and shifts and to create a report afterwards. But it is also strict enough to urge the officers to deliver the information right away after their operation or shift to the incident reporter. This way, the schedule can be expected to be met and deviations can be recognized and addressed. In order to make data upload and data transfer on time more likely, Frontex equipped the schedule with a monitoring device. When a report or a validation has been finalized, it is recorded by the information system and displayed at the Frontex situation center. In case of delays, service managers intervene into the practices of reporting by consulting and assisting the officers responsible (Frontex 2016). Yet, when validators refuse an incident report and it is sent back to the previous instance, scheduling restarts. In this sense, data quality is prioritized over speed. In case an incident reporter does not receive the information on time or validators do not accept the report, the report is forwarded tardy rather than on time but incomplete.

Nevertheless, Frontex achieved data processing in near to real-time using a work around. It created an additional channel that distributes preliminary datasets for operational management. There are three directives inscribed into the online input mask of the JORA report: ‘Send incident’, ‘save’ and ‘close’. When a report is finalized, the reporter clicks on ‘send incident’. But when the reporter has created a preliminary version of a report, she clicks on ‘save’. As soon as a reporter does so, this preliminary version becomes visible to all JORA users (with the proper access rights) from the coordination centers, the Frontex situation center, the Frontex risk analysis unit, and operational management. Although this preliminary data is not used for the creation of incidents on the interactive Europe map or for risk analysis, it is taken as a first assessment for operational management.

Real-time data processing is also achieved through the deployment of the incident reporters at the local coordination centers (LCC). As we observed on Lesvos, the incident reporter also worked as the so-called LCC coordinator and as such he was in steady contact with the field units and other control rooms. While coordinating the operation, he created an incident report, saved it as preliminary version and then entered data bit by bit each time when new information flew in. In this way, Frontex personnel is updated on ongoing border crossing incidents via preliminary reports quasi-real-time.

This technological work-around allows the circumvention of the regular reporting procedure. In creating two channels, datasets on border crossing incidents can be processed in quasi-real-time in the form of preliminary versions and used for operational management, while validated datasets are forwarded more slowly but then usable for risk analysis and other forms of knowledge production.

Conclusion and discussion

The datafication of mobility and migration management makes time a central issue of governing mobilities. Through new technologies and infrastructures, data is gathered, distributed, and assessed across authorities in real-time and multiple border sites are interconnected with control rooms, coordination centers, and headquarters. This mode of governing, which Walters (2016) describes as ‘life governance’, aims at situational awareness, situational pictures, instantaneity, and speed. While time is clearly an issue in the governance of movement, it is equally so in terms of the mobility of the data that enables that governance. However, although the control of migrant mobilities heavily depends on the temporality of data circulation, the latter as a critical research topic has been widely ignored and all too often real-timeness has been taken for granted.

Paraphrasing Lin et al. (2017), we problematized and decomposed the idealization of smooth real-time data flows by empirically investigating the physical and organizational architectures that are generative of data mobilities. Based on an in-depth analysis of the Frontex information system Joint Operation Reporting Application (JORA), we studied how various actors, practices, and materials are mediated into a chain of data processing. With reference to work from STS, we worked out four sources of turbulence that turn a smooth data flow into a crooked process which patches multiple temporalities and paces together. Although these sources of turbulence are related to a particular case, we think that they are characteristic of data mobilities and can be applied to other cases, too. In one way or another, data mobilities are affected by data frictions, data quality issues, the synchronization of multiple social worlds and their temporalities, as well as by clashing temporalities on the ground as a consequence of intersecting orderings of mobility. The infrastructuring of data mobilities thus can be described as an ongoing process of ordering, deordering, and reordering, which not only shapes the temporality of data circulation but also other forms of governance of mobility.

In the case of JORA, a data infrastructure has been designed to deliver data from so-called border crossing incidents to the Frontex Situation Center in Warsaw in near to real-time in order to achieve ‘situational monitoring’ of Europe’s external borders. Speed was one of the key concerns of this information system. However, each data infrastructure has to deal with data friction. In the case of JORA, various authorities and differing reporting routines, languages, and data systems needed to be integrated into a common data infrastructure. Frontex chose to create one centralized information system (JORA), limited its users, and strictly defined the data to be gathered through templates and item batteries. Although this extensive prescription of users and data entry minimized data frictions, it made the few incident reporters dependent on many additional reporters and thus made reporting into a distributed and hardly manageable activity. This produced many more translation steps as well as new frictions along the chain of data collection.

Moreover, as data infrastructures usually process data for many different actors, purposes, and outputs, they face issues of data quality. This also holds true for JORA. In order to generate valid data, a sequential and reversible validation chain was implemented. Data quality was achieved in a twofold sense: through the hardening of data by cross-checking reports and through the replication of data across the authorities that produce a Europe-wide data pool. The design of a reversible validation chain made the temporality of data processing variable and unreliable.

Implementing a data infrastructure in multiple social worlds means adapting an information system to multiple sites as well as mediating and synchronizing multiple relevancies, practices, and their temporalities. In the case of JORA, we could show how two temporalities of mobility needed to be aligned – that is, the policing of migrants’ movements with its own policies, routines, and urgencies and the control of data gathering and processing with its reporting practices. The interplay of mandatory items to collect, laborious processes of data collection, field units as pacemakers, and data practices not being in accordance with the relevancies of the course of a border operation produced problems of synchronization and turned data upload into a fragmented pace of a bit-by-bit processing. This extends reporting by hours and adds waiting time.

Furthermore, intersecting orderings of mobility cause struggles between different parties, their agendas, and practices and produce clashes of temporalities on the ground. In our case, three different orderings of mobility intersected with the practice of screening at the registration and identification center in Moria. While Hellenic police made the overflowing and the adverse conditions of the center the most pressing issue and thus asked for a quick identification procedure, Frontex personnel were primarily concerned with a systematic and careful gathering of data for the Eurodac system in order to fulfill EU Commission’s and Frontex’ vision of a functioning EU-wide data regime. Incident reporting again required a speedy but extensive gathering of data for the creation of situational pictures of the EU’s external borders. Carrying out screening more quickly would not only have affected other procedures of border control on site but also provoked stubborn resistance from Frontex officers who saw ‘good’ police work being endangered.

As a consequence, the real-time circulation of data has been undermined and the resulting patchwork of temporalities and paces slowed down data transfer substantially. In order to tame this complex ordering process, Frontex implemented scheduling and monitoring devices into JORA. As soon as an incident has been created, time markers and deadlines are set, which can be monitored by Frontex service. The schedule can be understood as a compromise between the temporal contingencies of the reporting practices and a reasonably stable pace of data transfer with ultimate deadline. With this, Frontex is far from providing a constantly updated picture near real-time. Nevertheless, Frontex has achieved real-time monitoring of border crossing events through a work-around that makes it possible to process preliminary versions of an incident report to a variety of Frontex users for purposes of operational management.

Having said this, we can specify how the design and implementation of a data infrastructure affects not only the circulation of data but also the contemporary forms of the governance of migrant mobilities. First of all, data infrastructures like JORA set up several channels and temporalities of data circulation and produce various connection possibilities. Preliminary data is forwarded to operational management while validated data produces situational pictures on several screens some hours later, which is then archived in the database for future usage. The standardization of data has made it possible to merge data since 2011 and to produce different outputs by different actors which draw on past events and sketch out possible futures to be governed. Tazzioli (2018) speaks of ‘coeval temporalities – that is to say, different temporalities (past, present and future oriented) that are simultaneously at play in the crafting of migration risk analyses and preemptive spaces of governmentality’ (273).

The case study also gives some details of the geographies of data circulation. Instead of a single supra-national data space, through which data can circulate without losing its shape, various data spaces are interconnected. The case study showed how the information channels of national police authorities and of Frontex are interlinked by JORA incident reporters who replicate data from one channel to another. In this sense, data circulation is achieved by specific ‘switching points’ that interconnect a variety of administrational network-spaces (Pollozek and Passoth 2020, forthcoming). Although this is beyond this paper, this hints to a mode of an interorganizational, and transnational technobureaucratic governance that is based on the interconnection of and the harmonization of data across national and EU administrations (Pelizza 2020, 279). It is exactly this infrastructural work of mediation and interlinking that strengthens Frontex’ position in the concert of European security actors.

Furthermore, data infrastructures like JORA produce their own ecologies in which they can operate and thus have effects on the practices of border control. On the one hand, JORA disciplines its users by technological means. The definition of classification sets and mandatory items, the creation of deadlines and the implementation of monitoring devices that observe the officers’ performance ensure a consistent data handling independent from the organizational background of the user. This is a crucial element for the development of a ‘common information sharing environment’. It also stabilizes routines and styles of reporting that build on computer readable datasets and data handling. On the other hand, JORA fosters interorganizational collaboration. It demands a lively exchange between control rooms, field units, EU and national agencies and interconnects border guards on the line with those who work remotely. It also brings issues of an ‘intelligence-led policing and a risk-based approach’ (Bigo 2014, 215) into all sorts of border work. Field units are turned into data processors and data issues prevail against other border control issues. In this way, while realizing data circulation in one way or another, data infrastructures reconfigure border practices, forms of collaboration, and positions within the European field of security through the back door.

Acknowledgments

An earlier version of this paper was presented at the “On time. Temporal and normative ordering of mobilities” conference at the Uiversity of Siegen in September 2018 organised by Claudio Coletta, Jörg Potthast, Tobias Röhl, and Susann Wagenknecht. The author is grateful to them, to the anonymous reviewers and to the journal editors for their very helpful comments. Finally, the author thanks all the informants who supported the fieldwork.

Disclosure statement

No potential conflict of interest was reported by the author.

Additional information

Funding

This article is funded by Deutsche Forschungsgemeinschaft and Exzellenzinitiative des Bundes und der Länder.