Keywords

1 Introduction

Smart Cities are becoming a pervasive topic of research and practice in a number of disciplines. Smart City itself is in our understanding a strong multidisciplinary field, combining many different stakeholder views and city-related disciplines with digitalization and ICT support for more livable and sustainable cities. It combines cities, their inhabitants, smart digitalization, and societal aspects [1, 4, 14, 19, 23].

We focus here on the ICT aspects in Smart Cities, and in particular, on how to define a large-scale smart city IT architecture that spans multiple actors in an open and collaborative way through an ecosystem approach. This means we are not just aiming at an architecture for the operation of city systems in a strict municipal sense, but rather at an open system approach that can include actors from municipalities, public services, utilities, external companies, societal groups, academia etc. into an open ecosystem.

The background and motivation for this paper is the EU H2020 funded +CityxChange project that aims to develop Positive Energy Blocks (PEBs) in smart cities and communities as part of emission reductions to reach the Paris Climate Goals. The project background is described in Sect. 2.

We use approaches from the fields of complex systems, large-scale systems, data platforms, and Enterprise Architecture (EA). Our conceptual approach acknowledges the inherent complexity of smart cities and is designed to be open to additional stakeholders in and around a city, and to enable smart city evolution as an ongoing process. This goes hand in hand with an open innovation approach [7, 10] that follows a quadruple helix participation model of collaboration between cities and public bodies, industry and business, research and academia, and citizens and civic society.

In this paper we thus focus on these communities, specifically on professional stakeholders to enable them to connect and build upon the ecosystem, and on citizens and private stakeholders to be able to participate in smart city development, benefit from open systems and open data, and for all stakeholders to make it easier to participate in smart city systems with lower entry barriers. We understand the ICT landscape as a complex systems-of-systems, forming an evolving ecosystem enabling openness and innovation. Based on these considerations, a decision was made for a loosely coupled, distributed, service-based ecosystem architecture instead of a monolithic, centralised, closed approach. Through this, we focus on system integration and data exchange, open standards, and a reference architecture supported by Enterprise Architecture methods to ensure autonomy of individual systems, while providing overall guidance and cohesion for the important collaboration and coordination aspects.

Open data, standards, IoT, etc. are a part of a smart city’s ICT landscape, but many individual system specifications and data streams can be the responsibility of individual systems and partners, based on a separation of concerns. Finding the threshold between individual and overall responsibility and concern is an interesting challenge. Then the overarching task focuses on the interplay and orchestration of the different systems, coordination, joint data sources, joint open standards, overall monitoring and evaluation. Then the ecosystem approach becomes as much a technical challenge as one of stakeholder engagement, participation, and coordination for a comprehensive smart city project.

The main objective of this paper is to discuss challenges, principles, and solutions in developing an open ecosystem for Smart Cities that supports open innovation through openness, access, and stakeholders’ awareness throughout its architecture.

The rest of this paper is structured as follows: Sect. 2 provides the background and describes the +CityxChange project; Sect. 3 describes the technological challenges of ICT support for smart cities: Sect. 4 describes EA in the project and provides an overview of its main methods; Sect. 5 describes the +CityxChange ecosystem-of-services architecture approach. Section 6 provides a conclusion and an outlook to future work.

2 Project Background

The +CityxChange projectFootnote 1 is developing and deploying Positive Energy Blocks and Districts (PEB/PED) and scale these out as part of the European Clean Energy Transition in cities. 32 partners, including 7 cities and industry and research partners have joined forces to co-create these future energy systems. It follows an integrative approach with a strong focus on city integration, open innovation and replication ability. The approach combines:

  • Integrated Planning and Design of Cities;

  • Creation and Enabling of a Common Energy Market;

  • CommunityxChange with all stakeholders of the city to create connected and engaged communities.

The project is funded by the EU H2020 Smart Cities and Communities topic SCC-1.Footnote 2 The call revolves around the sustainable energy transition in cities that should realize Europe wide deployment of Positive Energy Districts by 2050 through highly integrated and highly efficient innovative energy systems. Of interest are not only the direct technical solutions, but the interaction and integration between buildings, users, cities, the larger energy system, and the implications and impact on city planning, city systems, energy trading, citizen involvement, regulations, big data, digitalization, and socio-economic issues. A Positive Energy Blocks is defined by the EU as several buildings that actively manage their energy consumption and the energy flow between them and the wider energy system. They achieve an annual positive energy balance through use, optimization, and integration of advanced materials, energy reduction, local renewable energy production and storage, smart energy grids, demand-response, energy management of electricity, heating, and cooling, user involvement, and ICT. PEBs/PEDs are designed as an integral part of the district energy system. They should be intrinsically scalable up to positive energy districts and cities and are well embedded in the spatial, economic, technical, environmental and social context (see Footnote 2).

Solutions and demonstration projects will be first demonstrated in the Lighthouse Cities (Limerick, Ireland and Trondheim, Norway) and will be replicated in five Follower Cities (Alba Iulia, Romania; Sestao, Spain; Písek, Czech Republic; Smolyan, Bulgaria and Võru, Estonia).

New forms of integrated spatial, social, political, economic, regulatory, legal, and technological innovations will deliver citizen observatories, innovation playgrounds and regulatory sandboxes linked to urban living labs, and Bold City Visions to engage civil society, local authorities, industry, and RTOs to scale up from PEBs to Positive Energy Cities, supported by a distributed and modular energy system architecture.

3 Technology Objectives

The +CityxChange project spans many different objectives, however, in this paper we focus on the technical objectives. Regulatory issues, citizen-centered approaches, replication, or business models are out of scope. On the technical and physical side, the underlying approaches and systems that drive the ICT view are:

  • development and deployment of PEBs,

  • integration of local distributed renewable energy sources, and energy storage;

  • connection of buildings and building systems to energy communities and markets;

  • optimized energy system operation;

  • connection to energy and district heating systems;

  • smart metering;

  • integration of electric vehicles;

  • better mobility solutions by offering eMaaS;

  • integrated planning and design; [17]

  • digital platforms for community and stakeholder engagement;

  • integration with city systems;

  • open innovation supported by open data, hackathons, prototyping, etc.;

  • monitoring and evaluation of the project through KPI data processing and analysis;

Out of these arise the objectives for the ICT ecosystem architecture. The project needs to create an overall ICT architecture and service-based ecosystem to ensure that service providers of the +CityxChange project will develop, deploy and test their services through integrated and interconnected approaches that maintain an open approach.

In addition, the project needs to ensure that data can be transferred in an open, accessible, interoperable, and secure manner through data integration and exchange, and will further investigate new and emerging technologies such a Distributed Ledger Technologies, e.g., IOTA and the generation blockchain as additions to existing transfer, payment or transaction methods.

4 Enterprise Architecture

Enterprise Architecture [15] can be a very powerful facilitator for complex projects by playing an advisory role in the strategic level and a guiding role in the implementation, and most importantly, helping to bridge between these two levels in an enterprise or a project.

The Open Group in its EA Framework TOGAF describes EA as an activity focused on “understanding all of the different components that make up the enterprise and how those components inter-relate”Footnote 3. The Gartner Group’s definition further highlights EA as a process that facilitates change, through “principles and models that describe the enterprise’s future state and enabling its evolution and transformation”Footnote 4. EA is thus more than system architecture. It’s concern is the overall ICT landscape and aligns the organizational business strategy and its ICT implementation. That means EA is a full stack of business architecture, data architecture, application architecture, technology architecture, and security architecture. Traditional EA frameworks assume that it is possible to describe in detail all ICT applications since they are usually deployed in-house [6]. Thus, these frameworks may be challenged when EA is considered as an open ecosystem which encompass several stakeholders, services, and cities that do not necessarily have a central or purely hierarchical control.

We take the understanding that also a smart city or a smart city project suits the enterprise view of EA to benefit from its framework and approach. Here we model the project with its different actors in smart cities through an EA approach, which is a viable approach if leaving out certain overly detailed descriptions [12, 16].

In the context of the +CityxChange project, the project-wide enterprise architecture is then the process of translating the project’s cities’ visions into demo projects and their development, implementation, and deployment by developing principles, requirements, models, and guidelines that enable the consistent development of various components of demo projects and ensuring that project deliveries are in compliance with the project’s and cities’ visions and needs and contribute to the overall goals. EA can further help bridge between the overall more strict development model of an H2020 project and the more agile approaches for individual components and for the engagement of external stakeholders.

Enterprise architecture can play at least four roles in the project: (1) as a decision-support tool it can advise the project coordinators and task leaders to manage the service portfolio of the project more efficiently by conducting realistic gap analyses and overviews, (2) as an integration and interoperability tool it can ensure that various stakeholders, service providers and ICT systems are efficiently communicating with each other (ensuring organizational, semantic and technical interoperability), (3) as a quality assurance tool it can monitor whether development of different ICT components in the project are in compliance with project guidelines and city visions, and (4) as a communication tool it can ensure the knowledge reusability and replicability within and outside of the project.

Performed thoroughly, EA can produce a huge number of artefacts that all have their use in a large enterprise. Selecting the right ones for specific projects is a challenging process. One of the most comprehensive taxonomies for describing the artefacts from the views of the different stakeholders is provided by the Zachman FrameworkFootnote 5. More recently, TOGAF has become popular as it not only recommends what to capture and describe, but also a process to conduct EA projects. The TOGAF project Application Development Process (ADM) also supports the evolution of the EA and change management process. For example, care has to be taken to select the ICT solutions and artefacts with the maximum impact to reduce overhead and deliver the most value in line with the business objectives. TOGAF considers EA as a continuum and describes how architectures can continuously evolve. This also aligns well with the smart city approach, as shown in Fig. 1 and discussed below. It provides a set of foundation (or reference) architectures (for the Business, Application, Data and Technology architectures), which provide good starting points for EA.

It is then possible to adapt and refine a generic foundation architecture to suit the domain or specific needs of the enterprise. An overview and comparison of the main EA methods are provided in [21].

5 +CityxChange Ecosystem Approach

In this section, we describe our technical concept and framework towards a reference architecture for the +CityxChange development and implementation. The overall ecosystem will need to address the technical objectives detailed in the previous section through a number of principles and challenges discussed below.

The current situation of many smart city ICT systems is to go for a large single-vendor solution. We do not find this optimal and not in line with iterative municipal system approaches and hence, motivated by the city needs and the project challenges, we propose to not build one centralised urban monolithic platform, but instead to develop a flexible distributed service-oriented ecosystem. It will focus on system integration, orchestration, and collaboration, through open systems, integration of open data, and an Enterprise Architecture and open ecosystem approach.

5.1 Principles and Challenges

In order to reach the objectives set forward in the previous section, we design a +CityxChange ecosystem that builds on the following principles:

  • API-driven and distributed service-oriented architecture as architecture style for the ecosystem.

  • Loose coupling of components supports the previous point through independent components, defined interfaces, encapsulation and information hiding of internal structures of other components [18]. It offers flexibility and reusability around adding, replacing, changing, and evolving components and a reduction in system-wide effects.

  • Separation of concerns in the same line ensure that there is no need to run everything on a common platform but allows for distribution of systems and responsibilities. This also mandates the ability and necessity to use open standards and interoperability of systems. It also allows for easier replicability of individual parts of the project. This is a driving force for the project.

  • Individual system and data responsibility to ensure separation of concerns and domain-specific systems working independently.

  • Enterprise architecture view to include the whole city context as discussed in detail in Sect. 4.

  • Interoperability through Open standards and open APIs, open documentation, open data models etc.

  • Replicability As a main objective, replicability means that solutions are generic enough that they can be deployed in other cities and contexts, that the overall solutions are sufficiently modularised, and that interfaces are well defined and open to enable a solution work within a different deployment landscape.

  • Joint guidelines and data governance to ensure project-wide consistency and joint understanding of the approach and needs.

  • Open by default is the approach taken by the project to ensure maximised transparency and replicability. It should be reflected in all project work.

  • Open data open city data, open research data, etc. in line with FAIR principles (making research data findable, accessible, interoperable and re-usable)Footnote 6.

  • Enabling and facilitating systems open for everyone to ensure access not only to data, but also to frameworks and systems as much as possible.

  • Citizen engagement Engagement of citizens and external stakeholders through workshops, co-creation activities, early involvement, hackathons, open data, etc. is an open-ended tasks. Being able to integrate any unexpected results in an agile manner is a benefit and needs to be enabled properly

  • Open innovation as a guiding principle to enable meaningful connections and contributions from city and citizens, industry, academia, and other stakeholders [7, 8, 10].

  • Sustainability in both the ecological use of ICT [2] and the technical sustainability of solutions for long-term use and migration options for after the project.

  • Opening up and connecting silos is important since many existing systems to be used may be rather closed. Making them open and interoperable is a benefit for the project, but also for future work by others.

  • Reuse of existing knowledge from other Smart City and ecosystem project, reusing existing frameworks, standards, etc. See the overview in Sect. 5.2.

  • Transformation and change, smart city projects as a hub and trigger for change, as well as using existing transition projects to realise co-benefits [3]

  • Supporting digitalization and digital transformation.

  • Migration and integration of relevant parts after the project.

Fig. 1.
figure 1

Adapted from [11]

Smart city co-evolution through city and ICT/EA views.

At their core, many smart city initiatives are change projects and part of the digital transformation. This in turn means that frameworks and architectures need to address issues of large-scale system evolution and transition [3]. This also hold true for new smart city projects, as they do not operate on a blank slate. Figure 1 shows a few key concepts around this, based on [11] and adapted to this project space. It highlights the importance of including the city needs and strategies, the internal and external constraints and stakeholders, and the technological constraints and opportunities towards smart city co-evolution. The depicted concept is strongly linked to open innovation and stakeholder engagement through quadruple helix approaches, as discussed in Sect. 1.

5.2 Ecosystem Architecture

Following the definition of an ICT ecosystem from the Open ePolicy Group [13], the service-oriented ecosystem of +CityxChange encompasses not only the data, applications and technologies, but also the policies, regulations, processes, and stakeholders that together constitute the larger technology environment for implementing +CityxChange solutions in each of the cities.

The overall ecosystem will need to address different scales of granularity of systems and components ensuring interoperability and operation: individual partner and city systems (existing and new, posing different interoperability and integration challenges); individual demo projects; demo areas and sites within cities; general project within a city; overall project, integrating all cities. In addition, it needs to address the challenges raised above in Sects. 3 and 5.1.

We choose to follow an architecture style that moves away from central monolithic systems to distributed service-oriented ecosystems in a systems-of-systems thinking. We see this move in many other places. Foe example, the European SCC-1 project calls are evolving. As one of the latest changes, there has been a move away from central project-based systems. In part this is also based on the expectation that partners are mature enough for the next step in the energy transition and that smart cities will already have their own data platforms. This opens the path towards a distributed architecture, which allows all partners to operate their own systems towards a common project goal by focusing on an ecosystem approach with suitable interfaces between systems.

Additionally, common architecture styles that follow layered and distributed structures are being used more often, including for smart cities [22]. The TOGAF method can be represented as a layered architecture, where the different views (Business, Applications and Technology) could be considered as a layer. Thus, it is not surprising that some of the smart city architectures reported in the literature use a TOGAF-inspired layered approach.

Fig. 2.
figure 2

(Source: [9])

ESPRESSO smart city reference architecture.

The ESPRESSO Smart City Reference ArchitectureFootnote 7 [9] is a major EU-funded initiative. It is partly based on the TOGAF methodology and has selected relevant architecture artefacts for Smart Cities, similar to our project. As shown in Fig. 2, its conceptual reference architecture starts from the consumers of the services at the top. It then identifies the services provided by the enterprise (business services), the applications to support the services, the data services and the data sources. The bottom layers include physical sensing devices to capture real-time and survey data and their physical positions. Several cross-cutting services, such as the security, auditing, communication, and collaboration services, as well as integration, business intelligence, master data management etc. are linked to all the layers. We in turn have drawn inspiration from the ESPRESSO layered architecture and ability for decentralization.

The ITU meta-architecture [11] follows a similar multi-tier or layered model. It uses hard and soft infrastructure and surrounding layers defined as Natural Environment; Hard Infrastructure (Non ICT-based, such as urban infrastructure); Hard Infrastructure (ICT-based); Services (smart city services); Soft Infrastructure (people, governance, software and data).

Closer towards concrete implementation, data models, and exchange formats, FIWAREFootnote 8 [20] is an extensive framework and library of a networked architecture and an extensive list of data models for numerous entities and sensors/actuators within a smart city and will help to ensure standard-compliance, along with other relevant standards. It is a European project in line with the Digital Single Market strategy, and ensures portability, interoperability and openness of services across Europe.

Both Lighthouse Cities, Limerick and Trondheim, are part of the international smart city network Open & Agile Smart Cities (OASCFootnote 9). OASC has the goal of creating and shaping the nascent global smart city data and services market and, as our project, is driven by implementation and focused on open platforms and citizen engagement. The Minimal Interoperability Mechanisms (MIMs) approach inspires the replication task in our project, as MIMs are simple and transparent mechanisms, ready to use in any city, regardless of size or capacity. In practice, the OASC MIMs are a set of common (realtime) APIs to access data, context information to structure data, and a common, but optional, data platform to store and serve data. In addition, a reference architecture and a reference implementation complete the set of MIMs.

Fig. 3.
figure 3

(Source: +CityxChange project)

Conceptual view of the +CityxChange service ecosystem high-level architecture.

5.3 Proposed Solution

The conceptual view of the service ecosystem high-level architecture for the +CityxChange project is shown in Fig. 3. Following the ESPRESSO inspiration and adopting the TOGAF approach, the consumers of the services are described on the top layer, followed by the business services, which in this case are the actual demonstration projects around energy, modeling, and citizen engagement. This is followed by a governance, regulations, economy, and business model layer. Considering the focus on energy markets and prosumers of energy, this is an essential part of the service ecosystem of the +CityxChange project. As a side not, a lot of the resulting business models and value creation are also based on ICT approaches [5], but will be more than that and arise out of all aspects, including participation. Below this, the soft ICT services such as models, applications, data services, storage, and systems are described. The hard ICT components such as cloud infrastructure, smart grid, sensors, and other devices are found below the soft ICT layer. At the bottom, a non-ICT layer is described, identifying the physical context such as the energy hardware and controllers, buildings, other infrastructure, or public spaces. Furthermore, components in the service ecosystem are structured vertically according to the three themes of the project, ((i) integrated planning and design, (ii) common energy market and (iii) CommunityxChange). On the side of this, and not pictured, is an EA cross-cutting concern, comprising data and API repositories, user journeys, overall interface and architecture guidelines and other resources of use for the overall project development.

A recent Gartner reportFootnote 10 notes that the digital transformation requires organizations to choose new modern architecture styles and suggests service-oriented application architectures (SOA) Different styles of APIs, such as REST, SOAP, enterprise buses and others such as microservices or miniservices allow to abstract from individual partner and component details and easier include other digital services and assets. This forces an agreement on communication and interface definitions, structures, and workflows between systems, abstracting from implementation details. This supports our choices, as well as the large-scale software systems engineering literature that we do not go into detail at this time.

An open data platform will be established, supporting the “open by design” driver. KPIs stemming from the project will be published in the overall KPI system and by some cities in open data portalsFootnote 11. Note that the data to be published there is not limited to the KPIs. Trondheim municipality intends to open up as much data as possible, within legal boundaries, so third parties can use this data to develop innovative solutions. Also, it aims to become a good source of data for the university so students can work with real life data and real life scenarios rather than textbook examples. The work with the open data platform will not only be guided by the project, but will also find inspiration in other distributed open data platforms and aims to combine data from many different sources, some open, some national, some private. Partly to support open data, and partly to support the projects decision support, open APIs, with a clear description of the data models and functionality, will be provided, giving external parties access through various entry points. This approach is being used by multiple cities, and gives a chance to combine data nationwide.

6 Conclusion and Future Work

In this position paper we have presented IT-centered challenges that lie in designing an architecture for a flexible, open, transferable, and a replicable smart city ecosystem integrating a large number of stakeholders and systems. While we are describing one EU H2020 smart city project, we believe the challenges, principles, and initial solutions discussed here can be valuable for other projects, supporting our replication aim.

The project’s vision is to enable the co-creation and development of Positive Energy Blocks in smart sustainable cities in a holistic open innovation approach. This paper has presented an overview of the technological challenges in designing an overall ICT architecture and service-based ecosystem to enable this and other technological challenges and stakeholder integration.

The +CityxChange project is in its first few months and thus the work described in this paper is being discussed and refined and ideas for the detailed implementation are reviewed. Some of the main activities in the near future will be to instantiate the descriptions and ecosystem architecture provided in this paper, develop and maintain the repository for the lifecycle management of APIs, data models, vocabularies, etc. to support API discovery and registration, the identification and mapping of the data, data types and meta data and indeed the description of services and designing seamless integration of the multiple applications and data to support the demonstrations and their replication through architecture and interaction blueprints.