1st City Protocol Workshop: Building together better cities
16-17 July 2012, Barcelona, Spain
The 1st City Protocol workshop was an event co-organised by the Barcelona City Council, Cisco, and GDF SUEZ with participants from 22 companies, 33 cities, 19 organisations, and 17 universities. Imperial College London was represented in the workshop by a team of researchers from the Digital City Exchange programme.
The City Protocol is a new initiative that aims to bring together stakeholders from the industry, city councils, non-governmental organisations, and the academia with the goal to create a common global-scale framework for collaboration and innovation in cities.
Going to the workshop with no prior knowledge of what the City Protocol is (as with most participants), I didn’t know what to expect. The analogy to the Internet Protocol, which was implied by Vint Cerf (one of the creators of the TCP protocol) being one of the speakers, served part as a way to picture what the workshop would be about, and part as a confusing metaphor from the techie world. But let’s get started.
The City Protocol vision
On the first day, the welcome talk was given by Manel Sanromà, CIO of the City of Barcelona. His talk was a call for collaboration in order to create the cities of the future, which can be summarised in his phrase: “It’s about what we build together, alone we fail”.
The next speech by Vint Cerf was delivered through video as he couldn’t be there. The three main suggestions that he made, regarding what an initiative like the City Protocol should do in order to succeed, were:
- Create a pool of the kinds of applications that could be built on top of the City Protocol
- Rapid-prototype pilot projects to test ideas, and keep in mind that the ultimate goal should be to facilitate creating and finding the best ideas
- Always document the process
Vicente Guallart, Chief Architect of the City of Barcelona, presented the vision of the City Protocol. He stressed the importance of having a vision of what will happen in 50 years and preparing for it by taking decisions. He also highlighted that “the Internet has changed our lives but not our cities, yet” , therefore we need novel strategies to add value in our cities through technology. Guallart summarised two basic directions towards that goal:
- From product- and site-oriented cities to service-oriented cities
- From centralised to distributed management of resources, from one-to-many to many-to-many
He concluded his talk by suggesting that “cities need a common language”, and that the City Protocol could be this language.
Carlos Moreno, Scientific Advisor of the President & CEO with GDF SUEZ, presented cities as complex systems and proposed a methodological framework for understanding them as such in order to effectively intervene.
Anil Menon, President of Cisco’s Globalisation Smart+Connected Communities, underlined that “ICT is like water and electricity” for our cities, and we should not think about ICT after we build our buildings and infrastructures. He presented five elements that are needed in order to realise our vision of the sustainable cities of the future:
- Visionary leadership, not utopian thinking
- Global standards: We need to become globally-aware
- Smart regulation: The current regulation is not suitable for digital cities
- Intelligent public-private partnerships, not of the “avoid cost-avoid risk” kind
- Common language: We need to bring disparate ecosystems together, collaborate and support open innovation to achieve a common purpose
Why a City Protocol?
The first group session of the workshop was titled ‘Why a City Protocol?’. Counter-intuitive as it may seem the participants of the four groups were asked to define why cities need a City Protocol when nobody (or at least very few) knew what a City Protocol is. This was a reasonable question that many of us had, so Manel Sanromà gave us his idea of what the City Protocol is: “An open community that produces agreement in rough consensus mode”.
There were two sub-questions that we had to answer during the session, what the benefits of and the impediments towards the realisation of the City Protocol would be. On the one hand, the potential benefits of the City Protocol that the teams identified were:
- Service-orientedness
- Accelerated innovation
- New business opportunities
- Consolidation of standards
- Facilitation of knowledge sharing
- Collective action
- Emergence of a multi-actor view in cities
On the other hand, the impediments could be:
- A lack of vision (short-term vs. long-term)
- Problems of scoping the project (high-level vs. specific)
- Financing
- Resistance to change by various stakeholders
- A lack of transparency
- A lack of concrete deliverables
- The need for customisation for different cities (global vs. local)
- The governance model of the City Protocol itself
What should a City Protocol produce?
The second part of the first day started with a talk by Vicente Guallart who suggested the directions along which the City Protocol should move to define its deliverables. He said that the City Protocol “should produce agreements”. According to Guallart, these City Protocol Agreements (CPAs) should revolve around three areas:
- Standards and recommendations
- Projects and policies
- Indicators and certification
“We are moving from a world of regulations to a world of indicators”, Guallart remarked.
Naturally, the aim of the second group session that followed was to identify more specifically the ‘what’ of the City Protocol. The groups identified the following deliverables, which I’m quoting here in the original wording:
- A citizen-centred approach
- A key performance indicators (KPI) framework
- Business models for open data
- A model of cooperation among the stakeholders
- Technology guidelines
- A tangible programme
- Integrated planning
- Prioritisation of issues
- Customisation for local requirements
- A portfolio of use cases in order to convince citizens
- Experimentation (pilots, small projects)
- A governance model that addresses ownership, accountability, and control issues
- Standards
As it becomes obvious from the above, the discussion revolved around thinking about the effects of or managing and controlling what the City Protocol will produce, which is not there yet, and addressed the ‘what’ question only tangentially. In my opinion, the ‘what’ in a project as the City Protocol should be about very well-defined and tangible deliverables, which, apart from some notable exceptions, didn’t came up. I will address this issue in the final section of this post, because it is important to relate my remarks with the ‘how’ of the City Protocol, which is the subject of the next section.
How should a City Protocol be developed and how should it evolve?
On the second day, Manel Sanromà, presented his vision of the City Protocol Society, the body that will produce and loosely manage the City Protocol. The idea for the City Protocol Society is inspired from the way the Internet Engineering Task Force (IETF) and the Internet Society operate.
The IETF is the main body that determines the standards that allow the Internet to function, which is an open community with no formal membership, and operates through self-appointed deliverable-oriented and limited time-scoped working groups. The working groups produce draft documents called requests for comments (RFCs), and the RFCs that are approved by the community after discussion and modifications eventually become standards. The operating principle of IETF is “rough consensus and running code”.
The Internet Society is the formal organisation that manages the IETF. It has formal membership, is led by a Board of Trustees, owns the output of the IETF, and has 90 local chapters around the world.
Sanromà proposed a similar structure for the City Protocol. Effectively, according to Sanromà’s vision, the City Protocol will be the ‘task force’ that is responsible for the development of the protocol using an open, collaborative, rough consensus-based approach, and producing written documents (CPAs, similar to RFCs). In this scheme, the City Protocol Society will be responsible for the governance of the City Protocol ‘task force’, with formal membership, and will supervise and own the City Protocol. The society will be led by a board elected by the constituencies. The first CPA, CPA0, which was presented at the workshop and was signed by the participants, can be found on City Protocol’s wiki.
The task of the group session that followed this talk was to identify the ‘how’ of the City Protocol, although, in my view, the discussion should have preceded the talk, because, in a way, almost everyone felt like we would discuss about something that had been already fixed. The ‘how’s’ that the groups proposed were (again I’m using the original wording):
- Guarantee the commitment of the City Protocol participants, politicians, policy makers, community and citizens
- Create a knowledge base of existing projects
- Create a masterplan/roadmap with clear goals
- Write an elevator pitch for the City Protocol
- Concentrate on some quick wins
- Set up formal and flexible governance for the City Protocol
- Create a collaborative virtual space for the community
- Identify specific subjects
- Define the scope of the City Protocol
- Balance the interests of cities and companies
- Establish city labs to test ideas
- Find out how the City Protocol can be ‘sold’ to interested parties
- Identify the leaders
A document that summarises the outcomes of the workshop can be found here.
Closing remarks
I personally strongly believe in open and collaborative initiatives like the City Protocol, and my participation in the workshop was very rewarding from many perspectives. This is why I decided to sign the first agreement, CPA0, as a member of Digital City Exchange. There is a significant potential in such efforts and I certainly view positively the City Protocol project. There are, however, certain important issues that I would like to address at this point, with the sole aim of constructive criticism, and I hope they will be viewed with this in mind by the City Protocol community.
In my opinion, politically, the City Protocol and City Protocol Society pair makes perfect sense. However, I can already see an a priori dichotomy between development and governance that is not at all evident in the case of the Internet organisations. More precisely, in the case of the Internet, the people who develop the Internet (the IETF) and the people who manage the outcomes (the Internet Society) are not different (not by definition at least). In any open technological space leaders emerge through their contributions, and managers are often the most active contributors of working code too (see Linux as a good example of what I’m talking about). In short, there is a tight coupling of innovation and its management in terms of the people who participate in these areas.
On the contrary, from what I experienced at the workshop, many participants would want to appoint leaders before anything tangible is produced, and create a quite artificial border line between development and governance. This rationale tries to replicate old institutional forms in an open and collaborative setting, an act which, in my opinion, will make the project dysfunctional, and cause it to move slowly. And, especially at the very start, we need fast decisive steps by building things. Leadership will then naturally emerge. I don’t see why and with what criteria leaders can be appointed before anything is built.
I also have to admit that I was quite frustrated by the fact that some participants perceived the ‘why’ of the project as something that can be used for ‘selling’ the City Protocol from day one. Again, I don’t understand how we can sell something that is not made yet, and I feel that this urge by some participants to take up the ‘sales’ roles before the project begins emphasises the aforementioned dichotomy between development and governance, and, ultimately, puts the openness of the project into risk.
On a more technical point, as with any kind of smart cities-related project, data is a competitive advantage through which innovation distribution is controlled. I believe that for a project as the City Protocol, which is based upon the premise of openness and collaboration, it would be useful to see who of the participants are committed to open up their data, to whom, and under what conditions. If there can be no viable agreements and solutions to the lack of openness in the data domain, it will be very difficult to proceed in the project.
A related issue is that I got the impression that the majority of the participants in the workshop view technology as secondary in the City Protocol effort. For them, technology is the ‘tool’ that will realise whatever is decided at the governance level. In my opinion, the City Protocol has a very significant technical component, which is precisely the ‘running code’ of the project. Therefore, the City Protocol community should understand the importance of technology in the project, and define more precisely what the running code is.
I believe that the Internet analogy is a very apt one for the City Protocol, and by addressing and resolving the development-governance dichotomy, the lack of data openness, and the lack of well-defined running code, the City Protocol could be a project that will shape the future of our cities.