(applause)
- Okay thank you very much and thanks
for the honorable mention.
I just want to make sure that my co-authors
get the adulation that they deserve.
So this is work done with Arvid Engstrom,
Ari Lampton, and Barry Brown
and also Yakov Erlander, who helped us with interviews.
And today I'm going to give an overview
of a paper that is first informed by seven years
of our research center working
with our local authority as a partner.
But it's directly based on 20 interviews
in four northern European cities.
These cities were all between 500,000
and one million inhabitants, to give you an idea of scale.
In our interviews, we focused on the role
of digital data in both the ongoing operation of the city
and the increasing progress in their goal to be,
or to be seen as being a smart city.
Seven interviewees were managers, or staff working
with city government, even in the front-line positions,
or managing projects that made use of data.
Another 13 represented development companies,
civic initiatives, and non-profits.
Our interviewees were selected on the basis
that they had key roles in the development
of publicly released, citizen-facing applications
developed either directly by the city
or in collaboration with the city.
And while I do mention smart cities here,
and I'll come back to it at the end,
it's not really the focus of this paper.
We're looking at the part of the smart city story
that focuses on the deployment of data and technology
to improve city function.
What we highlight is that city governments
are bureaucratic organizations
with complex leadership structures
and at times quite conservative attitudes
towards innovation.
IT development and management is often contracted out
to private companies, making even more
complex relationships.
So in this talk, I'll touch on four aspects
of data and the city, and give brief examples
of projects which highlight the complexities
in each of these spaces.
The first area I'm going to talk about
is the relationship between data and power in the city.
Many of the projects that we looked at
were built on the idea of using data
that the city already had in a new way.
But something that became equally important,
was that the value of any data set
within the city was highly subjective.
An early application that one technology incubator proposed,
was using a database of green spaces in the city
to simply build an app to guide citizens to the closest one.
But this development had a number of problems.
The first was that, while the data necessary
for its completion seemed innocuous,
it was the cornerstone of the provision
of gardening services by the city.
And crucially, the lack of knowledge
of the number, location, and size of green areas
that needed maintenance, such as grass cutting
and hedge trimming, was seen as one of the major factors
protecting the gardening service
against private-sector contractors
that may want to bid to provide these services.
This difference in value the data had
between the developers and the department
and these external contractors
resulted in understandable reluctance to share that data
on the part of the department.
The second problem arose around,
that the development was in different timescales
for the different parties who were working with this data.
The development team wanted to generate applications
in a short, six-month timescale,
indeed they were contractually obliged to.
But that meant the staffer
maintaining the gardening database could,
without refusing the request for access the data,
and going against the wishes of upper management,
resist this request by simply waiting out the incubator.
As one of the developers remarked to us,
the parks and gardens manager, said to me,
I only have to stall until after the summer
and then you'll be gone.
But this was a double-edged sword.
Another example, it wasn't the city
that had the power over the data.
It was the external contractor.
Developers wanted to produce an app
to locate and report potholes using GPS
and accelerometer data.
However, the database of reported potholes
was held by the contractor who was making these repairs.
Now there was a suspicion on the developer's part
that reporting a pothole twice
would result in a double charge to the city
and that this app would necessarily,
as it bootstrapped, report every pothole
in the backlog of those needing to be fixed.
Meaning that any attempt to update
or change the mechanism to report road maintenance problems
was practically impossible until the contract was up
and they were able to negotiate access or keep it in-house.
And this sort of touches on open data,
which is the second of the four areas
I'm gonna talk about here.
Now the pressure of open data was felt
in all the departments in all the cities we spoke to,
coming from both on high, whether you have initiatives
and targets, but also the ground level,
as all those we talked to had the view
that transparency and openness of city function
was something that would strengthen their position
and the trust the citizens had in them,
which they were very proud of.
But the problem with open data
is that it implies more than just putting the data online,
or making it available somewhere.
When data's online, it's sort of open,
and this can seem like enough, but it does have problems.
In one city, they put the real time departure information
of buses and trains on their website.
A number of developers used web scripting techniques
to create alternative clients,
and the most popular of these was a Windows desktop widget,
which had more than 10,000 installations.
So when the city updated their website,
this widget started continuously reloading the page,
looking for the data in the format it expected.
Causing more or less a denial of service attack
and bringing down the authority's website.
This forced them to roll back to the old version
of that page until they had managed a way
to manage this problem.
And also, interestingly, was a large motivating factor
in the creation of a nationwide team
to manage the release of transport information.
And while there is, as one consultant put it,
a lot of heart in the right place-ness
around open data, what is actually needed
is the ability and the resources
to control the release of data,
to make sure that it's legible, and has an understandable
and defined update frequency and fidelity.
And this is something that many of the developers
and contractors we talked to bemoaned.
These aspects of the data, them being in zips of PDFs,
or being updated once a year, or having rough estimates
where they would like exact numbers.
But this data's only collected to be fit
for park use in its original use case.
The parks department doesn't need to know
how spaced out the trees in the street are,
or what particular species they are,
only that there are about 20 of them,
and that they're evergreens.
The purpose being to estimate
the manpower needed to manage an area.
So collecting and maintaining anything more precise
would take more resources they don't want to,
and probably shouldn't, spend.
Remember their agreement is to maintain the green spaces,
not data about the green spaces.
And when data is made open or pushed to be made open,
extra resources are not always given
to combat these problems.
There's also the problem of reputation.
Any data released by a city authority
carries its stamp of validity.
And on top of that, there are risks in making data open.
There was fear that any data that is shared
may be incorrect or ineffectively anonymized,
or correlated with other data that might embarrass the city,
or more worryingly, embarrass the citizens.
This risk aversion meant that the default position
was to keep data private, especially if that data
could be seen as being sourced from citizen themselves
and potentially traced back to an individual or group.
At times, this perhaps was used as an excuse
for those who didn't want to take on the extra work
of producing and maintaining an open data or database.
Which brings us the the third area,
which is data involving citizens.
There was a push to collect data from citizens
and build that into both the day-to-day functioning
of the cities, and the ongoing decision making
and planning of service provision.
In one area that pushed for initiatives
to support and encourage cycling
we saw three cycling apps in three different cities
collecting data to influence policy.
But all of these ran into problems.
The first was simply understanding
that collecting data was not enough.
In one city, by the time the city had established
a process for integrating data from citizens
to influence the planning and decision making,
the original cycle data initiative
had already been discontinued.
The team working on it had moved on to other projects,
and while it had succeeded in getting buy-in from citizens,
having them contribute information about problems
and wishes regarding cycling conditions,
it failed at getting that information effectively
in front of the decision makers of the city.
The other two apps both, interestingly,
had the same functionality across two different cities.
They both used GPS to track rides of users,
start point to end point, and to calculate distance,
average speed, total riding time.
But instead of supporting enthusiasts
with feedback on performance, the idea here
was it would support the city and allow them
to provide better support for cycling services
to their citizens.
However, while collecting this data
was seen as relatively simple,
presentation of that data was quite difficult.
In one city, the problem was that presentation of this data
to other users of the app was seen as a huge security risk.
Even when the end points were obfuscated,
so you couldn't see exactly where a route started
and exactly where a route ended,
or when there was no user information attached.
The scenario that was presented to developers
time and again in meetings,
was if a route seemed to be leaving near a hospital
and ending near a residential area,
would mean that there was a risk
that someone would lie in wait for a medical worker
and assault them on their way home.
Another problem was that in presenting the data internally,
it needed to be in a format that would be readily taken up
by those in decision-making processes.
One of these apps was made by an ex-city employee,
and he felt that they had to go much further
beyond simply presenting routes with times
and optimizations to give complex representations
of analysis of the data in attempt
to more influence city policy.
And, even they didn't see their data
having the impact in the way they expected.
Possibly they were naive.
Planning procedures have been in place
before these new data sources.
And as such, they have to make room for them
as one of many data sources used in decision making.
And these new data sources are unproven,
whereas trusted sources such as polling agencies
and consultancies are a known element to the city employees.
And simply the timescale might also be longer than expected.
The decision to take and build a new cycle lane
may take many years to go through all the steps required
to start breaking ground, which is quite at odds
with the app culture of these external developers
who are brought in to build these things.
The last of the four areas I'm going to talk about
is the bureaucratic nature of the city.
Now there are a lot of regulations
that influence city function, and in turn,
these influence the technology development.
These regulations are a combination of local, state,
and because these cities were in Europe, E.U. regulation.
So any time that the city would spend money
on an external service, it was highly regulated.
Now in general this is a good thing.
It ensures the city gets what they're paying for.
It ensures that what they're paying isn't more
than it should be.
And it protects the taxpayer's purse.
But it can lead to strange phenomenon
in the technology sector.
One can be seen in an application that was developed
to allow citizens to pay for their parking
using mobile phone.
This would be part of the ongoing service provision
of the city, so it had to be publicly procured.
And this process meant that specification was developed
and publicly released for external developers
to bid on if they met the constraints needed
to actually work with the city.
And one of our interviews worked for a company
that developed this application
and interestingly in this case, they were able
to white box the product, allowing them to re-sell
this app to multiple cities as a service.
The interview highlighted the differences
between the single app they developed
for their city authority and the unbranded version
of the app.
So as you can see, 20-25 releases of the unbranded version
of the app versus two releases in a year
of the app for the city.
So for the city, the new features could not be added
as they were not specified in the procurement process.
Even though they had been developed
and it might have been easier and cheaper
for the development house to maintain one code base
rather than two, they were forced to keep an old version
of this app specifically updated for the city.
And the last point I want to bring up
is one of the discussion points from the paper.
And that is the concept of what we've called here,
big little data.
You see an interesting aspect of the data-oriented projects
we looked at here, is that with very few exceptions,
they would not generally be counted as big data
in terms of their size, complexity
or the techniques they employed.
Instead, the sets of data we encountered were interwoven
with the city's organization practices and processes.
The majority of the projects we studied
are perhaps best understood as gradual improvements
on existing city services, rather than parts
of centralized big data or smart city initiatives.
When talking to people leading IT projects within the city,
it became apparent that terms such as big data
and smart city were seen as distant,
high-level, abstract things that were used
to promote a project or wrangle funding.
Catch phrases trickling down from top management
rather than something that individual departments
or projects actually identified with.
Yet while there may be reluctance to use big words,
at the same time there was a drive to use
and produce city data in new ways
and to gradually smarten city function.
Decisions in what to develop were pragmatic.
A parking app becomes an alternative to paper tickets
when smart phone penetration is sufficiently high
and processing fees drop below a certain threshold.
Aggregating real-time bus route information
is possible when GPS technology and data rates
are cheap and reliable.
These services all had less technically advanced
predecessors, and they'll all have more powerful successors.
So before I stop here and take questions,
I'll ask that you think a little bit
about the little data systems that might be at the core
of any big data projects you see
in large organizations such as cities.
(applause)
- [Audience Member] I have a very simple question.
A lot of this exploration, I found myself thinking,
well isn't that what you expected, right?
I expected the data to be as you described.
I expected the big data to be interweaved
in the process of growth, and I think most big data,
I think it's something that perhaps isn't widely understood,
most big data is interweaved in the process of growth.
It doesn't sort of sit there with the answers,
you aren't going to be able to pull it out
and come up with the answer.
What would you say you thought was particularly distinct
for cities as opposed to other entities of generated data?
What's different about the city from something like, time.
- One aspect of it was that the city really felt
that they were protectors of their citizens
and anything that touched on citizen data
was, had a much different way
than a commercial organization would.
These were not things that were ready to mined,
the citizens were, it was very patriarchal in a sense,
the citizens were protected and supported.
So that was one aspect were it was quite different
than what we expected, considering the big data narrative
around companies like Google and Yahoo and Carri.
- [Audience Member 2] What do you think,
if you took your paper back to the city
that you studied that you're quite so rigorous about
normalizing, if you took your paper back to that city,
is there something there that they would gain from it?
Is there something they could learn from it,
that they could make a change and do differently?
- Well we have, we've spoken to the cities,
our partner city, at least, about this data.
And something that they see as quite important
in big data is that when these things are pulled out,
it does force collaborations between departments
as well as with the city and external actors.
And that was something they were
really looking forward to pushing through.
(applause)