Agile Enterprise Architecture by Leveraging Use Cases

Hong Guo

1,2 a

, Jingyue Li

, Shang Gao

and Darja Smite

School of Business, Anhui University, No. 111 Jiulong Road, Hefei, People's Republic of China

Department of Computer Science, Norwegian University of Science and Technology, Trondheim, Norway

School of Business, Örebro University, Örebro, Sweden

Department of Software Engineering, Blekinge Institute of Technology, Karlskrona, Sweden

Keywords: Enterprise Architecture, Use Case, Enterprise Architecture Management, Agile.

Abstract: Despite benefits Enterprise Architecture (EA) has brought, EA has also been challenged due to its complexity,

heavy workload demands, and poor user acceptance. Researchers and practitioners proposed to use EA in an

agile and "business outcome-driven" way. This means that EA should not primarily be developed and used

according to a pre-defined framework. Instead, EA should be developed and used for specific business

purposes and by means of concrete deliverables. By doing so, a more effective and efficient way of EA

application could be enabled. However, there is no common agreement on what types of business goals can

be expected to be achieved by using EA (The What) and how to achieve these goals through EA solutions

(The How). To address these issues, we analysed the information provided by leading EA tool vendors

available on their websites to get inspiration. The results showed that Use Cases (UCs) are used generally to

motivate potential EA users by focusing on specific business issues. Then, EA solutions to address such

business requirements or challenges are scoped and derived accordingly. We expect relevant findings could

bring inspiration to agile EA engineering, change the EA “heavy-weight” reputation, and improve the

application of EA even among its sceptics.

1 INTRODUCTION

Although Enterprise Architecture (EA) has brought

many kinds of benefits, EA was also challenged due

to its complexity, heavy workload demand, and poor

user acceptance (Guo, Li, and Gao 2019). There is a

trend to use EA in a more agile way (Gampfer et al.

2018), such as business outcome-driven EA (Gartner

Research 2017). This means that EA should not first

be developed and used according to a pre-defined

framework. Instead, EA should be developed and

used for specific business purposes and by means of

concrete deliverables (artifacts) in a more effective

and efficient manner. However, there is no consensus

on what types of business goals can be expected to be

achieved by using EA (The What) and how to achieve

these goals through EA solutions (The How).

This research proposes that Use Cases (UCs)

could be leveraged as an effective medium to bridge

https://orcid.org/0000-0003-3608-0981

https://orcid.org/0000-0002-7958-391X

https://orcid.org/0000-0002-3722-6797

https://orcid.org/0000-0003-1744-3118

business expectations and EA deliverables.

Traditionally in software engineering or system

engineering, UCs are used to get requirements by

analysing the interaction between users and systems.

In the EA domain, we assume it could be leveraged

for a similar purpose: to address business

issues/requirements and to derive EA solutions.

Interestingly, leveraging UCs to facilitate the

agile way of applying EA is hardly reported in the

academic literature, while being advocated by many

leading EA tool vendors in the industry. In this

research, we analyse how these EA tools use UCs. We

reviewed and analysed relevant content about 3

different UCs covered by 6 leading EA tool vendors

on their websites. The remaining sections of this

article are organized as follows. Section 2 briefly

introduces some background information. Section 3

introduces the research method. Then in Section 4, we

present the results. We discuss the results in Section

5 and conclude the paper in Section 6.

Guo, H., Li, J., Gao, S. and Smite, D.

Agile Enterprise Architecture by Leveraging Use Cases.

DOI: 10.5220/0010534705010509

In Proceedings of the 16th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2021), pages 501-509

ISBN: 978-989-758-508-1

501

2 BACKGROUND

2.1 Enterprise Architecture

EA is often referred to as a blueprint for enterprise

composition and enterprise operating systems. Despite

many kinds of benefits EA might bring (Winter et al.

2010), one main role of EA is to provide the service of

understanding and communicating enterprise

interaction patterns through abstract and graphical

expressions and to facilitate the alignment of business

and information systems (Korhonen et al. 2016).

EA usually exists in the form of a set of abstract

graphics. They cover the high-level content of the

enterprise, across areas such as strategy, business,

information, and technology. We call these

abstractions EA artefacts, EA documents (usually

in more textual form), or EA models (usually in

graphical form).

Despite benefits brought by EA, applying EA in

practicing is also facing challenges (Hinkelmann et

al. 2016). One major challenge is its complexity.

Traditional approaches of EA Management (EAM)

follow formal processes and are separated from other

projects. It follows pre-defined frameworks and

pursues rigid and extensive upfront planning

(Kotusev, Singh, and Storey 2015). This might bring

a heavy workload. As changes are happening more

and more rapidly nowadays, such prescribed and

proactive ways of using EA (Kotusev, Singh, and

Storey 2015) could not meet the flexibility

requirement well.

To address such issues, relevant theories were

investigated, and agile EA practices were proposed

in academia and industry. Complexity Theories were

used (Gampfer et al. 2018). Systems Approaches

(Reynolds and Holwell 2010) were also applied

(Nurmi et al. 2018). For instance, according to Soft

System Theory (Platt and Warwick 1995), for

unstructured problem situations, a lens can be utilized

to narrow and focus perspective so that the problem

can be focused and structured further.

More agile approaches of EAM (Kotusev, Singh,

and Storey 2015) were proposed, such as MIT (Ross,

Weill, and Robertson 2006) and DYA (Wagter et al.

2005). Compared with more traditional EAM

approaches, they follow informal or no specific

process, develop and use EA when needed (business

changes severely, for instance) (Kotusev, Singh, and

Storey 2015). DYA also advocates “just enough, just

in time” architecture and does not design EA until

there is a need for it. In the industry, Gartner also

proposed Business Outcome Driven EA (Gartner

Research 2017).

Such efforts conform to the agile framework

Dynamic System Development Method (DSDM)

also, which believes the philosophy “that any project

must be aligned to clearly defined strategic goals and

focus upon early delivery of real benefits to the

business” (Agile Business Consortium Limited

2021). And among the eight principles of it, the first

is “Focus on the business need” (Agile Business

Consortium Limited 2021).

2.2 Use Cases

Use cases (UC) originate as a method for capturing

the user interaction with a piece of software or the

system under development in the field of user-centred

software and system engineering. The main idea

behind this concept is to obtain requirements by

analysing user scenarios and guide subsequent

software or system development. UCs are a simple,

straightforward, and very powerful way to express the

functional requirements/behaviour of a system. UCs

have gained wide acceptance as they make

requirements less ambiguous by specifying when and

under what conditions certain behaviours occur

(Bittner and Spence 2003) and help to manage

complexity, since they focus on one specific usage

aspect at a time (Lee and Xue 1999). As a result, those

who effectively employ UCs to model their systems

are said to deliver projects on time, within budget, and

with fewer defects (Bittner and Spence 2003).

2.3 Use Cases in (Agile) EA Practices

Traditional EA applications are increasingly facing

the challenges of complexity and difficulty in

adapting to various changes. To address these two

challenges, scholars investigated complexity and

systems theories to propose more lightweight EA

approaches adaptable to dynamic environments. But

there is no widely agreed method to implement them

or sufficient practical validation yet. Relevant

research gaps here include the types of business

issues that could potentially be solved/facilitated by

EA solutions (The What), and how to solve these

business issues through a lightweight EA (The How).

To address these gaps, we suggest exploring UCs

as a potential solution to define business goals and

derive EA solutions. UCs can be used to define

business problems accurately. Basing on the analysis

of UC definitions, an EA solution (a process with a

set of EA artifacts) could be derived. In industry, this

approach of using UCs has been used by several

leading EA management tools to promote how these

tools can help potential users solve specific and

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

502

important business problems and to show what the

solutions and EA artifacts to solve these problems are

like, with predictable and some kind of predictable

workload. But in academia, this method has not been

formally raised yet. Some researchers investigated the

possibilities to use EA together with use cases

(Miranda et al. 2018), but differently from us.

Therefore, this study observes how UCs are

leveraged by industrial leading EA tools, aiming to

answer two Research Questions (RQs) as below. Here

we assume if an EA solution implies a clear process

consisting of limited steps, and for each step of the

process, the workload is predictable, then the overall

workload is predictable.

• RQ1: Can UCs be used to clearly define business

issues that can potentially be solved by EA?

• RQ2: Can EA solutions with predictable

workloads be derived/outlined to solve business

issues that are defined with UCs?

3 METHOD

In this research, we analyse how leading EA tools

leverage UCs to address business issues and derive

EA solutions. To achieve this goal, we selected

relevant content about three UCs from websites of six

EA tools. As such, our analysis qualifies as a review

of grey data sources. Grey literature and sources,

such as commercial tools and tool vendors’ entries,

webinars, and guidelines, have been empirically

found to provide substantial benefits in certain areas

of research, especially when the evidence they bring

is experience- or opinion-based, i.e., outlying the

state-of-the-practice (Garousi, Felderer, and Mäntylä

2016). We used content synthesis (Cruzes and Dyba

2011) to extract and synthesize the results. In the

following, we explain our strategy of choosing UCs

and vendors, extracting relevant content, and the

synthesis process.

We investigated how UCs are used by leading EA

tools. Tools are both instrumental and very important

in the EA discipline (Korhonen et al.). Features of

such tools were investigated in other scientific papers

such as (Nowakowski, Häusler, and Breu 2018). But

to the best of our knowledge, there is no

comprehensive study about how they utilize UCs in

particular. The vendors were selected from the

vendor list in Gartner’s (Forbes Media LLC. 2021)

annual report named “Gartner Magic Quadrant for

Enterprise Architecture Tools” (Gartner 2020), where

long-established manufacturers, as well as insightful

new challengers, are included. We believe the fact

about how they are applying EA represents the

current trend of first-line EA applications. Some other

scientific papers also use the report for evaluating EA

tools (Nowakowski, Häusler, and Breu 2018).

Among the 16 vendors, we chose 6 vendors to be

included in our study. The reasons for the selection

are: First, the included vendors should use the term

“use case” explicitly. Some vendors use other

relevant terms, such as “solutions” or “features,”

which turn out to be more diverse and have mixed

irrelated information. Second, UCs should be used to

describe external use scenarios encountered by

potential EA users. Some vendors use the term

referring to more internal requirements, such as

generating EA documents according to some notable

EA frameworks. Such scenarios are not in the present

research scope. Third, there should be sufficient

description (relevant texts or figures) explaining how

these UCs are implemented. In this way, we could

extract information of interests and answer the

research questions. As a result, the six vendors we

included in this study are Avolution, Mega, Ardoq,

Orbus, LeanIX, ValueBlue (See Table 1 for more

detailed information).

The six vendors present many UCs. We selected

3 UCs for detailed analysis. The main selection

criterion is that at least two out of the six vendors

should support such UCs in a comparatively similar

way. This is to avoid analysing niche UCs that are

named from different perspectives and at a different

abstraction level due to the nature of grey literature so

that it is difficult for us to further extract and

synthesize information. The three chosen UCs are

Application Portfolio Management (APM), Data

Privacy Compliance (DPC) (Rozehnal and Novák

2018), and Strategy Planning (SP). These UCs can be

thought as to address typical challenges in different

phases of digital transformation (Capgemini

Consulting and the MIT Center for Digital Business

2011). They are also related to the three typical parts

of EA according to the notable TOGAF framework:

application, data, strategy (The Open Group 2020).

Thus, we think these three UCs are representative of

EA usage scenarios.

To extract data, we focus on three types of

information for each UC for each tool: 1) textual

description about the UC definition or usage

scenarios, 2) textual description about the UC

implementation, including process, sample EA

artifacts and visual representations, 3) figures about

the UC implementation. We used textual information

and figures in a complementary way. This is because,

on the one hand, textual information might not

include some implementation details, such as EA data

used, which might be derived according to sample

Agile Enterprise Architecture by Leveraging Use Cases

503

Table 1: Reviewed EA Tool Vendors and The Websites.

Vendor Tool Website

Avolution Abakus https://www.avolutio

nsoftware.com/

Mega

International

HOPEX Platform https://www.mega.co

m/en/

Ardoq AS. Ardoq https://www.ardoq.co

Orbus

Software

Orbus https://www.orbussof

tware.com/

LeanIX LeanIX Enterprise

Architecture Suite

https://www.leanix.ne

t/en/

ValueBlue BlueDolphin https://valueblue.com/

figures. On the other hand, sample figures with low

resolution might look blur sometimes. The textual

content could help us to identify and extract important

information.

For the extracted data, we analysed the

commonalities and differences in UC definitions and

implementations. For the definitions, we manually

compared the keywords in relevant sentences. For the

implementations, we identified the process

statements or figures and coded the steps for each

process. Then we compared the steps to identify

commonalities. The results of our analysis are

presented in the form of comparison tables. We then

summarize the results in Table 3, 5, 7 to answer our

RQ1 and Table 4, 6, 8 to answer the RQ2.

4 RESULTS

The three UCs are supported by different vendors. In

Table 2, for each UCs, we listed if they are supported

by each vendor and the total number of supported

vendors (last column). More detailed information for

each UC is introduced in the following sub-sections.

Table 2: UCs Supported by Different Vendors.

Avolution Mega Ardoq Orbus LeanIX Value

Blue

Tot.

UC1

Y Y Y Y Y Y 6

UC2

Y Y N N N N 2

UC3

Y Y Y Y N Y 5

4.1 UC1: Project Portfolio

Management (PPM)

According to Ardoq, PPM is thought to be “The

foundation for digital transformation in your

organization”. Six vendors have similar definitions

for this UC, which mainly refers to decisions about

whether and to what extend to invest in applications,

technologies, or more general projects based on how

they support strategic business needs. Among the six

vendors, four address “application” while the other

two address “IT” or “project/IT”. as described by

Avolution: “Project Management Office (PMO)

practitioners must consider both legacy applications

and infrastructure and new technologies including

mobile, cloud, IoT and big data.” Four vendors

propose “portfolio management” while the other two

propose “rationalization”.

Due to the comparatively clear and limited scope

of this UC, the implementation proposed by six

vendors are also similar and could be regarded as a 4-

step process. The first step is to make some

preparations, such as setting more specific goals. The

second step is to integrate relevant data required for

achieving the goals. Then, the third step is to analyse

the data for relevant purposes, such as gaining insight

about indicators regarding the goals. And the fourth

step is to benefit from the results by means of various

activities such as visualizing and facilitating

communication, enabling planning, and answering

questions.

Table 3: UC1-Project Portfolio Management (PPM).

UC1 Name UC1 Description

Avolution

Project/IT Portfolio

Management

“Managers can take control of their inventory and move quickly to rationalize and

plan portfolios. They can also calculate how technical investments map over to

the company’s business strategy.”

Mega

IT Rationalization “IT rationalization is the process by which an organization identifies and assesses

the value of business applications to determine which ones to keep, update, or

eliminate.”

Ardoq

Application Portfolio

Management

“Get application overview” “oversee application owners”, “control application

investment”, “run cost savings”, “manage business risk.”

Orbus

Application

Rationalization

“The number, nature and cost of applications should all be focused around the

business value they offer.”

LeanIX

Application Portfolio

Management

“Ensure application support for your business capabilities.”

Value

Blue

Application Portfolio

Management

“Identify the applications that support your business functions — eliminate

overlap and decrease complexity.”

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

504

Table 4: A 4-Step Process to Implement UC1.

Avo Mega Ardoq Orbus LeanIX ValueBlue

1 Prepare

Buy in from business

Goals

Show output

2 Integrate Data

Integrate data

Inventory

Data Data

Import Map data

Build portfolio

inventory

Add in a reference

model

Build on

data

Validate with

stakeholders

Assess data

More data to answer

business

3 Analyse Data

Analyse

Rank Analyse Analyse

Application

supports

business

capabilities

Determine

Align with

business

Benefit from the

results (visualize,

communicate,

plan, answer, act)

Present and

recommend

Plan

Communicate Visualize

Answer APM

questions

Goal and

rationalization

Plan and track

execution

Review and

present

Table 5: UC2-Data Privacy Compliance (DPC).

UC2 Name UC2 Description

Avolution

Data Privacy

and Control/

GDPR

Compliance

“Gain visibility of, and be proactive about data flows and data-management”, “provide

up-to-date and end-to-end information about data flows and storage of personal

information across departments, processes, and systems”, “understand who holds

decision rights and accountabilities how that information can be used.”

Mega

GDPR

Compliance

“To comply with the EU’s General Data Protection Regulation (GDPR), companies

must rethink the way they capture, manage and process personal data”, “have a

comprehensive understanding of their compliance level and to efficiently produce

regulatory documentation.”

To summarize, this UC addresses a comparatively

simple, specific, and prevalent business need.

Vendors share commonalities when defining the case

and designing reference EA solutions. Some exempts

from the vendors’ websites regarding the use case

definition are presented in Table 3. The

implementation process used in reference solutions is

summarized and normalized in Table 4.

4.2 UC2: Data Privacy Compliance

(DPC)

Two vendors explicitly support the UC of DPC,

which is about governing data and demonstrating

compliance with local and international laws and

regulations. As described in Avolution, “Global CIOs

and their teams need to think holistically about data

governance. Building trust and demonstrating

compliance with local and international laws and

regulations is becoming a key part of strong

enterprise architecture”.

The implementation looks similar and can also be

looked at as a four-step process. However, the overall

scope of relevant data is more diverse in types and

tangled than that in PPM. This will probably bring

much more overall workload than that of PPM.

To summarize, although the business issue

involved in the DPC case is clear and prevalent, the

implementation is much more complicated and

potentially involves a much heavier workload than

that of PPM. Only two vendors explicitly support it.

Despite the similar UC definitions, reference

solutions exhibit differences in terms of the overall

process and EA artifacts involved. Exempts about the

definition of this UC are presented in Table 5. And

the implementation process could be seen in Table 6.

Agile Enterprise Architecture by Leveraging Use Cases

505

Table 6: A 4-Step Process to Implement UC2.

Avolution Mega

1 Prepare

Audit information Build company organigram and roles & responsibilities

2 Integrate Data

Model interdependencies and data

flows

Document the Record of processing activities

3 Analyse Data

Prioritize data by risk and value Identify compliance gaps & reduce existing risks

Discover Shadow IT

4 Benefit

Report Implement remediation actions

Roadmaps for strong compliance

and innovation

Table 7: UC 3-Strategic Planning (SP).

UC3 Name UC3 Description

Avolution

Roadmapping

change

“Color or ‘heatmap’ your business capability maps or technology landscapes to

show WHAT is changing.”

Mega

IT Strategic

Planning

“Based on an initial assessment of the IT landscape, and a thorough understanding of

the business strategy, IT departments can create an IT roadmap that best supports

business initiatives.”

Ardoq

Strategic Planning

and Execution

“Connect your Strategic Objectives to your Project Portfolio or Capability Map to

identify your ability to execute.”

Orbus

Application and

Technology

Roadmapping

“Roadmaps communicate and influence change, earning buy-in from key

stakeholders and providing a plan of action to achieve particular goals, or in this

case, implement new applications and technology solutions.”

Value

Blue

Agile Business

Transformation

“Enables CIOs and Enterprise Architects to plan and manage their business

transformation, combining architectural insights with operational agility,” “structure

these improvements so that we can reduce the risks, improve the effectiveness and

enhance the efficiency of the transformation process.”

Table 8: A 5-Step Process to Implement UC3.

Avolution Mega Ardoq Orbus ValueBlue

1 Prepare

Inputs

Establish goals Strategy

2 Integrate Data

(current state)

Business

capabilities

Identify technical

components

Capabilities

Current state

3 Plan

(future state)

Colour business

capabilities

Create IT

roadmap

Objectives Determine the

target state

New

capabilities

(Propose change

initiatives)

Future state

4 Analyse Data (the

Gap between

current and

future states)

(Analyse

dependencies)

Define new IT

architecture

Impact analysis Execution Gap analysis

(Feasibility and

reachability

analysis)

Build a

portfolio of

projects

Projects

5 Benefit

Continuously

adjust

roadmap

Ensure portfolio

level alignment

Iterate

Business

outcomes

4.3 UC3: Strategic Planning (SP)

The SP use case is widely mentioned which is

proposed to address the complexity issue when

organizations plan strategic (digital) transformation.

SP usually consists of strategic planning, roadmapping

and execution which involves management of

applications, information technologies (IT) or more

general technologies. Due to different perspectives on

this UC, vendors define it with different names. See

Table 7 for more details.

The implementation of SP in general consists of

five steps as summarized in Table 8. Different with

PPM and DPC use cases, one extra step of “plan”

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

506

appears between “Integrate Data” and “Analyse

Data”. This is because SP not only integrates existing

data (“as is” or “current state” data), but also creates

new data (“to be” or “future state” data). Although the

data analysis (“gap analysis”) work sounds simple

which focuses on comparing the gap between two

states, the actual work might be very complex and

time-consuming. This is because “states” might imply

all aspects of an organization that can be involved at

different levels and tangled. Therefore, one vendor,

namely Avolution, proposes both a fundamental

solution which consists of two steps and other

optional steps (presented in brackets in Table 8),

which could be included in a more comprehensive

solution. In addition, this process can be executed in

an iterative way as maintenance is needed. This is

partly indicated by ValueBlue and Mega. See italics

in Table 8 for details.

To summarize, the roadmap UC has been widely

provided due to the trends of global digital

transformation. Five vendors explicitly support it.

The general solution to this UC is to design and

execute projects that are identified based on a gap

analysis that stems from a strategy evaluation.

Compared with PPM and DPC, SP might indicate a

much more complicated and time-consuming

process. This also might indicate coupling relations

between SP and other UCs such as PPM and DPC.

However, there is space for users to choose the

appropriate level of implementation according to

different vendors’ provision.

5 DISCUSSION

5.1 Feasibility (Answering the RQs)

Our RQs were proposed to address if UCs could be

used to clearly characterize relevant business issues

(RQ1) and to derive EA solutions with predictable

workload (RQ2). In general, we tend to say yes to

RQ1 and RQ2. As presented in Section 4, for all three

UCs, the four vendors presented clear descriptions of

business issues/requirements. Based on the

requirements, specific EA solutions with predicable

workload were also proposed. This means that a

process with limited steps was proposed. And for

each step, the tasks are clear and involves a

predictable workload.

5.2 Commonality

According to our analysis, we noticed that some

common UCs exist which address similar business

issues. For example, all the vendors we surveyed

support PPM. In contrast, other UCs such as

Technical Debt (supported by Avolution) are less

standardized and supported by fewer vendors.

Therefore, vendors encourage novice users to start

with simple and general UCs like PPM and try more

advanced, less standardized, and more customized

UCs like SP.

Regarding the EA solutions proposed, there seems

to be some common overall process (four or five steps

as presented in Table 4, 6, 8).

By establishing such connections between

business issues and EA solutions, users could be more

aware of the available options to use EA in a business

outcome-driven way (Gartner Research 2017). As

advocated by Ardoq, “Each of Ardoq's use case

modules comes with a pre-configured setup with

everything you need to get started and the flexibility

to expand on this effortlessly in-app.”

5.3 Diversity

Despite the commonalities of UCs that involve

common business issues and/or common processes to

solve them, we also noticed the space of diversity.

Vendors propose diverse UCs. Detailed definitions,

perspectives, and requirements for one similar UC

might also differ. Even for the simplest UC such as

PPM, core deliverables proposed, data to capture,

algorithms used to analyse, and the

presentation/visualization methods might differ.

To summarize, diversity might exist at four below

levels.

• Use case. There are different use cases. Detailed

perspective for one similar use case might differ.

For example, Mega focuses on IT roadmap

instead of general roadmaps, which Avolution

and Ardoq prefer. While Orbus focuses on

applications and technologies roadmap. In

addition, some use cases might include other

Use cases. For instance, SP often includes PPM.

• EA Implementation process. Vendors suggest

implementation processes of different

complexity or granularity for one UC. In

addition, one vendor might provide such

different options for one UC for their users to

choose. An example is Avolution, which

provides four types of SP solutions.

• EA Deliverables. Core deliverables involved in

EA implementation might be different.

Auxiliary artifacts are of the same. For SP, the

five vendors proposed quite different artifacts

when capturing and analysing data.

Agile Enterprise Architecture by Leveraging Use Cases

507

• EA Visualization. For instance, although all

vendors use a similar EA deliverable for one

simple UC PPM where the technical fit and

business fit of applications are evaluated,

vendors choose different ways to visualize it.

5.4 Related Works

There are a few studies that are also related to

analysing usage scenarios or use cases and tools in the

EA field. However, they are not addressing similar

RQs and have employed different methods.

In (Niemi and Pekkola 2017), 15 scenarios to use

EA were identified. However, some of them are

characterising how EA was used internally. Different

from this study, we observe UCs for business goals as

this is the key of agile EA. In (Nowakowski, Häusler,

and Breu 2018), seven EA tools were surveyed about

how they support eight capabilities including analysis

of scenarios and planning of scenarios. But the aim of

the research is to analyse how these tools support

industry 4.0 transformation planning, instead of

general use case utilization. (Miranda et al. 2018) also

discussed about the relation between EA and UC.

However, their proposal is that EA artifacts can be

useful to construct UCs for software development.

6 CONCLUSIONS

In this paper, we observe how 3 UCs are leveraged by

6 leading EA tools. The results showed that it is

possible to use UC as an approach to define business

expectations/issues on one hand and to derive EA

solutions on the other hand. We found that there exist

some common UCs and a common process to derive

EA solutions for UCs. But there is still space for

diversities where different UC details, EA artifacts

and visualizations could apply. The limitation of the

present research is that the observation is not very

systematic (although representative). For instance,

we have only investigated vendors that Gartner

recommends. We plan to review relevant content in a

more systematic way and validate the result in the

future.

ACKNOWLEDGEMENTS

This research is financially supported by The European

Research Consortium for Informatics and Mathematics

(ERCIM) (https://www.ercim.eu/). This work has been

partially supported by NFR 295920 IDUN.

REFERENCE

Agile Business Consortium Limited. 2021. 'What is DSDM'.

https://www.agilebusiness.org/page/whatisdsdm.

Bittner, Kurt, and Ian Spence. 2003. Use case modeling

(Addison-Wesley Professional).

Capgemini Consulting and the MIT Center for Digital

Business. 2011. 'Digital Transformation: A Road-Map

for Billion-Dollar Organizations'. https://www.

capgemini.com/resources/digital-transformation-a-

roadmap-for-billiondollar-organizations/.

Cruzes, Daniela S, and Tore Dyba. 2011. "Recommended

steps for thematic synthesis in software engineering."

In 2011 international symposium on empirical software

engineering and measurement, 275-84. IEEE.

Forbes Media LLC. 2021. 'Gartner (IT)'.

https://www.forbes.com/companies/gartner/.

Gampfer, Fabian, Andreas Jürgens, Markus Müller, and

Rüdiger Buchkremer. 2018. 'Past, current and future

trends in enterprise architecture—A view beyond the

horizon', Computers in Industry, 100: 70-84.

Garousi, Vahid, Michael Felderer, and Mika V Mäntylä.

2016. "The need for multivocal literature reviews in

software engineering: complementing systematic

literature reviews with grey literature." In Proceedings

of the 20th international conference on evaluation and

assessment in software engineering, 1-6.

Gartner. 2020. 'Gartner Magic Quadrant for Enterprise

Architecture Tools'. https://www.gartner.com/en/

documents/3970555/magic-quadrant-for-enterprise-

architecture-tools.

Gartner Research. 2017. 'Stage Planning a Business-

Outcome-Driven Enterprise Architecture'. https://www.

gartner.com/en/documents/3642517/stage-planning-a-

business-outcome-driven-enterprise-arch.

Guo, Hong, Jingyue Li, and Shang Gao. 2019.

"Understanding challenges of applying enterprise

architecture in public sectors: A technology acceptance

perspective." In 2019 IEEE 23rd International

Enterprise Distributed Object Computing Workshop

(EDOCW), 38-43. IEEE.

Hinkelmann, Knut, Aurona Gerber, Dimitris Karagiannis,

Barbara Thoenssen, Alta Van der Merwe, and Robert

Woitsch. 2016. 'A new paradigm for the continuous

alignment of business and IT: Combining enterprise

architecture modelling and enterprise ontology',

Computers in Industry, 79: 77-86.

Korhonen, Janne J, James Lapalme, Doug McDavid, and

Asif Q Gill. 2016. "Adaptive enterprise architecture for

the future: Towards a reconceptualization of EA." In

2016 IEEE 18th Conference on Business Informatics

(CBI), 272-81. IEEE.

Kotusev, Svyatoslav, Mohini Singh, and Ian Storey. 2015.

"Consolidating enterprise architecture management

research." In 2015 48th Hawaii International

Conference on System Sciences, 4069-78. IEEE.

Lee, Jonathan, and Nien-Lin Xue. 1999. 'Analyzing user

requirements by use cases: A goal-driven approach',

IEEE software, 16: 92-101.

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

508

Miranda, Gabriel M, César H Bernabé, Lucas A Santos, and

Monalessa P Barcellos. 2018. "Where enterprise

architecture and early software engineering meet: An

approach to use cases definition." In Proceedings of the

17th Brazilian Symposium on Software Quality, 240-49.

Niemi, Eetu, and Samuli Pekkola. 2017. 'Using enterprise

architecture artefacts in an organisation', Enterprise

Information Systems, 11: 313-38.

Nowakowski, Emmanuel, Martin Häusler, and Ruth Breu.

2018. "Analysis of Enterprise Architecture Tool

Support for Industry 4.0 Transformation Planning." In

2018 IEEE 22nd International Enterprise Distributed

Object Computing Workshop (EDOCW), 184-91. IEEE.

Nurmi, Jarkko, Mirja Pulkkinen, Ville Seppänen, and Katja

Penttinen. 2018. "Systems Approaches in the enterprise

architecture field of research: a systematic literature

review." In Enterprise Engineering Working

Conference, 18-38. Springer.

Platt, A, and S Warwick. 1995. 'Review of soft systems

methodology', Industrial Management & Data Systems.

Reynolds, Martin, and Sue Holwell. 2010. Systems

approaches to managing change: a practical guide

(Springer).

Ross, Jeanne W, Peter Weill, and David Robertson. 2006.

Enterprise architecture as strategy: Creating a

foundation for business execution (Harvard business

press).

Rozehnal, Petr, and Vítězslav Novák. 2018. 'The Core of

Enterprise Architecture as a Management Tool: GDPR

Implementation Case Study', 26th Interdisciplinary

Information Management Talks: 359-66.

The Open Group. 2020. "The TOGAF® Standard."

Wagter, Roel, Martin Van Den Berg, Joost Luijpers, and

Marlies Van Steenbergen. 2005. Dynamic enterprise

architecture: how to make it work (John Wiley & Sons).

Winter, Katharina, Sabine Buckl, Florian Matthes, and

Christian M Schweda. 2010. 'Investigating the State-of-

the-Art in Enterprise Architecture Management

Methods in literature and Practice', MCIS, 90.

Agile Enterprise Architecture by Leveraging Use Cases

509