Enterprise Architecture in Smart Cities: Developing an Empirical Grounded Research Agenda

ABSTRACT

The concept of Enterprise Architecture is suitable for managing the complexity of heterogeneous systems and technologies in Smart Cities. However, many cities and their urban governance processes still face the challenges of digitalizing public services. This paper aims to assess the applicability of TOGAF in a real-world Smart City following a case study method. A novel research agenda with ten major directions is provided as a result of the practical observations. This contributes to the current understanding of the application of Enterprise Architecture in Smart Cities, focusing on the identified issues in practice and the need for further research.

KEYWORDS:

• Smart City
• enterprise architecture
• public service design
• digital transformation and innovation
• TOGAF

Introduction

The digital transformation and innovation of public services in Smart Cities have taken advantage of the rapid advances in information technology (IT) capabilities (Zhuhadar et al., 2017). The application of new technologies such as the Internet of Things (IoT), cyber-physical social systems, and embedded artificial intelligence (AI) in these cities makes the delivery of public services more efficient (Zanella et al., 2014; Chiang and Zhang, 2016). A Smart City is defined as an innovative city which must provide a digital infrastructure and a platform for delivering advanced and novel services (Piro et al., 2014). Several Smart City cases show how cities face the service demands of multiple stakeholders (e.g., city authorities, citizens, service provides) in various domains such as government, mobility, security, education, environment, and tourism (Chiang et al., 2015; Yavuz et al., 2018; Neirotti et al., 2014). The management and provision of those services represent a significant challenge for cities and municipalities that require a coherent and structured approach in order to digitally enable public service innovation (Helfert et al., 2018).

Enterprise Architecture (EA) is viewed as an engineering approach and strategy determining the required enterprise capabilities and subsequently designing the organization, processes, services, information, and technologies to provide those capabilities (Rouhani et al., 2015; Giachetti, 2012). EA can be used to structure the digital transformation of public services and, consequently, manage complexity in Smart Cities (Kakarontzas et al., 2014; Lnenicka et al., 2017; Tanaka et al., 2018). Numerous researchers describe concepts and frameworks for EA, and emphasize its benefits, such as increased stability, better strategic agility, and improved alignment with business strategy (Alaeddini et al., 2017). Concepts, views, and layers of EA provide a common framework for stakeholders and a guide to model different city concerns (Bawany and Shamsi, 2015). EA models can help to guide the development and deployment of public services in an integrated and autonomous environment, thus increasing the quality of life (Clement et al., 2017).

The challenges faced in the digitalization and management of public services are also a strong focus of the EU where a number of EAs for Smart Cities have been proposed (Kakarontzas et al., 2014; Cox et al., 2016; Lnenicka et al., 2017). The suggested approaches use a multi-layer architecture, ranging from consumers to the infrastructure layers to support these services in large-scale urban environments. A few EAs for Smart Cities have adapted and customized The Open Group Architecture Framework (TOGAF) and its Architecture Development Method (ADM) method as the basis to create the IT architecture (Cox et al., 2016; Pourzolfaghar et al., 2019; Hidayat and Supangkat, 2014). TOGAF is considered a major reference in the area of EA with its application in several fields (Desfray and Raymond, 2014; The Open Group, 2018). Besides, the TOGAF ADM method is essential to manage the development and transformation of an IT architecture. However, TOGAF currently has some shortcomings that restrict its application and the reach of its benefits in Smart Cities contexts.

The objective of this study is to conduct a case study to assess the TOGAF applicability in the design of a city service delivered by Limerick, an Irish Smart City. This paper presents the architecture artefacts modeled with the ArchiMate language for each phase of the TOGAF ADM. ArchiMate (The Open Group, 2017) is an EA modeling language that complies with TOGAF and is used in this paper to describe and visualize urban data. In addition to this, this paper discusses the main findings in terms of the benefits and shortcomings of the application of TOGAF in the Smart Cities domain. Finally, 10 research directions are provided which constitute a research agenda to support the empirical application and close the identified research gap. Researchers and practitioners can use these directions as a comprehensive foundation to make more effective architecture decisions and advance the research in the Smart Cities field.

The remainder of the paper is structured as follows: the second section presents the literature review. The third section introduces the research method. The fourth section presents the main findings of this study. The fifth provides a discussion on the results and presents the research challenges identified in practice. The final section concludes the paper and proposes future directions for this work.

Literature Review: Enterprise Architecture in Smart Cities

Smart Cities are urban environments where advanced services are offered to improve the quality of life for the citizens (Piro et al., 2014). These cities are complex systems that perform diverse urban governance processes, use heterogeneous systems and technologies, and aim to fulfill multiple goals (Bastidas et al., 2017; Komninos et al., 2019). A number of Enterprise Architectures (EAs) for Smart Cities have been proposed to manage such complexity and face the challenges of urban governance. More precisely, Cox et al. (2016) define the ESPRESSO reference architecture for Smart Cities based on the TOGAF framework. This reference EA establishes a baseline for interoperability between various city services, platforms, and sectoral data sources. Kakarontzas et al. (2014) present a conceptual EA framework for Smart Cities to support the development of software systems. The framework is based on architectural patterns that address the identified quality and functional requirements of such systems. Hidayat and Supangkat (2014) propose an EA solution for Smart Cities following the TOGAF ADM. The authors emphasize that EA serves as a means of communication between city stakeholders to improve the IT implementation for city service delivery. McGinley and Nakata (2015) proposed a community architecture framework and a development methodology. This framework supports the various requirements and perspectives of multiple stakeholders involved in city governance. Sobczak (2017) presents a model framework based on EA management for Smart Cities. The author stresses that Smart Cities implementation should involve a portfolio of coordinated IT and organizational projects to transform the way cities operate.

Mamkaitis et al. (2016a) introduce the concept of Urban Enterprises in order to view Smart Cities from the EA perspective. Pourzolfaghar and Helfert (2017), Helfert et al. (2018), and Pourzolfaghar et al. (2019) propose a multi-layered framework as a reference for applying EA to urban environments. The authors augment the traditional EA view of multi-layered frameworks by adding the elements of context and services that are central to Smart Cities. Lnenicka et al. (2017) propose a government EA framework to analyze the requirements of big and open linked data analytics in Smart Cities. This framework interconnects the business and application architecture in the public sector using open government processes. Petersen et al. (2019) propose an EA framework for Smart Cities to manage data through a variety of virtual enterprises that enhances business collaboration. The principal element of the framework is the exchange of data to create value-added services for the citizens and data owners.

EA helps users to understand and manage the complexity of enterprises. However, the complexity of Smart Cities with diverse interests and goals from a variety of stakeholders (e.g., city government administration and its citizens) makes it difficult to apply EA in this domain (Helfert et al., 2018; Kuk and Janssen, 2011). Current EAs for Smart Cities mainly follow the TOGAF framework and its ADM method. Yet, these studies do not detail the practical results and necessary work to adapt the TOGAF ADM method to Smart Cities contexts. This paper outlines the main findings of the application of TOGAF in a real-world Smart City to close the identified research gap. Moreover, future research directions are presented to guide the empirical application.

Research Method

In this study, a qualitative research approach was used to facilitate the exploration and a better understanding of the phenomenon studied (Lincoln and Denzin, 2011). Specifically, a case study method was selected to analyze the applicability of the TOGAF ADM for the design of services in Smart City contexts. A case study was chosen to provide a better understanding and a holistic and real-world view of the problem under study (Yin, 2014).

Limerick Smart City Overview

Limerick is a city in the County of Limerick, Ireland. It is situated in the Mid-West Region of Ireland with a population of approximately 94,192 residents, making it the third-largest city in Ireland. Limerick has held the title of a Lighthouse Smart City. It has a digital strategy (Limerick City and County Council, 2017) that defines a roadmap of initiatives to create better services and accelerate sustainable, social, and economic growth. This strategy aims to support the digital transformation and innovation of public services aligned to the needs of the citizens by using digital technologies.

Limerick Enterprise Architecture

Limerick Enterprise Architecture (LEA) (Limerick City and County Council, 2018) is the adoption of EA best practices to provide a set of EA guidelines for any local government-related project in Limerick. We developed the LEA project that focuses on different case studies to illustrate how EA can be applied to add value to the services of Limerick City and County Council. With this project, we developed the foundations for “Insight Limerick” – the portal for information sharing, open data, data visualization, and analytics to gain insights leading to value-added services.

Footfall-Counter Service

A footfall counter service was selected for this case study because measuring footfall is one of the major indicators of urban and rural activity and the success of initiatives and events. It provides information about the number of people in various places of interest in Limerick City and its rural areas. With this information, the main stakeholders of the city can make informed decisions related to the planning of the city environments and the improvement of smart travel initiatives to encourage sustainable transport modes (e.g., walking and cycling). Limerick was awarded the Purple Flag as a practical application of this data. The Purple Flag is an accreditation in Europe similar to the Green Flag award for parks and the Blue Flag for beaches. It is the highest award for a vibrant and safe evening and night-time economy for town and city centers. Purple Flag areas report a steady rise in footfall within the evening and night-time economy.

A pilot solution for the footfall-counter service was implemented by the city council; however, the collected data were only available from the cloud platforms of the service providers with limited access and formats. This caused data and application silos due to the lack of access to the collected data by the main stakeholders of the service. As part of the future state, new footfall-counters and cycling counters need to be deployed in the city to gather the data that support the decisions of additional stakeholders. These stakeholders are internal stakeholders belonging to different departments of the city council (e.g., smart travel department, tourism strategy department, forward planning department, and economic development department) and external stakeholders outside the city council (e.g., retailers and citizens). Historical and real-time information of footfall-counters for pedestrians and cyclists must be available in an integrated environment.

Data Collection and Data Analysis

A major strength of a case study is the opportunity to use different sources of evidence (Yin, 2014). We collected the data for the case study using a direct method and independent analysis (Runeson and Höst, 2009). This study was based on two principal data sources, namely meetings and secondary data. First, a total of 18 meetings were held as evidence from the discussions of the current and future status of the footfall-counter service in Limerick City and County Council, between April 2017 and October 2018. We took notes on each of the 18 meetings. The 18 meetings helped gather the overall requirements of the service. Such requirements involved business, data, application, and technology requirements of the current and future state of the service. The first meeting was conducted with the head of digital strategy and the data manager. They expressed the main objectives of the Smart City project and the relevance of applying EA to deliver the desired services to citizens. This meeting facilitated having an overview of the project and its activities during the timeline. Secondary data refers to existing data sources such as internal documents (e.g., the strategy and vision of the Smart City project), reports, and deliverables published in an internal document repository in the council. Service providers provided information (e.g., technology advice, service solutions, brochures, and quotations) which were also included as part of secondary data. Secondary data were obtained by requesting the data manager to grant us access to this information in the internal document repository.

The identification of the meetings and secondary data was made manually, using a unique text identifier with the corresponding date. The meeting notes were integrated with the secondary data to produce a detailed record of each session. For instance, the notes related to the sensor’s deployment were complemented with the secondary data regarding footfall-counter sensor providers. The data manager gathered specific requirements of the service from the senior managers of the city council departments relevant for the project. For example, he gathered the requirements in relation with data and application platforms which were discussed as part of our 18 meetings. All collected data from the case study were managed and analyzed using the computer assisted, qualitative data analysis software NVivo Version 11.

We began the analysis process by coding the main findings of the case study according to the different phases of the TOGAF ADM. All data were analyzed considering the architecture concepts of TOGAF ADM, and the factors that facilitate or limit their application in practice in the Smart Cities field. In particular, the requirements management, architecture vision, and the design phases (e.g., business architecture, information systems architecture, and technology architecture) of the TOGAF ADM were selected to illustrate the evolution of a baseline to a target architecture of the footfall-counter service. We followed an inductive and iterative process of reading and reviewing in detail the different data sources to assign the information analysis units to the selected TOGAF phases (Runeson and Höst, 2009). Following this research approach, the next section provides the main findings regarding the analysis of the applicability of TOGAF ADM in the design of the baseline and target architectures of the aforementioned service.

Findings: Applicability of the TOGAF ADM

Limerick City has decided to develop an EA based on the TOGAF 9.2 (The Open Group, 2018) and ArchiMate 3.0.1 (The Open Group, 2017) specifications. Each iteration of the TOGAF ADM adds resources to the Architecture Repository. In the following, the main architecture phases and resulting artifacts are described.

Requirements Management

The requirements management aims to define a process for identifying, storing, and assigning the requirements to the TOGAF ADM phases. Different stakeholders in the city council provide the main requirements of the service. A requirements catalogue summarizes all the gathered requirements. A procurement guidelines document is created based on the identified requirements in order to conduct an appropriate procurement process whereby generic specifications for footfall-counter service contracts are defined. Finally, those requirements are used to define a tender document in order to invite service providers to a bidding request for the supply of traffic counters for pedestrians and cyclists.

Figure 1 shows how the goal: digitally enable and transform public services in Limerick is realized by the outcome: available and integrated footfall-counter information. This outcome is in line with the city digital strategy principle: “Build once, use multiple times.” The principle defines that in the implementation of smart initiatives in Limerick City, “duplication will be avoided in order to avoid inefficient use of resources, silo approaches, and missed opportunities to improve current capabilities.” This principle is realized by a combination of identified application, data, and technology requirements (i.e., requirements of sensors).

Figure 1. Goal, outcome, principle, requirements

Phase A: Architecture Vision

The Architecture Vision Phase aims to develop a high-level description architecture to be delivered as a result of the future solution for the footfall-counter service. As Limerick already has a solution of the footfall-counter service, a baseline solution architecture is presented to understand the current issues (e.g., data and application silos). In this phase, the main stakeholders and their concerns related to this service are identified. Additionally, a target solution architecture is specified as part of the proposed solution.

Solution Concept Diagram (Baseline Architecture)

Solution concept diagrams illustrate concisely the major components of the baseline and target architectures of the footfall-counter service. Figure 2 presents the solution concept diagram of the baseline architecture that is represented through the service, information, and technology views. The service view presents the footfall-counter service and the users of the city council (i.e., smarter travel department) who use the cyclist and pedestrian information. The information view presents the software platforms provided by two different service vendors. Both software platforms allow users to authenticate in the system, configure the dashboards, and download the data in different formats (e.g., doc, pdf, csv, etc.). The technology view presents the hardware and software infrastructure to gather pedestrian and cyclist data from different city locations, using 3D video-based sensors and passive infrared (PIR) based technology sensors. In total, there are nine sensors deployed in the city: one in the city center and eight around the city. This diagram illustrates an issue associated with the integration of data due to the login in two different systems to access the information. This was due to having two different departments procuring services at two different points in time. Procurement rules are one of the main causes of incompatible, non-integrated systems being implemented in cities, hence the need to develop better procurement guidelines. Each user downloads the information from diverse sources with different data formats. Information is not adequately shared but rather remains stored independently within each system, resulting in data and application silos. The stakeholders of the Smart City do not perceive the real value of the information collected through this city service.

Figure 2. Solution concept diagram (Baseline Architecture)

Solution Concept Diagrams (Target Architecture)

As part of the target architecture, Limerick aims to provide the footfall-counter service to a wide range of users in the city. Figure 3 shows the stakeholder map, identifying six stakeholders and their concerns. These stakeholders are organized in two groups: internal stakeholders and external stakeholders. Internal stakeholders belong to different departments within the city council (e.g., smart travel, economic development, tourism strategy, and forward planning). External stakeholders refer to stakeholders outside of the city council (e.g., retailers and citizens). The concerns of those stakeholders are modeled as drivers. As an example, users of the smarter travel department should identify the number of people who use bicycles to justify and request funding for smart travel projects. The target architecture must address all these concerns through EA models organized into multiple views.

Figure 3. Stakeholders map

One of the main objectives of the target architecture is to avoid data and applications silos while providing accurate real-time and historical information. Figure 4 presents a structured overview of the of the target architecture, using a layered solution concept diagram. The target architecture entails models and concepts that are specified in the service, information, and technology views. The service view presents the main actors (e.g., city authorities, retailers, and citizens) and their roles, and the departments within the city council that will use the footfall-counter service. The information view presents the application programming interfaces (APIs) offered by the service providers in order to access data collected by the footfall-counter sensors. Insight Applications (i.e., applications deployed in the city council to access, analyze, and download data) comprise the service clients and software applications (e.g., internal and public applications) to retrieve and visualize the collected data. The APIs encapsulate the data provided by service vendors. The technology view presents the hardware and software infrastructure to gather pedestrian and cyclist data. Data can be transmitted directly from the sensor to a provider database or to a gateway. The acquisition gateway can connect to all types of smart devices that generate relevant data.

Figure 4. Solution concept diagram (Target Architecture)

The refinement of the target architecture is modeled using the business, information, and technology phases of TOGAF ADM as follows.

Phase B: Business Architecture

The Business Architecture Phase aims to develop a target business architecture to describe how to achieve the business goals and respond to the strategic drivers that support the Architecture Vision. Business catalogues (e.g., Driver/Goal/Objective catalogue, Business Service/Function catalogue, Location catalogue), matrices (e.g., Actor/Role matrix), and diagrams (e.g., Value Stream diagram, Business Process diagram) were developed to demonstrate the applicability of TOGAF ADM within the Smart City project. In the following sections, architecture diagrams are modeled to carry over and support the business target architecture according to the requirements of the stakeholders.

Goal/Objective/Service Diagram

The purpose of a Goal/Objective/Service diagram is to define how a service contributes to the achievement of a business vision or strategy. Services must be associated with the drivers, goals, objectives, and measures that they support. This can facilitate Limerick City to understand which services contribute to similar aspects of the city performance. Figure 5 presents the Goal/Objective/Service diagram of the footfall-counter service that provides qualitative input on what constitutes high performance for this service. This diagram refines the high-level goals of the digital strategy into more tangible goals and the refinement of tangible goals into principles and requirements that are needed to realize the goals.

Figure 5. Goal/Objective/Service diagram

Value Stream Diagram

The value stream diagram illustrates how Limerick City delivers value in the context of the main stakeholders of the footfall-counter service (e.g., city authorities, retailers and citizens). Figure 6 presents the value stream diagram to show how the footfall-counter service creates the value that is exchanged with the main stakeholders. Limerick City can use the value stream to analyze the delivering of value within the scope of the project. This can help to better support the development of new solutions in later phases that might focus on specific stakeholders and the value produced for them.

Figure 6. Value stream diagram

Business Process Diagram

The business process describes the flow of the structured activities which in a specific sequence produce a service. Limerick City can use a high-level design of business processes in order to provide a city authority with insight into the processes and their shared services. Figure 7 shows a part of the business process diagram, identifying the departments inside of the city council represented by business functions and their key activities. This diagram depicts the way the footfall-counter service is realized by business processes.

Figure 7. Business process diagram

Phase C: Information Systems Architectures

The Information Systems Architecture Phase aims to enable the architecture vision and target business architecture to address the stakeholder concerns. Phase C comprises the combination of both data and application architectures. Matrices (e.g., Data Entity - Business Function matrix), and diagrams (e.g., Class diagram, Application Communication diagram, System Use Case diagram, Entity Relationship diagram) were developed to demonstrate the applicability of TOGAF ADM within the Smart City project. The following architecture models are presented in order to address the major challenges in Limerick City with respect to data and application integration.

Class Diagram

The purpose of the class diagram is to detail the relationships among fundamental data entities (or classes) of a system. Figure 8 presents the relationships between data entities regarding the footfall-counter service. These data entities and their relationships help to derive and define service application components, services data exchange and repository data schemas.

Figure 8. Class diagram

Application Communication Diagram

The purpose of the application communication diagram is to depict the architecture models in relation to communication between applications. Figure 9 depicts application components and interfaces between software services (e.g., APIs offered by service providers) and application components deployed in the city council. APIs enable interaction between data, applications, and devices and are associated with HTTP clients to support the data integration in Limerick City.

Figure 9. Application communication diagram

Phase D: Technology Architecture

The Technology Architecture Phase aims to enable the architecture vision business and target business and information systems architecture to be delivered through technology components and technology services. Matrices (e.g., Application/Technology matrix) and diagrams (e.g., Environments and Locations diagram) were developed to demonstrate the applicability of TOGAF ADM within the Smart City project. The following architecture models were designed in order to support the collection of pedestrian and cyclist information and to analyze the implications on the technology components and services.

Environments and Locations Diagram

The purpose of the application communication diagram is to represent in which locations of the city the sensors will be deployed. Figure 10 depicts the physical devices (e.g., footfall-counter services) and technologies (e.g., 3D video-based technology, PIR-based technology) used in each location. The technology of the sensors in each location is selected according to the physical characteristic of the place, i.e., sensors must be non-intrusive, suitable for urban location and must not be influenced by weather conditions.

Figure 10. Environments and locations diagram

Table 1 summarizes a sequence for the various phases and steps involved in developing this architecture (e.g., Requirements Management and Phases A, B, C and D). The artefacts and their purpose of use are presented for each phase of TOGAF ADM. As an example, the architecture requirements are specified to manage the requirements of the footfall-counter service and to support the procurement process of footfall-counter sensors.

Table 1. Architecture Artifacts of the Project

TOGAF ADM Phase	Artifact (Deliverable)	Purpose of Use
Requirements Management	Architecture Requirements Specification	To manage architecture requirements identified for services
Phase A: Architecture Vision	Solution Concept Diagrams (Baseline and Target Architecture)	To illustrate concisely the main components of the architecture solution
	Stakeholders Map	To engage city stakeholders involved and their concerns
Phase B: Business Architecture	Location Catalogue	To identify the locations where services operate in the city
	Goal/Objective/Service Diagram	To define how a service contributes to the achievement of the smart city vision or strategy
	Driver/Goal/Objective Catalogue	To provide a cross-organizational reference of how the city meets its drivers
	Business Service/Function Catalogue	To provide a list of services and their corresponding functions
	Actor/Role Matrix	To present the roles undertaken by each actor, including the role of citizens and city authorities
	Value Stream Diagram	To illustrate how the service delivers value in the context of the main city stakeholders
	Business Process Diagram	To provide city stakeholders with insight into the processes and their shared services
Phase C: Information Systems Architecture	Data Entity - Business Function Matrix	To detail the relationships among fundamental data entities of services
	Class Diagram	To present the relationships between fundamental data entities within services
	Application Communication Diagram	To depict software components and interfaces between software services and applications
	System Use Case Diagram	To describe the interactions of citizens and city authorities with applications
	Entity Relationship Diagram	To present information system entities and the relationships between those entities
Phase D: Technology Architecture	Application/Technology Matrix	To present city applications and their related technologies
	Environments and Locations Diagram	To depict the city locations where sensors and software services are deployed

Discussion

In this section, we discuss the benefits and shortcomings found when applying TOGAF ADM in the design of a footfall-counter service. In addition, research challenges are provided, focusing on practical observations and the need for further research.

Benefits and Shortcomings of the TOGAF Application

As described in the previous section, TOGAF defines a recommended sequence for the various phases and steps involved in developing an architecture (The Open Group, 2018). Next, the benefits and shortcomings of each applied phase are presented based on the practical observations.

Requirements Management

TOGAF supports a dynamic process whereby requirements for EA and subsequent changes to those requirements are managed (The Open Group, 2018). However, the framework provides very limited guidance to support city services architecture requirements. The requirements of Smart Cities must capture the main functionalities of the Smart City systems including resource discovery, application run-time, access to external data and the quality characteristics of systems like privacy, scalability, security, reliability, context-awareness (Bastidas et al., 2018). Therefore, requirements management for Smart Cities needs to be improved in order to describe the specific interests and concerns of diverse stakeholders and systems. This can help to better support the procurement process in public sectors and to prevent the implementation of wrong solutions (e.g., the deployment of inappropriate sensor technologies).

Phase A: Architecture Vision

TOGAF guides the development of a high-level architecture vision to be delivered as a result of the proposed Enterprise Architecture (The Open Group, 2018). However, the architecture vision should consider the architecture principles and related Smart City principles to guide the design of coherent IT solutions (Mamkaitis et al., 2016b). The classification of stakeholders, their concerns and the development of city service scenarios are necessary in order to articulate the Architecture Vision that responds to the identified requirements. Specifically, an Architecture Vision Template for Smart Cities should contain the aforementioned architecture concepts to ensure an early definition of required services.

Phase B: Business Architecture

TOGAF defines a business architecture to describe how to achieve business goals and respond to the strategic drivers (The Open Group, 2018). In Limerick, the digital strategy contains the main motivations, goals, objectives, principles, and initiatives to become a Smart City. It is necessary to establish a link between the digital strategy and the proposed Enterprise Architecture. TOGAF can assist in the establishment of this connection, however, particular concepts of Smart Cities should be defined in the architecture. Especially, indicators for city services and quality of life are required to measure the performance of a Smart City (ISO 37120, 2014). Introducing these indicators into the architecture can help to represent what is measured, and how that measurement is to be undertaken. City managers can plan better for future needs depending on the current use and efficiency of resources. City business units should be defined to identify what services and who delivers them to different actors (e.g., to the users of the City Council and citizens). In addition, Limerick City has a service portfolio to provide to its citizens a comprehensive list of services across economic, social, and physical environment needs and challenges (Limerick City and County Council, 2017). City services and solutions must be related to the domains (e.g., transportation, environment, economy, etc.) to allow the identification, integration and interoperability of systems and enhance decision making processes across different domains. Finally, business architecture focuses on business motivations and operations, but Smart Cities should follow a service orientation, mainly centered on the needs of citizens.

Phase C: Information Systems Architecture

TOGAF defines an information system architecture (data and applications) to address the statement of architecture work and the concerns of stakeholders (The Open Group, 2018). However, a data model for Smart Cities has to be able to describe and integrate data from multiple domains. It is required to identify the private and public data and the permissions to share data between different actors of the city. Applications should visualize the main indicators through the use of different dashboards. Software services are crucial to realize city services due to the service orientation of Smart Cities. Those services (e.g., a footfall-counter software service) should be defined and managed in order to be used and discovered automatically by citizens. For instance, software services can be discovered according to the urban context given by places close to the gateways and the city services that they offer to the citizens (Cabrera et al., 2018).

Phase D: Technology Architecture:

TOGAF defines technology architecture to realize the information system architecture and address the concerns of multiple stakeholders (The Open Group, 2018). Technology architecture assists in identifying the hardware and software infrastructures such as networks, storage structures, physical devices, etc. to support the daily activities of citizens and the Smart City operation. However, the specific concepts of Smart Cities should be detailed (e.g., sensors, actuators, gateways, etc.) in order support the interoperability of the collected data by monitoring devices within the network.

Based on the previous discussion, Table 2 summarizes the TOGAF ADM phases, architecture concepts covered and the identified limitations in terms of what is lacking in TOGAF to be applied in Smart Cities.

Table 2. TOGAF ADM limitations for Smart Cities

TOGAF ADM Phase	TOGAF Architecture Concepts	TOGAF Limitations
Requirements Management	Requirements Management: Business architecture requirements Information systems architecture Technology architecture requirements Interoperability requirements	Requirements Specification: City service architecture requirements Multi-stakeholder perspective Feed the service procurement process
Phase A: Architecture Vision	Motivation: Architecture principles, drivers and constraints Problem Description: Stakeholders and their concerns Business scenarios and issues Architecture: High-level baseline and target architecture	Motivation: Related smart city principles Problem Description: Multiple and diverse stakeholders City service scenarios and issues Architecture: Smart city architecture vision template
Phase B: Business Architecture	Orientation: Business motivations and operations Motivation: Driver, goal, objective, measure Organization: Organization unit, actors, roles Behaviour: Business service, process, function Contract, service quality Business capability, value stream	Orientation: Service orientation and citizen centricity Motivation: Digital strategy link City service indicators Organization: City business unit, multiple actors, roles Behaviour: City service Decision process Smart city application domain
Phase C: Information Systems Architecture	Data: Data entity, logical and physical data component Application: Logical application component, physical application component Information system service	Data: City data model Public and private data Application: City data visualization functions Domain software service
Phase D: Technology Architecture	Technology Service: Service provider technologies Logical Technology Component: Service provider platforms Physical Technology Component: Physical locations for sensors	Technology Service: Service management functions Logical Technology Component: Virtual objects Physical Technology Component: Gateways, sensors, actuators

Research Agenda

In this section, ten major research challenges are provided, focusing on identified issues in practice and the need for further research.

• Procurement Process: The procurement process of services in the public sector needs to be adjusted to respond to the growing transformation (Ylinen and Pekkola, 2019). End-users in Limerick City Council have domain knowledge of their field such as planning city environments, economic development, tourism strategies, etc. However, they have little understanding of IT (e.g., cloud services, APIs, sensor technologies, etc.). Understanding the potential of technology is essential before drafting the final specifications of services. Procurement plans and proposals should be prepared based on the requirements and needs of the stakeholders in collaboration with experts in the Smart City domain and Enterprise Architecture experts that can stand or bridge the interface between knowledge of the technology and its application in this problem domain. Consequently, more research is necessary to support this process within the public sector in the digital transformation age.

• Added-Value Services: The application of TOGAF can help to innovate and add value to public services, facilitating the design of solutions that allow more efficient use of data and applications. There is a need for this data to be available to all stakeholders in order to provide added value to these data sources (Lnenicka et al., 2017). Early identification of the stakeholders and their concerns in relation to the required data to make decisions contributes to the design of added-value services. It is necessary to continue investigating how to capture the requirements of multiple and diverse stakeholders in an Architecture Vision template to provide a high-level, aspirational view of the added-value services.

• Service Orientation: The major themes that arise regarding the public sector and Smart Cities are efficiency and integration of services to meet the needs of citizens (Nam and Pardo, 2011; Comerio et al., 2013). Different studies show how the public sector and Smart Cities have shifted towards a service orientation paradigm (Bifulco et al., 2016). Service orientation not only involves IT services but also people and personal interactions to meet a required level of quality of city services (Åkesson et al., 2008). The characteristics of service orientation need to be fully considered in the service design in order to achieve interoperability and deliver efficient public services to citizens.

• Citizen-Centricity: The principle “Citizens First” in the digital strategy of Limerick City establishes that “While support for customers is paramount, any initiatives will put the citizen’s interest first. Any designs must start with the citizen needs as far as it is practical” (King and Cotterill, 2007, 342). It is crucial to keep the objectives centered around benefits to the citizens and the ability of the citizens to contribute to the success of Smart City initiatives (King and Cotterill, 2007). A citizen-centricity approach can improve the quality of services that governments provide to citizens (Pereira et al., 2018). Therefore, strategies for citizen participation and engagement in the definition and design of services are key to enhance services and experience.

• Non-duplication: In the public sector, it is possible to have duplicated efforts, objectives and implementation options of the same initiatives (Tammel, 2017). In this case study, we saw how software applications that support the same city service were duplicated, increasing the cost to manage the applications and the difficulty of using several platforms. IT integration in the delivery of public services is critical for cities in order to avoid significant duplication of costs and effort, incompatible systems that generate information silos and limit the ability of city departments to collaborate in service provision. Hence, it is imperative to design city services, impacted stakeholders, and related interfaces to avoid duplication of systems and data silos.

• Interoperability: The interoperability of heterogeneous systems and technologies in Smart Cities is paramount (Ahn et al., 2016). It is necessary to define a set of common standards protocols to guarantee interoperability of different IoT devices (e.g., sensors, gateways, actuators, etc.). TOGAF allows the creation of a technology standards catalogue that could be used to ensure interoperability and adaptation within a specific technology architecture (The Open Group, 2018). Technology architecture specifies appropriate technical mechanisms to permit the information and service exchanges (e.g., APIs, data formats, protocols, hardware interfaces, standards).

• EA Layers Refinement: This case study shows that traditional EA layers (e.g., business, information systems, and technology) are suitable for structuring an EA for Smart Cities but not optimal for this purpose. More refinement layers are required, e.g., by identifying city services which operate differently. For instance, those services must respond to the concerns and goals of multiple and diverse stakeholders (Marrone and Hammerle, 2018) in order to support the Smart City strategy. Citizen support should be considered as one of the central aspects when refining architecture layers, as the point of view of citizens is crucial for Smart Cities (Pereira et al., 2018).

• EA Management Refinement: This case study presents how EA Management, specifically TOGAF ADM can assist cities and municipalities to digitize and transform public services. However, digital transformation affects EA Management (e.g., EA concepts and frameworks) (Julia et al., 2018). Hence, there is a need to refine the EA Management and related EA lifecycle. New mechanisms and processes of managing IT within Smart Cities and the wider public sector should need to be defined.

• Domain Specificity: There are various levels of domain specificity that may be represent a business sector, a paradigm, or a particular application area such as the Smart Cities domain (Karagiannis et al., 2016). A metamodel defines a language for describing a specific domain of interest (Bézivin, 2004). Metamodels describe and organize the abstract syntax (e.g., concepts, attributes, and relations), constraints and static semantics of a specific domain. The assessment of the TOGAF ADM in this case study shows that EA concepts for Smart Cities (e.g., domains, indicators, service objectives, organizational structures, decisions, APIs, sensors, etc.) need to be represented in architecture models. Accordingly, EA approaches and concepts such as EA metamodels need to be extended with these specific concepts of the Smart Cities domain.

• EA Modeling Tools: This case study demonstrates that ArchiMate can be used to describe, analyze and visualize EA in the context of Smart Cities. Smart Cities are complex systems, and modeling tools such as ArchiMate facilitates the management of complexity by applying abstraction (Bork et al., 2018). However, in the ArchiMate language, there is no accurate form of presenting some specifics of Smart Cities (e.g., city services, domains, indicators, sensors, etc.). ArchiMate can be extended with the architecture concepts and relationships between them to reduce complexity in the design of services and to support strategic alignment in public sector (Bastidas et al., 2021). This extension may also be relevant for simulation mechanisms of a variety of Smart City scenarios, for example, to simulate the location of sensors that may be affected by the unexpected behavior of pedestrians (Pax et al., 2017).

Conclusions

The management and provision of public city services represent a significant challenge for many cities that require a coherent and structured approach to digitally enable public service transformation (Helfert et al., 2018). This paper presents a case study to assess the applicability of the TOGAF ADM in the design of services delivered by an Irish Smart City. This paper discusses the benefits and shortcomings of each applied phase driven by the practical observations. Results demonstrate that it is necessary to modify or extend the TOGAF ADM to suit the specific needs of Smart Cities (e.g., multi-stakeholder perspective, service orientation, citizen centricity, service interoperability, etc.). We developed a research agenda with ten main research directions to close this research gap. This contributes to the current understanding of the application of EA to the Smart Cities field, focusing on the identified issues in practice and the need for further research. Researchers and practitioners can use these directions as a comprehensive foundation to make more effective design decisions and advance research in Smart Cities.

The results of this paper are also beneficial to ongoing research regarding the creation of a reference methodology for developing and transforming public services. Moreover, we have used these research results to extend the ArchiMate language with the specifics of Smart Cities (e.g., city domains, objectives, service indicators, sensors, gateways, actuators, etc.) to support the strategic alignment. This will allow the design of coherent and integrated architectures for Smart Cities which meet the requirements of stakeholders and systems in an integrated environment. We envisage that it can assist Smart City initiatives in digitalizing public services in alignment with city goals and objectives.

Acknowledgments

The authors would like to thank the people within the case for their active contribution.

Additional information

Funding

This work was supported with the financial support of the Science Foundation Ireland [grant 13/RC/2094] and co-funded under the European Regional Development Fund through the Southern & Eastern Regional Operational Programme to Lero—the Irish Software Research Centre (www.lero.ie).

Notes on contributors

Viviana Bastidas

Viviana Bastidas is a research associate at the University of Cambridge.

Marija Bezbradica

Marija Bezbradica is an assistant professor at the School of Computing, Dublin City University (Ireland) where she specializes in the data science, particularly in the areas of probabilistic and predictive modelling.

Mihai Bilauca

Mihai Bilauca was the Head of the Digital Strategy and EU Programmes departments in Limerick City & County Council, Ireland.

Michael Healy

Michael Healy is the Data, Analytics and GIS Manager at Limerick City and County Council. He is part of the network of senior Council staff that support the development of the Digital City and Smart Limerick initiatives.

Markus Helfert

Markus Helfert Markus Helfert is a professor at Maynooth University (Ireland) and the Director of the Innovation Value Institute at Maynooth University.