An Approach for Adaptive Enterprise Architecture
Wissal Daoudi, Karim Doumi and Laila Kjiri
AlQualsadi Team, ENSIAS Mohammed V University in Rabat, Rabat, Morocco
Keywords: Adaptation, Agile Software Development, Dynamic Environments, Enterprise Architecture, Scrum.
Abstract: Given the fast emergence of new technologies and the highly changing business demands, enterprises are
confronted with the need to keep up with the evolving transformation. This one is subject to internal and
external factors which make it very often in the form of disruptive changes. As a consequence, various parts
of companies’ Enterprise Architecture are impacted. To address the new requirements of these increasingly
dynamic environments, enterprises need to transition from heavy and document-centred Enterprise
Architecture Frameworks to more agile and continuously adaptive approaches. On the other hand, Agile
Software Development (ASD) are commonly used methods for IT development. They are mainly
characterized by the high involvement of the requester and the rapid accommodation to development needs.
This paper presents an Adaptive Enterprise Architecture model that is inspired from some ASD values.
Thus, we begin with a brief summary of the criteria that we consider compulsory for Adaptive Enterprise
Architecture. Then we present the related work and the connection between agile values and our criteria.
Finally, we describe our model and illustrate it via a case study.
1 INTRODUCTION
Nowadays, enterprises are facing the disruptions
caused by the digital transformation in a record time.
So, they are taking actions in order to adapt to the
current changes by improving their relationships
with customers, their internal processes, their
business models… As a result, the reaction to
change impacts different parts of the business
making it a major concern in enterprise architecture
(The Open Group, 2011) and (Lankhorst, 2009).
However, few Enterprise Architecture (EA)
approaches provide modeling and analytics solutions
to support rapidly changing environments. Indeed,
the so-called traditional EA approaches are heavy,
lack agility, and do not rely on well-defined
concepts.
On the other hand, the adaptation ensures that the
EA is consistent with the changes. It is a process of
adjustment and continuous improvement that makes
it possible to achieve an EA in harmony with its
environment.
Consequently, a so-called adaptive enterprise can
face unique challenges that it encounters with the
specificities of each of them (cycles, recurrence,
frequency, etc.). It recognizes the impact of change,
detects obstacles and facilitates decision-making. It
takes into account the uncertainty of change and its
diversity and responds effectively to it.
Thus, EA should focus on the methods and tools
needed to move from an initial, detailed, complex,
documentation-centred and prescriptive EA to an
EA that focuses on principles of adaptation to
expected changes and unforeseen ones. More
importantly, EA should provide continuous
improvement to proactively address development
needs. As a result, several research questions arise:
What are the criteria for identifying an adaptive
Enterprise Architecture? How to model an adaptive
EA? How to evaluate the implementation of this
model?
In this paper, we propose a model that we
consider meets the requirements of Adaptive
Enterprise Architecture. It is structured as in the
following. In Section 2, we summarize the results of
a comparative study done in a previous work. Then,
section 3 focuses on the values of agile methods and
on the mapping between them and our criteria. In
Section 4, we present some related works of
integration of agile methods and Enterprise
Architecture. The section 5 contains our model.
Then, section 6 is a case study. Finally, in the last
part, we conclude our work and present our
perspectives.
738
Daoudi, W., Doumi, K. and Kjiri, L.
An Approach for Adaptive Enterprise Architecture.
DOI: 10.5220/0009343807380745
In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, pages 738-745
ISBN: 978-989-758-423-7
Copyright
c
 2020 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

2 CRITERIA OF ADAPTIVE
ENTERPRISE ARCHITECTURE
In order to put into context our problematic, we tried
to identify the limitations of some frameworks of
Enterprise Architecture in relation with adaptation
requirements. Then we discussed a definition of
Adaptation: Adaptation ensures that the EA is
consistent with the changes, to maintain its normal
functioning. It is a process of adjustment and of
continuous improvement to reach an EA in harmony
with its environment. Then, based on this definition
and on an analytical grid, we defined some
evaluation criteria that we consider are compulsory
elements for Adaptive Enterprise Architecture
(Daoudi et al., 2018) and (Daoudi et al., 2020).
Multi-level of dynamics is the first criterion that
we identified. In fact, disruptive change not only
occurs at different layers but also impacts the
relations between those layers and elements.
Then the second criterion is the sensing of
change (Babar et al., 2015). In fact, having a
continuous sensing part helps the scheduling of
proactive actions.
Moreover the process of adaptation is the core
of the adaptive enterprise architecture. Also, this
process needs to have a low level of complexity.
This leads us to another criterion: the complexity of
change management. According to (Dietz, 2006),
complexity management is the most dominant
problem identified in scientific researches on
enterprise management. Also, complexity
(Chernobai et al., 2020) can be related to business
diversification, geographic diversification and
network interconnectedness and business complexity
is a significant driver of operational risk.
The ability of handling unforeseen changes is
another criterion. According to (Hinkelmann et al.,
2016) the ability of keeping up with continuous and
unexpected change is an essential quality of modern
enterprises.
Also, to conduct each change, there are many
properties, indicators, risks, etc. to deal with.
Adaptive Enterprise Architecture needs to specify
and assess adaptability properties of its different
components. Thus, the explicit management of
adaptability trade-offs is another criterion.
According to (Zhang, 2016), a most used maxim
in the business world is the following: “If you can’t
measure it, you can’t manage it.” As such, the last
criterion is the evaluation of adaptation.
3 ADAPTIVE ENTERPRISE
ARCHITECTURE AND AGILE
VALUES
Agile methods emerged in 2001 in computer
development context, their main aim is to involve as
much as possible the requester in the software
design. According to the agile manifesto for
software development (Beck et al., 2001), agile
methods assume change is inevitable. The key
values of the agile movement are: Individuals and
interactions over processes and tools, Working
software over comprehensive documentation,
Customer collaboration over contract negotiation
and Responding to change over following a plan.
Those methods do not spend effort and time on
extensive design phases. So, they are based on the
“design as you go” principle. Working with
iterations, the designs and developments are
improved after each increment. They provide
continuous delivery to the requester. Finally, those
methods are not document- centric although they
lead to deliverables. In fact, as they assume changes
occurs at a rapid pace, it makes no sense to produce
a huge amount of documents that soon will be
outdated, archived and difficult to manage.
As cited in (Yu et al., 2012), based on the
precedent values of agile methods, we can already
sense the convergence between the values of agile
methods and the criteria that we selected for
Adaptive Enterprise Architecture models. This can
be explained as follow.
The sensing of change is inherent in agile
methods. In fact, those methods have been proposed
to deal with these rapidly changing circumstances.
As mentioned before, they assume change is
inevitable and they deal with it by creating new
iterations.
Agile methods advocate to not ‘waste’ time on
expensive planning and design activities early on,
but to deliver something valuable to the requester as
quickly as possible. They are lightweight methods
that don’t require complex documentation. Also,
new or changed requirements trigger a new cycle
and so on. This point converges with criterion
related to complexity of change management in
EA.
According to the comparison of Agile, project-
planned and hybrid methods for multidisciplinary
design made by (Guérineau et al., 2016), agile
methods can deal with late/unexpected changes. This
is done through high meeting frequencies and
requester involvement. This characteristic meets the
An Approach for Adaptive Enterprise Architecture
739

criterion of handling unforeseen changes that we
pulled over in the precedent part.
In its comparison (Dybå et al., 2008) between
traditional development methods and agile
development methods, the authors highlighted that
the agile ones ensure a quality control via
continuous testing and continuous control of
requirements, design and solutions. This matches the
evaluation criterion that we proposed for adaptive
Enterprise Architecture.
The process of adaptation is the core of an agile
method and is based on rapid feedback loops. Also,
agile approaches strive for continuous improvement
by speeding up the plan-do-check-act cycle
introduced by Deming and Shewhart (Buckl et al.,
2011).
Regarding Multi-Level of dynamics and
explicit management of adaptability trade-offs, it
is facilitated by the high interaction between
different stakeholders in agile methods. They
encourage collaboration to bridge understanding
from both the problem-space and the solution-space.
The aspect multi-level will depend on the model that
we suggest for Adaptive Enterprise Architecture.
Since the year 2001, agile project management
for the development of software, especially Scrum,
are widely used in small, mid-sized enterprises, as
well as big global software engineering companies
(Taft, 2005). SCRUM is an agile method for project
management. It is based on iterations called Sprints.
We’ve chosen Scrum as a reference of agile
methodologies due to the fact that it is one of the
most popular approaches that are praised for coping
with rapidly changing conditions (Anwer et al.,
2017). It focuses on situations where it is difficult to
plan ahead, with mechanisms for “empirical process
control” where feedback loops constitute the core
element (Schwaber, 1997).
The Scrum framework (Rubin, 2012) consists of
a team with well defined roles, ceremonies and some
artifacts. The team is formed with the aim of
optimizing the value produced. There are three main
Scrum Roles. First, the Scrum Master who helps the
team apply Scrum and adapt it to the context.
Second, the Product Owner is the product manager.
Finally, the team is mainly responsible for actually
implanting and testing the user stories.
The Scrum ceremonies are mainly related to the
flow of the sprint: the "Sprint Planning”, the "Daily
Meetings" between the scrum master and the team
and the "Sprint review" which marks the end of a
Sprint. Finally, the "Retrospective" that examines
what has worked well and is a floor of discussion of
process improvement.
Scrum requires two main artifacts. First, the
"Product Backlog" that lists prioritized features and
associated acceptance criteria. Secondly, the "Sprint
Backlog" that lists all the tasks of a Sprint.
4 RELATED WORK
In (Buckl et al., 2011), the authors explored to which
extent agile methods, namely Scrum, can be applied
to EA management. They highlighted 4 challenges
that EA is facing: the EA management endeavor has
to be aligned with the stakeholders’ interests
expressed in a shared terminology, an EA
management endeavor has to ensure an early and
periodical delivery of concrete EA products, an EA
management endeavor has to ensure commitment
and involvement of all parties and an EA
management endeavor has to continuously adapt to a
volatile environment with changing criteria for goal
fulfillment. To address those challenges, they
propose a mapping between scrum concepts and
their equivalents in EA management.
In (Rhubart, 2010), the authors showed that both
the enterprise architecture and the agile development
methodologies are decision-making frameworks.
Thus they have the same foundations. They
suggested an interview related to agile EA
management but didn’t propose any model for
integrating agile techniques.
The paper (Armour et al., 2001) introduced an
’agile model driven development approach (AMDD)
at the enterprise level’. The model starts with the
creation of an architecture vision which is shared
with the different stakeholders at the various layers.
After having their feedbacks, the architecture is
updated.
On (Ambler, 2003), the authors focused on the
transition and implementation phases between an
As-Is architecture and the To-Be architecture. They
proposed a framework that uses an agile method in
order to analyze the activities needed in the
transition phase.
The work in (Pulkkinen et al., 2005) suggested a
cyclic EA process that goes through all three
decision making levels and reviews four enterprise
architecture types. There is no description of the
different phases explicitly.
In (Canat et al., 2018), the author did an
evaluation through meetings and a pilot interview.
The main findings highlighted were mainly that
enterprise architecture and agile methods are
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
740

preferable on different levels not only on the lower
levels (development and technology).
The authors in (Hanschke et al., 2015) runned
interviews with different stakeholders in some firms
in order to study the integration of Agile Software
Development and Enterprise Architecture
Management. They focused on Scrum and showed
the necessary collaboration of empowered
implementation teams with a central EA function
The authors in (Hensema, 2015) based on a
literature review and an empirical study found
specifically that there are similarities between
waterfall methodology and current EA approaches.
Moreover he highlighted the facts that agile
practices will allow less EA challenges as they have
the ability to deal with changing requirements and
focusing on the essential.
In their position paper, (Proper et al., 2014)
pointed out the success of agile methods and the
trend of less detailed enterprise architecture. They
claimed that those elements respond to the need for a
more iterative approach.
In their paper (Aarnink et al., 2012), the authors
conducted their study on a small population within
non-for profit organization and focused on the use of
agile software development method scrum. They
concluded that organizations can apply an agile
software development method in order to strive for
business-IT alignment.
5 THE PROPOSED APPROACH
The core of our proposed model is inspired from
Scrum and its sprint model in order to develop an
adaptive Enterprise Architecture. First of all, our
suggestion considers that during an enterprise
lifecycle we move from an EAi (i∈N*) to EAi+1
(i∈N*) (Elementary transition). So as to ensure
those continuous transitions, we propose every
elementary transition as a project with the main
objective to close the gap between the As-Is and To-
Be.
As shown in the diagram, we applied an inspired
model from Scrum horizontally at business and
application /IT layers. This allows us to inherit its
characteristics and check positively some of the
criteria of Adaptive Enterprise Architecture. As for,
the multi-level dynamics and explicit management
of adaptability trade-offs, thanks to the weekly
meetings and the committee of owners, the flow of
information goes top down and bottom up. This
important point, allows the multi-level dynamics and
the discussion of adaptability alternatives and trade-
offs.
Figure 1: Simplified diagram of the proposed model.
In the following sections, we first focus on the
strategy level and determine the formulation of
strategy elements. Then, we present the overall
approach and present its model and metamodel.
5.1 Focus on Strategy Layer
In the last decade, one of the main issues addressed
by researchers in the context of EA and business
strategy modelling is to integrate the business
strategy to the systems requirements analysis.
According to (David, 2008), the process of
strategy formulation consists of two main parts:
strategic analysis and strategic choice. The first step
consists of developing a vision and mission of the
organization. The second step is generating
alternative strategies to achieve the goals established
in the first step.
According to (Simon et al., 1986) the process of
problem-solving can be defined as a successful
search for an action or a series of actions in order to
transfer the given state of the system to a goal state
In the paper (Gavrilova et al., 2018), they
identified methods and divided them into two large
groups: generic and domain-specific. Generic ones
are used for a wide variety of tasks from different
areas; Domain-specific methods are mainly used
only for managerial tasks. They suggested 5 groups
of modelling methods from Informal description
using natural language to objects and relations
strictly defined.
According to (Kitsios et al., 2019) Although
researchers have used plenty of enterprise modelling
techniques to optimise the concepts above, the most
frequently used methods are Archimate (14.5 %),
i*framework (10.9%) and OWL(5.45%).
An Approach for Adaptive Enterprise Architecture
741

Focusing on i*, according to (Franch et al.,
2016), goals can be formulated at different levels of
abstraction, from strategic concerns to technical
issues, and are less volatile than requirements. Goal-
oriented methods allow analyzing consequences of
decisions, making interrogative questions and
exploring solutions.
We’ve chosen this modelling language for
strategy formulation as it proposes a simple but
relevant modeling perspective (Franch et al., 2016).
The integration of i* in our model is in the Strategy
level, it allows us to define a strategy map in the EAi
and in EAi+1 in a formal way. The i* framework is
a modelling technique which describes the
modelling of strategic dependencies among business
agents, goals, functions and resource (Doumi et al.,
2011).
In addition, according to (Doumi et al., 2013), i*
formalism is intentional, it lends itself well to
strategic level modeling because it offers useful
abstraction mechanisms when complex phenomena
are represented.
The four central concepts of the i* formalism
are: soft goal, hard goal, tactic and resource. First, a
soft Goal that is a strategic goal that the actor wants
to achieve. Second, a hard goal that is an operational
goal whose satisfaction criteria are precisely defined.
Third, a tactic that describes how to reach a goal
(soft or hard). Fourth, resources that are the means
that the company will make available to actors to
achieve a goal.
To sum up, the method that we’ve chosen to
formulate the To-Be Architecture is Goal modelling.
As of the assessment of the As-Is architecture, we
recommend the analysis of cartography and more
informal strategy modelling such as SWOT.
5.2 Description of the Approach
So as to describe our approach at all levels, we will
present the metamodel. Then, we will define the
roles, ceremonies and the mandatory artifacts.
As in the Metamodel, each transition from an
EAi to another one is a project that impacts all three
layers (Strategy, Business and application/IT). Also,
each project consists of iterations monitored by KPIs
and metrics. At the Strategy level, we adopt i*
concepts. So, we have soft goals linked to hard goals
and other elements. We also introduce the pattern
observer which allows the continuous listening of
goals and ensures the correction of the shots
whenever needed. The hard goals are related to the
business processes. Finally, at business ad
Application/IT layers, we use the activity queues
and items that allow the implementation of sprints.
Figure 2: Approach Metamodel.
Regarding the roles, we suggest to have a
committee of owners composed of an architecture
owner, a business owner and an application owner.
The business and the application/IT owners have
each of them a team composed of a scrum master
and members responsible of the development and
the engineering of the solutions.
The architecture owner facilitates the top-down
EA assets’ information sharing. He is the
architecture keeper vertically. He ensures the fluent
discussion between the different other owners and
consolidates their feedback. He will play the
interface between the strategy from one side and the
business and Application/IT levels from the other
side. He knows the strategy needs and translates
them into quantitative and qualitative goals for the
other EA levels. He is in charge of defining and
scheduling the architecture iterations. He also
defines the acceptance criteria that are essential for a
good understanding by the teams. He understands
the non-functional needs and the exception stories.
He maintains the architecture backlog and prioritizes
tasks. Finally, he is the only one who can accept or
reject the developed architecture. He defines and
maintains the architecture metrics.
The business owner has an overview over all the
business processes in the enterprise. He ensures their
correct application in a daily basis. He optimizes the
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
742

business processes and prevents deadlocks. He is in
charge of defining the impact of the stories in the
architecture backlog on the business level. He works
with his team to ensure the adaptation of business
processes and to maximize the business value. He
creates the business backlog and maintains it. He
schedules and defines the iterations. Also, he is in
charge of accepting or rejecting the implemented
business adaptation. He gathers the exceptions and
prioritizes tasks. He defines and maintains the
business metrics.
The application/IT owner knows the applications
landscape and the IT infrastructure. He determines
the application/IT backlog. He collects the bug
stories and non-technical needs from his team and
adapts the backlog. He prioritizes tasks in the
backlog. Also, he is in charge of accepting or
declining the implemented solutions. He defines and
maintains the Applications/IT metrics.
The scrum masters are responsible for
implementing Scrum and for doing the follow up
with the project teams. They facilitate the
communication between the different stakeholders
(their respective teams and owners).
The business and the application/IT teams are in
charge of implementing their respective backlogs.
Regarding the Ceremonies, we suggest to keep
Scrum Ceremonies for the business and the
application/IT. Also, we propose to add four others
at the architectural level: preparation meeting, kick
off meeting, weekly meetings and review meeting.
The preparation meeting gives the opportunity to
the different owners to know each other. The
architecture owner then explains the proposed
current analysis and To-Be architecture and shows
his backlog. The business owner and the
application/IT owner can challenge him regarding
his proposition or agree immediately.
The Kick off meeting allows the team sharing the
intermediate EA planning. Each of the members of
the committee share their release planning, their
backlogs, their KPIs and their sprints iterations. It
marks the official start of the cycle.
The weekly meetings permit the synchronization
between the three owners, the adaptation of backlogs
and the review of the KPIs. It allows the correction
of shots and the monitoring of the progress. Before
those meetings, each owner (Business,
Application/IT) has a weekly with his scrum master
as a checkpoint.
Finally, the review of the EA is the final step of
the work on an intermediate EA. The Team
members have the opportunity to inspect and adapt
their processes. They qualify what went right, what
could have gone better, and what can be made better
in the next cycle.
Regarding the artifacts, scrum ones remains the
same for business and Application/IT layer:
"Business Backlog", “Application/IT Backlog”,
“Sprint Backlog” for Business and Application/IT
layers. We add some other artifacts on the
architecture level. First, a Strategy model As-Is and
To-Be. Second, the chart of Key Performance
Indicators to monitor the transition from the As-Is to
the To-Be. Finally, the “Architecture Backlog” that
that lists prioritized features at the architecture level.
6 CASE STUDY
We present a case study to illustrate the proposed
Adaptive Enterprise Architecture model.
XYZ is a large company with a B2B and a B2C
channels. It is a manufacturing company with
providers and distribution partners located in many
countries. With the digital transformation trends,
they envision to develop their online visibility in
both channels. After analysing those elements, the
enterprise would like to go from EAi : Enterprise
without online channel to EAi+1 : Enterprise with
online channel. For the sake of simplicity we will
only focus on one aspect of EAi+1which is online
selling in B2C. To describe the application of the
model on the case studied, we will do it by steps.
In the beginning of the project, the architecture
owner takes the lead; he checks the As-Is
cartography of the current EA. Then, he runs the As-
Is assessment. In our case, he used the SWOT matrix
that summarizes as in the following. First, the
strengths are: Well positioned in the market share,
Strong customer relationship, Strong brand and
business reputation, Successful marketing strategies,
Strong organisation with well known processes.
Second the weaknesses are: High costs due to
storage in distributors stocks, Aged inventory,
Classic channel only, No online marketing strategy.
Then, the main opportunities are: Competitors
products have less quality, High demand on products
in many areas. Finally, the threats identified are: A
lot of competitors with similar products, Online
advertising campaign on B2C level by competitors.
After the identification of the main limitations
and the study of the current architecture, he then
uses i* concepts to formalise the To-Be architecture.
For the sake of simplicity, we will display only one
Soft Goal: Ensure online shopping deployment.
An Approach for Adaptive Enterprise Architecture
743

Figure 3: Goal modelling of the To-Be architecture.
Then, he creates his own backlog “Architecture
backlog”: “As digital company, I have online
shops”, “As a digital company, I can develop
strategic alliances with online partners”.
Now, that the architecture owner has all the
founding elements, he runs the preparation meeting
to align with the two other owners. As he was not
challenged by the Business Owner and
Application/IT owner regarding the backlog content,
they moved forward and did the Kick off meeting.
As a result, all the backlogs were created as follow.
The elements presented are only the main ones.
• Business Backlog: “As member involved in
online business, I have a business process with
validation hierarchy that handles online
payment”, “As marketing manager, I have a
process of validation of online assets”, “As
partner manager, I have a clear process of
onboarding online partners”, “As member of
management team, I can track online business “
• Application/IT Backlog : “As online buyer, I
can authentificate”, “As online buyer, I can
select items and add them to my bucket”, “As
online buyer, the products displayed are the
ones in stock”, “As online decision maker, I
can know the most demanded elements and
estimate the demand”, “As online decision
maker, I can monitor the penetration rate per
country.”, “As online partner, I can run the
syndication at the frequency that I need.”.
Then the owners defined the KPIs and metrics
that will help them assess their improvement:
Number of online shops created on partners
websites, Number of landing pages created on
official websites, Penetration rate using online tools
over the testing period, Number of delays, errors
after the implementation of the online process /
internal complaints, Number of external complaints,
Market share increase.
Finally, before starting the work with the
respective teams, the business and the application/IT
owners estimated with the scrum masters the number
of iterations needed. During the weekly meetings,
the owners assessed their improvement and resolved
the new requirements. They also shared with the
architecture owner the bottom up feedback from
their teams.
7 CONCLUSIONS
In this paper we explored the usage of some of Agile
Software Development (ASD) values in order to
meet the criteria for Adaptive Enterprise
Architecture: multilevel of dynamics, sensing and
responding to change, handling unforeseen changes,
process of adaptation, explicit management of
adaptability trade-offs and the evaluation of
adaptation. Then, we outlined our approach that uses
some ASD values. Finally, we illustrated our method
via a case study.
The main contribution in this paper is to
stimulate discussion about the requirements and the
methods of adaptation of EA to increasingly
changing environments. In subsequent work, we aim
to deep dive into the evaluation part by defining
some standard KPIs and exploring the use of data
driven analysis on To-Be architectures.
REFERENCES
Aarnink, A., & Kruithof, G. (2012). Contribution of agile
software development methods to business-IT
alignment in non-profit organizations.
Communications of the IIMA.
Ambler, S. W. (2003). Agile Enterprise Architecture:
Beyond Enterprise Data Modeling.
Anwer, F., Aftab, S., Shah, S. M., & Waheed, U. (2017).
Comparative Analysis of Two Popular Agile Process
Models: Extreme Programming and Scrum.
International Journal of Computer Science and
Telecommunications. pp. 1-7.
Armour, F. J., & Kaisler, S. H. (2001). Enterprise
architecture: Agile transition and implementation. IT
professional. pp. 30-37.
Babar Z., Yu, E. (2015). Enterprise architecture in the age
of digital transformation. International Conference on
Advanced Information Systems Engineering. Springer.
pp. 438-443.
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
744

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A.,
Cunningham, W., Fowler, M., & al. (2001). Manifesto
for agile software development.
Buckl, S., Matthes, F., Monahov, I., Roth, S., Schulz, C.,
& Schweda, C. M. (2011). Towards an agile design of
the enterprise architecture management function. IEEE
15th International Enterprise Distributed Object
Computing Conference Workshops. pp. 322-329.
Canat, M., Català, N. P., Jourkovski, A., Petrov, S.,
Wellme, M., & Lagerström, R. (2018). Enterprise
Architecture and Agile Development: Friends or
Foes?. 22nd International Enterprise Distributed
Object Computing Workshop (EDOCW). pp. 176-183.
Chernobai, A., Ozdagli, A., & Wang, J. (2020). Business
complexity and risk management: Evidence from
operational risk events in US bank holding companies.
Journal of Monetary Economics.
Daoudi W., Doumi K., Kjiri L., (2018). In Press. Adaptive
Enterprise Architecture: comparison of approaches,
International conference on modern intelligent
systems concept, Morocco.
Daoudi W., Doumi K., Kjiri L., (2020). In Press. Adaptive
Enterprise Architecture: Towards a model, 10th
International Conference on Information Systems and
Technologies, Italy.
David, F. R. (2008). Strategic Management: Concepts and
Cases: International Version.
Dietz, J. L. G. (2006). Enterprise ontology—theory and
methodology, Springer, Berlin
Doumi K. (2013). Approche de modélisation et
d’évaluation de l’alignement stratégique des systèmes
d’information Application aux systèmes d’information
universitaires. PhD Thesis.
Doumi, K., Baïna, S., & Baïna, K. (2011). Experimenting
a modeling approach for modeling enterprise strategy
in the context of strategic alignment. In International
Conference on ENTERprise Information Systems.
Springer. pp. 356-368.
Dybå, T., & Dingsøyr, T. (2008). Empirical studies of
agile software development: A systematic review.
Information and software technology. pp. 833-859.
Franch, X., López, L., Cares, C., & Colomer, D. (2016).
The i* framework for goal-oriented modeling.
Domain-specific conceptual modeling. Springer. pp.
485-506.
Gavrilova, T., Kubelskiy, M., Kudryavtsev, D., &
Grinberg, E. (2018). Modeling methods for strategy
formulation in a turbulent environment. Strategic
Change. pp. 369-377.
Guérineau, B., Rivest, L., Bricogne, M., & Durupt, A.
(2016). Agile and project-planned methods in
multidisciplinary product design. In IFIP International
Conference on Product Lifecycle Management.
Springer. pp. 108-118.
Hanschke, S., Ernsting, J., & Kuchen, H. (2015).
Integrating agile software development and enterprise
architecture management. 48th Hawaii International
Conference on System Sciences. pp. 4099-4108.
Hensema, M. A. (2015). Applying Agile in Enterprise
Architecture. Master's thesis, University of Twente.
Hinkelmann, K., Gerber, A., Karagiannis, D., Thoenssen,
B., Van der Merwe, A., & Woitsch, R. (2016). A new
paradigm for the continuous alignment of business and
IT: Combining enterprise architecture modelling and
enterprise ontology. Computers in Industry. pp. 77-86.
Kitsios, F., & Kamariotou, M. (2019). Business strategy
modelling based on enterprise architecture: a state of
the art review. Business Process Management Journal.
Lankhorst, M. (2009). Enterprise architecture at work.
Volume 352. Springer, Berlin.
Proper, H., & Lankhorst, M. M. (2014). Enterprise
architecture-towards essential sensemaking. Enterprise
Modelling and Information Systems Architectures
(EMISAJ). pp. 5-21.
Pulkkinen, M., & Hirvonen, A. (2005). EA planning,
development and management process for agile
enterprise development. 38th Annual Hawaii
International Conference on System Sciences. pp.
223c-223c.
Rhubart, B. (2010). Agile Enterprise Architecture. Oracle
Magazine. p. 32.
Rubin, K. S. (2012). Essential Scrum: A practical guide to
the most popular Agile process. Addison-Wesley.
Schwaber, K. (1997). Scrum development process. In
Business object design and implementation. Springer,
London. pp. 117-134.
Simon, H. A., Dantzig, G. B., & Hogarth, R.
(1986).Report of the research briefing panel on
decision making and problem solving. Research
briefings. pp. 17-36
Taft, D. K. (2005). Microsoft lauds' scrum'method for
software projects. EWeek.
The Open Group (2011). TOGAF Version 9.1. The Open
Group Architecture Framework.
Yu, E., Deng, S., & Sasmal, D. (2012). Enterprise
architecture for the adaptive enterprise–A vision
paper. In Trends in Enterprise Architecture Research
and Practice-Driven Research on Enterprise
Transformation. Springer, Berlin. pp. 146-161.
Zhang, X., Murad, A., Risher, A., & Simmons, J. (2016).
How to Measure IT Effectiveness: The CIO's
Perspective.
An Approach for Adaptive Enterprise Architecture
745