Keywords

1 Introduction

The adoption of internet of things (IoT) technologies, is one of the so called IT mega trends that are assumed to have impact on diverse industries [7]. For 2020, Gartner expects a total number of 25 billion installed IoT units [6]. Today, a broad range of sensors, actuators, smart labels and other systems is available. While the manufacturing industry, for example, considers these technologies as one of the major drivers for change today [3], other industries are still undertaking innovation projects to identify use cases that are relevant for their business.

In the logistics industry, companies began early with testing and adopting smart technologies, e.g. for monitoring the cold chain [1]. In other fields, like container logistics, smart technologies are still not used at large scale because of missing standardization [15]. Nevertheless, some actors in the logistics industry continue with testing and piloting IoT systems.

At the harbor of Hamburg, the port authority (HPA – Hamburg Port Authority) started to test and evaluate IoT systems as a part of its “smartPORT” initiative [10]. This initiative comprises projects that strive for implementing smart technologies like sensors into roads, bridges and railway points. These IoT systems generate data, which can be aggregated and used for improving traffic management or for predicting the failure of important physical components (predictive maintenance).

As the new IoT systems and the related processes are getting part of the enterprise architecture (EA), the HPA’s EA model has to be modified and the meta-model needs to be analyzed whether it is still appropriate. Though a technical oriented reference architecture for IoT architectures has been published, the impact of IoT systems on EA models, EA meta-models and EA management is a rather new topic that is only briefly covered in the literature so far.

Hence, the research question for this paper is: How can the IoT-related changes of HPA’s enterprise architecture be adequately captured in its EA model and EA meta-model? In order to address this research question, we followed an action design research based approach in cooperation with the HPA.

The remaining paper is structured as follows: In Sect. 2, we briefly summarize the related research regarding EA and IoT. Section 3 provides an overview of the smartPORT initiative. Section 4 describes the methodological approach we employed. In Sect. 5, we present the results including the meta-model. The paper closes with a conclusion and an outlook in Sect. 6.

2 Related Literature: EA and IoT

During the last 30 years, the modelling of enterprise architecture shifted from a niche topic to a well-researched field [14, 18]. Today, many companies use models and tools that are based on enterprise architecture approaches for improving the alignment between business and IT. For managing the enterprise architecture, appropriate models need to be build, kept up-to-date and should be taken as a basis for decision making regarding issues that affect the relation between business and IT. As change in organizations today is also driven by the impact of IT innovations, EA approaches and models have to adopt to new challenges like cloud computing, mobile computing, social networks or the increasing interconnectedness with external partners and customers [5]. Hence, the EA models and meta-models need to be modified accordingly. Meta-models play an important role, as they ensure “semantic rigor, interoperability and traceability” [16]. While existing meta-models in the literature as well as those defined by frameworks like TOGAF [19] provide a high level of abstraction, new technologies still might impose the need for adapting them [16].

As one of the IT megatrends, IoT technologies are expected to be one of the forces that will lead to changes of IT infrastructures, processes and business models. By using a large number of small sensors and computers, the physical world and the “information world” are getting directly interlinked. Companies from diverse industries are seeking to implement IoT devices [8]. Often, they start with identifying use cases for IoT systems that match the company’s needs. Though the implementation of a large number of new devices and the changing processes are expected to impose severe changes to the enterprise architecture, research on the relation between EA and IoT is scarce so far.

From the EA research perspective, Zimmermann et al. recently published a paper on “digital enterprise architecture” that seeks to identify relevant IoT architectural objects [20]. The paper only provides vague suggestions for how IoT objects might be considered in an EA meta-model. The second related field, IoT research, covers a broad range of applications in diverse industries like smart retail, smart transportation and smart city [8]. The most relevant source from the IoT field to the topic of this paper is the final publication of the IoT architecture project “enabling things to talk” [2]. In this book, the authors present a detailed model for IoT architectures (ARM – architectural reference model) as well as related processes. A basic part of the ARM is the domain model, which captures “the main concepts and the relationships that are relevant for IoT stakeholders” [2, p. 118]. The authors propose an “augmented entity” that combines a physical with a virtual component. From an EA perspective, the ARM mainly focusses on technical artifacts and their properties. Relations between the business and the IT perspective are only covered very briefly in the ARM.

3 Context: The Hamburg smartPORT Initiative

In 2012, the Hamburg Port Authority (HPA) launched the smartPORT initiative. This initiative consists of two sub-initiatives: smartPORT Logistics (SPL) and smartPORT Energy (SPE) [9–12]. While the SPE projects aim at reaching sustainability goals, the SPL projects strive for optimizing the logistic processes in the harbor mainly by adopting smart technologies. The SPL projects are carried out together with several partners from industry. Most of the projects had an innovative and pilot character. The results of these projects were presented at the IAPH 2015 (29th World Ports Conference) in Hamburg [13]. The SPL projects strive for increasing “the efficiency of the port as an important link in the supply chain” [10]. As the space in the harbor of Hamburg is limited, the HPA needs to manage the existing infrastructure in an efficient manner. The goals are to establish an “intelligent infrastructure” and to optimize “the flow of information to manage trade flows efficiently” [10]. In several sub-projects, the SPL projects explore the use of smart technologies for better managing the traffic on the roads (smart road, port road management system, depiction of the traffic situation, parking space management), rail and water as well as for predictive maintenance scenarios (intelligent railway point, smart maintenance for bridges) [10].

Our research project at the HPA started, after the results of the exploratory IoT projects were presented at the IAPH. In this phase, the HPA had to evaluate and further integrate the projects. They also had to decide, which projects will be transformed to a productive mode and which partners and vendors will be chosen for this mode. Furthermore, information about the projects had to be spread within the organization. We assume that such a situation is typical for innovative and exploratory IoT projects. During the exploratory phase, the focus lies on demonstrating the feasibility of adopting a certain IoT system. A complete alignment with the existing EA might be skipped due to limited budgets and unknown outcome. Proceeding in such a way is well known in IS research and captured by the term “bricolage” [4].

In this paper, we look at this consolidation phase mainly from an enterprise architecture viewpoint as it can contribute by: (1) analyzing the projects’ results in a uniform way, (2) identifying relationships among different projects, (3) providing tools for performing these tasks, (4) developing models and visualizations for supporting decisions, (5) defining and ensuring compliance with architectural guidelines, (6) determining a to-be architecture for roll-out and transfer to operations.

4 Methodological Approach: Action Design Research

This research project was carried out as an action design research (ADR) project according to Sein et al. [17]. It started with the problem of the HPA to integrate the results of the IoT projects in its existing enterprise architecture model and tool during the consolidation phase (principle 1: practice-inspired research). We categorized this as an IT-dominant BIE (building, intervention and evaluation) type of ADR project. However, during the project we learned that the HPA wants to use the EA model and visualizations based on this model for communicative purposes with the organization as a part of the digital transformation process. This would lead to a second, organization-dominant BIE task, which will become more relevant in the future.

Our research team consisted of two senior researchers and several graduate students. The research team was interested in exploring whether EA meta-models – as a fundamental type of artifacts for EA research – need to be changed and adopted if companies integrate IoT systems into their EA (principle 2: theory-ingrained artifact).

A first analysis of the existing literature and discussions with the EA tool vendor lead to the conclusion that – regarding both problem formulations – scarce information is available in publications as well as in practice. These findings encouraged us to start a cooperative project for developing the required EA model and meta-model. During the ADR project, mixed teams (researchers and practitioners) conducted 17 informal interviews (with project managers, internal and external experts and other stakeholders within the HPA), analyzed documents about the projects and the existing EA as well as the EA tool and the EA model. For discussing the intermediate results and for planning next steps, regular workshops were established as well as less frequent review meetings. During these meetings, researchers and practitioners evaluated the applicability, coherence and correctness of the related artifacts (models and meta-model) (principle 4: mutually influential roles).

In several iterations, the EA models for each IoT project were evaluated and refined and the EA meta-model was co-developed and evaluated (principle 3: iterative reciprocal shaping and principle 5: authentic and concurrent evaluation). Based on the insights from the interviews and the document analysis, the project team decided, which information about the IoT projects should be captured, held and managed in the EA model. The team’s decisions were also driven by the goal of using concepts for the EA model that are easy to understand and to communicate while also being comprehensive and precise. The intermediate results were regularly evaluated in the above mentioned meetings. They were also discussed at a practice-oriented conference to gain further general feedback from practitioners from different domains.

During the cooperation so far, some decisions were made that may be understood as design principles. For example, sensor types were modelled instead of sensors, the concept of smart bricks guides the understanding of sensors attached to infrastructural elements, the distinction of raw data, information streams and information services makes transparent how sensor data get transformed and enriched to useful business-oriented information. Furthermore, design principles for a generalized (cross-project) to-be architecture were developed (principle 6: guided emergence). Since the cooperation will be extended, the evolving of design principles and their ongoing shaping by organizational use and different stakeholder perspectives is ensured. Due to the cross-project comparison, we also achieved a first step of generalization from the individual projects. Additionally, we also take first steps for generalizing from the HPA case at the end of this paper (principle 7: generalized outcomes).

Out of the four ADR stages, we passed through an extended and reflected problem formulation (stage 1), an ongoing intertwined BIE (stage 2) and reflection and learning (stage 3) and started with the formalization of learning (stage 4).

5 Results: Capturing IoT in Extended EA Meta-Models

In this section, we present the results we developed in this project regarding the extension of the EA meta-model. We start by reasoning our suggestions of how to model sensors and physical objects as “smart bricks” in Sect. 5.1. In the following sections, we describe changes regarding data streams and cloud systems (5.2) and summarize the suggested changes in a combined meta-model (5.3). This is followed by a recommendation for the to-be architecture (5.4).

5.1 Smart Bricks: Introduction, Level of Abstraction and Database

In the smartPORT projects, hundreds of sensors were installed on several real infrastructure elements at the harbor. Like in other IoT initiatives, the number of sensors is likely to increase dramatically in the future, if the explorative projects will be transferred into a productive mode. Hence, the first question is, whether the EA as a strategic tool is the appropriate place for administrating each instance of the operative sensors. For maintenance reasons and evaluation tasks within the IoT systems, each installed and activated sensor needs to be known, described and its description needs to be kept up-to-date. A company seeking to use IoT systems has to decide, which tool is appropriate for storing and managing this information. In our case, we learned that a geographic information system (GIS) is used to briefly document and visualize these sensor instances. During our analysis, we considered this as a similar situation compared to the use of a configuration management database (CMDB) that stores detailed information on IT infrastructure components. Hence, we decided to keep a similar separation of concerns and to only model sensor types and not instances within the EA model.

Since sensors are only one part of smart infrastructure elements, we introduced a combined element, the smart brick. A smart brick consists of a brick and a sensor. A brick describes a physical element of the harbor’s infrastructure (such as streets, bridges, quay walls, berths, etc.). As the past and current main task of the HPA is to maintain the harbor’s infrastructure, we chose the word brick as it fits to the organization’s identity. As each brick is usually constituted out of a hierarchy of (sub-)bricks, a brick is made smart by adding at least one sensor to it or to one of its sub-bricks. In this way, the concept can be used to classify the “smartness” of a smart brick or states of its IoT enrichment.

We illustrate the concept of a smart brick by drawing upon the example of a smart bridge (see Fig. 1). The bridge is enhanced with sensors for predictive maintenance purposes. As illustrated, a typical bridge might be composed of track beams and steel beams. Track beams will become vibration-sensitive by attaching vibration sensors, steel beams strain-sensitive by strain gauges or tilt-sensitive by tilt gauges. Hence, some smart bridges might be only vibration sensitive whereas others are tilt sensitive, strain sensitive or it may be monitored by a combination of different sensor types.

Fig. 1.
figure 1

Smart bridge as an example for a smart brick

Full size image

The corresponding EA meta-model for smart brick types expresses their hierarchical (tree) structure by a recursive relationship (See Fig. 2). It is a “simple” concept in which the smart brick types mainly follow the tree structure of their corresponding brick types. Each smart brick type is related to exactly one brick type (at the appropriate tree level). However, there might be more smart brick types based on one brick type due to different related sensor types, see e.g. the strain-sensitive steel beam type and the tilt-sensitive steel beam type above – both are based on a steel beam brick type. Hence, we have a 1:n instead of a 1:1 relationship between brick and smart brick types. Further integrity constraints exist for this meta-model: The set of sensor types on each smart brick node is the same as the sensor types of all smart brick nodes of the related subtree.

Fig. 2.
figure 2

EA meta-model extension for smart brick types

Full size image

The meta-model allows to derive models with detailed or less detailed granularity. For a detailed model, we would propose to model sensor types on leaf smart brick nodes only and to allow exactly one related sensor type. The sensor types on the non-leaf nodes would be calculated in this case. Alternatively, the sensor types on the root node can be completely omitted like in the above fatigue smart bridge type example.

Attributes on sensor types comprise information about sensor ID types. They further allow distinguishing sensor types regarding their vendors and versions. As this distinction is important for maintenance and strategic decisions, we differentiate sensor type instantiations in a concrete architecture from those stemming from different sensor type vendors and versions. Attributes on brick types will indicate their purpose, location, material and status of maintenance.

In correspondence to the decisions described above, we propose the implementation of a “smart brick management database” (SBMDB) for documenting smart brick instances. The instances will be classified by the smart brick types, which form the link between the two documentation repositories (EA tool and SBMDB). Apart from maintenance purposes, the SBMDB can play a major role in the resolution of identifiers in information streams needed within the cloud system layer (see below). In the future, sensor integration might follow automated subscription patterns and models [20]. But in our case, the diversity of sensors, intermediate systems and vendors will inhibit such an approach for the upcoming years.

The extended EA meta-model with smart brick types can be integrated with a corresponding SBMDB for answering concerns that were mentioned by stakeholders in the interviews such as: Which are fatigue-sensitive bridges that are not yet vibration sensitive? Which sensor types can be attached to steel under water? Where are instances of smart brick types located? Which sensor types are provided by vendor A and in which smart bricks of which type are they installed?

We challenged our modelling approach by applying it to other smartPORT projects. In a predictive maintenance project related to marker posts in road construction areas, the smart bricks (marker posts) can be moved. The changing location can be captured with our meta-model by an attribute. This movement would be handled by the SBMDB. Furthermore, we ensured that the concept of smart bricks can also easily be adopted for capturing actuators in the future. Within a project aimed at reducing power consumption by implementing a usage-dependent light control, a key aspect to be modelled were dimmable lights. These actuators were modelled analogous to smart bricks by replacing the sensor part with an actuator. This extension captures the required details and thus fits in well with the existing model.

5.2 Data Streams, Cloud Systems and Service Applications

The diverse smart bricks are the source of various continuous data streams, which are typical for IoT architectures and applications. Data is being processed and transformed in different types of systems for which we introduce different layers. We distinguish fog systems, cloud systems and service application systems. Fog systems (such as section controllers for induction loop sensors) aggregate and transform raw data. Similar to sensors, these systems are only modeled by types due to the high number of instances. IoT systems today often come with accompanying cloud systems for integrating, analyzing and managing the sensor instances and the data they provide. The data streams are consumed by service applications like logistics systems, consumer related apps or monitoring services. Accordingly, we distinguish different types of data streams between these layers. Raw data streams flow between smart bricks and fog systems, information streams between fog and cloud systems and information services from cloud systems to service application systems.

This is exemplified by the project EVE (a German acronym for “effective depiction of the traffic situation in the Port of Hamburg”), which provides traffic status and forecast information. This information is used to provide several information services like internal monitoring services, public monitoring services and navigation and logistics services. The project extends (and partially replaces) an existing system that estimates the current traffic situation (traffic analysis system) in four ways: (1) the new system utilizes further types of sensors (Bluetooth, video cameras, floating car data (FCD) from an automobile association), (2) it provides a sophisticated traffic simulation component for better forecasts, (3) it uses data storage in the cloud (unlike typical application systems at the HPA), and (4) it receives from and provides data for a public cloud, the mobile data marketplace (MDM).

The smart bricks in this project are smart roads, which are further subdivided into different road segments. Each sensor type requires different ways of defining road segments. Some of the smart bricks need fog systems whereas others do not require fog systems and deliver their information streams directly to the cloud systems.

Apart from common attributes for applications such as vendor, version and operator, the new data processing systems need additional attributes as they are operating in the cloud. These attributes include the cloud type (public, hybrid or private), data-related attributes (such as location of data repositories, data storage format, time and volume, scalability, archiving regulations) as well as infrastructure and management-related attributes (like administrative responsibilities and location, e.g. for data privacy regulations).

In the content component of the different data streams, the semantic enrichment of the stepwise processed information becomes apparent. E.g. in case of the induction loops (1) the raw data describes inductivity in Henry, (2) the information stream exhibits speed by vehicle class and the time vehicles were above the induction loop, whereas (3) the information service provides travel density and travel time per segment. This data can be used by a service application system for delivering individually estimated arrival times.

Further support for optimizing the traffic flow combines services of the EVE project with those of other projects, e.g. from smart parking. Here, we want to point out that the proposed way of modeling smart bricks also fits to the scenario where different information streams are generated out of the same raw data. In these two projects, we have a dissimilar use of induction loops. While induction loops always measure inductivity, the measured data is interpreted differently depending on its later usage. For traffic situation estimation, the attached fog systems aggregate data such as vehicle speed and the number of passing cars. On smart parking lots, the data is aggregated to “vehicle footprints”, uniquely identifying each truck on the parking lot. These fog systems and the attached information streams can be easily distinguished by attaching either a road segment brick type or a parking lot brick type. Thus, the smart brick logic provides intuitive means of differentiating the way that one type of sensor is used on a use case level (Fig. 3).

Fig. 3.
figure 3

EA model slice for the EVE project

Full size image

5.3 An Extended Meta-Model for the IoT-Related EA at the HPA

We summarize the required extensions in a combined meta-model. This model comprises the IoT specific layers with smart bricks and fog systems (each on a type level) and their relations to layers of cloud systems and service applications (each on an instance level). The meta-model classifies the related interfaces between elements of each layer in raw data, information streams and information services. Figure 4 also briefly indicates an EA tool based on the meta-model together with a link to the SBMDB. This combination of tools contributes to a future concern-directed IoT information platform, which can be used to answer concerns based on an integration of instance-level smart brick data and sensor data (SBMD – smart brick management data) from the SBMDB and the architectural relations from the EA model based on the extended meta-model (see Sect. 5.1). The models of both systems are connected by sharing the same smart brick and sensor types.

Fig. 4.
figure 4

Extended meta-model for the IoT-related EA at the HPA

Full size image

5.4 Towards a to-be Architecture for the IoT-Related EA at the HPA

After documenting and analyzing impact of the smartPORT projects on the EA, we recognized that each IoT data processing system typically consists of three vendor-specific components: a data acquisition and conversion component, a data fusion and calculation component and an information provisioning component. The data acquisition and conversion component resolves identifiers of sensors stemming from the information streams in order to relate them to smart bricks. In the EVE project, identifiers are substituted by road segments (logical location) and geographical references (physical location). In the two parallel traffic analysis systems, this is done separately based on different segment types and different repositories relating the sensor instances and the respective segment instances. As a consequence, each change in the sensor farm requires changes in both sensor lists.

For the to-be architecture as shown in Fig. 5, we suggest a vendor-independent component. This component provides acquisition (Acqu), filtering (Filt) and conversion (Conv) functionality and a unique smart brick identity resolution management component. The latter is exactly the SBMDB we introduced in Sect. 5.1. In Fig. 5, we use icons combining letters for sensor types (F for FCD, V for Video, B for Bluetooth and I for Induction loops) for indicating their smart brick type (here: two lines for road segments). The outlined to-be architecture should be considered for defining future contracts with vendors for developing the productive cloud systems. This again underlines the role of EAM in the interrelated consolidation tasks mentioned in Sect. 3.

Fig. 5.
figure 5

As-is and to-be architecture for the IoT-related EA: suggested change on the cloud layer

Full size image

6 Conclusion and Outlook

Based on the insights gained from a real case, we modeled concrete architectures for different explorative IoT-based projects. During this process, we investigated possible IoT-related extensions for the EA meta-model. The extensions mainly consist of new layers that are used for modelling smart brick types and fog system types and a cloud system and a service application layer. Furthermore, we emphasize the information streams that connect the different layers and distinguish raw data, information streams and information services.

For the HPA, the unified models for several explorative IoT-based projects contributed to the ongoing consolidation phase. The project-focused models form a valuable basis for better understanding interrelationships among the projects and for improving strategic decision making for the future development and roll-out of IoT. The developed meta-model introduces standardized naming conventions and concepts that are understandable for several stakeholders within and beyond the organization (including e.g. system vendors). From a research perspective, we developed an IoT extension for EA meta-models that is so far rooted in a cross-case analysis of several different IoT applications in one organization. Determining whether the suggested extensions are applicable for other port authorities or in related domains like smart city initiatives has not been subject of our study and requires further research. Yet, during our research process, we identified several basic issues that we consider relevant for other IoT related EA endeavors: (1) the level of abstraction (instances/types), (2) business-oriented conceptualizations of IoT system and (3) the introduction of a SBMDB together with a concern oriented analysis platform.

Ongoing research is focusing on IoT-based application services, business models and inter-organizational processes (ecosystem architecture). Additionally, the meta-model extensions might be integrated into EA frameworks like TOGAF. Security, safety and privacy issues should to be covered appropriately and visualizations of IoT-specific EA information and analysis patterns should be developed.