An Agile Approach for Modeling Enterprise Architectures

Petr

onio Medeiros

1 a

, Alixandre Santana

2 b

, Myllena Lima

1 c

, Hermano Moura

1 d

and

Miguel Mira da Silva

3 e

Center for Informatics, Universidade Federal de Pernambuco, Recife, PE, Brazil

Federal University of Agreste de Pernambuco, Garanhuns, PE, Brazil

Instituto Superior T

ecnico, Universidade de Lisboa, Portugal

Keywords:

Enterprise Architecture, Agile, Modeling.

Abstract:

Organizations need a holistic view of their information assets in order to lead a digital transformation. Infor-

mation assets can be obtained from modeling the Enterprise Architecture (EA) of the organization. However,

the current EA modeling methods have been criticized for being heavy and rigid. In fact, EA modeling meth-

ods present similar problems to those faced by traditional software development (waterfall) methods. We

propose that EA modeling could beneﬁt from ideas presented in the Agile Manifesto. Previous research al-

ready pointed out the importance of ﬁnding the ”ideal” boundaries for the intersection between agile software

development methods and EA practices. In this paper, we apply the Design Science Research Methodology

(DSRM) to propose an Agile Enterprise Architecture Modeling Method based on agile principles and values.

The proposal was demonstrated in two organizations, from which we extracted evidence such as continuous

deliveries, short interactions (Sprints), proximity to customers, and systematic improvements in the process.

We conclude that our proposal can improve EA modeling.

1 INTRODUCTION

One of the biggest challenges faced by Informa-

tion Technology (IT) managers is to ensure that the

technologies used by the organizations are perfectly

aligned with the business objectives and the satisfac-

tion of their customers (Ferreira et al., 2017). In this

context, the concept of Enterprise Architecture (EA)

has gained importance, being established as a funda-

mental element for the management of information

assets of organizations (Hosiaisluoma et al., 2018).

EA methods use many artifacts to represent the in-

formation assets of one organization. They are holis-

tic and can be represented from different perspectives

or layers, with different (although similar) nomencla-

tures, which range from the strategy level to the in-

frastructure one (Ahlemann et al., 2012). The Open

Group, for example, presents an EA modeled in four

layers: business, applications, data, and technology

https://orcid.org/0000-0001-7270-0004

https://orcid.org/0000-0003-1910-3360

https://orcid.org/0000-0002-0562-8409

https://orcid.org/0000-0001-5992-2171

https://orcid.org/0000-0002-0489-4465

(Group, 2018). It is not difﬁcult to imagine that, de-

pending on the size of the organization, modeling an

EA can be laborious and quite challenging.

More recently, EA methods have been criticized

for being heavy and rigid (Hosiaisluoma et al., 2018;

Kotusev, 2018; Gill, 2015; Hauder et al., 2014). The

most popular EA framework, the Open Group Archi-

tecture Framework (TOGAF), for example, is heav-

ily based on processes, tools, and artifacts, similar to

what occurs with traditional approaches for develop-

ing software that are heavily based on planning and

engineering (Group, 2018; Dyb

a and Dingsøyr, 2008;

Nerur et al., 2005).

In response to those criticisms, Agile Software

Development (ASD) has been widely applied in the

software industry (Ambler, 2013; Hauder et al., 2014)

and, more recently, its principles, values, and agile

project management practices have been tested in the

context of EA (Hensema, 2015; Hosiaisluoma et al.,

2018; Rasnacis and Berzisa, 2017). ASD promises

ﬂexibility, velocity, lean, learning, and adaptability,

characteristics that motivated previous research ef-

forts to implement agile concepts in the EA con-

text (Qumer and Henderson-Sellers, 2008; Dyb

a and

Dingsøyr, 2008).

Medeiros, P., Santana, A., Lima, M., Moura, H. and Mira da Silva, M.

An Agile Approach for Modeling Enterprise Architectures.

DOI: 10.5220/0010450506590670

In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 2, pages 659-670

ISBN: 978-989-758-509-8

659

Although there is still some confusion about

whether EA and Agile can and should be used to-

gether, so far, there is no research that may give us the

state of the art about the possible interactions between

both areas (Canat et al., 2018). Some research efforts

are worth citing, such as (Ambler, 2013) that argues

EA management has to be business-driven, evolution-

ary, collaborative, and focused on producing valuable

artifacts. Other research efforts focus on applying

lean and agile methods in the context of EA (Bente

et al., 2012; Hosiaisluoma et al., 2018; Hensema,

2015).

More recently, it has been developed and launched

by The Open Group, a Guide to Agile Architecture

Modeling using the ArchiMate

 Language (Group,

2020). An Agile EA framework has also been already

proposed (Rouhani et al., 2008). Other researchers

presented agile methods for creating EA deliverables

and also for collaboration between architects and de-

velopers (Hanschke et al., 2015). There are also some

evidence that current EA development follows the

same software development problems, so agile prin-

ciples and values (Fowler et al., 2001) could provide

beneﬁts for EA (Hanschke et al., 2015).

Based on these initial research efforts (Ambler,

2013; Hensema, 2015; Canat et al., 2018), we propose

to apply Agile to EA modeling in order to generate

beneﬁts such as faster deliveries, better artifacts, and

alignment to the needs of stakeholders. In particular,

considering the scarcity of empirically grounded Ag-

ile EA approaches (Hauder et al., 2014) in this paper,

we not only propose but also demonstrate an Agile

Enterprise Architecture Modeling Method to answer

the following research question: How can we model

EA, using Agile principles and values?

The rest of the paper is organized as follows. In

Section 2, we present the main concepts related to EA,

agile methods, and the relationship between them. In

Section 3, we present the methodology used to con-

duct this research. In Sections 4 and 5, we propose

and demonstrate the artifact. In Section 6 we present

the results of evaluating the proposal. We then ﬁnally

present the lessons learned in Section 7 and conclude

the paper in Section 8.

2 BACKGROUND

In this section, we summarize the main concepts

needed for this paper about EA, agile, and related

work.

2.1 Enterprise Architecture, Layers and

Models

According to Kotusev, Singh, and Storey (Kotu-

sev et al., 2015), ”EA is a description of an enter-

prise from an integrated business and IT perspec-

tive”. However, EA is more inclusive is presented

from different perspectives at different layers of ab-

straction (Ahlemann et al., 2012). According to TO-

GAF (Group, 2018): ”EA is a system formed by four

subsystems, namely Business, Data/Information, Ap-

plication, and Infrastructure (or Technology) Archi-

tecture”.

The ArchiMate

 Framework deﬁnes a structure

composed of layers and aspects. Its language deﬁnes

generic elements, and their relationships can be spe-

cialized in different ways. Business, Application, and

Technology are the layers speciﬁed. Active Structure,

Behavior, and Passive Structure are the aspects. In

this paper, we consider the EA concept covering the

four layers: business, information, application, tech-

nology (Group, 2019).

Architecture models constitute the core of the EA

approach and serve to make the complexities of the

real world understandable and manageable (Winter

and Fischer, 2006). Considering the previous layers,

EA models are used as an abstraction of the enter-

prise’s structure in its current state (AS-IS models).

They show possible alignment issues, ease communi-

cation and can aid in decision-making, by being used

to predict the behavior of future states (TO-BE state

models) rather than modifying the systems in the cur-

rent architecture (Buschle et al., 2010). EA models

are tools for planning, communicating, and of course,

also for documenting (remembering) (Johnson et al.,

2014).

2.2 Agile and Enterprise Architecture

The authors of the ”The Agile Manifesto”

in 2001

identiﬁed a set of frequent problems in the software

development’s practice. Generally speaking, those

problems were related to the excess of focus in pro-

cesses, methods, documentation, and plans instead of

fast delivery of results and the response to changes.

Similar to software development, EA manage-

ment initiatives face challenges that delay results,

complicate the collaboration, and deteriorate the over-

all work quality (Hauder et al., 2014). The striving for

agile principles and values enhancing the efﬁciency of

EA management is mainly found in practitioners’ cir-

cles. While only a small number of experts emphasize

https://agilemanifesto.org/

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

660

the misﬁt of both disciplines, the majority of the in-

dustry consider Agile means being well suited for EA

management. A similar position has the interviewees

from (Canat et al., 2018).

While in ASD, more tangible methods like

SCRUM

, Extreme Programming

and others, in EA,

no such proposal has been highlighted among the

community so far. As one of the most popular EA

approaches, in the Architecture Development Method

(ADM)

of the TOGAF, the modeling efforts are con-

centrated along with the phases B (Business Archi-

tecture), C (Information Systems Architecture) and D

(Technology Architecture), also known as the design

cycle of the ADM. Each of those phases is divided

into several steps, each of them with its inputs and

outputs.

The TOGAF advocates its adaptation to the con-

text, that is, practitioners may tailor the framework

(e.g., the breadth of coverage of the enterprise, the

level of modeling detail, etc.) according to the orga-

nization’s speciﬁcity. As a generic method, the ADM

is intended to be used by enterprises in a wide vari-

ety of different geographies and applied in different

vertical sectors/industry types. Despite also being it-

erative, the TOGAF does not explicitly recommend to

manage an EA in an Agile style, and does not claim

to be an Agile approach (Group, 2018).

According to the Agile alliance

, Agile software

development (ASD) is an umbrella term for a set of

frameworks and practices based on the four values

and twelve principles expressed in the Manifesto for

ASD. Some important features among those practices

are quick releases of small versions, lean (focuses on

shortening the time and cost and improving quality),

responsiveness to expected and unexpected changes,

and attentive to learning (emphasizes improvement

during and after product development) (Qumer and

Henderson-Sellers, 2008).

Agile practices have already been applied to EA,

but no method to implement EAM or EA modeling

was proposed though (Hensema, 2015). Translated

into an EA management context, enterprise architects

should strive to ship their deliverables as early as pos-

sible, pursue an incremental and iterative approach,

and embrace changes regarding their working style

and results. Recently, (Canat et al., 2018) interviewed

twelve professionals in different roles, such as devel-

opers and architects, in ﬁve companies about EA and

Agile relations. They found out that ”all interviewees

https://www.scrum.org/

http://www.extremeprogramming.org/

https://pubs.opengroup.org/architecture/togaf8-

doc/arch/chap03.html

https://www.agilealliance.org/agile101/

believe that enterprise architecture and Agile devel-

opment can be combined, although not at all levels”.

In this direction, (Hauder et al., 2014) performed a

survey among 105 industry experts working for more

than 10 industry sectors across 22 different countries

about the agile principles applied to EA management

in their organizations. They identiﬁed a set of agile

principles, such as cross-functional operations, itera-

tive and incremental approach, self-organization, and

so on, which were used by practitioners in the indus-

try. Therefore, we can see that the potential of com-

bining EA and Agile is already perceived by prac-

titioners and practiced in several organizations. Al-

though no systematization of those practices is avail-

able.

Agile and EA can beneﬁt each other in a two-way

relationship. These relations are depicted in Figure

1. At this point, we only talked about the ﬁrst side of

the relation (ASD - EA), which represents the con-

tributions of Agile to the EA context. To the best

of our knowledge, the EA community does not have

its ”EA Agile Manifesto” nor a consolidated ”Scrum-

like” EA method for modeling purposes. In the sec-

ond side of the relation, some scenarios were found

by (Canat et al., 2018).

Figure 1: Possibilities of convergence between EA and

ASD research and practice.

The ﬁrst one relates to the reuse of software ap-

plications. In this case, the companies are not reusing

existing systems or applications and are developing or

procuring new ones with the same or similar function-

alities. It is obviously costly and ineffective to support

all these different applications, and it adds complex-

ity to the architecture. The most common reason the

authors found for the reusability issue was the lack of

knowledge about existing systems and applications,

which is partly caused by not working enough with

architecture and not having an excellent overall view

of the IT landscape. Without the architecture to guide

them, team members and engineers are unaware of

what is available and have no other choice but to de-

cide on one ineffective alternative.

An Agile Approach for Modeling Enterprise Architectures

661

This quote is particularly interesting: ”To solve

these issues, a good architecture that is kept up-to-

date is required in order to provide procurement and

developers guidance on what is already available to

them, and how the systems are connected. The archi-

tects also need to show their coworkers the value of

reusability and avoid having multiple systems cover

the same area of functionality.”(Canat et al., 2018)

Those ﬁndings highlight the necessary balance

(represented by the intersection in Figure 2) between

prioritizing enough architecture documentation and

providing software releases quickly. This is architec-

ture helping developers to integrate better and reuse

software and, thus, save resources.

2.3 Related work

Few works tried to merge Agile constructs in EA

methods or frameworks. The work of (Rouhani et al.,

2008) presents a framework for Agile EA with seven

models and eleven interactions between them. They

believe that their framework is performed in a way

that allows the enterprise ”to ﬁnish the architecture

better, faster, and cheaper and with the complete ad-

hesion of stakeholders”. However, no evidence for

those achievements is presented. A speciﬁc work de-

scribes how to streamline the architecture processes,

set up an Agile EA project, and foster collaboration

(Bente et al., 2012). Even though their explanations

are based on several toy examples, therefore no em-

pirical evidence is provided about the adoption of Ag-

ile practices in EA management.

This master thesis presents an Agile EA manage-

ment method (Agile EAMM) that embodies eight es-

sential elements adapted from lean and agile princi-

ples and values (Lumor, 2016). He demonstrates,

conceptually, that the Agile EAMM has the propen-

sity to support the agility of the EAM function and the

agility of the enterprise as a whole. Similarly, (Hosi-

aisluoma et al., 2018) introduces a lean EA develop-

ment (LEAD) method for EA management based on

agile principles. The applied lean and agile principles

encourage to avoid unnecessary big design up-front

and redundant planning activities. In practice, the

LEAD operating model organizes capabilities around

the value delivery chain. The authors adopted and

used the LEAD in a public organization, one of the

largest cities in Finland, as a case.

The Open Group, has been development a work

as part of a broader set of initiatives focused on the

relationships between Agile and EA. The main focus

of the work is: ”a) expressing the business intent, to

help prioritize epics and features, and to convey the

architecture vision to Agile teams; b) fostering enter-

prise agility, complexity reduction, and managing ar-

chitectural and technical debt; c) facilitating the com-

munication within, between, and across Agile teams”

(Group, 2020). However, the document does not pro-

vide many application details.

As in (Hosiaisluoma et al., 2018), this paper fo-

cuses on applying Agile principles and values to EA

(ﬁrst side of the Agile-EA relation in Figure 1). Our

approach differs from previous works because we fo-

cus on EA modeling, one of the phases of the EA

management life cycle. Also, we provide practical

guidance for experts to build their models using our

method and artifacts. Additionally, we perform the

method in two public organizations providing empir-

ical evidence of its applicability as described in the

next sections.

3 RESEARCH DESIGN

In this section, we present the research question, re-

search method, and data collection and analysis meth-

ods.

3.1 Research Classiﬁcation

This work can be classiﬁed as an exploratory,

inductive-based, applied and qualitative research

(Wohlin and Aurum, 2015). We design an Agile

method for EA modeling called Agile Enterprise Ar-

chitecture Modeling Method (AgEAMM). Then, we

demonstrate the application of this method in two or-

ganizations, described in the following sections. The

goal is to answer the following research question:

How can we model EA, using Agile principles and

values?

3.2 Research Method

As in any research approach, we need to ensure ad-

herence to a method, transparency in the procedures

and decisions, and specify clearly the evaluation crite-

ria, in order to enhance our conclusions’ validity and

artifact’s utility. As for research method, we adopted

the constructs and the process for the Design Science

Research Methodology (DSRM) proposed by Peffers

to frame our initiative (Peffers et al., 2007).DSRM is

an empirical method (based on evidence) for the sys-

tematic creation of innovative solutions (Hevner and

Chatterjee, 2010). The central concept in the DSRM

is the artifact, that is, solutions to problems material-

ized in methods, techniques, processes, or tools (Pef-

fers et al., 2007).

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

662

The initial motivation to investigate the current re-

search problem (or opportunity) came from our ad

hoc literature review (Ambler, 2013; Hauder et al.,

2014; Hensema, 2015; Canat et al., 2018; Hosiaislu-

oma et al., 2018) which indicated that the EA Agile

ﬁeld is relatively recent, with the ﬁrst one published

in 2008 (Rouhani et al., 2008). However, more than

half the works were published in 2013 or later and

conﬁrmed that it still lacks some theoretical founda-

tions. This was an opportunity to propose a method

for Agile modeling for EA, our ﬁrst artifact (problem-

centered research).

The purpose of the proposed artifact is to pro-

vide an agile way of modeling EA with stakeholders,

performing a set of activities that generate beneﬁts

aligned with agile values and principles, such as (a)

short deliveries/interactions, (b) artifacts aligned with

the business, (c) promoting stakeholder engagement,

systematically improving the modeling process (d)

quick responses to changes for establishing EA mod-

eling. We argue that the two knowledge domains (Ag-

ile and EA) could complement each other and pro-

vide answers to the criticisms mentioned previously

in Section 1.

We used constructs from the theory about ag-

ile principles and values (Schwaber, 1997) com-

bined with the concepts from EA domains (TOGAF)

(Group, 2018) to deliver the modeling artifact, de-

scribed in Section 4. Since EA is a robust modeling-

based discipline and modeling is one essential part of

it, we believe introducing the Agile perspective in an

effective modeling method is an important contribu-

tion to the EA community.

Following the cycle of (Peffers et al., 2007), af-

ter deﬁning the problem, we designed the AgEAMM

artifact and demonstrated it at the same public organi-

zations selected by convenience (one researcher is af-

ﬁliated). The same artifact was instantiated and eval-

uated in two selected organizations, from September

2019 to February 2020, with a time gap of one month

between them.

3.3 Data Collection and Analysis

Methods

One commonly used qualitative data collection

method in the information system (IS) research is

participant observation (Wohlin and Aurum, 2015).

Three researchers were part of the artifact’s design in-

stantiation team. The AgEAMM artifact and its eval-

uation are presented in Section 4 and 6, respectively,

resulted from the perceptions and discussions among

those researchers along with the executed cycles, ex-

plained in detail throughout this paper.

The AgEAMM is based on Scrum (Schwaber,

1997) and also has a step called ”Sprint Retrospec-

tive”, which runs at the end of each Sprint. The ob-

jective was to collect and evaluate points where the

method worked well, or what could be changed, and

in that situation, what actions should be taken to im-

prove the method. Notes about insights, bottlenecks,

and improvements’suggestions for our method (arti-

fact) were recorded and shared in Google Documents

in what we called ”EA Diary” (see Figure 3). We also

kept and shared the method’s outputs, such as BPMN

and Archimate models and minutes of each one of the

meetings. All those ﬁles can be accessed upon re-

quest.

The research team performed qualitative analysis

over the notes and comments made in the records and

produced models. As for the artifact’s evaluation (Prat

et al., 2014), we consider as a criterion the applica-

tion of the AgEAMM (applicability) and the stake-

holder’s validation of the produced models (utility).

3.4 Selected Organizations

As mentioned early, the artifact (AgEAMM) was

demonstrated and evaluated in two organizations -

Public Service Consumer (PSC1 and PSC2), with the

intermediation of a third organization, a Public Ser-

vice Provider (PSP). A work plan was established by

PSP to be performed as a service for two of its cus-

tomers, PSC1 and PSC2. The Figure 2 represents the

relationship between the organizations.

Figure 2: Organizations involved in the study and their re-

lationships.

The PSP is a public, non-proﬁt IT provider with

approximately 230 employees. It provides IT ser-

vices (such as software development, and user techni-

cal support, data center, etc.) to the city hall’s ofﬁces

(Health, Education, Infrastructure and so on). The

city has around 1.6 million inhabitants. The PSC1 is

also a public, non-proﬁt organization, with approxi-

mately 700 employees. It is responsible for executing

the urban cleaning services for the entire city. The

PSC2 is also a public, non-proﬁt organization with

approximately 1,200 employees. Its core business is

engineering and urban infrastructure services for the

entire city. In this particular condition, PSP is pro-

viding the EA modeling service to PSC1 and PSC2.

An Agile Approach for Modeling Enterprise Architectures

663

Value/importance for PSC and ease of access were

the criteria used to select the organizations for this re-

search.

In PSC1, there are systems implemented in differ-

ent technologies, although no software development

department exists. Its IT function provides only tech-

nical support services and manages the infrastructure

(internet, servers, printers, etc.). In the PSC1, the

business planning unit was our EA modeling client.

Seven employees from this department took part in

the modeling sessions (see Figure 4).

In PSC2, it has infrastructure similar to PSC1, and

there are also systems implemented in different tech-

nologies, and there is also no software development

department. Its IT function provides only technical

support services and manages the infrastructure (in-

ternet, servers, printers, etc.). In the instance of PSC2,

the ”customer service” unit that was our EA modeling

customer. Five employees from this department par-

ticipated in the modeling sessions (see Figure 3).

4 PROPOSAL

In this section, we present the proposed Agile Enter-

prise Architecture Modeling Method (AgEAMM) re-

search artifact. The method is described below, in-

cluding the nine activities and eight artifacts.

• Sensitize CIO and CEO: The activity of rais-

ing awareness on top management (modeling ini-

tiative’s sponsor), aims to present the fundamen-

tal concepts related to EA, its related advantages,

and beneﬁts. It is a productive communication

activity. In practice, it is a way to convince

the main stakeholders to achieve a predisposition

for a change within the organization in order to

strengthen its business.

Related Artifact: This activity was aided by an

Executive Presentation made with simple slides.

The topics approached in this presentation were:

basic EA concepts; a proposal for the organiza-

tion; a list of expected outputs, a list of partners

involved; an overall explanation of the Agile pro-

cess used by the team; counterparts and responsi-

bilities of those involved, and an overview of the

next steps. We faced our EA modeling initiative

as a project and presented its project charter in this

step.

• Deﬁne EA Committee: The committee’s idea is

to establish a group of people empowered to delib-

erate, direct, or clarify points of the work in ques-

tion.

Related Artifact: We created a document called

EA Committee, which contained the members of

the PSP organizations (its director and the three

EA researchers), PSC1 (two IT specialists, and

ﬁve business specialists) and PSC2 (two IT spe-

cialists, one from the human resources sector and

two business specialists). This artifact contained

the names of those stakeholders, the type of in-

volvement, the role played in the project, their re-

sponsibilities, and their contact details numbers.

Regarding the type of involvement, they can be

classiﬁed as Strategic, EA Technical, Manage-

ment, and Business). Regarding the role of those

involved in the project, the classiﬁcation used

was:

– Sponsor: To sponsor the project, establish pri-

orities, decide strategic issues and select clients

for the project;

– EA Leader: To understand and to interpret the

requirements for building the models, as well

as to reﬁne and validate the models produced,

ensuring EA adherence;

– EA Consultant: To provide guidance, best

practices, application referrals and technology

for the project;

– Modeling Team: To perform EA modeling

work (modeling sessions);

– Project Manager: To establish and manage

the project;

– IT Expert: The professional on the client-side,

responsible for arranging meetings and helping

with technical knowledge related to the local

applications and

– Business Expert: The specialist in the busi-

ness to be modeled, responsible for gathering

and validating the expected data, and articulat-

ing the necessary knowledge for the modeling

team to compose the outputs of the corporate

architecture.

These roles were obtained mainly from the Scrum

Framework elements and Project Management

Body of Knowledge guide (PMI, 2017).

• Perform EA Diagnosis: The goal of this activ-

ity was to examine the EA artifacts existing in the

investigated organizations. The questions are di-

rected towards obtaining answers about the pres-

ence or lack of common EA artifacts, as well as

discovering the organization’s maturity concern-

ing these practices. The questions, together with

the answers, guided our study.

Related Artifact: We artifact called EA Diag-

nosis, which contains a set of guiding questions,

as shown in Figure 4. In our situation, the re-

sponses were entirely different from ”YES”. The

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

664

Figure 3: Agile Enterprise Architecture Modeling Method (AgEAMM), in BPMN notation.

complete questionnaire was developed on Google

Docs and contained thirteen questions.

Figure 4: EA Diagnosis form.

• Deﬁne EA Business Question(s): Activity per-

formed right after the diagnosis to prioritize the

work, as well as directing it.

Related Artifact: The organizations’ deﬁnition

business questions came through brainstorming

sessions between the Business Expert team and

the Modeling Team, considering the EA Diagno-

sis’s content. The business questions deﬁned by

the PSC1 and PSC2 organizations are respectively

described below:

- What are the current IT applications, and

how they support the organization’s business pro-

cesses?

- What are the main business processes in

the directory, and how are the IT applications sup-

porting them?

It is essential to notice that although they are sim-

ilar, the questions differ in scope and orientation.

In the ﬁrst one, the concern was to map the en-

tire IT landscape, while in the second one, the

focus was to map critical processes and appli-

cations of one speciﬁc business unit. Based on

the deﬁnition of the business question(s), an EA

Product Backlog (Schwaber, 1997) artifact es-

tablished and documented on the web tool Trello

(https://trello.com/).

• Plan EA Sprint: These meetings establish the

Sprint goal based on the deﬁnition of the scope

(increment) of work to be delivered in this time-

box.

Related Artifact: In practice, a piece of the EA

Product Backlog (input) with activities related to

EA modeling was prioritized and delivered dur-

ing as an EA Sprint. Those planning meetings

lasted on average of two hours. A planning meet-

ing was arranged to happen every two weeks. The

only one input artifact for this activity was the EA

Product Backlog, produced by the previous activ-

ity, as depicted in Figure 3.

An Agile Approach for Modeling Enterprise Architectures

665

• Deﬁne Business and IT Experts: Once the

workload in each of the two organizations in-

volved several of their sectors/departments, im-

mediately after each Plan EA Sprint, it was nec-

essary to deﬁne or update information about the

Business and IT Experts that had to be consulted

for that EA Sprint.

Related Artifact: In our experience, this activity

proved to be extremely necessary and valuable, as

it allowed us to keep those people informed and

committed to the work. A Communication Plan

artifact was established for the project. This doc-

ument contains a list of stakeholders with their

names, roles, type of requested information, fre-

quency, and contact details for communication.

• Modeling Session: One of the most important ac-

tivities, where the Modeling Team participated to-

gether in loco with the Business Experts, the own-

ers of the knowledge of the business to be mod-

eled.

Related Artifact: The modeling sections took

place in the companies. Four modeling meet-

ings were held in one organization and three in

the other. They were weekly meetings, of 2

hours, recorded, documented, and later reﬂected

in Business Process Model and Notation (BPMN)

or Archimate diagrams. The beginning of each

modeling session was used to validate the incre-

ment of the work of the previous modeling sec-

tion. Useful EA deliverables in the form of BPM

or Archimate models were produced and validated

by the stakeholders.

• Perform Sprint Review: In this Activity, the

Modeling Team presents the work done during the

current Sprint to Business Experts and stakehold-

ers. Then, the Sprint may be validated.

Related Artifact: This activity does not have any

speciﬁc artifact. It only has, as input, the EA de-

liverables produced in the previous activity (Mod-

eling Section). This Sprint review took place in

the customer’s environment, with the modeling

team, IT specialists, and business specialists. The

review meeting lasted around one hour.

• Perform Sprint Retrospective: Its occurs at the

end of a Sprint in order to identify, under the pro-

cess perspective, what worked well, what can be

improved, and what actions will be taken to im-

prove it.

Related Artifact: We used an EA Diary as a way

to record the improvement actions identiﬁed in the

Sprint Retrospective.

The proposed AgEAMM is based on incremental

improvements through four cycles of practical use in

both organizations (two cycles in each), as explained

in Section 3. The ﬁrst version was only based on

the literature. After the ﬁrst instantiation in PSC1,

it was possible to establish an improved version of

the AgEAMM with the knowledge obtained from this

ﬁrst experience. In the second version of AgEAMM,

new activities were included (Deﬁne EA business

question (s) and Deﬁne business and IT specialists);

and also artifacts (Executive presentation, Communi-

cation Plan, Matrix of stakeholders, and EA Diary.

This ﬁnal version of the method consists of nine ac-

tivities and eight artifacts, as depicted in Figure 3.

5 DEMONSTRATION

The AgEAMM artifact proposed in Section 4 and

shown in Figure 3 was demonstrated in the two public

organizations, described in Section 3.4 from Septem-

ber 2019 to February 2020. The study was conducted

through regular meetings with the presence of three

professionals proﬁles: EA Leader, Modeling Team,

and Business Expert (see Section IV). While driving

the work, the proposed artifacts generated in activi-

ties of the AgEAMM were delivered to organizations,

through short, iterative and incremental sprints. At

the start of each meeting, we validated the EA deliv-

erables from the previous activities.

All AgEAMM activities to be performed on that

particular Sprint were planned and monitored with

the Trello

, a free tool that may be easily conﬁgured.

Our Trello’s conﬁguration is depicted in Figure 5. We

used four lists: ”BACKLOG”, representing what we

have to do throughout the project; ”TO DO”, repre-

senting what we have to do in the current Sprint; ”DO-

ING”, representing what we are doing; and ”DONE”,

representing what has already been completed in the

current Sprint.

Also, we used some ”Trello labels” to systematize

the work, such as:

Sprint: Represents a Time Box within which a set

of activities must be performed. In our instance, it is

numbered to represent the current Sprint (in Figure 5,

it is highlighted in red);

Story: Represents a User Story or a simple, light

and concise description of a user’s need (in Figure 5,

it is highlighted in green);

Ceremonies: There were two types of ceremonies

(Planning and Retrospective). The ﬁrst served to

record the planning carried out for the Sprint and the

other to discuss improvements in the method (in Fig-

ure 5, it is highlighted in orange);

https://trello.com/

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

666

Figure 5: Managing AgEAMM activities with Trello.

Modeling: Used to mark EA’s modeling activities

(in Figure 5, it is highlighted in purple);

We also used a Trello extension (Agile Tools) that

allowed us to estimate the size of the story, following

the Fibonacci scale (Boehm et al., 2012).

As mentioned before, all deliverables and docu-

ments involved in the AgEAMM instantiation were

kept in our Google Drive Repository, which was

shared with PSC1 and PSC2.

6 EVALUATION

This section presents an evaluation of AgEAMM (the

artifact), following the DSRM, and proposing to an-

swer the established research question.

The evaluation is grounded in the re-

searchers´perspectives and discussions along with

the artifact’s instantiation, especially at the end of

the each Sprint (Sprint Retrospective). First, we

applied the applicability criterion to evaluate the

AgEAMM artifact. Instantiations help to reason

about an artifact’s feasibility and applicability at

build-time or its usefulness when applied to some

reality. Once we executed the artifact and we were

able to produce EA deliverables in accordance with

agile principles, thus, we claim the applicability of

our artifact. The second used criterion was ”corre-

spondence with another model” (Prat et al., 2014), in

this case, the correspondence of the AgEAMM with

the Agile Manifesto’s ideas (Fowler et al., 2001).

Our reasoning is based on the four values and twelve

principles of the Agile Manifesto:

• Customer satisfaction can be increased with fast

and continuous deliveries of artifacts or small

parts of the expected architectural models. We ob-

served that this approach could generate the per-

ception of value delivered and thus, customer sat-

isfaction;

• Welcome changing requirements, even late in de-

velopment, is what Agile Manifesto describes.

The approach used in this work was to establish a

macroscope, with the ﬂexibility of changes at any

time during the course of the Sprints. In practice,

we realize that the continuous delivery of value, in

the form of artifacts or models, can help trim pos-

sible problems related to changes. Obviously, in

environments where more tight or rigid contracts

are required, the change may not be precisely wel-

come;

• The promotion of constant cooperation between

people who understand the business (Business Ex-

perts) and the Modeling Team is essential for the

job. Looking and worrying about how to promote

cooperation can save the project. Here, coopera-

tion was promoted through the use of messaging

tools (smartphones) and the promotion of less for-

mal environments during meetings;

• Face-to-face meetings, which were frequent and

in the client’s environment, were determining fac-

tors in keeping those involved motivated. It was

natural that, in times of absence, the pace of

work was hampered due to the unavailability of

the client. However, conﬁdence remained high

throughout the project;

• Artifacts or architectural models delivered be-

came a measure of the project’s progress. How-

ever, the idea of delivering components that gen-

erate value was the determining factor in progress.

For example, when delivering a list of all the or-

ganization’s systems, as well as other related in-

formation, we could realize the idea of deliver-

ing value and progress. It is something we rec-

An Agile Approach for Modeling Enterprise Architectures

667

ommend practicing: we thus reinforce that it was

crucial to bring early value to the clients.

• The concept of simplicity is often understood as

maximizing the amount of work not done. The

idea of simplicity was something related to the

project, and despite being at the head of the team,

we were unable to state exactly the simplicity

points applied. As previously mentioned, actions

to focus on what was perceived by the model-

ing team as ”delivering value”, can be understood

with actions to promote simplicity;

• The Agile Manifesto talks about self-organizing

teams. In this sense, we were able to apply

this concept while maintaining sufﬁcient auton-

omy and conﬁdence for Modeling Team to de-

cide the best way to carry out its work. This self-

organization was deepened a lot by the proﬁles

of the project’s professionals and the collaborative

relationship;

• Finally, the reﬂection on how to make the team

and the method more effective occurred with

each Sprint cycle, starting from the Sprint Retro-

spective meeting, inspired by the Scrum frame-

work. These meetings served, among other subtle

points, to improve AgEAMM in each cycle.

7 LESSONS LEARNED

The method was applied after authorization and for-

mal support by the top management (the sponsor in

the organization). This authorization already pointed

out the indication of IT experts (as already de-

scribed, client-side professionals responsible for fa-

cilitating meetings with business specialists). The two

EA modeling initiatives in both organizations started

shortly after the ”Sensitize CIO and CEO” meetings

which occurred independently.

In each of the organizations were introduced: the

goals, the schedule of activities and delivery stages,

descriptions of those involved, including the project

manager, and his authority. Assumptions, restrictions,

and risks were also part of the presentation. Concern-

ing the deliverable, they started to appear according

to customers’ needs, Sprint after Sprint, as shown in

Figure 3.

The relationship between the modeling team and

the clients took place in a very collaborative way, fol-

lowing the precepts of the Agile Manifesto “Customer

collaboration over contract negotiation”(Fowler et al.,

2001). This collaboration was important and made

the communication easier during the course of the

project, especially during meetings, which always

took place at the client. Collaboration, in addition to

improving trust between the parties, eliminated un-

necessary efforts, and allowed us to focus on actions

that could generate value for the work/business. The

willing to collaborate was perceived by both organ-

isations. We repute this to their expectations about

improving their IT solutions/work conditions.

Difﬁculties in the application of the method were

issues related to a) availability of the participants

of the two organizations; b) need to formalize the

work, for cultural reasons related to public organiza-

tions (agility was hindered for this reason); c) lack of

knowledge in some parts of the business and diver-

gence between practical work and existing processes,

caused by the existence of organizational silos.

7.1 Recommendations

Below are some critical points present in the

AgEAMM that we can mention, and that deserves at-

tention when conducting the EA modeling process:

• It is essential to obtain the support of top man-

agement. Understanding and giving the necessary

importance to this activity is essential to conduct

all the work. For this reason, we explain this step,

”Sensitize CIO/CEO”, in the proposed method.

Many barriers or resistance from those involved

can be broken by winning a good sponsor for the

project, someone within the organization’s com-

mand chair. In this work, we start by requesting a

meeting with the organization’s top management.

The objective was to present the concepts of EA,

as well as the advantages related to its implemen-

tation in the institution. This meeting proved to be

very efﬁcient, as it made top management become

sponsor the project, supporting the group and pro-

moting the project in organizations;

• Establishing clear roles, appropriate profession-

als, and a multidisciplinary team is a critical suc-

cess factor. It is essential to avoid situations where

there are delays or failures in EA modeling jobs’

quality due to deviations from functions (some-

one doing someone else’s job). Agile methods

talk about multidisciplinary teams, but that does

not mean that a professional knows or should do

everything. For agile methods, the team has to

be multidisciplinary. In this work, we propose

a set of roles (Sponsor, EA Leader, EA Consul-

tant, Modeling Team, Project Manager, IT Expert,

Business Expert), which we recommend. Section

4 presents these roles in more detail;

• To guide the work based on business questions.

When the question is speciﬁc and clear, it can be

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

668

an excellent way to direct the work, promote a fo-

cus on the planning and execution of the model-

ing sections, or even a way to direct the conver-

sation between the modeling team and the busi-

ness experts. In the two organizations surveyed,

the team encouraged customers to formulate ques-

tions, to which the answer could generate value

for their organization. For example, one of the

many questions asked for one of the organizations

was: ”What are the existing applications in the

organization, and how are these applications sup-

porting the organization’s business processes and

strategy?”;

• Communication means making every day, infor-

mation exchanging, sharing ideas, feelings, expe-

riences, and values through gestures, acts, words,

ﬁgures, images, symbols, etc. (Cockburn and

Highsmith, 2001). Communication is a critical

factor in the success of the project, and it was no

different for this work. Creating a communication

plan associated with a stakeholder matrix can help

the EA modeling process. This concern with com-

munication was designed at the beginning of the

work and was consolidated throughout the life-

cycle of the project. We recommend continuous

attention to avoid communication noise.

8 CONCLUSION

In this paper, we present the proposal for a hands-

on Agile Enterprise Architecture Modeling Method.

The research problem was established from the litera-

ture and conﬁrmed during the execution of the study.

We used the Design Science Research Methodology

as a methodology for proposing an artifact to im-

prove the organization’s EA modeling process. We

described in detail the AgEAMM and its relation to

the twelve principles deﬁned in the Agile Manifesto.

The demonstration and evaluation were conducted in

two organizations.

Some critical points in the implementation of Ag-

ile modeling were: obtaining support from the orga-

nization’s top management, establish appropriate and

clear roles for the project, guide the project through

business questions, and do not neglect communica-

tion with stakeholders. We also presented lessons

learned along with the present research. Our expe-

rience and results allow us to conclude that the two

concepts, Agile and EA modeling, are convergent and

may help us minimize the current challenges in carry-

ing out the modeling of one EA.

8.1 Research Limitations

Although this research has achieved all of its objec-

tives, some limitations must be considered:

• The evaluation presented in this work may have

been limited by analysis unit used to validate the

AgEAMM. The cultural factors of the organiza-

tions surveyed may differ from those obtained in

private organizations, for instance;

• A weak point in our research design is that the

evaluation of the method was done by special-

ists who were members of the project. Thus, the

opinions of the researchers may produce a bias to-

wards the ﬁndings and conclusions;

• TOGAF ADM represents an important approach

to EA modeling in the market. Our method does

not cover the entire ADM cycle.

8.2 Future Work

As for future works, we can think of suggesting the

application of the AgEAMM in private organizations,

since the two organizations, PSC1 and PSC2, are in

the public sector. The goal would be to understand if

there would be necessary to make any adaptation in

the AgEAMM. Another point would be to intensify

agile practices in the method proposed here, apply-

ing and testing adaptations to other techniques well-

known in the Agile ﬁeld, such as Daily Meetings,

Pair Programming, Refactoring, Planning Poker, etc.

(Fowler et al., 2001). Third, to apply the method as-

sociated in association with structured questionnaires

that can measure customer satisfaction to minimize

analysis bias. Finally, to conduct studies on which

could be possible to evolve the AgEAMM and inte-

grate it with the software development process and

strategic planning and project portfolio management

processes of the organization.

REFERENCES

Ahlemann, F., Stettiner, E., Messerschmidt, M., and Legner,

C. (2012). Strategic enterprise architecture manage-

ment: challenges, best practices, and future develop-

ments. Springer Science & Business Media.

Ambler, S. W. (2013). Agile enterprise architecture. Ac-

cessed: Jan. 04, 2020.

Bente, S., Bombosch, U., and Langade, S. (2012). Col-

laborative enterprise architecture: enriching EA with

lean, agile, and enterprise 2.0 practices. Newnes.

Boehm, B., Abts, C., and Chulani, S. (2012). Does the

use of ﬁbonacci numbers in planning poker affect ef-

fort estimates? In 16th International Conference

An Agile Approach for Modeling Enterprise Architectures

669

on Evaluation\& Assessment in Software Engineering

(EASE 2012), volume 10, pages 177–205. IET.

Buschle, M., Ullberg, J., Franke, U., Lagerstr

om, R., and

Sommestad, T. (2010). A tool for enterprise architec-

ture analysis using the prm formalism. In Forum at

the Conference on Advanced Information Systems En-

gineering (CAiSE), pages 108–121. Springer.

Canat, M., Pol Catal

a, N., Jourkovski, A., Petrov, S.,

Wellme, M., and Lagerstr

om, R. (2018). Enterprise ar-

chitecture and agile development: Friends or foes? In

2018 IEEE 22nd International Enterprise Distributed

Object Computing Workshop (EDOCW).

Cockburn, A. and Highsmith, J. (2001). Agile software de-

velopment, the people factor. Computer, 34(11):131–

133.

Dyb

a, T. and Dingsøyr, T. (2008). Empirical studies of agile

software development: A systematic review. Informa-

tion and software technology, 50(9-10):833–859.

Ferreira, A. H., Laurindo, F. J. B., and J

unior, J. L. B.

(2017). Analysis of information technology sector

companies in brazil in the 2013 to 2015 period: A

knowledge intensive business services and innovation

perspective. In 14th CONTECSI-International Con-

ference on Information Systems and Technology Man-

agement.

Fowler, M., Highsmith, J., et al. (2001). The agile mani-

festo. Software Development.

Gill, A. Q. (2015). Agile enterprise architecture mod-

elling: Evaluating the applicability and integration of

six modelling standards. Information and Software

Technology, 67:196–206.

Group, T. O. (2018). Togaf version 9.2. Available:

https://pubs.opengroup.org/architecture/togaf92-

doc/arch/. Accessed: Feb. 10, 2021.

Group, T. O. (2019). Archimate 3.1 Speciﬁcation.

Available: https://pubs.opengroup.org/architecture/

archimate3-doc/. Accessed: Feb. 21, 2021.

Group, T. O. (2020). Guide to agile architecture mod-

eling using the archimate language. Available:

https://publications.opengroup.org/g20e. Accessed:

Dec. 19, 2020.

Hanschke, S., Ernsting, J., and Kuchen, H. (2015). Inte-

grating agile software development and enterprise ar-

chitecture management. In 2015 48th Hawaii Inter-

national Conference on System Sciences, pages 4099–

4108. IEEE.

Hauder, M., Roth, S., Schulz, C., and Matthes, F. (2014).

Agile enterprise architecture management: an analysis

on the application of agile principles. In 4th Interna-

tional Symposium on Business Modeling and Software

Design, pages 38–46.

Hensema, M. (2015). Applying agile in enterprise architec-

ture. Master’s thesis, University of Twente.

Hevner, A. and Chatterjee, S. (2010). Design science re-

search in information systems. In Design research in

information systems, pages 9–22. Springer.

Hosiaisluoma, E., Penttinen, K., Mustonen, J., and

Heikkil

a, J. (2018). Lean enterprise architecture

method for value chain based development in public

sector. In ECDG 2018 18th European Conference on

Digital Government, page 86. Academic Conferences

and publishing limited.

Johnson, P., Lagerstr

om, R., Ekstedt, M., and

Osterlind, M.

(2014). It management with enterprise architecture.

KTH, Stockholm.

Kotusev, S. (2018). Togaf-based enterprise architecture

practice: An exploratory case study. Communications

of the Association for Information Systems, 43(1):20.

Kotusev, S., Singh, M., and Storey, I. (2015). Consolidat-

ing enterprise architecture management research. In

System Sciences (HICSS), 2015 48th Hawaii Interna-

tional Conference on, pages 4069–4078. IEEE.

Lumor, T. (2016). Towards the Design of an Agile En-

terprise Architecture Management Method. Master’s

thesis, University of Jyv

askyl

a, Finland.

Nerur, S., Mahapatra, R., and Mangalaraj, G. (2005). Chal-

lenges of migrating to agile methodologies. Commu-

nications of the ACM, 48(5):72–78.

Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chat-

terjee, S. (2007). A design science research method-

ology for information systems research. Journal of

management information systems, 24(3):45–77.

PMI (2017). A Guide to the Project Management Body of

Knowledge (PMBOK

). Project Management Insti-

tute, Inc.

Prat, N., Comyn-Wattiau, I., and Akoka, J. (2014). Arti-

fact evaluation in information systems design-science

research-a holistic view. In PACIS.

Qumer, A. and Henderson-Sellers, B. (2008). An evaluation

of the degree of agility in six agile methods and its

applicability for method engineering. Information and

software technology, 50(4):280–295.

Rasnacis, A. and Berzisa, S. (2017). Method for adapta-

tion and implementation of agile project management

methodology. Procedia Computer Science, 104:43–

50.

Rouhani, B. D., Shirazi, H., Nezhad, A. F., and Kharazmi,

S. (2008). Presenting a framework for agile enterprise

architecture. In 2008 1st International Conference on

Information Technology, pages 1–4. IEEE.

Schwaber, K. (1997). Scrum development process. In Busi-

ness object design and implementation, pages 117–

134. Springer.

Winter, R. and Fischer, R. (2006). Essential layers, artifacts,

and dependencies of enterprise architecture. In 2006

10th IEEE International Enterprise Distributed Ob-

ject Computing Conference Workshops (EDOCW’06),

pages 30–30.

Wohlin, C. and Aurum, A. (2015). Towards a decision-

making structure for selecting a research design in em-

pirical software engineering. Empirical Software En-

gineering, 20(6):1427–1455.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

670