Empirically Modeling Enterprise Architecture Using ArchiMate

Qiang Zhi1,* and Zhengshu Zhou2,3

1Graduate School of Engineering, Tokyo Institute of Technology, Tokyo, CO 1528550, Japan2Graduate School of Informatics, Nagoya University, Nagoya, Aichi, CO 4648601, Japan

3Institute of Innovation for Future Society, Nagoya University, Nagoya University, Nagoya, Aichi, CO 4648601, Japan�Corresponding Author: Qiang Zhi. Email: zhiqiang0728@gmail.com

Received: 20 March 2021; Accepted: 02 May 2021

Abstract: Enterprise Architecture (EA) has evolved based on the practice of infor-mation systems architecture design and implementation. EA is a rigorous descrip-tion of a structure, and the objectives of EA modeling not only include clarifyingcorporate strategies, visualizing business processes, and modeling informationsystems to manage resources but also include improving organizational structures,adjusting information strategies, and creating new business value. Therefore, EAmodels cover a wide scope that includes both IT and business architectures. Typi-cally, EA modeling is the initial and most important analysis step for researchers,architects, and developers. ArchiMate is the dominant modeling language for EAand it has been shown to improve visualization of EA models. However, few stu-dies have systematically introduced general modeling methods using ArchiMateto meet a broad range of needs and few studies have empirically evaluated themodeling method using ArchiMate. This paper introduces an EA visualizationapproach to fill that gap and conducts a case study on a wilderness weather stationsystem. Strict controlled experiments are conducted to verify the effectiveness andfeasibility of this modeling method, and the experimental results show that thismodeling procedure is not only feasible, but also can effectively transform thesystem metamodel and restore the EA scene.

Keywords: Enterprise architecture; system modeling; visualization methodology

1 Introduction

Enterprise Architecture (EA) is a generic solution to a systemic and universal problem in enterprisebusiness information management systems. More precisely, EA is a business-oriented architecture tounderstand, analyze, design, build, integrate, extend, operate, and manage information systems. The keyto the integration of complex systems is architecture or system based integration rather than component-based integration. Effective EA is critical for the survival and success of an enterprise, and is anindispensable means for the enterprise to gain competitive advantages through IT.

The earliest incarnations of enterprise architecture came from the field of enterprise modeling. Until themid-1980s, enterprise reengineering or enterprise modeling was primarily an academic pursuit; however, thetheories and models used were usually limited to the design and development of a particular information

This work is licensed under a Creative Commons Attribution 4.0 International License, whichpermits unrestricted use, distribution, and reproduction in any medium, provided the originalwork is properly cited.

Computer Systems Science & EngineeringDOI:10.32604/csse.2022.018759

Article

echT PressScience

system. In the United States, the Clinger-Cohen Act of 1996, enacted as the Information TechnologyManagement Reform Act, led to the creation of the term “IT Architecture (ITA).” The purpose of EA isto visualize business processes and model ITA to manage resources, improve organizational structures,adjust information strategies, and create new business value. EA can be generally divided into businessarchitecture and ITA. Most EA methods are developed from ITA, which can be further divided intorequirement engineering, governance, operation, technology infrastructure, and security analysis.

Essentially, business architecture is a channel to translate an enterprise’s business strategy into dailyoperations. The business strategy determines the business architecture, which includes various elements,such as the business operation model, process system, organizational structure, and geographicaldistribution. IT architecture guides IT investment and design decisions. It is a comprehensive blueprint forestablishing enterprise information systems, including data, application, and technical architectures.

Visual EAmodels are developed to facilitate analysis, design, development, and implementation of EAs.EAvisualization raises the level of abstraction in information system design, enables verification in the earlystages of system development, and gives information system designers a bird’s eye view of the business andorganization. When developing large-scale projects for large enterprises, EA visualization facilitates themanagement of resources, policies, risks, and business processes. In both academic research and practicalengineering, EA modeling methods are indispensable for EA visualization. In our previous work [1],112 research papers on EA methods are selected for a systematic literature review to examine the currentstatus, technical features, and unsolved challenges of EA visualization research. Although many EAmodeling methods have been proposed, the application of the underlying theories is fragmented, andthese methods are rarely used systematically in empirical studies. As an extension of that work, this paperintroduces a detailed generic EA modeling procedure using ArchiMate [2] and presents a detailed casestudy to show the modeling procedure. Also, controlled experiments are conducted to verify its effectiveness.

The remainder of this paper is structured as follows. Section 2 briefly reviews previous studies related toEA modeling. Section 3 introduces the proposed EA visualization procedure and presents a detailed casestudy. The empirical evaluation and the discussions are described in Sections 4 and 5. Conclusions,including a summary of the contributions of this study, are provided in Section 6.

2 Related Work

In general, EA models focus on ITA, business modeling, technology infrastructure, and securityanalysis. This part briefly summarizes recent EA modeling research in each area.

Modeling EA for requirements engineering (RE) is important to analyze requirements. RE is the processof defining, documenting, and maintaining requirements in the engineering design process. Quartel et al. [3]proposed an approach to integrate goal-oriented RE language with EA modeling, and described anarchitecture-based approach for IT valuation [4]. Mylopoulos et al. [5] proposed the TROPS frameworkfor requirements-driven software development, and Teka et al. [6,7] compared the expressive ability ofTROPS and nonfunctional requirements (NFR). Several studies have proposed EA modeling approachesto represent operation models [8–10]. In addition, many studies have focused on how to apply EAmodeling to governance, such as governance enterprise architecture) (GEA) [11,12], enterprisearchitecture management (EAM) [13–15], and business governance [16–20]. Another research area thatrequires EA modeling is security analysis, and representative studies include multi-level dependencies[21], security assessment frameworks [22–26], and security assurance and analysis [27–31]. Moreover,EA modeling can be applied for specific validation or evaluation. For example, EA properties evaluation[32–37] and business application evaluation [38,39].

358 CSSE, 2022, vol.40, no.1

The alignment between business architecture and ITA is a natural alignment of two related disciplines.Business architecture represents a business in the absence of any ITA while EA provides an overarchingframework for business and ITA. In application, business architecture provides a bridge between thebusiness model and corporate strategy as well as the business functions of the enterprise. It often enablesa methodology from strategy to execution. Many EA studies are related to business architectures, such asservice-oriented architecture (SOA) [40–43], and IT business architecture projects [44–47].

Although there have been many research papers on EA to date, they are only applicable to specificconditions and purposes. This paper attempts to summarize a generic EA visualization method to meetthe requirements for different purposes based on those fragmented modeling methods, and conductsempirical evaluations to verify its effectiveness.

3 A Generic EA Modeling Approach

Most EA studies mention their limitations, such as the scope of application, lack of empiricalevaluations, lack of completeness, unclear semantics, complexity, cost, etc. Those fragmented methodswere analyzed and summarized in our previous work [1]. Now, based on that work, this paper introducesa generic method using ArchiMate to model EAs based on EA scenarios.

3.1 EA Modeling Procedure

This EA modeling procedure consists of five phases including (1) metamodel creation, (2) classification,(3) mapping, (4) reconstruction, and (5) assessment.

[Phase 1] Metamodel creation

Create a visual diagram of EA objects based on the system scenario. This scenario may be a systemspecification or a descriptive text.

(Step1-1) Analyze the EA scenario: An EA system scenario is used to describe how the system workswith minimal technical details. Scenarios are written in plain language. For example, the scope of a scenariocould be a single system, a piece of equipment, an equipped team or department, or an entire organization.The EA scenario analysis generally includes coverage analysis, dependency analysis, Interface analysis,complexity analysis, and cost analysis.

(Step1-2) Extract core artifacts from the EA scenario: In general, the core artifacts can be presented asfollowing types [48]: strategy specification, organization/process specification, application specification,software specification, technical infrastructure specification, specification of dependencies between layers.

(Step1-3) Create object elements and the corresponding relationships based on the extracted coreartifacts.

(Step1-4) Create EA metamodel: This step can generally be defined and visualized by a specific genericmodel of the object elements and their relationships. Creating a systemigram to represent an EA metamodelis a common method because the syntax and semantics are usually free. Notably, there should be text notes toclearly represent the relationship between elements.

[Phase 2] Classification

Classify the objects and relations from the metamodel diagram. In general, the object elements in an EAscene can be classified as actor, role, interface, collaboration, process, function, event, service, product, dataobject, and system software. An EA scenario can also include elements related to requirements analysis, suchas goals, assessment, principle, constraints, and requirements. Typically, the relationships include composition,realization, assignment, serving, access, influence, triggering, flow, specialization, association, and junction.

(Step2-1) Classify the extracted core artifacts.

CSSE, 2022, vol.40, no.1 359

[Phase 3] Mapping

The classified elements and relationships need to be replaced by entities in ArchiMate via the mappingrules. ArchiMate has corresponding definitions for the object and relationship types mentioned in Phase 2.The mapping relationship definition should be consistent with the EA scenario.

(Step3-1) Define mapping rules to translate the metamodel objects and relations based on entities ofArchiMate.

(Step3-2) Replace the object elements and relationships with the entities of ArchiMate.

[Phase 4] Reconstruction

To improve visualization, the new EA model can be restructured following specific criteria.

Aggregation: Few EA modeling studies have mentioned the concept of aggregation; however,aggregation can effectively improve readability. In the model developed in the previous step, differenttypes of elements were mixed; thus, the EA model is disorganized and poorly visualized. Different typesof elements, such as requirements, functions, risks, applications, can be categorized and then integrated.A tree structure or an inclusion structure can be created with an aggregation. When there are multiplemetamodels, they should be integrated if the intersections are not empty.

Decomposition: Similar to technical models of components and devices, information models can bedecomposed from high-level concepts to details. The elements and relationships in metamodels are oftenabstract. Increasing the amount of EA information is an important part of the visualization process thatcan be achieved by decomposing and subdividing these elements. Typically, structure trees are used todecompose aggregation or composition relationships into multiple levels. A tree structure is a convincingrepresentation of the scope that can be reviewed by stakeholders and serves as a guide for the entireprogram. Gaps or out of range characteristics should be identified as early as possible, and the tree can bemodified to reflect these characteristics. Out of range features can be retained as part of the tree; however,they should be annotated in some way to indicate that they are out of range, such as by using specificmapping definitions or different colors. Element and relationship decomposition requires the definition ofnew elements and relationships.

Multiple layers: To improve readability and maintainability, the new EA model can be reorganized intodifferent layers. Classic EA includes business, data, application, and technology layers [49]. There are alsosome derived layering methods such as GEA, EAM, as well as specific layering methods for specificpurposes. However, ArchiMate retains the business, application, and technology layers and introduces amotivation layer into EA models to facilitate application to most EA scenarios. Most of the elementobjects from the other layers, such as data, manage, environment layers, can be assigned to theintroduced four-layers EA model: (1) Motivation layer: mainly includes strategy, goals, functional andnonfunctional requirements, and risks. (2) Business layer: mainly includes business logic, business actors,business service, and business processes. It represents a business to the customer and is also relevant tointernal-facing organizations. (3) Application layer: it is generally between the business and technologylayers. The application layer is essential in a complete EA model, i.e., both business and IT architectures.(4) Technology layer: it describes system software applications and infrastructure. Although it may be notnecessary to define the technology layer in detail in a business model, it is indispensable in ITA.

The reconstruction phase can be summarized as follows.

(Step4-1) Integrate EA entities with same properties and retain different entities.

(Step4-2) Decompose EA entities to reflect detailed characteristics (if necessary).

(Step4-3) Improve visualization through layering.

(Step4-4) Integrate EA diagram with the extended analysis diagrams (if necessary).

360 CSSE, 2022, vol.40, no.1

[Phase 5] Assessment

In an EA scenario, a clear set of vision, tasks, and processes is often required. The effectiveness of an EAmodel can be measured by how EA artifacts reflect EA scenarios. This phase evaluates whether thedeveloped EA model can clearly and effectively represent the EA scenario.

(Step5-1) Check object elements and relationships.

(Step5-2) Check object elements’ mappings and relationships’ mappings.

(Step5-3) Restore the EA scenario based on the new model.

[Extended EA Analysis]

Sometimes some additional analysis is necessary for various purposes, e.g., assurance cases [50],security analyses, and NFR quantitative evaluations. In general, assurance cases and system architecturediagrams are developed separately. When assurance case objects are the elements of the systemarchitecture diagram, two types of diagrams need to be developed simultaneously, and gaps may occurwhen the two diagrams are manipulated. Therefore, integrating the system architecture diagram and theassurance case diagram into a single diagram should be considered (Fig. 1). An assurance case isgenerally developed using goal structuring notation (GSN), therefore, the proposed EA modelingapproach is also applicable to an assurance case. The relationship between the element in the systemarchitecture and the evidence in the assurance case can be presented as a “realize relation.”

Assurance cases can also be extended for NFR quantitative evaluations and security analyses. Withweighted evaluations, the general practice is to assign weight values to the elements or relationships ofthe model [51,52]. When the target system is a system with complex state transitions, the interactions inthe system will become important. However, in such a scenario, it is necessary to verify explicitly thatthese interrelations are correctly expressed since EA or system models generally need to be modeledmanually. Zhi et al. [53] proposed an approach to model such systems with model checking to visualizecomplex interactions. The EA modeling procedure can be summarized as Fig. 2.

3.2 Case Study

EA model transformation based on a wilderness weather station system has been discussed in ourprevious work [54]. Here, a similar target system is used as the case study. Such weather stations aredeployed by the government of a country with large areas of wilderness to help monitor climate changeand improve the accuracy of weather forecasts in remote areas [55]. The EA scenario of a wildernessweather station system can be summarized as follows.

Figure 1: Integration of system architecture and assurance case diagrams

CSSE, 2022, vol.40, no.1 361

(1) The weather station system collects data from a set of instruments that measure temperature,pressure, sunshine, rainfall, wind speed, and wind direction. (2) The weather station system collectsmeteorological data, performs some initial data processing, and transmits the data to the data managementsystem. (3) The data management and archiving system collects the data from all wilderness weatherstations, carries out data processing and analysis, and archives the data in a form that can be retrieved byother systems, such as weather forecasting systems. (4) The station maintenance system can communicateby satellite with all wilderness weather stations to monitor the status of these systems and provide reportsof problems. It can update the embedded software in these systems. In the event of system problems, thestation maintenance system can also be used to control a wilderness weather system remotely. (5) Theweather station system includes a number of instruments that measure weather parameters, such as windspeed and direction, ground and air temperatures, barometric pressure, and rainfall over a 24-h period.Each instrument is controlled by a software system that takes parameter readings periodically andmanages the collected data. Wildness weather stations are battery-powered and must be entirely self-contained. All communications are through a relatively slow-speed satellite link, and the weather stationmust have a mechanism (solar or wind power) to charge its batteries. (6) The potential risks, availabilityof devices and security of data should be fully considered.

Now apply the EA method to the wilderness weather station system using ArchiMate. First, coreartifacts are extracted from the EA scenario after analyzing the EA scenario. Then a systemigram iscreated as a metamodel of the system (Fig. 3). It is also necessary to define the mapping between theelements and relations of the metamodel and the ArchiMate modeling language. A complete four-layer

Figure 2: Generic procedure of EA model development

362 CSSE, 2022, vol.40, no.1

model is given, but this is not necessary for all EA scenarios. To classify the elements and relationshipsaccording to the characteristics of each layer, system software should be allocated to technologyarchitecture (TA), and corresponding applications and services should be in application architecture (AA)and business architecture (BA). Application goals, requirements, and risks should be discussed in relationto the motivation architecture (MA). The elements and relationships in the system diagram are aggregatedand decomposed according to the properties of each layer, and then new elements and relationships fordecomposition are defined. Typically, the aggregation and decomposition process requires sufficientknowledge of the system. The core artifacts, classification, and mapping results are presented in Tab. 1.

The EA models for the wilderness weather station system in ArchiMate representation are shown inFig. 4. Information coverage ratio is used to measure the visualization capability of the developed EAmodel. The information coverage ratio is defined as the total number of specific nouns and verbs of thedomain contained in the EA model, divided by the total number of specific nouns and verbs of thedomain contained in the aforementioned enterprise scenario of the system.

4 Experiments

Controlled experiments are conducted to verify the effectiveness of the EA modeling approach. Sixteensoftware engineers and eight graduate students were invited to participate in the experiments, and then theywere divided into four groups (Groups A, B, C, and D) for comparative experiments.

4.1 Experimental Hypotheses

Prior to implementing the controlled experiments, three hypotheses are formulated.

[Hypothesis 1]: Using the introduced method to model system scenarios is feasible.

Figure 3: Systemigram of the wilderness weather station system

CSSE, 2022, vol.40, no.1 363

[Hypothesis 2]: A metamodel can be transformed based on the modeling procedure.

[Hypothesis 3]: The EA model derived from the modeling procedure is sufficient to restore the EAscenario.

Table 1: Core artifacts, classification, and ArchiMate mapping of the wilderness weather station system

System Core artifacts ArchiMateLayer

Mapping in ArchiMate

Meteorologicalstation system

Element E1: Digital measuring unit TA Device

E2: CommunicationHardware Platform

TA Interface

E3: Alternative measuringinstallation

TA Device

E4: Station software TA System software

E5: Weather data AA Data object

E17: Soundness MA Requirement

Relation R1: Collect (E1→E5) AA Service

R2: Alternate (E3→E1) AA Association

R3: Switch control (E4→E3) AA Trigger

R4: Send (E5→E2) AA Access

R5: Monitor (E4→E1) TA Realization

R6: Monitor (E4→E14) TA Association

Data managementsystem

Element E6: Data collectionapplication

TA, AA Technology serviceApplication collaborationApplication service

E7: Archive application TA, AA Technology serviceApplication componentApplication function

E8: Data processingapplication

TA, AA Technology service,Application componentApplication function

E9: Data analysis application TA, AA Technology serviceApplication componentApplication function

E18: Weather data AA Data object

Relation R7: Collect (E6→E18) AA Access

R8: Analyze (E9→E18) AA Access

R9: Process (E8→E18) AA Access(Continued)

364 CSSE, 2022, vol.40, no.1

4.2 Experimental Process

The experiment process to evaluate the proposed method is designed as follows.

System introduction: Only members of Group A received a 15-min explanation of the target system—

the wilderness weather station system (in the case study of Section 3).

Method seminar: The members of all groups received a one-hour seminar on system architecturemodeling methods (modeling system architecture from system scenarios) and the proposed EA methods.The members of all groups took part in a 90-min seminar to familiarize them with the basics of ArchiMate.

Table 1 (continued).

System Core artifacts ArchiMateLayer

Mapping in ArchiMate

Stationmaintenancesystem

Element E10: Station maintenancesystem

TA Technological node

E11: Problem report BA Representation

Relation R10: Provide (E10→E11) TA, AA,BA

Realization, Serving, Access

R11: Remote control(E10→E4)

TA Serving

R12: Monitor (E10→E17) TA, AA,BA, MA

Realization, Serving, Access

R13: Communicate(E10→E16)

TA Association

Charging devices Element E12: Charging devices TA Technological node

E13: Solar power generationdevices

TA Equipment

E13: Wind power generationdevices

TA Equipment

Relation R14: Charge (E12→E14) TA Association

Power supply Element E14: Power supply TA Resource

Relation R15: Power (E14→E4) TA Association

Stand-by powersupply

Element E15: Stand-by power supply TA Resource

Relation R16: Alternate (E15→E14) TA Association

Satellitecommunicationsystem

Element E16: Satellite communicationsystem

TA Technological node

Relation R17: Communicate (E16→E6) TA Association

Strategy Element E19: Risks MA Driver

E20: Functional andnonfunctional goals

MA Goal

E21: Functional andnonfunctional requirements

MA Requirement

Relation R17: Require (E20→E21) MA Realization

CSSE, 2022, vol.40, no.1 365

Pre-experiment: A pre-experiment was conducted to determine the time-limited term under timepressure conditions.

Group experiment: An experiment was prepared for each of the four groups. The assigned tasks wereas follows. Members of Group A performed EA modeling of the target system using the introduced EAmethodology based on the target system scenario. Members of Group B transformed the systemigram(Fig. 3) based on the introduced EA methodology. Members of Group C restored the system scenario

Figure 4: EA model of the wilderness weather station system in ArchiMate

366 CSSE, 2022, vol.40, no.1

based on the systemigram (Fig. 3). Members of Group D restored the target system scenario based on theproposed target system model (Fig. 4). The simplified wilderness weather station system scenario hasbeen described in the case study section. The time limits for Groups A and B, Groups C and D were90 and 60 min, respectively. An overview of the controlled experiment is shown in Fig. 5.

The evaluation criterion for Group A was the information coverage ratio (Tab. 1). The evaluationcriterion for Group B was also the information coverage ratio; however, in this case, the comparisonobject was the systemigram rather than the system scenario. For Groups C and D, the evaluation criterionwas the information restore ratio. All created scenarios were scored on a ten-point scale by anindependent system design expert not associated with the research or the experiment.

4.3 Group Configuration

Sixteen software engineers with knowledge of EA modeling and eight graduate students majoring insoftware engineering participated in the experiment. For the software engineers, we planned andexperimented a training seminar as an empirical investigation. The seminar met both our and theparticipants’ objectives. The goal of the seminar was for the software engineers to gain knowledge andskills, i.e., EA visualization modeling methodology. Our purpose was to analyze the feasibility withpractitioners as the object. For the students, the experiment was conducted in weekly student seminars.

The subjects were divided into three teams according to their work experience: Team I, more than fiveyears; team II, 0–5 years; team III: students. To make the experimental results objective, all subjects weresingle-blind. The group configurations of this experiment are shown in Tab. 2. A t-test showed that therewas no significant difference in experience (α = 0.05) between each group.

4.4 Experimental Data

The experimental results for Groups A and B are summarized in Tab. 3. The information coverage ratioof system elements and relationships was calculated. The experimental results for Groups C and D aresummarized in Tab. 4. In addition to the evaluation scores by the system design expert, the informationrestore ratio of the system elements and the relationships were also calculated based on their createdscenarios. The calculations were performed without knowing any information about the subjects. Thetotal restore rates for Groups C and D are compared in Fig. 6.

Figure 5: Overview of the controlled experiment

CSSE, 2022, vol.40, no.1 367

Table 2: Group configuration

Group No. of members Avg. work experience

Group A I 2 6.5 3.3

II 2 3.5

III 2 0

Group B I 2 6 3.1

II 2 3.5

III 2 0

Group C I 2 6.5 3.1

II 2 3

III 2 0

Group D I 2 6 3.1

II 2 3.5

III 2 0

Table 3: Information coverage ratio for groups A and B

Group Elements Relationships Avg. time Benchmarks

Group A I 0.92 0.86 85 System scenario

II 0.90 0.88 90

III 0.86 0.84 90

Group B I 1.00 1.00 72 Systemigram

II 1.00 1.00 85

III 0.96 0.96 82

Table 4: Information restore ratio for groups C and D

Group Elements Relationships Avg. time Average score

Group C I 0.96 0.88 46 7.2

II 0.92 0.86 55

III 0.86 0.85 58

Group D I 0.96 0.90 52 7.9

II 0.94 0.88 58

III 0.92 0.88 55

368 CSSE, 2022, vol.40, no.1

4.5 Results Analysis

In this section, experimental results are analyzed to test the stated hypotheses.

[Hypothesis 1]: The members of Group A knew the target system scenario, and they modeled thesystem architecture with the introduced procedure. Hypothesis 1 can be confirmed according to theexperimental results: the created EA models have a high information coverage ratio (Tab. 3).

[Hypothesis 2]: The members of Group B did not know the target system, and they modeled thesystem architecture with the introduced EA model method based on a systemigram. They also achieved agood performance (Tab. 3). The results demonstrate that a systemigram can be transformed into anArchiMate model.

[Hypothesis 3]: Groups C and D created the system scenarios based on the introduced systemigram andthe EA model. The scenarios created by Group D have high information restore rate. Therefore, the resultsdemonstrated that the introduced method does not reduce the readability of EA model and is efficient inunderstanding system scenarios. Group D outperformed Group C; however, the difference was minimal(Fig. 6). This may be due to two reasons: (1) the standard answers we set only contain the majorelements and relationships (specific nouns and verbs), and (2) the target system is less complex.Furthermore, Group D’s scenarios achieved a higher average score from the system design expert, whichindicates that the scenario created based on the introduced EA model shows more comprehensiveinformation.

As the sample size was relatively small, the independent sample t-test was used to analyze theexperimental results for each group, the test results showed that experienced engineers perform betterthan inexperienced students.

5 Discussion

5.1 Effectiveness

To verify the effectiveness of the introduced EAvisualization method, three hypotheses were postulatedand four controlled experiments were designed to verify these hypotheses. According to the experimentalresults, the introduced EA visualization method is feasible and effective.

UML is the most commonly used EA modeling language for the large software companies in Japan,while systemigram is favored by smaller companies. These modeling methods usually have neither

Figure 6: Total restore rate comparison between Groups C and D

CSSE, 2022, vol.40, no.1 369

uniform rules nor obvious defects, and most companies have used them for many years. To carry out furtherempirical research, a questionnaire is designed and an anonymous questionnaire survey is conducted on all16 software engineers who participated in the experiments.

Questionnaire: the practicability, necessity, adaptability, promotion value, and persuasiveness of theintroduced EA modeling method were queried. Participants responded to the questions using a five-pointscale: (1) strongly disagree; (2) disagree; (3) neither agree nor disagree; (4) agree; (5) strongly agree. Theresponses were assigned 1-5 point, respectively. On average, all questions received positive results.Among them, the promotion value score was the highest, which means that the participants think that theintroduced generic modeling method is instructive. The lowest score was the necessity, which indicatesthat participants felt that this method was not urgently needed for their current work. The questionnaireresults are presented in Fig. 7.

5.2 Threats to Validity

5.2.1 EA Visualization ProcedureA systematic review of the existing literature to analyze existing EA modeling methodologies is

conducted in our previous work. This paper first introduced a detailed generic EA visualization procedureby summarizing these existing fragmented methodologies. A detailed case study was conducted toenhance the understanding. In the case study, a simplified system scenario and the correspondingmetamodel (systemigram) were introduced. Then, according to the modeling method, ArchiMatemodeling language was used to define the system elements and relationships in detail and restructurethem into a well-visualized model. However, the target system is less complex, and a more extensive EAscenario may be required to verify effectiveness.

5.2.2 Controlled ExperimentsExperiments were conducted with software engineers and graduate students majoring in software

engineering as the subjects to evaluate the effectiveness of the proposed approach. To validate theexperiments, the following issues should be considered: whether the constituent elements of theexperiment can be guaranteed; how a human-oriented experiment affects the effectiveness; and whetherthe experimental results can be extended to an actual working environment. The subjects were dividedinto four groups according to their work experience, and there is no significant difference in the workexperience. The experiments for each group were designed and carried out independently. Due to thesmall scale of the system used in the experiments, the experimental results may not be generalizable.

Figure 7: Questionnaire results

370 CSSE, 2022, vol.40, no.1

However, the target system can be considered as a part of a large EA scene. Indeed, large-scale EA scenariosare often decomposed according to certain criteria before modeling.

6 Conclusion

This paper presents a general modeling methodology to improve the visualization of EA models. To thebest of our knowledge, this is the first empirical study that introduces a general EA visualization procedureusing ArchiMate. The contributions of this study are summarized as follows: (1) Based on the previoussystematic literature review, a detailed EA modeling procedure is introduced that uses ArchiMate forgeneral use. (2) A detailed case study is carried out to show the modeling procedure. (3) Controlledexperiments are conducted with 24 subjects to verify the feasibility of the modeling procedure, and theexperimental results confirmed that it is feasible to use the introduced method to model system scenarios.Besides, the experimental results also show that a metamodel (systemigram) can be transformed to anArchiMate model based on the modeling procedure, and the EA model derived from the modelingprocedure is sufficient to restore the EA scenario. However, it should be mentioned that this EAvisualization approach may not be applicable to some novel EA modeling concepts, such as augmentedreality EA modeling, virtual reality EA modeling, and 3D EA modeling.

Acknowledgement: We would like to thank the Nagoya University students and Sumitomo ElectricIndustries software engineers for their cooperation.

Funding Statement: This work was supported by 2020 TSUBAME project of Tokyo Institute ofTechnology.

Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding thepresent study.

References[1] Z. Zhou, Q. Zhi, S. Morisaki and S. Yamamoto, “A systematic literature review on enterprise architecture

visualization methodologies,” IEEE ACCESS, vol. 8, pp. 96404–96427, 2020.

[2] The Open Group, The ArchiMate 3.1 Specification, 2019.

[3] D. Quartel, W. Engelsman, H. Jonkers and M. V. Sinderen, “A goal-oriented requirements modelling language forenterprise architecture,” in IEEE Int. Enterprise Distributed Object Computing Conf., Auckland, New Zealand,pp. 3–13, 2009.

[4] D. Quartel, M. Steen andM.M. Lankhorst, “Application and project portfolio valuation using enterprise architectureand business requirements modelling,” Enterprise Information Systems, vol. 6, no. 2, pp. 189–213, 2012.

[5] J. Mylopoulos and J. Castro, “Tropos: A framework for requirements-driven software development,” InformationSystems Engineering: State of the Art and Research Themes, 1st ed., Berlin, Germany, Springer-Verlag, pp. 261—273, 2000.

[6] A. Teka, N. Condri-Fernandez, I. Kurtev, D. Quartel and W. Engelsman, “Change impact analysis of indirect goalrelations: Comparison of NFR and TROPOS approaches based on industrial case study,” in IEEE Int. Workshopon Model-Driven Requirements Engineering, Chicago, pp. 58–67, 2012.

[7] A. K. Jallow, P. Demian, C. J. Anumba and A. N. Baldwin, “An enterprise architecture framework for electronicrequirements information management,” International Journal of Information Management, vol. 37, no. 5,pp. 455–472, 2017.

[8] M. Vicente, N. Gama and M. M. D. Silva, “Using ArchiMate to represent ITIL metamodel,” in IEEE Conf. onBusiness Informatics, Vienna, Austria, pp. 270–275, 2013.

[9] N. Siva, M. M. D. Silva, B. Barafort, M. Vicente and P. Sousa, “Using ArchiMate to model a process assessmentframework,” in Proc. of the 30th Annual ACM Symp. on Applied Computing, New York, pp. 1189–1194, 2015.

CSSE, 2022, vol.40, no.1 371

[10] G. Emmanuel, S. S. Kusumawardani and R. Ferdiana, “The requirements analysis of Elisa business architecturewith education enterprise architecture perspective,” in Int. Conf. on Science and Technology, Yogyakarta,Indonesia, pp. 1–6, 2018.

[11] V. Peristeras and K. Tarabanis, “Governance enterprise architecture (GEA): Domain models for e-governance,” inProceedings of Int. Conf. on Electronic Commerce, New York, pp. 471–479, 2004.

[12] S. Zhang, S. Yang and J. Song, “Research on collaborative IT governance model oriented to businessarchitecture,” in Proc. of IEEE Int. Conf. on Computer Supported Cooperative Work in Design, Whistler, BC,Canada, pp. 116–120, 2013.

[13] S. Buckl, A. M. Ernst, F. Matthes, R. Ramacher and C. M. Schweda, “Using enterprise architecture managementpatterns to complement TOGAF,” in IEEE Int. Enterprise Distributed Object Computing Conf., Auckland, NewZealand, pp. 34–41, 2009.

[14] F. AhlemannEric, E. Stettiner, M. Messerschmidt and C. Legner, Strategic enterprise architecture management.Berlin, Germany: Springer-Verlag, 2012.

[15] S. Hanschke, J. Ernsting and H. Kuchen, “Integrating agile software development and enterprise architecturemanagement,” in Hawaii Int. Conf. on System Sciences, HI, USA, pp. 4099–4108, 2015.

[16] M. Iacob, D. Quartel and H. Jonkers, “Capturing business strategy and value in enterprise architecture tosupport portfolio valuation,” in IEEE Int. Enterprise Distributed Object Computing Conf., Beijing, China,pp. 11–20, 2012.

[17] A. Luo, J. Fu and J. Liu, “An impact analysis method of business processes evolution in enterprise architecture,”in Int. Conf. on Progress in Informatics and Computing, Shanghai, China, pp. 733–737, 2016.

[18] K. Hinkelmann, A. Gerber, D. Karagiannis, B. Thoenssen, A. van der Merwe et al., “A new paradigm for thecontinuous alignment of business and IT: Combining enterprise architecture modelling and enterpriseontology,” Computers in Industry, vol. 79, pp. 77–86, 2016.

[19] P. Gomes, G. Cadete and M. M. D. Silva, “Using enterprise architecture to assist business continuity planning inlarge public organizations,” in IEEE Conf. on Business Informatics, Thessaloniki, Greece, pp. 70–78, 2017.

[20] A. Aldea, M. Iacob and D. Quartel, “From business strategy to enterprise architecture and back,” in IEEE Int.Enterprise Distributed Object Computing Workshop, Stockholm, Sweden, pp. 145–152, 2018.

[21] P. Bahl, R. Chandra, A. Greenberg, S. Kandula, D. A. Maltz et al., “Towards highly reliable enterprise networkservices via inference of multi-level dependencies,” in Proc. of the 2007 Conf. on Applications, Technologies,Architectures, and Protocols for Computer Communications, Kyoto, Japan, pp. 13–24, 2007.

[22] T. Sommestad, M. Ekstedt and P. Johnson, “Combining defense graphs and enterprise architecture modelsfor security analysis,” in Int. IEEE Enterprise Distributed Object Computing Conf., Munich, Germany,pp. 349–355, 2008.

[23] U. Franke, W. R. Flores and P. Johnson, “Enterprise architecture dependency analysis using fault treesand Bayesian networks,” in Proc. of the 2009 Spring Simulation Multiconference, San Diego, California,pp. 1–8, 2009.

[24] E. Zambon, S. Etalle, R. J. Wieringa and P. Hartel, “Model-based qualitative risk assessment for availability of ITinfrastructures,” Software & Systems Modeling, vol. 10, no. 4, pp. 553–580, 2011.

[25] M. Korman, T. Sommestad, J. Hallberg, J. Bengtsson and M. Ekstedt, “Overview of enterprise information needsin information security risk assessment,” in IEEE Int. Enterprise Distributed Object Computing Conf., Ulm,Germany, pp. 42–51, 2014.

[26] G. Biggs, T. Sakamoto and T. Kotoku, “A profile and tool for modelling safety information with designinformation in SysML,” Software & Systems Modeling, vol. 15, no. 1, pp. 147–178, 2016.

[27] E. Grandry, C. Feltus and E. Dubois, “Conceptual integration of enterprise architecture management and securityrisk management,” in IEEE Int. Enterprise Distributed Object Computing Conf. Workshops, Vancouver, BC,Canada, pp. 114–123, 2013.

[28] K. Gaaloul and H. A. Proper, “An access control model for organisational management in enterprise architecture,”in Int. Conf. on Semantics, Knowledge and Grids, Beijing, China, pp. 37–43, 2013.

372 CSSE, 2022, vol.40, no.1

[29] W. Abbass, A. Baina and M. Bellafkih, “Improvement of information system security risk management,” in IEEEInt. Colloquium on Information Science and Technology, Tangier, Morocco, pp. 182–187, 2016.

[30] N. Mayer and C. Feltus, “Evaluation of the risk and security overlay of Archimate to model information systemsecurity risks,” in IEEE Int. Enterprise Distributed Object Computing Workshop, Quebec City, QC, Canada, pp.106–116, 2017.

[31] N. Mayer, J. Aubert, E. Grandry, C. Feltus, E. Goettelmann et al., “An integrated conceptual model forinformation system security risk management supported by enterprise architecture management,” Software &Systems Modeling, vol. 18, no. 3, pp. 2285–2312, 2019.

[32] R. Lagerström, P. Johnson and D. Höök, “Architecture analysis of enterprise systems modifiability—models,analysis, and validation,” Journal of Systems and Software, vol. 83, no. 8, pp. 1387–1403, 2010.

[33] C. Becker, G. Antunes, J. Barateiro, R. Vieira and J. Borbinha, “Modeling digital preservation capabilities inenterprise architecture,” in Annual Int. Digital Government Research Conf.: Digital Government Innovation inChallenging Times, College Park, Maryland, USA, 2011.

[34] J. Lakhrouit and K. Baïna, “State of the art of the maturity models to an evaluation of the enterprise architecture,”in Int. Symp. ISKO-Maghreb, Marrakech, Morocco, pp. 1–8, 2013.

[35] G. Plataniotis, S. de Kinderen, D. van der Linden, D. Greefhorst and H. A. Proper, “An empirical evaluation ofdesign decision concepts in enterprise architecture,” in The Practice of Enterprise Modeling, Berlin, Heidelberg,pp. 24–38, 2013.

[36] H. Florez, M. Sánchez and J. Villalobos, “Extensible model-based approach for supporting automatic enterpriseanalysis,” in IEEE Int. Enterprise Distributed Object Computing Conf., Ulm, Germany, pp. 32–41, 2014.

[37] V. Borozanov, S. Hacks and N. Silva, “Using machine learning techniques for evaluating the similarity ofenterprise architecture models,” in Advanced Information Systems Engineering, Cham, pp. 563–578, 2019.

[38] J. S. Addicks and H.-J. Appelrath, “A method for application evaluations in context of enterprise architecture,” inProc. of ACM Symp. on Applied Computing, Sierre, Switzerland, pp. 131–136, 2010.

[39] H. Ahmadi, B. Farahani, F. S. Aliee and M. A. Motlagh, “Cross-layer enterprise architecture evaluation: Anapproach to improve the evaluation of TO-BE enterprise architecture,” in Proc. of the Int. Conf. on Omni-Layer Intelligent Systems, Crete, Greece, pp. 223–228, 2019.

[40] M. R. Majedi and K. A. Osman, “A novel architectural design model for enterprise systems: Evaluating enterpriseresourceplanning system and enterprise application integration against service oriented architecture,” in Int. Conf.on Pervasive Computing and Applications, Alexandria, Egypt, pp. 116–121, 2008.

[41] H. Chen, R. Kazman and O. Perry, “From software architecture analysis to service engineering: An empiricalstudy of methodology development for enterprise SOA implementation,” IEEE Transactions on ServicesComputing, vol. 3, no. 2, pp. 145–160, 2010.

[42] G. Antunes, J. Barateiro, C. Becker, J. Borbinha and R. Vieira, “Modeling contextual concerns in enterprisearchitecture,” in IEEE Int. Enterprise Distributed Object Computing Conf/. Workshops, Hong Kong, China,pp. 3–10, 2011.

[43] A. Šaša and M. Krisper, “Enterprise architecture patterns for business process support analysis,” Journal ofSystems and Software, vol. 84, no. 9, pp. 1480–1506, 2011.

[44] B. Fritscher and Y. Pigneur, “Business IT alignment from business model to enterprise architecture,” in AdvancedInformation Systems Engineering Workshops, Berlin, Heidelberg, pp. 4–15, 2011.

[45] V. Agievich, V. Taratukhin, J. Becker and R. Gimranov, “A new approach for collaborative enterprise architecturedevelopment,” in Int. Forum on Strategic Technology, Tomsk, Russia, pp. 1–5, 2012.

[46] M. E. Iacob, L. O. Meertens, H. Jonkers, D. A. C. Quartel, L. J. M. Nieuwenhuis et al., “From enterprisearchitecture to business models and back,” Software & Systems Modeling, vol. 13, no. 3, pp. 1059–1083, 2014.

[47] P. Loucopoulos, C. Stratigaki, M. H. Danesh, G. Bravos, D. Anagnostopoulos et al., “Enterprise capabilitymodeling: Concepts, method, and application,” in Int. Conf. on Enterprise Systems, Basel, Switzerland,pp. 66–77, 2015.

CSSE, 2022, vol.40, no.1 373

[48] T. Bucher, R. Fischer, S. Kurpjuweit and R. Winter, “Analysis and application scenarios of enterprise architecture:An exploratory study,” in IEEE Int. Enterprise Distributed Object Computing Conf. Workshops, Hong Kong,China, pp. 28, 2006.

[49] S. H. Spewak, S. C. Hill and J. A. Zachman, Enterprise architecture planning: Developing a blueprint for data,applications, and technology, 2nd. edition, A Wiley-QED Publication, NY, USA, 1993.

[50] ISO/IEC/IEEE 15026-1:2019: Systems and software engineering—systems and software assurance. Geneva,Switzerland: International Organization for Standardization, 2019.

[51] S. Yamamoto, “Assuring security through attribute GSN,” in Int. Conf. on IT Convergence and Security, KualaLumpur, Malaysia, pp. 1–5, 2015.

[52] Z. Zhou, Q. Zhi, S. Morisaki and S. Yamamoto, “An evaluation of quantitative non-functional requirementsassurance using archiMate,” IEEE Access, vol. 8, pp. 72395–72410, 2020.

[53] Q. Zhi, Z. Zhou and S. Morisaki, “A composite safety assurance method for developing system architectureusing model checking,” International Journal of Systems and Software Security and Protection, vol. 12, no. 1,pp. 78–93, 2021.

[54] C. Xia, Q. Zhi, Z. Zhou and S. Yamamoto, “An approach to transform enterprise architecture modelsfrom systemigrams,” in IEEE Int. Conf. on Software Engineering and Service Science, Beijing, China,pp. 571–574, 2019.

[55] I. Sommerville, Software engineering, 10th edition. . London, UK: Pearson, 2015.

374 CSSE, 2022, vol.40, no.1