It is of enormous importance that our IT-solutions contribute to sustainable development of society. The ZEN (center on Zero Emission Neighbourhoods) have developed a set of Key Performance Indicators that are deemed important to follow up as we build and refurbish the builtenvironment to achieve net-energy-positive areas that produce more electricity than what it uses, including during the building process. The focus on these kinds of initiatives is often technical and represented as informal descriptions and models of IT and data architectures. In this study, we investigate the use of Enterprise Architecture Modeling in ArchiMate to represent both the technical aspects, but in interplay with also the organizational and business aspects of a solution to support the achievement of zero-emission buildings and neighborhoods from the point of view of a diverse set of stakeholders. Going from a purely technical focus to an enterprise focus enables a richer discussion on what needs to be in place to enable the development and evolution of systems to monitor the adherence to the selected Key Performance Indicators. It also illustrates the multi-valency of the underlying data in that it can be used in different ways for different purposes and user-groups. In this work, we use this insight in the development of a set of dashboards presenting data for different types of users for different purposes.
Information and Communication Technology (ICT) plays an important role in assuring both
social, environmental and economic sustainability. This is fundamental to achieving Industry
5.0 and Society 5.0, both of which focusses on balancing economic development while resolving
social and environmental problems [
In the research center on Zero-Emission Neighbourhoods (ZEN), there is a focus on ensuring that our built environment for the future is environmentally sustainable. The center has so far focused on the built environment, being specifically relevant for reaching SDG 11: Sustainable cities and communities, the environmental aspects being a central part for reaching SDG 13: Climate action. To follow up energy-usage of built environments, it uses sensors to gather real time data and to run simulations. Such data could be considered as a possible basis for a digital twin of ZENs, which is a virtual representation of a physical object, using real-time data to understand it better [5]. To enhance the social value of such work to humans in their everyday life, easy access to data and the reuse of data, and not least, visualization of relevant data is important. This requires the management of abundant data, their storage, accessibility and security. However, there has been a limited focus on the role of ICT and the implications of the ICT architecture towards achieving this goal.
Early work has developed high-level data and IT-architecture frameworks that range from IT focus only to ones that incorporate sustainability and citizens (e.g., [6]). In this context, the idea of Enterprise Modeling and Enterprise Architecture (EA) [7, 8] have been introduced as a means of understanding and describing the needs for environmental sustainability and the role of data and the IT applications for meeting the needs. Thus, more recently, in line with Industry 5.0 and Society 5.0, researchers have applied ideas from EA to address strategic alignment of data and IT architecture to address the needs of citizens [9] and governance aspects [10, 11]. Furthermore, the value of Enterprise Modeling in supporting digital transformation and digital twins have been highlighted [5].
In this paper, we describe the interplay between EA models and the data architecture of a building, designed as a Zero-Emission Building, referred to as ZEB. To meet the Key Performance Indicators (KPIs) of ZEB, such as energy efficiency and limiting Greenhouse Gas (GHG) emission, sensors and other technologies are used to gather relevant data, to monitor, analyze, identify trends and patterns and to simulate future scenarios. The quality of this data and accessibility of the data are important for conducting research in and operating ZEBs. Such data is often shared with stakeholders in the form of dashboards that visualize the data. Designing such dashboards for the monitoring of KPIs requires an infrastructure to support easy access and selection of the relevant data sources for any KPI. As such, this study aims to explore the ideas of EA Modeling to understand the interplay between the high-level business needs of a ZEB, or a ZEN, and the data architecture. The main research question that this paper aims to answer is: how can EA modeling be applied to manage the interplay between the IT and data architecture and the business needs in ZEBs and ZENs?
The EA approach helps to describe the data architecture and how it relates and supports the diverse user scenarios of the available data. It also highlights the need for flexibility in the architecture and helps to design appropriate solutions for different business needs. To illustrate these, we have used the Action Research method to analyze a case and examined the data architecture and data management processes in a ZEB.
The rest of this paper is organized as follows: in Section 2, we discuss the method used for this study, before presenting the ZEB case in section 3. The results of using EA models are presented in section 4 and discussed in section 5. Section 6 concludes the paper and identifies the limitations and future work.
The overall research method that was followed was Action Research, which consists of a cycle of planning, action and reflection to improve the planning and activities. Action Research provides a means of systematically inquiring and analysing to stimulate self-reflection, critiquing and improving the practice [12]. The research method could be considered as Action Research for two main reasons: i) the work was aimed to solve an immediate problem which was to understand how the data architecture could meet the high level needs, and ii) the researchers were involved in the work and participated and contributed to solving the problem, which is that of using EA modeling to highlight the interplay between the data architecture and the contextual needs. The action part that was conducted by the researchers was the development of the EA model itself. However, the work was based on the study of a specific case, the ZEB building. As such, the research method also consisted of elements of a case study [13]. Similar to a Case Study, Action Research also involves gathering and analy zing data. However, Action Research includes planning and taking action, based on the data analysis, whereas in a Case Study, it involves only gathering andanalysis of the data. The study examined a specific case, that of the ZEB-lab dashboard and the visualization of data.
The data for the study was initially collected from documents related to the data architecture and through discussions with two people working with the building IT infrastructure. One of them is responsible for the IT and data architecture and the operation of it. The second one is a researcher who accesses data directly from the data architecture for his research. These two researchers were selected due to their in-depth knowledge of the case and their availability. The data gathering discussions were conducted in several rounds. The first three meetings were to obtain a general understanding of how the IT infrastructure and data architecture was implemented and how specific data relevant for a dashboard with overview of building performance was retrieved. The main artefacts for these discussions were the current dashboard and the IT and data architecture. An example of such a dashboard is provided in the next section. Following this, further two meetings were held to understand the different scenarios of use and to identify the specific components of the IT and data architecture that were relevant. In these discussions, one of the authors shared the ideas of EA and sketches of simple EA models were used as illustrations to support the discussions.
The data that was gathered included the overview of the data architecture and helped to identify the different scenarios to describe how the data architecture was used to create the dashboard and meet the needs of the ZEN KPIs and the stakeholders. The data was gathered as notes from the discussions. Diagrams of the IT and data architecture and EA models were used to support the discussions. Furthermore, the different rounds of discussions supported an iterative development of the EA models that also contributed to the validation of the models that were created.
The ZEN Research Center develops solutions for future buildings and neighbourhoods with no GHG emissions and thereby contributes to a low carbon society. Researchers, municipalities, industry and governmental organizations work together in the Center in order to plan, develop and run neighbourhoods with zero GHG emissions. The ZEN Center has nine pilot projects spread over all of Norway that encompass a physical area of more than 1 million m2 and more than 30,000 inhabitants.
In order to achieve its high ambitions, the ZEN Center and its partners focus on the development of neighbourhood design and planning instruments while integrating sciencebased knowledge on GHG emissions, cost effective and resource and energy efficient building through low carbon technologies and construction systems based on lifecycle strategies, decision-support tools for optimizing local energy systems and their interactions on the larger system. This is also supported by the creation and management of neighbourhood scale living labs, or pilots, such as the ZEB, which act as innovation hubs and testing ground for the solution developed at the ZEN Center.
A number of KPIs have been defined for ZEN [14], in areas such as emission reduction and compensation, energy efficiency in buildings, own energy production, power performance, load flexibility, density and land use mix, building layout, street network, green open spaces, mobility, life cycle cost, and cost benefit. Data and data infrastructure are primarily focused on capturing and following up energy and power data, and through this, the ability to calculate the emission data. While some of these have a technical focus for the operators of a ZEN, they also contribute to the well-being of the people that inhabit the area, e.g., achieving thermal comfort and affordable energy.
The ZEB pilot building is a living laboratory of an office building , where people have their normal workplace. The building is highly instrumented and is constantly monitored through the data available through multiple sensors. The ZEB building is described in more detail in https://zeblab.no/.
This study has looked at concrete reporting dashboards for decision support available for the ZEB, to be able to follow up selected KPIs, and the overall IT and data-architecture supporting the provision of such KPI data from a building in operation.An example view of the dashboard is shown in Figure 1.
The data that is displayed as graphs and other graphics visualise relevant data sources for one or more KPIs that is of interest, e.g., energy efficiency which would use the data related to the energy produced by the building (solar and thermal energy) and the energy that is consumed. Contextual data such as the outdoor and indoor temperatures are also displayed. Colours are used to indicate how well the building is performing. Thus, for designing such dashboards for the monitoring of KPIs, an infrastructure to support easy access and selection of the relevant data sources for any KPI, or to meet the interests of specific stakeholders (e.g., building operator or a researcher) is a necessity. As such, this study aims to explore the ideas of EA and modelling to understand the interplay between the high-level business needs of a ZEB, or a ZEN, and the data architecture that supports the data pertaining to it, in this case a data visualization dashboard.
A high-level overview of main data-sources and data flows as it was depicted in the IT architecture connected to the building, is provided in Figure 2. The notation used is ad-hoc, not following any standard notation. The center part of the figure shows the elements of the data architecture that is directly linked to the building, e.g., the BlueGPS unit gathers data about the inhabitants of a space, the room controller that monitors the conditions within a space and the sensors that are installed for data collection. The Influx database stores the data and the Grafana API provides access to the data. Figure 2 shows the IT infrastructure for the data architecture. While this shows the users of the architecture, e.g., the researchers’ technical details, it does not contain the relevant information for the KPIs or the interests of the diverse stakeholders.
Enterprise Modeling has been considered in information management in changing contexts such as the monitoring of dashboards [5, 15]. Ideas from EA and Enterprise Modeling can contribute to a better understanding of the IT and data architecture and how that could be used to meet the needs of the stakeholders. Through workshops with people involved in the management of the building described in section 3, including following up the energy usage and production, we enriched this IT architecture, taking into account the organizational aspects of the overall digital ecosystem around achieving ZEN in smart cities. The ZEB laboratory IT and data architecture can also be described as an EA model, using the +CityxChange EA framework, described in [16]. This EA framework is designed to describe digital and business ecosystems related to smart cities. A central aspect of this is the context in which the ecosystem is developed and the needs of the human users.
The +CityxChange EA framework consists of seven layers, where one layer serves another layer, which is described above it. The seven layers are Context, Service, Business, Applications, Data, Technology and Physical Infrastructure. It enhances and extends the layers identified in TOGAF [17]. The main parts of the EA model are shown in Figure 3 using the ArchiMate modeling language. The upper layers are modeled using the concepts found in the Motivation and Business layers of ArchiMate, while the lower more technical layers are modeled using the concepts found in the information and data and the technology layers of ArchiMate.
A description of the seven layers of the EA model is provided below: • • • • •
The context layer describes the goals, needs or the interests of the stakeholders. For the ZEB laboratory, one of the contexts is the ZEN KPI and guidelines, e.g., a specific context could be the energy KPI for the building operators.
The service layer describes the services to meet the needs described in the context layer; in this case, the energy KPI need could be met by a dashboard that displays information and data related to the energy KPI.
The business layer describes the actors involved in providing the service; in this case they could be researchers, but also industrial partners are included.
The application layer describes how the actors’ needs are met by using some applications; in this case, the researcher queries Grafana through the web interface. Grafana then accesses the Influx database and fetches the relevant data. Influx provides persistent data storage (i.e., long term data storage).
The relevant data is described in the data space layer; in this case, it could be time series data related to energy consumption and production in the ZEB laboratory. The influx DB may be available on both a public and private cloud. • •
The data is collected through the BACnet gateway described in the technology layer, which uses the BACnet API and the SD building management system to access the data from the assets and resources in the ZEB laboratory.
The assets and the resources that provide the data are described in the physical infrastructure layer, which include the photovoltaic (PV) panels and sensors in the ZEB laboratory.
The main aim of the EA model, shown in Figure 3, is to illustrate how the IT architecture described earlier in Figure 2 is relevant for meeting the needs of the stakeholders. Hence, it may be incomplete and lack some details such as specific APIs. The lowest three layers of the EA model, the data space, technology and physical infrastructure layers, describe primarily the IT architecture shown in Figure 2. In particular, the lower layers often describe stationary components, and may remain unchanged, independent of the varying needs of the stakeholders, i.e., a diversity of contexts and services in the upper layers could be supported by the same IT architecture.
It should be noted that the components described in this EA model describe one specific solution for the IT architecture. Several of these components could be replaced by other similar technologies that provide the same functionality. The application layer also represents a part of the IT architecture as it includes several software or hardware applications that often connect the components of the lower layers to the upper layers; in this case the Influx database and Grafana. The EA model illustrates how the components in the IT architecture are related to high level or strategic needs of the various stakeholders. It can further be used to understand the data flow, depending on the needs of the stakeholders.
The data gathered from the ZEB laboratory may be accessed in several ways and serve several purposes to meet the diverse needs of the stakeholders. The model shown in Figure 3 shows a general scenario, where data is accessed to create dashboards, such as the dashboard in the ZEB laboratory building. In the following sub-sections, additional scenarios are described, where different data pipelines may be used, although the IT architecture remains the same.
Users and stakeholders are able to access data directly from the assets and resources in the ZEB laboratory through the SD Building Management System. In this scenario, the user may be the building manager or the building maintenance manager, who is interested in the general status of the building, or specific information, e.g., related to energy efficiency, solar production or indoor climate in the building, such as comfortable indoor temperature. An EA model for this scenario is shown in Figure 4.
The specific components of the model that are relevant for this scenario are shown with a red rectangle and the relevant relationships are shown as bold lines connecting the different components. In this case, the building manager can access the SD Building Management System directly to retrieve data. There may also be applications that support services such as provide notifications to the building manager, e.g., activates an alarm when maintenance is due, or under specified conditions.
Data from Influx and Grafana could be accessed in several ways. The most common way is through the Grafana API as shown in the model in Figure 5. In addition, data could also be accessed using a web-based front end to Grafana and through scripts and this is also shown in Figure 5. An example of such a script -based web interface could be to select the desired time period that is of interest to the user. The web-based front end and scripts enhance the possibilities to retrieve data from Grafana and to customize the data that is retrieved. Similarly, users could also access data directly from Influx, through an API, e.g., developed using Python. This is relevant for researchers, who may require specific data sets for specific research activities, such as to run simulations or to create dashboards for a specific KPI or target group.
The EA model in Figure 5 shows the specific components relevant for accessing data through the web-based front end and scripts. The upper four layers are included in the figure as this is where additional components, e.g., “scripts” in the application layer or a new service such as “research simulation” may appear. The components in the lower layers, i.e., the data architecture, remains the same as for the other scenarios and could support several applications, such as scripts and web-based interfaces for the different needs of the users.
In some situations, a tailored and direct access is needed, e.g., the Campus Service at the university campus where the ZEB laboratory is situated, which gathers data from several buildings and visualizes energy consumption of all or several buildings within the campus. In such situations, the user is interested in accessing raw data from several buildings such as the ZEB laboratory and other buildings on the campus. In this case, the Campus Service has its own gateway which accesses the BACnet gateway of the ZEB laboratory IT architecture (in the technology layer) as well as the BACnet gateway of several other buildings, as shown inFigure 6. The Campus Service then processes the data using their own applications.
The model shown in Figure 6 shows a part of the EA of the ZEB laboratory, which is relevant for this situation. It is likely that other buildings on the campus that the Campus Service accesses data from may have similar components in their lower layers of the architecture, such as the BACnet gateway.
The Campus Service itself could also be represented using the seven layers of the architecture. What is perhaps of interest here are the upper layers of the Campus Service. The application layer is likely to include applications to process the raw data from the different buildings, such as aggregate data and to visualize the data and APIs. The business layer may include the different actors that are relevant from the different buildings or the data providers and technology providers. The services could include dashboards to visualize energy consumption.
This scenario is particularly interesting from a ZEN perspective as it looks at the data architecture within a neighbourhood and how data from several buildings is accessed, gathered, shared and processed for creating services.
There are several systems that gather and write data to the Influx database as shown in Figure 7, which shows the lower layers of the ZEB laboratoryIT architecture. For example, robots with sensors can be used to gather data about the indoor climate, or the availability of sunlight in the different positions in the building, or to check if windows are open or closed.
Elhub, which is the Norwegian power industry's common data hub, where all data from electricity meters across the country is collected in a common system (elhub.no), for instance, might in other cases have relevant energy data (e.g., from other comparable buildings). Such systems use the MQTT or Restful protocols to transfer data to the BACforsk system, or the BACforsk system picks up the data using MQTT from various devices and systems. The BACforsk system then writes the data to Influx. This is shown in Figure 7, which shows the lower layers of the ZEB laboratory IT architecture. The relevant components are shown with a red rectangle and bold connection lines. BACforsk also communicates directly with the room controller, e.g., in situations when some adjustments need to be made, such as adjusting the ventilation in a room or a specific area. BACforsk is also able to access the building data set and make changes in it, such as adjust the “set point”, based on the updated data values gathered through the external systems.
The focus of current research on data management in smart cities and building is mostly focussed on the IT architecture and technical aspects. Returning to the main research question ‘how can EA modeling be applied to manage the interplay between the IT and data architecture and the business needs in ZEBs and ZENs?’, we have seen how we have enhancetdhe discussion of IT and data architecture in ZEN by including all levels in an EA , adopting the EA approach from the + CityxChange project [16], and in this way, been able to investigate the congruence between business and IT.
The IT and data architecture described in this paper does not go deep into the types of data gathered and how the storage could be implemented as our focus has been on the data pertaining to a single building, although also on this level, we have more comprehensive and precise models than the ones found in the ad-hoc diagrams existing originally from the project. However, it is evident that there could be layers in the data itself, e.g., such as contextual data (e.g., weather data), data from different buildings or related to particular KPIs. Data is captured, processed and made available at different levels, rather than all collected in a cloud to be made generally available for all, which is the general approach e.g., in EU data spaces and the smart building hub project.† The case is driven by the need for access to data on the current state, and to some design targets, but not a combination of current and simulated data, which could be relevant for a building manager.
We see in the ArchiMate EA models presented in the figures how one can combine the technical and business levels. One can also more clearly define boundaries of who owns / is responsible for the various parts of the architecture using e.g., ArchiMate for depicting the whole EA, including the IT architecture as a part of it.
One area that we have not looked into in detail in this study is aspects related to the security infrastructure. Data as collected presently needed for following up the KPIs do not have privacy issues. Privacy issues can be linked to data for following up, e.g., workplace quality. An example of this is shown in Figure 3, where the BlueGPS component in the Application layer, via Bluetooth and a camera, may gather data that could be personal data. Thus, introduction of a distinction between a private and a public cloud is warranted. It was also noted that the current solution does not support the management of meta-data, and there are plans to adopt a standardized meta-data schema.
Finally, the ArchiMate modeling language provided the main concepts for creating the EA models and the flexibility in the language and the Archi modeling tool allowed structuring the model as seven layers rather than the four layers of ArchiMate. Given the richness of the data in smart city and smart buildings contexts, the concepts in Archi Mate could be enriched to represent such diversity. However, based on the feedback from the interviewees and project participants, we were able to create models that described the IT and data architecture, the contexts and other relevant details for the main stakeholders involved in the creation of the dashboards.
In this study, we have investigated the use of EA modeling in ArchiMate to describe both the technical aspects and the interplay with the organizational and business aspects of a solution to support the achievement of ZEBs and ZENs. Going from a purely technical focus to an enterprise focus enables a richer discussion on what needs to be in place also on the technical side to enable the development and evolution of systems to monitor the adherence to the necessary KPIs for ZENs, supporting a sustainable transition of the built environment. It also makes the multi-valency of the underlying data clearer in that it can be used in different ways for different purposes and user-groups. In our current work, we are using this insight in the development of a set of new dashboards presenting data for different types of users for different purposes.
This work has contributed to a common understanding among researchers from different disciplines and interests connected to the ZEN center. It has also helped to identify the parts of the IT infrastructure that remains stable, while meeting the needs of users and stakeholders, † https://www.sintef.no/prosjekter/2023/smart-building-hub/ such as the researchers, the building management and campus monitoring services. This can contribute to the identification of value-added services, such as the web-based portal and scripts to access data and the building’s interaction with external systems such as data gathering devices. It has also highlighted additional needs related to the other, non-IT related, research activities in the ZEN center such as the work on the ZEN KPIs. Some of these are that we need additional feedback from those responsible for the different KPI-areas: e.g., How is it best to represent the different KPIs in a dashboard? How could we capture missing KPI-areas e.g., on workplace quality. For those needing a more holistic view, e.g., from the different entrepreneurs and technology providers, how should one investigate and illustrate the interactions between KPIs? How do we integrate illustrating baselines/reference data, design targets, historical data, and simulated future data, pursuing a digital twin approach? Similarly, researchers focused on different areas might want to have tailored views on the overall dataset.
One of the limitations of this study is that the focus has been on an individual building as a part of a ZEN. Given that context, not all ZEN KPIs are relevant. Thus, the next step is to investigate this on an area level. Missing areas in the ZEN KPIs are also identified, e.g. on the quality of the working environment such as air quality that one should have ways of following up. FME-ZEN is also a national project . Thus, additional aspects might be relevant in other countries, e.g., which have a different energy-mix for heating and cooling of buildings. Nevertheless, starting small has given a good testbed providing relevant results both for the IT and data Architecture and for the development of the KPIs themselves. Another limitation of this work is that we have based our study on the data sources available through the building management system, the sensor data gathered from the building and by interviewing people managing the IT infrastructure. Our future work will include discussions with users of the data, such as the ones identified in some of the scenarios presented in this paper and researchers that work with the development of ZEN KPIs. Furthermore, work is in progress on representing emission and other data for a building manager, dwellers and general citizens, through dashboards and other visualization technologies.
This work has been done within the FME-ZEN Research Center on Zero Emission Neighborhoods, financed by the Norwegian Research Council, project number 257660. The authors would like to thank the colleagues in the project and the researchers Kristian Skeie and Odne Oksavik, from SINTEF Community, for their willingness to share the data and the discussions around the EA models. [5] Sandkuhl, K. and J. Stirna, Supporting Early Phases of Digital Twin Development with Enterprise Modeling and Capability Management: Requirements from Two Industrial Cases, in EMMSAD, S. Nurcan, et al., Editors. 2020, Springer International Publishing. p. 284–299. [6] Silva, B.N., M. Khan, and K. Han, Towards Sustainable Smart Cities: A review of trends, architectures, components and open challenges in smart cities. Sustainable Cities and Societies, 2018. 38: p. 697–713. [7] The Open Group. The Open Group Architecture Framework TOGAF Version 9.1. 2011; Available from: https://www.opengroup.org/public/member/proceedings/q312/togaf_intro_weisman.pdf [8] Zachman, J.A., A framework for information systems architecture. IBM systems journal, 1987. 26(3): p. 276–292. [9] Petersen, S.A., et al., Value-Added Services, Virtual Enterprises and Data Spaces inspired Enterprise Architecture for Smart Cities, in Collaborative Networks and Digital Transformation – 20th IFIP WG 5.5 Working Conference on Virtual Enterprises, PRO-VE 2019. 2019, Springer: Turin, Italy. [10] Bastidas, V., I. Reychav, and M. Helfert, Design Principles for Strategic Alignment in Smart City Enterprise Architecture (SCEA), in CENTERIS – International Conference on ENTERprise Information Systems. 2023, Elsevier. [11] Pourzolfaghar, Z., V. Bastidas, and M. Helfert, Standardisation of Enterprise Architecture
Development for Smart Cities. Journal of Knowledge Economy 2019. [12] McCutcheon, G. and B. Jung, Alternative Perspectives on Action Research. Theory Into
Practice, 1990. 29(3): p. 144–151. [13] Yin, R.K., Case Study Research: Design and Methods. Applied Social Research Methods.
Vol. 5. 2014: SAGE Publications. [14] Wiik, M.K., et al., The ZEN Definition – A guideline for the ZEN Pilot Areas, in ZEN Report 44. 2022, SINTEF Community, Norwegian University of Science and Technology. [15] Sandkuhl, K. and J. Stirna, eds. Capability Management in Digital Enterprises. 2018,
Springer Cham. XII, 396. [16] Petersen, S.A., et al., +CityxChange – D1.2 Report on the Architecture for the ICT
Ecosystem. 2021. [17] Group, T.O. The TOGAF® Standard, Version 9.2 Overview. 2019 [cited 2019 9 March]; Available from: https://www.opengroup.org/togaf