A Conceptual Enterprise Architecture Framework for Smart Cities

A Survey Based Approach

George Kakarontzas

, Leonidas Anthopoulos

, Despoina Chatzakou

and Athena Vakali

Department of Computer Science and Engineering, TEI of Thessaly, Larissa, Greece

Department of Business Administration, TEI of Thessaly, Larissa, Greece

Department of Informatics, Aristotle University of Thessaloniki, Thessaloniki, Greece

Keywords: Digital Cities, Smart Cities, Survey Study, Software Architecture, Reference Architecture, Software

Quality.

Abstract: Enterprise architecture for smart cities is the focus of the research project “EADIC - (Developing an

Enterprise Architecture for Digital Cities)” which is the context of the reported results in this work. We

report in detail the results of a survey we contacted. Using these results we identify important quality and

functional requirements for smart cities. Important quality properties include interoperability, usability,

security, availability, recoverability and maintainability. We also observe business-related issues such as an

apparent uncertainty on who is selling services, the lack of business plan in most cases and uncertainty in

commercialization of services. At the software architecture domain we present a conceptual architectural

framework based on architectural patterns which address the identified quality requirements. The conceptual

framework can be used as a starting point for actual smart cities’ projects.

1 INTRODUCTION

The European Smart Cities project defines a smart

city as a city “well performing in 6 characteristics,

built on the ‘smart’ combination of endowments and

activities of self-decisive, independent and aware

citizens” (European smart cities project, 2007).

These 6 characteristics are: smart economy,

mobility, environment, people, living and

governance. Such diversity creates a challenging

landscape for smart cities’ enterprise architecture

(Anthopoulos and Fitsilis, 2013). However without

carefully crafted software architectures and the

corresponding business processes supporting them,

it is not possible to handle the complexity of a smart

city project. In this work we present a survey for

smart/digital cities. The purpose of the survey was

twofold: (1) discover important quality properties

for smart cities and propose a conceptual

architectural framework for smart cities with these

properties. This framework can be used as a starting

point for actual smart city architectures. (2)

understand the current state in business aspects in

relation to the IT support infrastructure for smart

cities’ projects.

The rest of this paper is organized as follows: in

Section 2 we present the survey’s details including

its construction and participants as well as the

questionnaire and the obtained results. Then in

Section 3 we use survey’s results to derive

functional and quality requirements. Based on these

requirements we proceed in Section 4 in deriving

appropriate architectural patterns for use in smart

cities and we propose a conceptual application

architecture framework for smart cities, which is

based on these patterns. Finally in Section 5 we

discuss related work and in Section 6 we present

briefly some future research directions and

conclusions.

2 SURVEY DETAILS

The construction of the survey targeted the most

important aspects of enterprise architecture, namely

organizational structure, business processes,

information systems and infrastructure (Lankhorst,

2009). Consequently our survey comprises five

general groups of questions: “architectural relative

questions”, “data sources”, “smart city management-

organization and funding”, “smart city management-

Kakarontzas G., Anthopoulos L., Chatzakou D. and Vakali A..

A Conceptual Enterprise Architecture Framework for Smart Cities - A Survey Based Approach.

DOI: 10.5220/0005021400470054

In Proceedings of the 11th International Conference on e-Business (ICE-B-2014), pages 47-54

ISBN: 978-989-758-043-7

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

critical issues/milestones”, and “smart city

management-project mission and objectives”.

The experts who participated in the survey are

engineers of real smart cities throughout the world.

In total there are 18 engineers from the following

smart cities: Digital City of Trikala (Greece), Den

Haag (The Netherlands), Amsterdam (The

Netherlands), Brisbane (Australia), Waterfront

Toronto (Canada), Turin (Italy), Thermi (Greece),

Thessaloniki (Greece), Heraklion (Greece), Zurich

(Switzerland), Geneva MAN (Switzerland), smart

city of Melbourne (Australia), green city of

Queensland (Australia), green city of Roland

Victoria (Australia), smart city of Brisbane

(Australia). Regarding the educational background

of the surveyed experts, 11 have a PhD, 5 have a

Master degree and 2 a Bachelor degree. The survey

took place in June/July of 2013.

The questionnaire comprises 34 questions,

including 3 questions with demographic

characteristics. As mentioned already, the

questionnaire is divided into five general categories.

In most questions multiple answers were possible so

the percentages do not always sum up to 100%. Also

notice that for brevity in most cases we only present

the most popular answers where the rest of the

answers do not influence the conclusions. Therefore

not all possible questions and responses are

mentioned in the various tables.

The first group of questions, entitled

“Architectural relative questions”, contains two

questions: “Provided services” and “Installed

infrastructure”. In the first the most popular services

are the environmental and communication services

with 67% and 56% respectively. In the second

question, the most popular infrastructures are wired

or wireless backbone infrastructures with 67% and

61% respectively (Table 1).

Table 1: Architectural Relative Questions.

Provided Services Total Percentage

Environmental services 12 67%

Communication services 10 56%

E-Government Services 9 50%

Installed Infrastructure Total Percentage

Wired backbone 12 67%

Wireless backbone 11 61%

Rented backbone 0 0%

The “Data Sources” category of questions (Table

2) tries to understand how data collection is

conducted and to identify the level of data security.

The first question is related to the “Data collection

and storage” where it appears that 72% of the smart

cities address this issue with direct data collection,

while the 33% with indirect methodologies.

Regarding the data storage 44% use local data

infrastructure and 22% external data infrastructure

(e.g. cloud storage). Additionally, there are three

questions related to the level of access in the

available data from the city administrative staff, the

city’s stakeholder’s staff and the city’s end users. In

these questions ‘project dependent’ access means

that different access mechanisms may be used per

project, whereas role-based authentication means

that access is provided based on the users’ role.

Concerning data ownership in general usually the

municipality and the project organization with 50%

and 39% respectively are responsible for the

manipulation of the data. In many cases data is

owned jointly by more than one organization.

Finally, an impressive element (not shown in Table

2) is that the 78% of smart cities do not make use of

encryption. The remaining 22% supported that

usually the data encryption is based on the used

software and the data in question.

Table 2: Data Sources.

Data Collection and Storage Total Percentage

Direct data collection 13 72%

Local data storage 8 44%

Indirect data collection 6 33%

External data storage (cloud) 4 22%

Access level of city's staff Total Percentage

Role-Based Access 7 39%

Project-Dependent 4 22%

Access level of city’s

stakeholders

Total Percentage

Project-Dependent 12 60%

Access level of end users Total Percentage

Individual Data Access 6 33%

Project-Dependent 5 28%

Data Ownership Total Percentage

Municipality 9 50%

Project Organization 7 39%

Various stakeholders 5 28%

Regarding the “smart city management -

organization and funding” set of questions the aim

was the identification of some critical financial,

administrative and promotional issues, as the

followed procedure is important for the viability of

the smart cities (Table 3).

The goal of the first question in this category was

the recognition of the key persons that are involved

in the performance of the services. Service

performance measurement here means which party

is responsible for monitoring and improving the

ICE-B2014-InternationalConferenceone-Business

various services. According to the results in all cities

the municipality was involved, as well as the local

transportation services with 50% and various others.

Of course in most of the cities more than one

organization are involved in the performance of

services.

Table 3: Smart city management - organization & funding.

Who are involved in service

performance measurement?

Total Percentage

Municipality 18 100%

Local Transportation 9 50%

Local SMEs 7 39%

Who funds the project? Total Percentage

Both Private & Public Sectors 10 56%

Public Sector 8 44%

Where do funds come from? Total Percentage

Government 9 50%

Individual funding 9 50%

EU 7 39%

Service Provider 5 28%

Who is responsible for

service promotion

(marketing)?

Total Percentage

Public Organization 12 67%

Municipality 12 67%

Private Company 10 56%

Who sells the services? Total Percentage

Uncertain 8 44%

Services are free of charge 3 17%

Private Companies 3 17%

Who collects incomes? Total Percentage

Municipality 4 22%

Free-of-charge 4 22%

Various stakeholders 4 22%

Who manages the services? Total Percentage

Municipality 13 72%

Project organization 12 67%

The next four questions are related to funding.

They reveal that usually either the public sector with

44% or the public and private sector together with

56% are responsible for the project’s funding.

Usually funds come from the government and/or

individual funding with 50% in both cases and the

European Union with 39% for the EU cities

involved in this survey. Regarding services’

marketing, it is being jointly performed by public

organizations with the municipality and private

companies in most cases. Regarding

commercialization of services 44% were uncertain

about the mechanism followed, while for 17% of the

participants services are either free of charge or sold

by private companies.

In respect to the income collection the

respondents stated that the municipality is

responsible for this procedure, that it is free-of-

charge or that various stakeholders are involved in

the procedure with 22% at each case.

In relation to the management of services, in

72% of the cases the municipality has this

responsibility and in 67% of the cases the project

organization (or in some cases both).

The next group of questions “Smart city

management - critical issues/milestones”, in Table 4,

tries to identify the quality of the provided services

based on the evaluations and the reviews that are

conducted during the operation of the smart city.

Initially, the respondents were questioned about the

key person or organization (public or private) that

had the initiative for the smart city. The municipality

was responsible in 44% of the cases and in 28% of

the cases a research team had this role.

Table 4: Smart city mgmt. - critical issues/milestones.

Who had the central

initiative?

Total Percentage

Municipality 8 44%

Research Team 5 28%

Who is responsible for the

service monitoring?

Total Percentage

Municipality 12 67%

Various stakeholders 5 28%

Project partners 4 22%

Do you perform evaluation

& reviews and if yes how

often?

Total Percentage

Regular evaluations 11 61%

How often are the

services/infrastructure

undergo maintenance?

Total Percentage

Uncertain 9 50%

Continually (more than

once/year)

3 17%

Rarely (less than once/year) 3 17%

Annually 2 11%

Depends on project

specifications

1 5%

Regarding the key actors in the service

monitoring, answers include the municipality (67%),

followed by “various stakeholders” (28%) and

project partners (22%). It is quite promising that

61% of smart cities perform regular evaluations and

reviews. Finally, the smart city managers’ were

asked to state the frequency with which the service

or infrastructure maintenance is carried out. 50% of

the respondents stated that they are not sure about

the frequency of this procedure, while the remaining

AConceptualEnterpriseArchitectureFrameworkforSmartCities-ASurveyBasedApproach

50% stated that this procedure takes place

continually, rarely, annually or depending on the

project’s specifications.

The final set of questions, namely “smart city

management - project mission and objectives”,

attempts to specify the reasons that led to the

development of the smart city and if the whole

project was developed according to some specified

standards, such as following business or project

plans.

Table 5: Smart city mgmt. - project mission & objectives.

Potential business goals Total Percentage

Innovative spirit 6 33%

Resource savings 6 33%

Increase extroversion 4 22%

Internal organization

structure

Total Percentage

N/A 11 61%

SOE (State-Owned

Enterprise)

5 28%

Individual organization 3 17%

Internal organization

framework

Total Percentage

Rules 10 56%

Guides 9 50%

What where your initially

provided set of services?

Total Percentage

Varies 8 44%

Intelligent Transportation 4 22%

Online dialogues 4 22%

Have you added services

and which?

Total Percentage

Too numerous to mention

individually

3 17%

Have you canceled services

and which?

Total Percentage

Intelligent Transportation 1 6%

The existence of a well-constructed

master/business plan determines to a significant

degree the city’s viability. Only 56% of the

respondents stated that a master or business plan was

followed, which is a quite small percentage for such

an important procedure, whereas 44% did not follow

a business plan. In the question “What are the

potential business goals” the predominant responses

(with 33% each one) were: innovative spirit,

resource savings and various other goals (for

instance increase city’s extroversion etc.).

The Internal Organization Structure in most

cases (61%) is not available. When available the

internal organization framework is based on rules

and guides.

A final set of questions was concerned with the

initially provided set of services and the evolution

(addition and cancellation) of the provided services.

3 FUNCTIONAL AND QUALITY

REQUIREMENTS FOR SMART

CITIES

In order to come up with the suitable architecture

patterns for the smart city architecture we will first

use the questionnaire results to understand the most

important functional and quality requirements for

smart cities. Then we will use these requirements to

suggest an architectural approach for smart cities

based on architectural patterns. Quality requirements

can be defined using the ISO-25010 quality model

(ISO/IEC, 2011), which provides the different

quality categories that we need to consider.

The many different types of applications and

services (Table 1 & Table 5) reveal the need for a

generic application architecture, ensuring at the

same time the communication between these

applications in a seamless manner (if needed).

Therefore ensuring interoperability among these

different applications and services is necessary.

Providing only a small percentage of security and

health related applications (22% each), smart cities

seem to have a relatively low need (at the moment)

for safety-related hard real-time infrastructures and

therefore performance efficiency sub-characteristic

of timing behavior is less important.

Since there is no virtualization (17%),

metropolitan backbone (6%) and rented backbone

(0% in Table 1) it will be challenging to guarantee

specific Quality of Service (QoS) levels. It seems

again that time performance is not a predominant

concern.

In Table 2 the local storage (44%) combined

with the multitude of service performers (Table 3)

shows that data may be stored in many different

locations. Each application and the host organization

is ultimately responsible for safeguarding its own

data, but at the same time it should be possible that

other applications are allowed to access this data

remotely in prescribed ways. Therefore the

authenticity aspect of security becomes important as

well as the interoperability aspect of the

compatibility characteristic.

Table 2 also shows that data access is

complicated since many different parties may access

data with many different ways. Again this shows

that each application should be made responsible for

ICE-B2014-InternationalConferenceone-Business

providing its own authentication mechanism. Role-

based access for authorization is needed for

administrative staff. Also in Table 2, depending on

the application and the organization responsible,

data is owned by many different parties, something

that again creates a need for interoperability and for

the provision of some application dependent data

access mechanism. There are a small percentage of

cases (22%) that use encryption. So confidentiality

may not be one of the prominent architectural

drivers, but nevertheless it should be possible.

Table 3 reveals that there is a multitude of

service performers. This fragmentation of

responsibility strongly points to the need to create

some interoperability layer between these services

since in many cases the performance besides the

Municipality is assigned to other parties. It also

raises concerns for the reliability of the provided

services as a whole. In general it may be more

challenging to guarantee that all provided services

are available all the time since the many different

installations for isolated services will have different

types of hardware/software infrastructure.

The marketing and commercialization of the

services (Table 3) show that most of the smart cities

projects at this time are not considered as income

sources with only 17% reporting that private

companies are responsible for services’

commercialization and an apparent fragmentation

regarding income collection. Therefore in order to

become viable, they must be able to provide these

services with relatively low cost. This creates some

constraints for the smart city project (e.g. usage of

open source software usually drops the cost at the

expense of supportability). Also, there is split

management between the Municipality and project

organizations, which again demonstrates the need to

provide interoperability, different access

mechanisms (usability) and different authorization

mechanisms (security).

Although there are evaluations and reviews

(Table 4), service maintenance is not performed

regularly. This shows that there is a need for

recoverability regarding the reliability quality

property. Services should be able to recover rather

gracefully and quickly in cases of failures.

The lack of business plan in many cases as well

as the existence of a multitude of potential business

goals (Table 5), imply that these projects can be

considered at the time as an umbrella under which

many different applications co-exist and can grow in

many different directions in the future. This creates a

need for improved maintainability in order to enable

such developments. This need is also apparent when

considering the diversity of the initially provided

services (Table 5). The multitude of provided

services also indicates that usability may be

important, especially when considering the different

types of user interfaces that may be required to

support all these different types of applications.

Concluding this Section we can say that the most

prominent quality drivers that we need to consider

are in the order of importance: 1) Interoperability;

2) Usability; 3) Authentication and

Authorization; 4) Availability; 5) Recoverability;

6) Maintainability; and 7) Confidentiality (should

be possible).

Free/Libre and Open Source Software (FLOSS)

can and should be used, when possible, to drive

down costs.

Of course the above mentioned ranking is a

generic one. Specific applications may have

different needs (e.g. an application may require

increased confidentiality).

4 SELECTING

ARCHITECTURAL PATTERNS

FOR SMART CITIES

In this Section we identify suitable architectural

patterns the combination of which provides a

conceptual application architecture framework for

smart cities considering the identified needs.

To follow a systematic approach, we apply the

Pattern-Driven Architectural Partitioning (PDAP)

proposed in (Harrison and Avgeriou, 2007) and

depicted in Figure 1. PDAP is a stepwise iterative

process that uses architectural patterns (Buschmann

et al., 1996) with known quality outcomes. Usually

in complex architectures, such as those for smart

cities, more than one architectural pattern must be

applied to satisfy the many and at times conflicting

architectural drivers.

In this work we do not have a complete

architecture to consider because specific functional

requirements do not exist and the stakeholder

concerns, as expressed in the questionnaire’s

answers, are generic and not particular for a specific

application. What we discuss here is best described

as a conceptual application architecture framework

capturing the most prominent architectural drivers

for smart cities’ applications. This conceptual

framework will be modified and transformed as

necessary to address all specific functional and non-

functional requirements for specific smart city

projects. It is expected that in most cases the

AConceptualEnterpriseArchitectureFrameworkforSmartCities-ASurveyBasedApproach

framework will cover the most significant

requirements and will be suitable for most projects

without or with small modifications. Notice in

Figure 1 that we grayed out the tradeoff analysis

which is based on the documentation and evaluation

of a specific architecture. We cannot evaluate a

conceptual framework because many aspects (e.g.

specific technologies used), that have an impact in

the evaluation of the architecture, are not finalized.

Figure 1: Pattern Driven Architectur al Partitioning

(Harisson and Avgeriou, 2007).

The first step of PDAP is the identification of

prominent drivers, which was discussed in Section 3.

In the next step the architecture patterns for each

driver are selected.

1. Interoperability: For the interoperability aspect

we suggest an API Façade (Gamma et al.,

1995.) for each application. Each application

will expose through this façade a set of services.

In order to enable the communication between

different types of applications, possibly written

in different programming languages, the

provided façade will be WSDL-based using

SOAP/XML for the interfaces. To enable this

type of API we will use the Layers

architectural pattern (Buschmann et al., 1996)

for each application in which the Business

Logic layer is separate and the WSDL interface

can be built around this layer. Business layer

includes various services public or private etc.

depending on the specific smart city that the

proposed model will be used.

2. Usability: The use of the Model-View

Controller (MVC) pattern (Reenskaug et al.,

1996), (Buschmann et al., 1996) is highly

recommended in the User Interface layer to

enable many different types of presentation

approaches for the same data. This is considered

necessary since the same information may be

presented differently for different user types and

for different types of devices.

3. Authentication, Authorization & Confidentiality:

For these aspects the Layered architecture

pattern is very suitable because it can provide

authentication and authorization at designated

layers in the software architecture. Additional

services such as anonymity of information are

application-specific and are left for the

instantiation of the conceptual framework in

specific smart cities.

4. Availability and Recoverability: In order to

guarantee some availability in cases of failures

and to integrate additional data from many

possible databases that store data locally, we

propose the use of an integrated application

that communicates loosely with other smart city

applications using the Messaging architecture

pattern (Hohpe and Woolf, 2003). The

integrated application will run in a reliable

application server (e.g. in the Municipality or in

a public cloud) and will collect data from all

other applications using messaging. Messaging

with Message Oriented Middleware (MOM)

enables loose communication with many

different styles (e.g. publish-subscribe pattern

etc.) and many different QoS levels.

5. Maintainability: the Layered architectural style

and the MOM-based communication both

provide excellent maintainability.

The third step after selecting the appropriate

architectural patterns is the application these patterns

to partition the system. The result is the conceptual

application architecture framework which is

depicted in Figure 2.

In Figure 2 we display one application hosted in

a host organization and also a second host

organization is depicted but without the details

which are analogous to the first one. In addition we

depict a separate integration server which is

executed in the municipality infrastructure or in any

other reliable organization that can be considered the

main organizer of the smart city project.



IdentifyProminent

ArchitecturalDrivers

Stakeholder

concerns

Architecturally

Significant

Requiremetns

Prominent

Drivers

SelectArchitecture

patternsperdriver

Candidate

Architecture

Patterns

ApplyPatternsto

PartitiontheSystem

System

Partitioning

AccerssImpacton

Drivers

Impacton 

Drivers

PerformTradeoffs

w.r.t.Drivers

MorePatterns

Needed?

Architectural

Documentation(form

architecturaldesign

method)

ArchitectureEvaluation

(formarchitecture

evaluationmethod)

Alternative

OrAdditional

Patterns

Needed?

ICE-B2014-InternationalConferenceone-Business

In the fourth step of the process we will assess if

the proposed partition has the desired impact on the

architectural drivers.

Interoperability is achieved by providing a Web

Services (WSDL) interface at the Business Logic

layer which runs in the application server.

Figure 2: Conceptual Architectural Framework.

Usability is served by providing access to the

application from possibly different channels

including browsers and mobile devices.

Authentication, authorization and confidentiality

(if desired) are all achieved thought the application’s

and web server’s provided mechanisms, while at the

same time various levels of security are supported

with ease.

Availability and recoverability are enhanced by

using the smart city integration host which uses the

messaging pattern to gather data from the different

applications. The integration platform can be used as

a failover platform when an application in a host

server becomes unavailable. Furthermore it can

provide features such as data collection and

archiving, data aggregation, statistical analysis etc.

Maintainability for a single application is

achieved from the layered architectural style which

excels in this aspect. Maintainability is also served

with the use of messaging since it enables the

various applications that exist in the smart city to

evolve gracefully without compromising their clients

as well as the integrated application.

5 RELATED WORK

There are some works in relation to the architecture

of smart cities. In (Da Silva et al., 2013) the authors

refer to the need for a distributed and integrated

architecture and relate this need with numerous

nodes where each one has the obligation to produce

and provide data to a central location. This

architecture leads to the Internet of Things, which is

the necessary infrastructure for “smart” cities. The

authors conclude that a reference architecture that

contains all the functionality aspects of a “smart”

city has not been proposed yet, so they proceed to

analyze existing architectures from the literature for

extracting the minimum necessary requirements that

a “smart” city should satisfy. We provide in this

article a conceptual architecture framework as a first

step towards a more detailed reference architecture.

Our proposed framework however concerns only the

application layer of the smart city and also provides

suggestions for the business aspects.

In (Hernández-Muñoz et al., 2011) the authors

mention that smart cities ‘at a holistic level are

systems of systems’ and that ‘a unified ICT platform

should be built on top of a unified model so that data

and information could be shared among different

applications and services at global urban levels’.

Our approach, in which several applications provide

information to a federated integrated application at

the municipality center, reflects also this multi-

systemic reality. The authors also emphasize the

need for interoperability. Indeed this reflects our

own findings too. In our work, the Ubiquitous

Sensor Network (USN) described in (Hernández-

Muñoz et al., 2011) could be the sensor network

represented in Figure 2. Sensor networks and other

infrastructure are considered to belong in the

physical layer of the proposed architecture

In (Anthopoulos and Fitsilis, 2014) the authors

report, based on the literature, a number of

architectures for smart cities, which follow the

layered architecture. Here, we follow a similar

approach, but we propose that each application is not

only layered but also provides a messaging interface

(e.g. a Publish-Subscribe messaging). So it is

possible to loosely get data that will be

presented/integrated/analyzed etc. in other

applications, increasing in that way the availability,

and providing at the same time improved fault

tolerance and maintainability. Cities that follow the

layered architectural style are reported in (Al-Hader

and Rodzi, 2009), (Anthopoulos and Tsoukalas,

2006), (City Council of Barcelona, 2014) and

elsewhere. In our approach we provide a

Integration Host

(Municipality)

Host Organization of Application 1

BUSINESS LOGIC LAYER API

Local Data Store

UI M VC LAYER

Browser

Host

Organization of

Application 2

MOM Server

SmartPhones,

Tablets etc.

Sensor

Netw ork

registrrations &

notifications

registrrations &

notifications

regi strra ti on s &

notifications

registrrations &

notifications

regi strra ti on s &

notifications

regi strra ti on s &

notifications

WSDL

API or

Similar

DB Connectivity

Protocol

«flow»

syncrhonous API calls

AConceptualEnterpriseArchitectureFrameworkforSmartCities-ASurveyBasedApproach

justification in the form of quality attributes served

using the layered approach rather than concentrating

on specific types of services that may differ from

city to city.

6 CONCLUSIONS AND FUTURE

RESEARCH DIRECTIONS

In this work we presented the results of a survey

related to architectural aspects of smart cities. The

sample and the investigating process can be

considered sufficient for conclusion extraction, due

to geographic distribution and sample’s

homogeneity, accompanied by the expertise of the

participants. A limitation concerns the absence of

Asian experiences, which authors aim to cover in

their future research. However, it is estimated, due to

the variance and size of the involved cases, that

there will be small divergence from the existing

outcomes, but this speculation has to be confirmed.

Using the survey’s results we identified important

quality properties for a smart city architecture.

Additionally, we used the Pattern Driven

Architectural Partitioning (PDAP) method to select

appropriate architectural patterns and provide a

conceptual application architecture framework. This

framework will need to be tested, evaluated and

complemented on each specific city case, but it

provides a good starting point to take into account

when launching such a project.

Concerning the business aspects we suggest the

use of a supporting IT organization and also the use

of Free/Libre Open Source Software to drop the

costs where feasible.

In the future we aim to create partnerships with

real smart cities interested in applying the proposed

framework and use the findings of real projects to

adjust the conceptual application architecture

framework proposed in this work.

ACKNOWLEDGEMENTS

This research has been co-financed by the European

Union (European Social Fund - ESF) and Greek

national funds through the Operational Program

"Education and Lifelong Learning" of the National

Strategic Reference Framework (NSRF) - Research

Funding Program: ARCHIMEDES III. Investing in

knowledge society through the European Social

Fund.

REFERENCES

Al-Hader, M., Rodzi A., 2009. The Smart City

Infrastructure Development & Monitoring, Theoretical

& Empirical Researches in Urban Management, no.

2(11).

Anthopoulos, L., Tsoukalas I. A., 2006. The

implementation model of a Digital City. The case

study of the first Digital City in Greece: e-Trikala.

Journal of e-Government, Vol.2, Issue 2.

Anthopoulos, L., Fitsilis P., 2013. Using Classification

and Roadmapping Techniques for smart city viability's

realization. Electronic Journal of e-Government, 11(1),

pp. 326-336.

Anthopoulos, L., Fitsilis, P., 2014. Exploring Architectural

and Organizational Features in Smart Cities. In proc.

of the 16th International Conference on Advanced

Communications Technology, IEEE.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,

Stal, M., 1996. Pattern-oriented Software Architecture:

A System of Patterns. Wiley.

City Council of Barcelona, January 2014. Barcelona Smart

City (http://www.majorcities.eu/workshops/2012-

helsinki/helsinki2012_barcelona.pdf)

Da Silva, W.M., Alvaro, A., Tomas, G.H.R.P., Afonso,

R.A., Dias, K.L., Garcia, V.C., 2013. Smart cities

software architectures: a survey. In proc. of the 28th

Annual ACM Symposium on Applied Computing,

1722–1722.

European smart cities project, Smart cities Ranking of

European medium-sized cities, October 2007

(http://www.smart-

cities.eu/download/smart_cities_final_report.pdf)

Gamma, E., Helm, R., Johnson, R., Vlissides, J., 1995.

Design Patterns: Elements of Reusable Object-

oriented Software. Addison-Wesley.

Harrison, N., Avgeriou, P., 2007. Pattern-Driven

Architectural Partitioning: Balancing Functional and

Non-functional Requirements. In proc. of the 2nd

International Conference on Digital

Telecommunications, ICDT ’07, IEEE.

Hernández-Muñoz, J.M., Vercher, J.B., Muñoz, L.,

Galache, J.A., Presser, M., Gómez, L.A.H. and

Pettersson, J., 2011. Smart cities at the forefront of the

future internet. (Jan. 2011), 447–462.

Hohpe, G., Woolf, B., 2003. Enterprise integration

patterns: designing, building, and deploying

messaging solutions. Addison-Wesley.

ISO/IEC, 2011. ISO/IEC 25010: Systems and software

engineering - Systems and software Quality

Requirements and Evaluation (SQuaRE) — System

and software quality models

Lankhorst M., 2009. “Enterprise Architecture at Work:

Modelling, Communication and Analysis”, 2

ed.,

Springer-Verlag.

Reenskaug, T., Wold, P., Lehne O.A., 1996. Working with

objects: the OOram software engineering method.

Manning.

ICE-B2014-InternationalConferenceone-Business