Supporting Cross-Organizational Assimilation of IoT InnovationExemplified by the ChainPORT Initiative

Joran TesseUniversity of Hamburg

tesse@informatik.uni-hamburg.de

Ingrid SchirmerUniversity of Hamburg

schirmer@informatik.uni-hamburg.de

Sebastian SaxeHamburg Port Authority

sebastian.saxe@hpa.hamburg.de

Ulrich BaldaufHamburg Port Authority

ulrich.baldauf@hpa.hamburg.de

Abstract

The chainPORT community of port authorities (PAs)around the world gave their commitment to collaborate.Many PAs developed Internet of Things (IoT) basedsolutions to increase their operational efficiency. Withinits IT solutions workgroup, the challenge of supportingthe diffusion and assimilation of these IoT innovationswas adressed by creating a centralized communicationplatform for IoT solutions to allow inter-organizationalknowledge exchange. We draw upon the knowledgegained by analyzing 24 solutions from 8 port authoritiesand present concepts on how the specific challenges inthis setting were adressed and what principles guidedthe creation of the emerging IT artifact.

1. Introduction

Organizational competitiveness has been widelyaccepted to be strongly influenced by an organization’sability to innovate [1]. While innovativeness canbe achieved through invention, another importantsource of innovation is the assimilation of existinginnovations to an organization’s specific situation.Innovations can be seen to follow general trends,like the Internet of Things (IoT) which is anticipatedand observed to impact many different industries [2].Within this stream of innovations, a multitude ofchallenges arises, both from a technological perspective,as the increasing numbers of interconnected devicescomes with increased technological complexity andheterogeneity, and from a business perspective, wherethe link to the physical world impacts especially thestrategic level [3].

The logistics industry started adopting smarttechnologies relatively early [4] and, especially in themaritime logistics industry, continuous efforts have beenundertaken to increase efficiency through innovation [5].

Nonetheless, digitization is still at an early stage, assome areas were observed to be widely untouched bysmart technology not too long ago [6].

At the port of Hamburg, digitization played animportant role in recent years, due to the need toincrease efficiency. The port of Hamburg is locatedat the center of the city of Hamburg and has verylimited potential of spatial growth. Therefore, theincreasing amounts of freight [7] have to be handledby utilizing the available area more efficiently. Toincrease efficiency through digitization, the HamburgPort Authority presented their smartPORT-initiative’sresults when hosting the 2015 IAPH international portconference. After a consolidation phase of their smarttechnology projects [8], they can currently be seenas a driving force in the relatively young chainPORTinitiative, a global community of port authorities (PAs)committed to collaborate.

The field of innovation diffusion research isconcerned with the process of an innovation spreadingthrough a social system, spanning from knowledgeof an innovation to, potentially, its adoption andimplementation [9]. This field of research as well asthe research field of enterprise architecture managementhave been identified to be able to support the diffusionof Internet of Things innovations throughout thechainPORT community [10], although only a vaguedefinition from a broader diffusion perspective has beenstated.

In contrast to the diffusion of innovations, theinnovation assimilation process focuses on how aninnovation is adopted by an organization and how itis adjusted to accommodate the organization’s specificcontext. The question to be answered here is how theinter-organizational assimilation of Internet of Thingsinnovation can be supported.

Proceedings of the 52nd Hawaii International Conference on System Sciences | 2019

URI: https://hdl.handle.net/10125/59478ISBN: 978-0-9981331-2-6(CC BY-NC-ND 4.0)

Page 380

2. Context

The presented research was conducted at the portof Hamburg in close cooperation with the local portauthority. Organizationally, the research was situatedwithin the solutions workgroup of the chainPORTinitiative. Previous research projects with the HamburgPort Authority have created a solid basis of trust andtransparency between the university of Hamburg and thepractitioner, which led to the opportunity to be includedin the solutions workgroup’s tasks.

Port authorities are commonly responsiblefor developing, providing and maintaining trafficinfrastructure for road traffic, waterways and railways.Especially their role as a coordinator across differenttypes of traffic infrastructure can be highly complex,for example when coordinating the arrival of largecontainer ships with tidal flows, movable bridges, truckscoming to pick up the containers, and the few parkinglots inside and in front of the port area.

2.1. Hamburg Port Authority

Hamburg’s local port authority faces the challengeof having to handle increasing amounts of freight on anarea that can not be expanded, as the port is surroundedby the city of Hamburg. Previously, the HPA tackledthis problem with their smartPORT initiative, aimedto increase organizational efficiency. Several of theseprojects were showcased at the 2015 IAPH internationalport conference that was hosted by Hamburg. After aconsolidation phase, accompanied by research projectswith the University of Hamburg, the chainPORTinitiative was formed with the HPA as a foundingmember. The goal of this new initiative was lessan internal perspective focussing on self-optimization,but rather a global perspective perspective to increaseefficiency in the business ecosystem as a whole.

2.2. smartPORT Initiative

Initially, more than 20 exploratory projects werelaunched within the smartPORT initiative, ranging fromprocess optimization projects to technology evaluationprojects. Currently, the efforts are still ongoingand advertise over-arching digitization efforts at theHamburg Port Authority. Many of the early projects areoperational and have proven to deliver value. Followingthe 2015 international port conference, the University ofHamburg accompanied the HPA’s consolidation phasethat followed their initial exploratory projects [8, 11]

2.3. chainPORT Initiative

The group of ports within the chainPORT networkis a small but global group of ports around the globe,and most of the participating ports are the largestport of their respective country. Although theseports are competitors with similar goals and sharemany customers, the goal is to collaborate and tomove ”beyond bilateral partnerships” to face ”changingcompetitive challenges” [12]. Participating members are(west to east): Los Angeles (USA), Montreal (Canada),Barcelona (Spain), Antwerp (Belgium), Rotterdam(Netherlands), Hamburg (Germany), Busan (SouthKorea) and Singapore (Singapore).

2.4. IT Solutions Workgroup

The IT solutions workgroup tries to captureknowledge about IT solutions of different stages (idea,piloted, productive). One first goal of this workgroupwas to create a common understanding of what an ITsolution is, as this relatively common term has notbeen defined from an architectural and IS managementperspective [10].

2.5. ChainPORT Projects

We introduce the 24 IT solutions that were examinedand modelled during our research. Due to the context ofmaritime logistics, the majority of solutions can be seento be IoT related.

Digital 3D Port Model (1): Step-by-step creation ofa full digital copy of the port area to gain experiencein merging various sources of 3d-data, for example theincorporation of the current state of a building during itsconstruction into a virtual reality (display) system. Thesolution is piloting for planning activities.

Port Monitor (2): Incorporation of various datasources to create a holistic view of the current stateof the port, most importantly the traffic situation andinfrastructure status on the different traffic carriers. Thissystem is in full productive usage.

Smart Railway Switch (3): Implementation of newsensors to allow predictive maintenance for railroadswitched, thus reducing the need to send maintenanceteams on a fixed schedule while reducing the risk ofunexpected failure. This solution is productive but notfully rolled out due to pending regulatory changes.

Sharing Port Information (4): Project proposal togain experience in connecting data streams betweenports. This solution is still in ideation state.

Smart Sounding Table (5): Digitization of vesselmovement planning, utilizing a touch screen andvarious data sources such as vessel information

Page 381

systems, river depth measurements/forecasts andmovable infrastructure information. The solution isused productively.

Road Traffic Simulation System (6): Exploresadvantages of incorporating new sensor types intocomplex road traffic simulations, allowing moreaccurate traffic estimations and traffic forecasts. Thesolution is operational but results are partially mergedwith legacy system data.

Virtual Gates (7): Assessing gates’ traffic situationsby sharing real-time traffic information betweenterminal operators and port authority. This solution isused productively.

Port Links (8): Collaborative platform to allowestimation of total CO2 emission on complex routes.The solution is operational but not fully rolled out.

Internet Infrastructure (9-11): Four ports reportedinfrastructure projects to provide wireless internetpublicly within the port area or to carry out aninternal network redesign, though the employedtechnologies vary (public: 4G, WiFi; internal: opticalfiber, WiFi). They are seen as a prerequisitefor internet-based services as well as new Sensors(IoT-specific challenges).

Cyber Security Center (12, 13): Two portsaddressed possible cyber security threats by establishingoperational cyber security groups. These develop bothtechnological resilience as well as raising awarenessfor phishing and social engineering, and establishingcounter measures. These solutions are operational.

Single Window Projects (14, 15): Two ports eachreported a project aimed at creating a single front-endfor several customer-facing services to streamlinethe customer journey and increase the incorporatedservices’ usability. The services are related to berths,customs and other port authority tasks. Both solutionsare in productive usage.

Data Analytics Dashboard (16): Creating adashboard service aimed at creating a holistic view bymerging reporting visualizations of multiple stakeholdergroups. The scope also includes reporting processdigitization, as these reports were previously createdand sent manually. This solution is operational and hasfurther development potential.

Surveillance Drones (17): Project aimed atleveraging small unmanned aerial vehicles to lowerresponse times in cases of disasters like oil spills. Thesolution is in an ongoing pilot state.

Push Communication (18): Mobile app aimed atallowing provider-to-consumer communication to notifyabout certain events rather then requiring customersto actively check for events. This solution is usedproductively.

Trucking Portal (19): Sensor project aimed at moreaccurately capturing truck turn times. The data is used inseveral services and publicly accessible in a web portalfor truckers. This solution is used productively.

Smart Port Challenge (20): A public event as amethod to innovate and to generate new ideas in thecontext of maritime logistics. The event has been hostedat least once.

River Navigation (21): Sensor and simulationproject to increase accuracy of under-keel depthestimation, thus allowing more efficient planning ofport basin and river utilization. This solution is usedproductively.

Remote-controlled Infrastructure (22): Automationproject employing sensors and actors to allow remotecontrol of movable infrastructures such as locks andbridges. The solution is still in pilot state.

Barge Traffic System (23): Process digitization forterminal slot management, allowing more efficient andless reactive traffic coordination. This solution is in fullproductive usage.

Gas Detectors (24): Distributed mesh of gas sensorsaimed at noticing gas leaks in real-time at dozens oflocations throughout the port area. The solution is usedproductively.

3. Methodology

The conducted research follows the principles ofAction Design Research (ADR) as formalized bySein et al. [13]. In accordance with ADR,the research project was initiated by the HamburgPort Authority’s (the practitioner’s) problem to gatherand systematically document information about smartsolutions developed and/or implemented at other ports(principle 1: practice-inspired research). While creatinga formalized descriptive model of IT solutions, the focusof the research project was to develop an informationsystem incorporating the model as well as shapinga new communication channel to communicate thedocumented solutions. Therefore, we classified ourresearch to follow an IT-dominant Building, Interventionand Evaluation (BIE) task.

The research team was composed of a seniorresearcher and a PhD student, and our area ofinterest was how our emerging definition of theterm solution [10] could communicated in a moreformalized matter and how the portrayal would shapethe communication, an essential part in the diffusionof innovation [9] (principle 2: theory-ingrainedartifact). To align artifact shaping and organizationalcontext, regular meetings every two to three weekswere implemented with a subset of the participating

Page 382

practitioners (principle 3: reciprocal shaping). Duringthese meetings, the researchers’ theoretical backgroundwas used to progress into being able to answer thepractitioners’ questions, while the practitioners’ insightsand knowledge were leveraged to ensure the usabilityof the artifact, i.e. its effectivity, its efficiency, and theperceived satisfaction during application [14] (principle4: mutually influential roles).

Although this ensured a continuous alignment witha very small group of practitioners, we did severalevaluation cycles and with each cycle we increased thenumber of participants as well as the organizationalscope of their roles (principle 5: authentic andconcurrent evaluation). The first evaluation cyclewith participants other than those attending ourregular meetings was with a subject expert (head ofdepartment). The second evaluation took place withanticipated end-users at the port of Hamburg. Tobroaden the organizational scope beyond the port ofHamburg, the third evaluation cycle was conductedwith an anticipated later user at another European portparticipating in the chainPORT initiative, and our fourthand last evaluation cycle was done in a group meetingwith chainPORT members of multiple continents.

The continuous development of the ensembleartifact was guided by principles on several levels.Most importantly, we followed an concern-baseddevelopment of the underlying architecturalmeta-model. These architectural concerns ensured analignment of theoretical background and organizationalcontext (principle 6: guided emergence). Thestakeholders of these concerns were identifiedby a stakeholder analysis guided by [15], usingsemi-structured interviews to identify stakeholders(step 1). We then used reconstructive, bottom-upcategorization of these stakeholders by employinga stakeholder-led categorization approach (step 2).To grasp the responsibilities, capabilities and socialinterplay of the stakeholders, a mixed approachwas taken to investigate the relationships betweenstakeholders (step 3).

To generalize our findings, we conceptualizeour IS-based approach to the specific challengesencountered in our research project’s setting (principle7: generalized outcomes). Accordingly, we focus onhow the solution to the research problem was found andwhich conceptual problems needed solving, allowingour approach and/or learning to be leveraged in similarsettings.

4. Related Literature

Several streams of scientific research were foundto be relevant for our research project. We looked atInternet of Things literature to better understand the ITsolutions in place at the ports, as most of those projectswere IoT projects or very similar to IoT projects.To document solutions in a uniform way, enterprisearchitecture management was expected to be a goodfoundation, as its core concept is to link different aspectsof projects / solutions / IS artifacts with each other tocreate a high-level understanding of the subject matter.The process of sharing the gathered knowledge and allrelated aspects are described and formalized in the richbody of innovation diffusion research.

4.1. Internet of Things

The term Internet of Things is less a well definedterm but rather an umbrella term [16] for many differentaspects of technological systems and physical objects,and their relationships and interconnectedness, and theapplication of IoT is seen in many different typesof industries [17]. An important perspective is toacknowledge three different aspects of the subject,an internet-oriented vision, a things-oriented visionand a semantics-oriented vision [18], defining the IoTparadigm as the intersection between them. Theseperspectives were applied to the port authority context in[11] by choosing different levels of detail or abstractionfor different kinds of objects, focusing either on thething-aspect of IT or on connectivity-related aspectsto tackle the overarching problem of documentingsemantic relationships within IT architectures.

4.2. Enterprise Architecture Management

The main goal in enterprise architecturemanagement is to create a meaningful link betweendifferent, specialized architectures [19]. In practice,EAM can serve both as a planning tool and as arepresentation of an enterprise’s current state [20],and has matured over the last decades to be awell-researched field [21].

The link between IoT and EAM has been drawn inthe past, with a focus on technology-related architecturallayers [11, 8]. This research builds upon the smartbrick concept introduced by Schirmer et al. [11],which addresses the thing-aspect of the Internet ofThings. Smart bricks are an abstraction from sensorsand are virtual entities combining a physical objectwith attached sensors. Thus, sensors are describedby their role when attached to an object, e.g. aninduction loop (sensor) would instead be described as

Page 383

a car-counting road segment (combination of sensor andphysical object).

Drews et al. [8] use architectural slices to describeIT solutions, a viewpoint that is related to depictingprojects. Still, a solution may be changed, adapted orrefactored throughout several projects, so a distinctionbetween solution and project should be made froman architectural perspective. From an architecturalperspective, descriptions of solution architectures areeither only valid in a very specific context [22] or thedescription is very abstract [23]. An outline of whatconstitutes an IT solution in the context of maritimelogistics has been made [10], and research indicates thatthe character of an innovative IT solution spans beyondthe essential architectural layers outlined by Winter etal. [19].

4.3. Innovation Diffusion

The diffusion of innovation is the process in whichan innovation spreads through a group of organizations[1]. This field has a rich body of scientific researchand guided our research by providing an encompassingprocess model with a detailed framework of descriptionsof relevant artifacts. Most importantly, Rogers[9] stresses the close relationship to communicationand the impact that communication channels have.He also breaks the diffusion process down to (1)gaining knowledge of an innovation, (2) persuasionthrough perceived characteristics, (3) decision to adoptor reject, (4) implementation and (5) confirmation.The assimilation of an innovation is defined as therespective process within an organization that adopts aninnovation, which follow the same steps from gainingknowledge (1) to implementation and confirmation (5),but from a single organization’s perspective.

The goal of our research project was to assist inthe assimilation process, i.e. to help organizationswithin the stated process. Since most of theregarded innovations were relatively new to themaritime logistics industry and the practitioner’s statedgoal was to increase effectiveness and efficiency incross-organizationally assimilating innovations, a desireto be placed in the early adopter bracket (as definedby Rogers [9]) is implied. Therefore, several attributesof early adopters can be assumed to describe thepractitioners, most noteworthy their greater abilityto deal with abstractions and uncertainty, greaterrationality and a positive bias towards change [9].Therefore, we identified the need to abstract fromdetails, even though the reduction of details increasesuncertainty in certain aspects. This connects well tothe concepts of enterprise architecture management,

which also tries to neglect details while describing thehigh-level relationships between architectural artifacts.

During our research, we focused on the first threestages of the process, while keeping in mind that laterstages may possibly be supported in yet to be plannedresearch projects. Regarding the knowledge phase (1),Rogers [9] identified socioeconomic characteristics,personality variables and communication behavior asimportant factors. Our IS-based approach focuses onformalizing and improving the communication behaviorby providing a technology-based communicationchannel for innovations and reducing the need ofinformal communication, thus reducing the overhead in(1) gaining knowledge of an innovation.

The (2) persuasion phase identified by Rogersdepends most notably on the perceived characteristicsof an innovation, namely its relative advantage,compatibility, complexity, trialability and observability[9]. Throughout our research, we aimed to solve thesespecific problems by building upon the architecturaldescription of IT solutions by Tesse et al. [10],and formalizing visualization, data collection, specificattributes and relationships by means of a web-basedsoftware that was developed during our researchproject.

5. Results

We created a piece of software that allowedus to iteratively develop a suitable meta model toarchitecturally describe the IT solutions investigatedwithin the IT solutions workgroup of the chainPORTnetwork. We will first describe the derived modelas well as viewpoints / visualizations, and secondlyattempt to generalize our findings by describing howthe chosen development approach and data model wasbeneficial and how it might help research projects inother organizational settings.

5.1. Map View / Global View

Enterprise architecture tools commonly focus onarchitectural components displayed in table-like formsor in different diagram types. This makes sense asenterprise architecture management typically abstractsfrom object instances and only regards object classesand their relationships. While the possible needto regard object instances has been mentioned [11],we encountered several architectural concerns whereinstance knowledge was necessary. To cope with theincreasing numbers of objects at display, we neededto find suitable a viewpoint on our collected data.Systems that solve this problems are for exampleconfiguration management databases (e.g. as proposed

Page 384

by ITIL® [24]) or conceptually related geo informationsystems. Especially geo information systems usuallydepict objects on a map. We adopted this approachand created a map-based viewpoint on architectural data.The goal of this viewpoint is to depict informationcontextually, i.e. allowing users to understand thepurpose of objects by seeing how they are situated. Thisis necessary, as anticipated users have a large variety ofeducational background, ranging from topic experts toIT specialists and managers. And example are locks,as they can solve different purposes which are easilyunderstandable when displayed on a map, whereas theknowledge of what characterizes a ”flash lock” cannotbe assumed for all users.

Because of the amount of objects to display on aphysical map, this viewpoint is not automatically useful.Instead, the complexity was reduced by introducinga filter concept and by binding levels of detail tozoom-levels on the map. Starting with a world map,one can see all the participating ports of the chainPORTinitiative. In this viewpoint, a filtering mechanism canbe used to highlight ports that match certain criteria asdefined in our collected architectural concerns. Theseinclude for example highlighting ports having certaintypes of physical objects, for example movable bridges.Another filter was to highlight ports that have piloted orproductive IT solutions concerning the selected physicalobjects. Filtering on other solution attributes, forexample based on the usage of certain innovationaltechnologies or paradigms, was deemed necessary asper the collected architectural concerns, but was notimplemented in the evaluated prototype.

Figure 1. Screenshots showing a low level of detailwhen zoomed out (left side) and a high level of

detail when zoomed in (right side).

Source: Map material ©OpenStreetMap [25]

When zooming into a specific harbor, the level ofdetail would switch, depicting actual physical objectswithin the harbor limits, as depicted in figure 1.Furthermore, the detailed display of a port was furtherinfluenced by the applied filters, i.e. highlightingphysical objects that are linked to solutions or that area sub-type of the filtered object class.

5.2. Solution Details

The solution details were modelled leveraging themodelling techniques of previous research [11, 8]. As an

Figure 2. Technology layers of a sample solution

architecture, modelled following [11].

example of this modelling paradigm, figure 2 shows thePrePORT Parking project’s solution architecture withthe solution’s main information system, an analysisplatform, at the center. This solution addresses theproblem of scarce parking lot availability within the portlimits and is piloted at a parking lot outside the main portarea. The main issue for the trucker is that they need tobe at a specific terminal at a certain time, but parkingoutside of the port area introduces a risk of not reachingthe terminal in time as the road traffic is hard to predict.The solution tackles this problem by leveraging anothersolution’s traffic forecast data, which is generated bycomplex simulations on data from various sources,including in-road induction loops, video cameras andpassive wireless device id recognition. As the trafficsimulation system is part of another solution, thesesensor types are not displayed in the PrePORT Parkingsolution’s architecture. This information would beavailable in the respective solution’s architecture.

The displayed operator analytic services targetreporting and internal utilization monitoring, asindicated in figure 3. As the analysis platform tries tocreate lanes of vehicles wanting to leave at the sametime, the enrollment service asks truckers for theirdestination and desired time of arrival. This informationis then combined with detailed traffic forecasts fromthe traffic simulation system to estimate a resonabledeparture time for each truck. Then, the trucker is shownindividual instructions on large boards at the parkinglot (vehicle recognition by license plate), alongsidewith general parking lot utilization information (publicmonitoring services).

Page 385

Figure 3. Monitoring system for port-wide trafficdata.

Source: Screenshot provided by the Hamburg Port

Authority, AR

These solution details target step (2) of theassimilation process and display the perceivedcharacteristics of solutions. The technologicalsolution architecture specifically targets the abilityto gauge a solution’s compatibility and complexity. Theother attributes stated by Rogers [9] are dealt with bydocumenting solution attributes identified by Tesse etal. [10], namely a solution description, a solution’srelative advantage and a description of the problemthat the solution attempts to solve, thus allowing otherorganizations to trial the solution.

5.3. Comparison View

To align the derived use cases and specificstakeholder needs with the IS, an in-between viewpointneeded to be introduced, with the purpose of comparingarchitectural entities, as seen in figure 4. Firstly,this screen is necessary to compare organizations froma high-level perspective, to see whether or not theyare comparable. This information includes statisticaldata of the organization and its documented physicalobjects, in the context of ports for example the containerthroughput, degree of containerization, average bridgelength or average age of a port’s ship locks. Therefore,a necessity exists to make organizations comparable,which is most probably highly dependant on the industryand focuses on aspects that vary among organizations ofthe reviewed type and within the documented group oforganizations.

5.4. Types of Relationships

Throughout our research we found four kinds ofrelationships: linked to, part of, extends and implementsrelationships. Part-of relationships are very commonto any system documenting physical entities. Thepart-of relationship-type allows for a very naturalway of hiding details and reducing complexity, and

Figure 4. Screenshot showing the comparison viewof two ports

Source: Map material ©OpenStreetMap [25]

accordingly proved very useful when documentinghierarchies of physical objects. Furthermore, this allowsfor more comprehensive ways of filtering data, whichimplies that the concept of part-of relationships mightprove useful elsewhere, for example when embeddinga solutions processes into an overarching enterpriseprocess architecture.

While common in software engineering, theextends and implements relationships seemed usefulin combination with our specific data model. Sincethe created software has an adaptable meta model thatcan be changed at runtime, the implements relationshipindicates that a certain architectural entity is describedby a certain meta model class. Furthermore, theextends relationship is a special case of the implementsrelationship and describes the a meta model class isdescribed by another meta model class and furtherdescribes it by adding more attributes. As an example,both movable bridges and locks can be specified asextending the movable infrastructure class, and theattribute ”vehicles passing per year” is stipulated bythe movable infrastructure class. Instances exist, whereextended objects are directly instantiated, but we foundthose to occur solely when sufficient documentation tofurther specify an object was not present.

5.5. Role-based Enterprise Architecture

To allow for faster development of the organizationalaspects of our IS, a role-based data model was chosen.This differs from instantiation in that an a class instancehas exactly one class-template, whereas our role-basedmodel allows objects to take on multiple roles. We foundthis approach to allow slightly more flexibility at earlymodeling stages, but the current state of documentationdoes not have a single object that does not take onexactly one role. Therefore, we find the concept of

Page 386

role-based EAs slightly beneficial for developing newmodelling concepts, but do not recommend productiveusage in matured architecture tools, as there appears tobe no evidence that a matured model needs this kind offlexibility.

5.6. Types of Attributes

Since the created IS allows changes to the metamodel at runtime, special care needed to be tended tothe attribute types. We identified the types text, number,position, enumeration, link and map of numbers. Weneeded to introduce the position attribute-type to allowdocumenting physical objects. With our model of classinheritance, a sub-class of a class with a position wouldinherit a position attribute. We did not find any situationswhere this behavior was not semantically correct andanticipate that the position attribute-type is a base type.To allow for varying levels of details, it is (in oursoftware) defined by 4 values: latitude and longitude areset on a per instance level, the minimum and maximumzoom levels are set on a per class level.

The link attribute-type can model both logicalrelationships as well as part-of relationships. As ourattributes are per class, links automatically have acardinality of exactly one at its object instance of origin.Therefore, a link needs information of the destinationcardinality, which is set on a per class level. Wefound that for class inheritance the cardinality wouldonly decrease for sub-classes, i.e. an object of thesubclass could link to less than or the same amountof object instances as the orignial class would allow.Common scenarios include reducing the cardinalityfrom ”any” to ”one” or from ”one” to ”zero” (e.g.part-of relationships).

Enumerations seem to be a special case of text-basedattributes, permitting only the selection of a specified setof attributes. We found this to be replaceable in manycases by creating sub-classes, but enumeration-typeattributes allow faster and more comprehensiblemodeling, e.g. a movable bridge with hydraulic drives,rather than a sub-class ”hydraulically movable bridge”.In cases with multiple enumerations, sub-classes forany combination of the enumerations would have tobe created. Therefore, we deemed enumeration-typeattributes very useful in EA modelling.

Lastly, we identified map-like attribute-types fornumbers, which were used for example to documentthe number of vehicles passing a bridge per year.Possible other use-cases include a more structureddocumentation of attributes per unit of interest, forexample a responsibility per employee. In the specialcase of documenting amounts per year, we found it

helpful to limit the available map keys to a specific setof years, so that the documentation process is faster andmore uniform among objects in different organizations.

5.7. Lessons Learned: Visualization

Visualizations are strongly coupled with anarchitecture’s meta model, and our meta model can beadapted at runtime. Hence, the visualizations wouldneed to be adaptable at runtime too, to incorporatethe changes done to the meta model. Because of thecomplexity innate to changes in the visualization,it is a difficult task to create a flexible visualizationmodel editable at runtime that is not limited to verybasic operations and is also able to create specificviewpoints. The approach taken to tackle this problemwas to leverage the close relationship of our role-basedapproach with class inheritance models in softwareengineering, allowing us to create a class representationin our used programming language at runtime, whichwas then imported into the software’s source codeafter meta model adaption cycles, which increasedthe development speed at the cost of an conceptualgap within the software and meta model developmentprocess. This approach caused less issues thananticipated, and the conducted rapid feedback cycleswhen developing the architectural meta model proved tocreate a stable core structure very early on, and furtherimprovements mostly refined the used attributes andcreated new specialized types inheriting from stablecore classes.

5.8. User Feedback

The general feedback during our artifact’sevaluations was positive, and we can confirm thatthe approach of leveraging both innovation diffusionresearch and EAM was seen to create added valuefor the interviewed practitioners. The formalizationand modelling methods of EAM helped structuringand abstracting from the actually present ecosystemarchitecture, while innovation diffusion researchprovided a valuable framework for a guided overarchingprocess. This was especially necessary for ourinter-organizational environment of enterprises acrossthe globe.

During the evaluation cycles one recurring concernwas the non-existance of a data collection process, asEAM may fail to deliver value when data is incomplete,not up-to-date or if commitment of key stakeholdersis missing. Furthermore, documenting object instancesinstead of just classes of objects further increases theamount of time needed to document and to keep the dataup-to-date.

Page 387

6. Discussion, Limitations and Outlook

Throughout the conducted research we foundmultiple occasions where more conceptual work wasneeded. In this section we list these occasions andgive recommendations on how each problem can beaddressed. Within each of the following subsections,there is one paragraph each for discussion, limitationsand outlook.

6.1. Gap: Flexibility in Modelling andVisualization

The indicated gap in flexibility between modellingand visualization (see 5.7) stems from editing each oneof them in a different conceptual layer of the application:The model is edited at run-time while visualizationswere created in code. This offered great flexibility forboth aspects - for modelling by allowing rapid modelprototyping during interviews, as allowed by quick andeasy meta model changes, and for creating targetedvisualizations, as we were not limited to a predefinedset of available visualizations.

Both the convenience in changing the meta modeland the flexibility in visualizing significantly sloweddown the generation of visualizations. This wasobserved to negatively impact the speed of feedbackcycles for the application, as discussions tended to staytheoretical while concepts evolved at a faster pace thantheir visualization.

We found no situations contradicting with classinheritance models of scripting languages that wouldprevent the mapping of our role-based approach to aclass-based model. We would very much like to seehow modelling best practices in programming languagesmight benefit agile meta model prototyping in enterprisearchitecture management.

6.2. Concept for Data Collection

Enterprise architecture management is seen toincorporate more and more data in order to answerthe posed concerns. This needs to be an anticipatedproblem, and was somewhat anticipated in our researchproject but not formalized. After the research project isfinished, the port authorities need to be able to managetheir data to keep it up-to-date.

We did enter data as the tool evolved, but notice thatlevels of granularity and data quality (especially age)vary among our documented solutions. This diminishesthe trust in the tool itself, as participants cannot easilygauge the quality of the data they look at.

We propose further research on automating theprocess for some of the architectural layers. This

automization can be done by either connecting tospecialized tools (automated data collection) or byincorporating some of the specialized architectures intoEAM (convergent paradigms). To achieve this, furthergeneralization on types needs to be done and a morecomplete, stable and detailed meta model needs to bein place, e.g. by defining common components withinspecific architectural layers [26].

6.3. Shareability of Solutions

The emerged ensemble artifact is targeted atsupporting the cross-organizational assimilation ofsolutions, and the created software does address theneeds of the assimilation process, as formalized ininnovation management theory.

The concepts need to be tested on a more completedataset of the chainPORT participant’s respectivearchitectures, as only some projects have been modelledand the majority of the modelled solutions are stillmissing some specific details. We have establishednew ways of gaining knowledge of innovations, but aholistic view on an integrated architectural landscapeis yet missing. Additionally, no solution has yetbeen fully assimilated by another port authority, soonly the first steps of the innovation adoption processformalized by Rogers (knowledge, persuasion) [9] havebeen supported.

We anticipate to extend our research toaccompanying the actual assimilation of a port’sinnovation by another port. The learnings fromaccompanying the adoption / assimilation of onesolution by another port may refine and extend themodel, allowing it to aid at later stages of Rogers’innovation diffusion process, namely step (3) decisionto adopt or reject and (4) implementation [9]. To guidethe decision-making process, an IT artifact can providecommunication methods such as ratings and commentsper stakeholder, which would yield detailed knowledgeabout how decisions are made. Interesting parametersare the number of stakeholder involved in a decision,seeing which steps of the decision-making processrun in parallel and which run sequential, and lastly byoutlining communication patterns and behavior and if itis correlated to other factors.

6.4. Towards a Core Enterprise Architecture

The concept of a core EA [10] in contrast toa solution EA may benefit from further research.Solutions are always embedded into an enterprise andhave links to several architectural entities that cannotbe attributed to any specific solution, and the entitiesthat a solution is embedded to can be characterized as

Page 388

the core architecture. We found that some stakeholderconcerns can only be answered by looking at the port’score EA rather than a solution EA, as it holds detailedknowledge about how solutions are embedded into anorganization and at what levels an organization employsstandardization.

Currently, there is scarce knowledge of this topicand its implication on the diffusion of innovation, i.e.whether certain types of core EAs promote modularityand thus benefits an organization’s ability to adopt orshare innovations. We anticipate that a core architectureis strongly related to the researched industry’s context,in our case the maritime logistics industry with a specificfocus on port authorities.

A core enterprise architecture may further promotethe ability to assimilate IoT innovations and we lookforward to explore this subject in the chainPORTinitiative’s inter-organizational setting. A possible nextstep could be the identification of a core architecture’sscope and attributes important to innovation diffusion,which may later lead to partial standardization or toenabling strategic development of an enterprise’s corearchitecture.

References

[1] R. G. Fichman, “The diffusion and assimilationof information technology innovations,” Framing thedomains of IT management: Projecting the futurethrough the past, vol. 105127, 2000.

[2] Gartner, “Five megatrends shift the computinglandscape,” Gartners hype cycles for 2015, 2015.

[3] F. Wortmann and K. Fluchter, “Internet of things,”Business & Information Systems Engineering, vol. 57,no. 3, pp. 221–224, 2015.

[4] E. Abad, F. Palacio, M. Nuin, A. G. De Zarate,A. Juarros, J. Gomez, and S. Marco, “Rfid smart tagfor traceability and cold chain monitoring of foods:Demonstration in an intercontinental fresh fish logisticchain,” Journal of food engineering, vol. 93, no. 4,pp. 394–399, 2009.

[5] M. Fruth and F. Teuteberg, “Digitization in maritimelogisticswhat is there and what is missing?,” CogentBusiness & Management, vol. 4, no. 1, p. 1411066, 2017.

[6] B. Montreuil, “Toward a Physical Internet: meeting theglobal logistics sustainability grand challenge,” LogisticsResearch, vol. 3, no. 2-3, pp. 71–87, 2011.

[7] B. Wiegmans and S. Dekker, “Benchmarking deep-seaport performance in the Hamburg-Le Havre range,”Benchmarking: An International Journal, vol. 23, no. 1,pp. 96–112, 2016.

[8] P. Drews, I. Schirmer, J. Tesse, S. Saxe, and U. Baldauf,“Internet of Things-specific Challenges for EnterpriseArchitectures Internet of Things-Specific Challenges forEnterprise Architectures: A Cross-Case Comparison ofExplorative Projects from the smartPORT Initiative,”Twenty-third Americas Conference on InformationSystems, 2017.

[9] E. M. Rogers, Diffusion of Innovations. Free Press,5th ed., 2003.

[10] J. Tesse, I. Schirmer, P. Drews, S. Saxe, and U. Baldauf,“Supporting diffusion of iot solutions exemplified by thechainport initiative,” 2018.

[11] I. Schirmer, P. Drews, S. Saxe, U. Baldauf, and J. Tesse,Extending enterprise architectures for adopting theinternet of things Lessons learned from the smartPORTprojects in Hamburg, vol. 255. 2016.

[12] Hamburg Port Authority, “Press release: Foundation ofthe global port network ChainPORT,” 2018. https://www.hafen-hamburg.de/en/news/---34590(accessed 2018-06-14).

[13] M. K. Sein, O. Henfridsson, S. Purao, M. Rossi, andR. Lindgren, “Action design research,” MIS quarterly,pp. 37–56, 2011.

[14] E. Frøkjær, M. Hertzum, and K. Hornbæk, “Measuringusability: are effectiveness, efficiency, and satisfactionreally correlated?,” in Proceedings of the SIGCHIconference on Human Factors in Computing Systems,pp. 345–352, ACM, 2000.

[15] M. S. Reed, A. Graves, N. Dandy, H. Posthumus,K. Hubacek, J. Morris, C. Prell, C. H. Quinn, and L. C.Stringer, “Who’s in and why? A typology of stakeholderanalysis methods for natural resource management,”Journal of environmental management, vol. 90, no. 5,pp. 1933–1949, 2009.

[16] A. Bassi, M. Bauer, M. Fiedler, T. Kramp,R. Van Kranenburg, S. Lange, and S. Meissner,“Enabling things to talk,” Designing IoT Solutions Withthe IoT Architectural Reference Model, pp. 163–211,2013.

[17] E. Borgia, “The internet of things vision: Keyfeatures, applications and open issues,” ComputerCommunications, vol. 54, pp. 1–31, 2014.

[18] L. Atzori, A. Iera, and G. Morabito, “The internet ofthings: A survey,” Computer networks, vol. 54, no. 15,pp. 2787–2805, 2010.

[19] R. Winter and R. Fischer, “Essential layers, artifacts, anddependencies of enterprise architecture,” in EnterpriseDistributed Object Computing Conference Workshops,2006. EDOCW’06. 10th IEEE International, pp. 30–30,IEEE, 2006.

[20] L. Kappelman, T. McGinnis, A. Pettite, and A. Sidorova,“Enterprise architecture: Charting the territory foracademic research,” AMCIS 2008 Proceedings, p. 162,2008.

[21] D. Simon, K. Fischbach, and D. Schoder, “Anexploration of enterprise architecture research.,” CAIS,vol. 32, p. 1, 2013.

[22] J. Banerjee and S. Aziz, “SOA: the missing link betweenenterprise architecture and solution architecture,”SETLabs briefing, vol. 5, no. 2, pp. 69–80, 2007.

[23] The Open Group, “The open group architectureframework,” 2018. http://www.opengroup.org/togaf/ (accessed 2018-06-14).

[24] AXELOS limited, “IT Infrastructure Library®,”2018. https://www.axelos.com/ (accessed2018-06-14).

[25] Open Street Map, “openstreetmap.”[26] A. Josey, “The open group it4it reference architecture,

version 2.0,” Berkshire, UK: The Open Group, 2015.

Page 389