1. Introduction
Over the last 20 years the smart city agenda has evolved from being initially focused on connectivity, mustering data for operational efficiency, to now looking beyond direct municipal services to support connected communities. As this slow migration of focus has come about, the consequences of the technologies that compose the smart city have shifted as well. From enabling new forms of community that emerged through connectivity [
1], to then facilitating city-scale operational surveillance [
2], and now supporting citizen-led data production, analysis, and mobilization [
3,
4,
5], the turn to computing platforms to mediate community action builds from the aspirations of open data and democratization of influence through information technology. However, this shift from data connection to data coalition arrives as the information infrastructures within municipal entities have grown ever more complex, managed, and centralized.
One of the enduring questions of smart cities, which goes back much further to early visions of how computation would impact policy making and governance, is what does it take embed computing such that it can bridge the world of professional civil servants who rely on enterprise-grade platforms to carry out their work in the world of community groups with constrained technical expertise and capacities? As Voida et al. have pointed out previously, it is not just that there might be a gap in technical expertise, but that there is also often a gap in the organizing principles—or logics—that shape how professionals adopt new computing capabilities versus how a community group might adopt those very same capabilities [
6]. These gaps, along with misaligned incentive structures [
7], make for enduring challenges in developing multi-stakeholder coalitions that bridge the different organizational worlds of civic work.
Beginning in 2019, we undertook an embedded collaborative research project in Albany Georgia, a small rural city, to understand three primary research questions: (1) How do community organizing practices take shape around joint initiatives with local government? (2) What data, tools, and processes are needed to support those initiatives? (3) How do the affordances of City-run enterprise platforms support such community-born initiatives? The city had internally deployed a geospatial and data management enterprise platform and was in the process of developing a rich set of resources to link public initiatives with City-held data assets. Our project was developed as a collaboration with the City and the platform vendor to better understand how community-born initiatives might make use of the platform as they collected and analyzed data, built a constituency of concerned citizens and volunteers, and constructed public-facing interactive tools to share and explore relevant data.
We used a mixed-methods approach that interwove participant observation, qualitative fieldwork, and participatory workshops to understand how a community-led initiative on food security could be supported by the public-facing features of the city’s enterprise tools. What results is a rich account of how data, people, and process become entangled through enterprise civic systems, pointing both to tensions in how formal professionalized organizations intersect with informal voluntary organizations, and to opportunities for building out public data infrastructure that supports both municipal operations as well as local, grassroots mobilization.
3. Context and Methods
The research project took place in the City of Albany Georgia, a small rural town in the southern part of the state. The research team had an existing relationship with the municipal government, having collaborated on an earlier project to use City-held data to understand the impact of low-income housing rehabilitation on energy costs. Leading up to that prior project, the city had more fully deployed an enterprise geospatial management system made by ESRI that was being used to normalize and regularize all the city’s operational data. This undertaking was part of a larger effort within the City of Albany to integrate operational data resources to improve operational management, decision making, and policy development across city functions and extending those resources to enable new avenues for direct citizen engagement. The ESRI platform was the foundation of this data integration and included a suite of tools—called the Hub—that was the technology centerpiece of the citizen engagement effort, of which this project was one example. The Hub platform was positioned as a tool for organizing and coordinating community action through different initiatives enabling community members to create, follow, and contribute content. Since the Hub was organized around initiatives important to the community, we began our research by interviewing community leaders to surface issues of importance. Through this first set of interviews we came to know partners from Albany State University (ASU) and several local businesses and advocacy organizations that would come to advise our future efforts. In an initial workshop we brought together ESRI, ASU, and city partners to propose a collection of potential community issues that could benefit from an organized effort mediated by the Hub platform. Food insecurity in the city emerged as an issue of urgent importance that already had a small but diverse and loosely connected set of active stakeholders. It was also an issue that would benefit from more focused data collection and analysis, and a data-driven communication campaign to show how pervasive the issue was in Albany. This was the genesis of the Food Security Initiative that would encompass city-wide data collection of food access, maps of food insecure populations by city ward, and a coalition of community advocates from the food bank, a mobile pantry business, a farmer with plots in vacant land around town, and volunteers from affected neighborhoods.
The history of Albany, and historic legacy of food and community in the southwest Georgia town played an important role in shaping the initiative [
67]. The City of Albany was incorporated in 1838 but for centuries had been a civic and commercial center for indigenous peoples. Cotton and peanuts were the primary crops grown by enslaved Black people on plantations. By the turn of the 20th century, the Black population in Albany had decreased from 80% to 40%, and became a stronghold of racism in the south: white violence against Black people was prevalent [
68]. From this oppression emerged the “Albany Movement,” which was the beginning of non-violent, direct action in the Civil Rights Movement [
69]. Albany State College, now Albany State University, was central to the organizing of anti-segregation protests [
69]. The varied tactics included mutual aid, voter registration, and economic boycott. After mass arrests and police oppression of the movement in the summer of 1962, the movement turned to “long-haul” tactics like a citizenship school taught by Albany State College SNCC (Student Non-Violent Coordinating Committee) members. In 1969, the first community land trust in the United States was founded as a collective farm established to preserve and sustain Black families and their farming culture (
https://www.newcommunitiesinc.com/, accessed on 12 April 2021). New Communities Inc. continues to empower Black agriculture today and speaks to the intersection of racial justice and food justice in Albany. The Food Security Initiative drew on this historic lineage as much of the experience and effects of food insecurity, as well as the efforts to confront it were born by the city’s Black community.
To gain insight into how the Food Security Initiative might operate through the Hub platform, we deployed a mixed-method approach that integrated a variety of qualitative methods, including: in-person participatory workshops with city and community stakeholders; a coordinated crowdsourced data-collection event and asynchronous data-collection effort post COVID; interviews with key stakeholders in the initiative steering committee; data analysis and the production of interactive dashboards on the Hub platform; and ethnographic fieldwork throughout.
3.1. Alliances and Coalitions
Together with our partners, we established an advisory committee whose purpose was to exchange knowledge of the conditions of food insecurity in the City of Albany, to define the goals of using the Hub platform, and identify other community organizations with whom we could collaborate. The advisory committee was composed of 15 members, of which four belonged to ASU, two faculty members, and two graduate students. One of the ASU graduate students had recently been elected to the city commission and represented a ward that experienced particularly low access to good food. Six members were from non-profit organizations and food banks in the area, two members were from Georgia Tech, and three members from the City of Albany. We met once per month and kept detailed notes of the meetings.
Through this partnership, we connected with a Food Justice Coalition organized by members of the advisory committee. The coalition was composed of farmers, activists, public servants, and committed citizens of Albany. Their mission was to improve the quality of life and health for people in Albany and Southwest Georgia by focusing on various aspects of food insecurity including, education, nutrition, and food sovereignty. The coalition was mostly focused on developing a set of tactics to collect data and craft evidence of the multiple social issues that contribute to food insecurity. By working with the coalition, we gained a deeper understanding of the multiple tactics the coalition was planning, met several of their partners, and began understanding their perception of the Hub platform and its role in supporting future action.
The overall structure of the Food Security Initiative was that the operational questions of what data to collect and how to bring those data into conversation with the goals of addressing food insecurity in Albany were all directed by locals in Albany. This was the community-born piece of the initiative in that their concerns and goals drove the work of the initiative. As researchers and technologists, our role was to help bridge to the computational capabilities in the Hub and to provide technical and research support in developing the tools and instruments used to collect data. We also provided assistance and training on the tools so that local stakeholders could maintain and extend the resources developed during the research project—this in an effort to preempt the pitfalls of creating data and computational resources that do not get used or that become a barrier to engagement due to their complexity [
18,
70,
71].
3.2. Collecting Data
As we developed the Food Security Initiative, members of the research steering committee noted that collecting more detailed data about the kinds of food access across the city would enable a more specific public discussion about how to respond. Going by reports from the US Department of Agriculture, the entire City of Albany was considered a food desert simply because the reporting granularity in rural Georgia sits at the county level: the city is neither large nor dense enough to warrant finer-grained data. The research team, however, understood that within the city there were substantial differences in food access across neighborhoods. To document this differential in food access, we worked with members of the steering committee to create a data-collection protocol based on the Nutrition Environment Measures Survey (NEMS) developed at the University of Pennsylvania [
72]. Using this survey, we completed a city-wide census of food stores. The store census looked at any store that sold food, including established big-box stores such as Walmart and Target, large commercial grocers like Publix and Kroger, discount stores such as Dollar General, as well as gas stations, corners stores, and small neighborhood bodegas. In total, 147 stores were identified and surveyed.
We conducted two crowdsourced data-collection events with student volunteers from ASU who were recruited through the community engagement office and were fulfilling service requirements at the university. After the steering committee adapted the NEMS survey for the Albany store census, the City of Albany office of Technology and Communications implemented it on the Hub platform and provided ongoing technical support for the initiative. To guide data collection, we created a data set of stores to survey from a combination of public sources made available through partnership with the City. This data set provided a list of addresses and businesses that fed into the deployment of the survey app used by volunteers to assess the types of food and their costs at stores across the city (see
Figure 1).
Once the data-collection protocol was in place, our research partner at ASU developed a scoring metric from the survey data so that we could easily segment stores that provided fresh fruit and vegetables and a variety of healthy staples such as bread and rice from stores that primarily offered packaged and processed foodstuffs. The metric also distinguished between the price of food available. This showed how some small food stores in lower income parts of town were reselling food purchased at chain grocery and big-box stores at a substantial markup. This kind of granular insight fed into a much more robust discussion of food insecurity—rather than simply being tuned against access, it enabled the team to look at kinds of access and how that access met the conditions and needs of the immediate community.
3.3. Artifacts
To make the work of the Food Security Initiative visible, we created a site on the Hub platform that showcased a collection of story maps and other data resources to communicate the findings from our store census and work toward a shared understanding of food insecurity and food access in the City (see
Figure 2). The site showcased multiple data sets and national indexes that described food insecurity, the local food environment, and social needs of residents around the City of Albany. Descriptors such as demographics, income, and transportation access all helped add nuance to how the initiative communicated the impact of quality food access for different neighborhoods. Importantly, these stories helped articulate that food insecurity is a multi-layer problem that needs to be addressed from multiple disciplines with the guidance of the community’s needs. As the initiative matured, these artifacts were used by stakeholders during presentations to City Council and in developing materials for grant proposals and policy briefs that would directly address food access.
Interviews
Once the Food Security Initiative began, we conducted semi-structured interviews with eight members of the advisory committee. Interviews were conducted over the phone or through video conference due to the COVID-19 pandemic and were transcribed for analysis (The COVID-19 pandemic was caused by the SARS-CoV-2 virus that emerged globally at the end of 2019). The interviews provided a foundational understanding of how the different stakeholders were attached to the issue of food insecurity and how to position and support the Hub as an infrastructure to support the different priorities each of the stakeholders held [
73]. The focus of our interviews was to understand everyday work practices and challenges in confronting food insecurity, to better understand different community engagement activities, their expectations as part of the advisory committee, and finally, their understanding of the Hub platform as a resource for the initiative. The interviews gave us a holistic perspective on the specific needs for data, collaboration, and engagement practices to address stakeholder goals.
To analyze the interview data, one researcher that did not participate in the interview sessions coded the transcripts inductively and iteratively [
74], consulting the interviewer when context was needed. The analysis focused on finding similarities and differences between the perspectives of the interviewed parties with regards to food security and the use of data in the initiative. The initial codes broadly focused on different aspects of access, food, and community. After the initial codebook was generated, the entire team discussed the results to inform further iterations and to contextualize with field notes and observations gathered throughout the research engagement. Our analysis shed light on action-oriented practices to increase access to data and food and to engage with various sectors of the community including, government, grassroots, and marginalized groups.
4. Findings
Following 18 months of embedded collaboration with our partners, there were three larger themes that organize how the Hub platform intersected with building and supporting a local community-based initiative. By drawing attention specifically to
managing data,
managing people, and
managing process, we are highlighting the loci of activity where substantial work was needed to develop resources and capacities within the initiative. At times, those resources and capacities were primarily technical: identifying and curating existing data, building out interfaces for collecting new data, and creating interactive tools for exploring and communicating those data with a wider constituency. At other times, the work was more focused on organizing individuals and groups and their particular attachments to food security [
73]. Ultimately, the integration of data and people meant understanding how existing and new civic processes came to be mediated through the Hub platform. Although each of these areas exhibited unique needs, and tapped into particular affordances of the underlying enterprise technology, they were nonetheless deeply interdependent, particularly as people and organizations moved between acting on data and being represented as data.
4.1. Managing Data
Although the Hub platform had a suite of features built in to enable collaboration, it was more narrowly focused on the kind of collaboration that happens with managed data. Permissions and access to data ran through the platform, and consequentially, through the City as the maintainer of the platform. Although not an immediate concern for this project, because of the ongoing partnership with the City of Albany, it does point to some mismatches between the way data are managed in community-born projects versus how data are managed in formal—and regulated—environments such as a municipal government. One of the recurring issues that arose throughout the project was the issue of data ownership. The project team understood that data from the City was owned and maintained by the City, but data that was produced as part of the store census sat across multiple institutional and organizational boundaries, including the initiative steering committee, ASU as the primary mobilizer of the volunteer workforce, Georgia Tech as the research lead, and the City of Albany as platform operator.
Even as members of the research team worked through establishing and documenting an open-data sharing agreement, the nagging uncertainty persisted for two reasons. The first connects to the simple pragmatic operations of who—down to the individual assigned the task—would maintain collected data into the future? This included making sure the data remained available to interested parties within and outside the established partners, as well as how efforts to update and expand on the store census data would be managed. The second concern was one of accountability for how the data might be used, analyzed, and represented. In both cases, questions about owning and managing the data were caught in a tangle of competing institutional power dynamics: there were academic interests of partners from Georgia Tech and ASU, there were a set of interests from the food providers on the team whose goal was to help develop more targeted distribution in needed areas, there were policy and political interests from the elected officials involved, and there were the operational interests from the City’s Technology and Communications organization.
One of the key disjunctures between how members of the Food Security Initiative team viewed data and how it was managed and made available in the Hub platform could be described in terms of desired outcomes. Through the steering committee interviews, one of the widely shared motivations of the project was to develop a more robust resource for communicating the severity and ubiquity of food access issues in the city. On a basic level, steering committee members understood the severity of the problem and had been active in trying to address food security, either through innovative food distribution programs, policy-based responses, or through political negotiation. The Food Security Initiative was seen as an opportunity to build on those separate efforts through a robust data infrastructure that would support the rhetorical work needed to advance a more systematic response to the issue. The Hub story maps that were created during the project helped illustrate this: these interactive websites helped identify particular intersections of food access with demographic, economic, and health factors to illustrate the wide-ranging hurdles to, and consequences of, poor food access. Like other crowdsourced data efforts [
42], the store census data provided affordances for enabling the exploration of conditions on the ground and counterfactuals for how to respond—the
what is and
what if of civic problem solving.
By being able to bring multiple and different kinds of data together: the store census data, city demographic data, transportation data, and health risk and health outcome data shared by the local hospital system, the initiative was able to develop a more robust explanation of how food security affected a wider range of residents, and demonstrate the wider geography of impact. No longer was it confined to the low-income districts, the data collected helped show a larger penumbra of effect which in turn opened the possibility for new kinds of social and political opportunities to address the challenges of food security.
However, even with this new rhetorical resource, there was a mismatch between the underlying enterprise Hub platform as the foundation for data-driven management of city operations and the needs of an informal community coalition. The system was not deployed and maintained for public speculation about what might be, but to help the City move toward more efficient management of what was—this was especially true in a small city confronting post-industrial divestment and an urgent need to address widespread economic hardship and recovery. Using data to more precisely identify and target programs that would have economic impact—through revitalization or reinvestment, or through cost cutting and increased efficiency—fed the desire and inertia to move more elements of city operations under the managed umbrella of the enterprise platform. That the platform enabled community-born initiatives was nice, as far as it went, but it was not the central motivation, as was evident in the lack of an open-data policy that would have made clear the relationship between the city’s data, third-party data, and community-created data that might coexist in the system. The information technology was ahead of the policy priorities of the city which contributed to the uncertainty about long-term viability of tying a community activist agenda to a system that was not managed (or manageable) by those same community activists.
4.2. Managing People
The Hub platform made it possible to integrate existing City data, to cluster and plan store census activities for data collection, and enable ongoing data collection and updates through a mobile app. Although pulling these elements together still required expertise and sustained collaboration between the City, and the initiative steering committee, the work was straightforward. Breakdowns only started to appear when working around what—or who—should become part of the data around which the initiative operated. As described above, to kick off the store census, we hosted a day-long data-collection workshop where we trained 40 volunteers from the community, most of which were students or faculty from ASU on how to use the store census survey. We then sent teams of individuals around the city to begin surveying pre-defined clusters of stores.
One of the initial decisions we had to make in using the Hub platform to collect the census data was whether to require volunteers to create individual user accounts. The Hub platform, as with all enterprise software, was built around a tiered set of user accounts that enabled different features and access which could be managed by the City. Consulting with members of the technical team at ESRI, one of the touted features of the Hub platform was the ability to create community accounts. It could enable sustained engagement, allowing individuals to track initiatives they cared about and indicate willing levels of voluntary labor across a set of possible events and civic needs. In principle, this sounds powerful—it creates a store of willing residents that organizations operating through the Hub platform could tap into and link as a larger voluntary workforce. In practice, however, it makes some assumptions about the nature of public engagement, including that it comes from benevolent care for the greater good as opposed to mobilizing to address self-interested issues with immediate impact [
75].
Despite the ability to create community accounts for every volunteer, during the planning process for the data-collection workshop, it was clear from our community partners that creating individual accounts was unnecessarily burdensome both logistically and socially. Logistically, it was another set of steps that individuals would need to navigate for what we assumed would be a one-time interaction with the platform. Socially, the requirement to register was seen with deep skepticism because the platform was city-operated, with members of the planning team asking why should volunteers need to share personal information with the City for a one-time event?
Here is one of the mismatched logics that became exposed through the initiative: volunteers and residents interested in the food initiative might contribute partial or piecemeal work to advance the overall effort, but there was not a larger move toward coordinated and sustained long-term action among the residents with whom we worked. That is not to say such sustained engagement was not possible or even likely in the breadth of civic encounters. However, it does illustrate that the logic of centralized enterprise management of human resources is misaligned with the community values of being able to move in and out of engagement fluidly and without a substantial structure of technological accountability.
Another way the logic of the enterprise was poorly matched the needs of a community-born initiative was also tied to the structuring and hierarchy of user accounts and the access control lists that defined how individuals could access and operate on the data. Access control lists have long been an understood hurdle in multi-user systems, adding complexity and uncertainty around how and when and whether different users can or should gain access to parts of a system [
76]. In the context of the Food Security Initiative, it created uncertainty about the collaborative roles across organizations—questions of data ownership and stewardship were interpreted based on whether an individual’s permissions had been correctly setup. The account hierarchy and structure also fed into an enterprise business-model reality where the platform operated on a system of paid credits that were used for more advanced features. Some of these credits were available to the lowest level accounts and unlocked some features of the platform, while other credits were only available to in-organization accounts and were required for much of the spatial analysis the project required. Both had a relationship to real costs for the City—costs that were suspended by ESRI for the duration of the project, but which nonetheless figured into some uncertainty on the City’s part in terms of how the project might be sustained beyond the course of the research project and how or whether it should continue to bear those costs.
The kind of fluidity in role and responsibility that our community partners were accustomed to bumped up against the more rigid managed world of civic enterprise software. It is worth being explicit that throughout the project, the City and all the individuals involved with the initiative—including members from ESRI supporting the work—were committed to making sure the software met the needs of the initiative. However, in that commitment came a real measure of work: work to setup and configure user accounts, work to ensure that the right capabilities and credits were available to enable analysis, work to manage the data resources, work to implement functionality and train City staff and community members on how to use new Hub platform features. For a project that was meant to explore how this class of civic enterprise system might support community-born initiatives, the centrality of the City as ultimate arbiter of access and system management, and the need to call on ESRI for technical assistance and system integration, was not lost on anyone. Managing the people in the initiative became a process of managing how and when they were resolved by the Hub platform and whether or not they had access to the needed data and analytic features. Although perfectly workable given the partnership established to conduct this research, it is easy to see how other data-intensive community-born initiatives might not garner the same responsiveness and support from their respective municipalities.
4.3. Managing Process
To align the people, organizations, and data collected together in the Food Security Initiative, we created a specific kind of container in the Hub platform. This container, called a Hub Initiative was the basic system object that enabled the association of user accounts and the management of capabilities, the linking of data from sources both internal to the City as well as from external organizations (which might also be using instances of the same platform), the creation of interactive applications to enable activities such as the data collection and event management, and the creation and presentation of content that would be used to communicate goals and outcomes of the initiative over time.
As the project developed, and we needed to build out additional capabilities—the integrated store census survey, or features to help manage the data-collection workshop—the impulse was to use the features exposed through a Hub initiative to organize the work and ensure that the right entities were resolved in the underlying data models. As observed above, this included both the stores that were to be surveyed and the attributes of the food therein, as well as the people who were associated with the Food Security Initiative, either through the steering committee or as volunteers.
What the Hub Initiative offered was a structure around which to organize data and functionality, organizations and people. It provided a great deal of flexibility and functionality. To illustrate this, as the research project matured two things happened: first, partners developed some apprehension around data ownership over the long-term, and second additional external data were brought in to help link food security to long- and short-term health impacts. The latter was a direct response to the rapidly developing COVID-19 pandemic and public health crisis that was gripping the City of Albany [
77]. Health data was linked directly to the local hospital system through the initiative site, a feature directly supported since both the City and hospital system used the same geospatial enterprise platform. This federated model of data sharing was then suggested as a solution to the former concerns around data ownership: each of the university partners had their own instances of the platform through state-wide research agreements, so data from the initiative might be better housed in one of those instances and then linked into the City-run Hub Initiative. This would have side-stepped the ownership question by moving the bits out of the City’s data store and into organizations who could offer different long-term stewardship of the data.
Hub Initiatives could also create hierarchical relationships as a Hub Initiative could contain multiple sub-Initiatives. This opened the possibility for both wide, federated networks of peers with the hospital system and university partners, as well as deep nested networks of subordinates where multipart collaborative undertakings could be decomposed as needed. Throughout all of this, data process flow would be managed through the user accounts and roles created and assigned to each. This kind of object model makes a great deal of sense when engineering and developing complex enterprise software stacks, but the models that make complex software manageable do not often map well to managing complex social and organizational relationships.
Moreover, what scholars continue to run into are the push and pull between information representations and the social and organizational practices that operate around them [
78,
79]. This is where the representational structure of the Hub Initiative did not match the organizational context of a loose community coalition confronting food security. The informal and fluid structure of the coalition vectored toward less formal and fluid representational structures in the tools that were brought to bear. Familiarity with freely accessible web-based tools such as the Google Suite, and their attendant simplified models for data collection, representation, and sharing were the first places initiative members turned to get work done. Bringing them back to the Hub Initiative to leverage the City integration was frequently met with resistance due to it unfamiliarity and because the model of a collaborative organization in the Hub did not match the reality of the collaborative coalition. Moreover, moving from a simple model with complete individual control to one of federated institutions only added complexity to the daily management of data and process as the system administrative work would need to be replicated for each instance of the Hub platform. Although this begins to work the edges of trade-offs between centralized and distributed process models, the overhead of the underlying platform being designed for an enterprise environment was much more important. Simply put, the distributed work that occurs through self-serve applications is flexible and manageable in ways that enterprise software is not.
5. Discussion
One of the basic premises underpinning the collaborative project was that cities operate most effectively with expanded participation in governance—participation beyond the typical modes of information sharing and consultation [
80,
81]. This premise feeds into a counter narrative to reinvigorate the smart city as a network of relations between individuals, communities, and institutions instead of simply a site for surveillance and control [
20,
82]. By working alongside the institutional capacities of municipal government, and specifically the computational resources of the Hub platform, we aimed to better understand how community groups might amplify their ability to tackle systemic issues that would otherwise remain out of reach.
5.1. Keeping Track
Once the Food Security Initiative began in earnest, there was an intentional effort to make the Hub platform a central part of the workflow. From coordinating volunteers to event planning to data collection, analysis, and visualization, the Hub platform was positioned as the organizing tool that would enable the team to more effectively track and manage the many pieces needed to run the city-wide data-collection effort. However, to keep track of these pieces they needed to be represented in the system in some form, which revealed a mismatch between the expectations of community members leading the initiative and assumption of entity resolution in the technology stack meant to support the initiative.
At play here was the performativity of the Hub platform as an enterprise system that “shape[d] the world in its image” [
83]. Without comprehensive data capture—not just data about food access that was the
raison d’être of the initiative, but data about all the actors who might encounter the food access data—the Hub platform would not offer much in the way of new capabilities to the overall effort. It was precisely the work of configuring local food stores as data, and the volunteers as data, and the members of the steering committee as data that would unlock the ability to settle each into a hierarchy of entities to be managed over time to produce outcomes over this initiative as well as linked effects across future initiatives of different origins. Yet, just as Bopp et al. argued about nested consequences of the primary key (a fundamental feature of relational databases that enable data linking and retrieval), from the structure of the technologies built around the databases, to the structure of the organizational and front-line work done to manage breakdowns and limitations [
84], similar consequences became evident in how different parts of the community process resisted being resolved in the Hub platform.
The first of this was in the choice not to use individual volunteer accounts for the data-collection process, instead electing to create a single account that was shared and pre-loaded on devices used for the store census. The choice to not use individual accounts was partly a logistical optimization made to manage limited time during the large data-collection event, partly an administrative expedient to manage the need for the City IT manager to create and issue many accounts, and partly a response to the expectations of volunteer work within the community where membership in the initiative was understood to be temporary or provisional. By working with ASU, an historically Black college and university (HBCU), the students were part of a university setting where the excellent student is one who is civically active, and often required to complete community service hours. So, while student volunteers often served the community of Albany, they did not necessarily become attached to specific initiatives—theirs was a participation of duty. Even though food security was a widely shared issue among the volunteers, the shared attachments to how it might be addressed through the nascent coalition of public, private, and university leadership meant there was only a provisional shared identity in the initiative and therefore muted desire to be deeply embedded in its infrastructure [
73].
Even for members of the research team who were much more vested in the long-term viability of the initiative, the relationship to the Hub platform was precarious in large part because it was managed by the City of Albany. The City’s Technology and Communication department was the single source for creating and assigning accounts and for determining the capabilities of those accounts. This makes sense in an enterprise environment where managing access and maintaining records are good practice, and in the case of a public entity, required by law or statute. However, as a coalition of municipal and private individuals and organizations, this managed environment did little to support collaboration among peers. The issue here was not based on an assumption of bad faith on the part of the City, instead, as observed above, it was the confluence of several factors: limited capacity for a single employee to administer the Hub platform amid many other more urgent responsibilities—especially as the City confronted the COVID-19 pandemic; uncertainty about the long-term availability of the platform—would it only be available through research-led project or beyond; and persistent challenges in enabling the right sets of Hub platform features so needed data analysis could be accomplished.
5.2. Lines of Responsibility
Integrating the data and the people comprising the initiative were a set of loose processes and social and political vectors toward desired outcomes for the initiative. Here too there existed informative disjunctures between the way the Hub platform was conceived and the realities of how the Food Security Initiative unfolded over the course of the research. The mismatch between the needs of the Food Security Initiative partners and the managed environment of the City of Albany’s enterprise infrastructure turns on the notion of managed collaboration the Hub platform enabled. It is the collaboration of the enterprise environment where shared access is centrally managed, but it is not the collaboration of a distributed coalition of community actors. In the latter model, there is a mix of formal and informal organizations, roles, and responsibilities, often with dynamic shifts as priorities and capacities move between the distributed actors [
38,
85]. The logics that govern the collaborative enterprise are importantly different from the logics that govern distributed community coalition such that even when there are shared goals, values, and technologies linking the two, incompatible expectations and practices emerge and persist [
6]. Perhaps more importantly, though, is that issues of social justice such as food security do not have a single or simple solution and it is in the gaps and breakdowns between governing institutions and a plurality of community voices that friction shifts from an impediment to progress to the necessary grit needed to provide traction to confront the systemic issue [
86].
In the end, the clear lines of responsibility that ran through the university partners and the City of Albany meant that the on-the-ground community stakeholders were less certain where they fit and how much of what was accomplished was or would remain under their control. The issue of data ownership was raised early and persisted and much of that concern was shaped by the fact that data collection and warehousing was, by design, in the Hub platform. However, since that platform remained out of local control, questions of whether it required an ongoing commitment from the City to maintain access continuously undermined the autonomy of the community initiative. In addition, this fact worked against the impulse for using the Hub platform to begin with. As noted above, the commercial positioning of the Hub platform was as a public-facing extension of the enterprise systems cities nominally use to manage their data (and physical) assets: it offered an invitation to collaboration across a range of interested civic partners. However, many small community organizations move carefully to collect and manage their own data because doing so is a bulwark against outside interference and provides the kind of legal and rhetorical autonomy needed to confront policies deemed unfit or unfair [
24,
37].
Instead of a collaborative model, organized under one regime of access and data management, we would argue for a distributed or federated model where independent groups could maintain individual autonomy but enable shared access to data and computational resources. Such a model would not necessarily obviate the issues of managing access control, but we already have models for this kind of work as grassroots groups work in ecosystems such as the Google Suite or social platforms such as Facebook. To be sure, this opens a more complicated conversation about data accountability and the obfuscation of actual costs and potential for un-seen harms when trusting civic operations to data-brokering companies such as Google or Facebook. However, to bracket those for the time being, what those platforms afford is control of data and messaging that does not run through local political power structures. The veneer of autonomy is important, however thin, because a Google Sheet can be downloaded and exported at any time and does not exist with the blessing of the local council, nor is it put at risk when a City procurement office decides to change software vendors or cut costs by eliminating access not deemed central to City operations.
Normative and centralized data infrastructures of the smart city are at odds with the distributed and accessible infrastructure needs of diffuse community coalitions. At least three things need to be true to close this gap, (1) communities need to have in-house technical capabilities, (2) they need ready access to the technical platforms that collect store and share data, and (3) they need an ecosystem of socio-technical resources to put that data to work. The first is beginning to evolve as data and computational literacy continues to develop across organizations looking to effect social change. Several scholars have begun to show how mission-driven organizations can successfully apply data-driven approaches and the opportunities, limits, and real-life consequences as more organizing turns to online platforms [
37,
87,
88,
89]. The second is likely incompatible with current platforms as the managed data environment is both part of the pitch to implement smart city technology deployments and the foundation for business models built around providing these services [
90]. The current response to the need for distributed data infrastructures is a bricolage of free services that are sufficient, but are precarious because they are tied to individuals instead of embedded in organizations [
91]. The third challenge falls outside the scope of any technical system and is about the social, personal, and political capital needed to guide the design and selection and development of appropriate solutions. Here analytic models from global development and digital democracy contexts might be instructive, not because they tell us what systems to build, but because they provide a frame for understanding how to situate those systems within a complex network of personal, political, and power relations [
92,
93].
5.3. From Aspirational to Operational
Where the Hub platform delivered novel functionality was in the ability to generate a rich and detailed account of food security based on integrative data. As illustrated in the images presented above, the geospatial representation of food access and quality resulting from the store census presented a much more detailed account of the experience of food insecurity in the City of Albany and became a potent tool for communicating about the issue beyond those stakeholders who were already invested in the initiative.
This success as a communication platform—enabled by the ability to quickly build out web sites and story maps and visualizations and not just warehouse the data, but enable explanations rooted in the data—made it an important tool to advance the initiative goals of being able to communicate the seriousness of the issue more widely. Reflecting on the goals of the initiative, core stakeholders repeatedly indicated that being able to communicate clearly about the legacy of food access on different communities in Albany was urgent. A local vernacular understanding of who was affected most already existed, but being able to use the Hub platform to show and tell the realities of limited food access and combine that with the long-term effects was considered a success for the initiative.
One way to interpret the goal of the initiative was as an aspiration of providing more data and a more solid foundation for generating political will for a deeper policy response. At the time of running the project, steering committee members did not have a clear policy response in mind, though pieces began to emerge. One example was the desire to look more specifically at the disruptive impact of low-cost stores such as Dollar General that often entered low-income communities under the guise of addressing a gap in the market, but which did not offer fresh or healthy food options and in fact further exacerbated the food insecurity. The presence of these low-quality retail food stores was an important part of the story the steering committee wanted to tell: the issue was not just about food access, but what kind of access and at what kind of cost. The initiative was motivated by an aspiration to a more fully realized understanding of the situation so that a more nuanced plan of advocacy and action could be formulated.
The potential of mediating this policy and advocacy aspiration with the enterprise infrastructure running the city was that it opened potential avenues toward city operations. The enterprise platform, while mismatched to many of the realities of working across a community coalition, did confer legitimacy on the initiative because the basis for analysis and action was already couched within the very system the City used for analysis and action on any number of other operational decisions. The value in this legitimacy underpinned the apprehension stakeholders had around ongoing access to the Hub platform and the level of continued buy-in the City would have as they sought to develop and integrate additional layers of analysis. The integration through the Hub did exactly what it was meant to, it framed the problem of food security as a technocratic problem that simply needed the right people, data, and technology in place to address [
5]. In bracketing the political and power relations, the technocratic framing of food security as a data and operations problem opened a new avenue of action for a coalition of minoritized actors working against the political status quo. Rhetorically, this enabled the group to shift from arguments originating in
pathos, to arguments rooted in
logos.
Going beyond simple open-data initiatives that provide access to official data, the Hub platform offered more robust data integration from official sources, and importantly, complementary data integration by feeding community-collected data back into the same enterprise environment. This two-way exchange creates novel opportunities for community-born initiatives to become directly integrated into City operations. The difficulty here is in figuring out where to place and how to manage organizational boundaries so that the community-born part of the initiative maintains autonomy, and the city-operated part maintained efficacy. Integrating everyone and everything, from key stakeholders to temporary volunteers, as centrally managed data undermines the power of community coalitions where outcomes do not just come through operational efficiencies, but through the development of social and political capital as groups develop new capacities and new connections. Although we resist the idea that such social ties can be reduced to interactions mediated by enterprise software, it is clear that enterprise software is firmly planted in our local governments and therefore offers a role to play in linking people, data, and technology.
6. Conclusions
Cities of all sizes are grappling with how to address long-standing issues for their residents while also looking to create new avenues for action by applying data and information technology to those same long-standing issues. By working with the City of Albany and a coalition of local partners, we initiated a project to better understand how a collaborative enterprise platform used by the City could support a community-born initiative on food security. Although the underlying technology enabled new kinds of data about food security to be collected, analyzed, and visualized, there were substantial gaps between how the enterprise platform configured collaborative work and how a loose coalition of community partners needed and expected collaborative work to unfold. The managed environment of the city as enterprise assumes a stability in the attachments community members have to a given civic effort, but volunteer work in support of a cared-about issue is more often episodic and temporary. To reconcile these different models, civic enterprise systems need different models of collaboration, models that are more distributed and which enable the preservation of organizational and individual autonomy instead of assuming centralized management.
Specific system features aside, this work bumps up against the role of commercial software vendors and the enabling of different forms of civic engagement. To what degree does the civic enterprise need to rely on a commercial vendor, and what risks or consequences does such reliance invite? We saw through the project persistent negotiation around making needed functionality available to volunteers working on the initiative. This ties directly to a software-as-service business model where features are metered and billed. In a managed environment, such metering makes sense and can be costed out through planning and appropriations. However, in a community-focused environment, pay-walling and metering features works against open forms of collaboration where often lower-technical expertise necessarily mean more experimentation and trial and error.
What we offer here are a set of empirical insights to help shape how this emerging class of civic enterprise system might be better matched for bridging across the formal organizations of municipal government and the informal coalitions of community activism. Recognizing that similar goals and desires may not be enough to bring these two worlds together, information technologies meant to fill the gaps need to expose different affordances that both preserve the institutional accountabilities of the municipality without imposing those same requirements on informal groups of residents who are seeking resolution to issues they face.