Dual Capability EAM for Agility in Business Capability Building:
A Systems Theoretical View
Jouko Poutanen and Mirja Pulkkinen
Faculty of Information Technology, University of Jyvaskyla, Finland
Keywords: Enterprise Architecture Management, Complex Adaptive Systems, Business Agility, Dual Capability EAM.
Abstract: Through two cases of IT-enabled business capability building in large enterprises, this paper elucidates how
the systems theory approach can explain the enterprise architecture management (EAM) challenge to support
business agility. The observation in both of these cases is that a legacy EAM approach does not adapt to a
business development scenario involving agility. This leads to a study of the nature of the challenges in EAM
when enabling strategic business moves involving new technologies, at the business unit level. For the type
of projects as in these cases, we do not find a fitting paradigm in the EAM literature. Suggested solutions are
IT bimodality, or Two Speed IT. However, its combination with EAM is scarce in earlier research. To be able
to provide guiding ideas for the further development of a dual capability EAM approach, with an evident need,
we develop a systems theoretical starting point to examine the cases. Complex Adaptive System (CAS)
characteristics appear to give the necessary explanations to build on. Supported by this theoretical
development, the study results in principles of a dual capability EAM, for agile strategic business capability
building involving enterprise re-structuring.
As enterprises see dazzling business opportunities
with new technologies, they face governance
challenges in the areas of e.g. risk and security
management. IT Governance as the broadly accepted,
value based approach (Op’t Land et al. 2008), with
Enterprise Architecture Management (EAM) as a
tool, points to the need to consider the value of any IT
investment for the enterprise, as well as direct and
monitor the planning and implementation of the
induced business change. This requires a balanced
development at the corporate level, as opposed to
individual business units developing their specific
solutions and running the risk of partial optimization,
potentially even counterproductive to the corporate
goals (Ahlemann et al. 2012, Peterson 2004). The
EAM process, supporting the goal of circumspect
decision making, joins the technological viewpoint to
the business goals. If a novel IT solution needs
integration to the existing architectures, engaging the
corporate IT function is necessary, and their
responsibility continues with the planning and
executing of the operation, support and maintenance
of the new system. However, the corporate IT and
EAM aiming at the alignment of business and IT
developments with an architectural approach
(Ahlemann et al. 2012) can be questioned as a
“legacy” approach, with “bureaucratic” governance
models hampering agile development both for the
business and for IT (Drews et al. 2017). Therefore,
EAM practices might need a revision for cases of
agile IT-driven business unit level development,
enabling the swift seizing of new digital business
opportunities. In their covering review of
organizational (business and IT) agility, Tallon et al.
(2019) give a thorough understanding of the
complexity of the problem. While capability building
and the dynamic capabilities dominate as theoretical
stance, with some, the question of architectural
modularity (Tiwana and Konsynski 2010) and
decision rights Tiwana and Kim (2015) point to
similar observations as are triggering our interest in
this study, especially the co-location of knowledge
and the decision rights pointed out in Tiwana and Kim
Research has evidenced the IT corporate functions
transforming to Bi-modal or two-speed IT (Haffke et
Poutanen, J. and Pulkkinen, M.
Dual Capability EAM for Agility in Business Capability Building: A Systems Theoretical View.
DOI: 10.5220/0010455007260734
In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 2, pages 726-734
ISBN: 978-989-758-509-8
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
al. 2017; Horlach et al, 2016). In academia, the term
ambidexterity has been coined for the dual IT
function capability (Lee et al. 2015). An IT unit with
this double approach serves the business not only
with agile development, but also with new culture-
changing approaches, as DevOps, further joined with
the business developers to BizDevOps (Gruhn et al.
2015). The duality means also ensuring sustained
support for balanced long-term planning and
governance with risk management at various levels.
A ‘fast IT’, however, is a solution only where the
developments are conducted in-house, with the
enterprise IT resources.
In our case study, we observe the need for a
business agility, where IT solutions new to both the
business and the IT in the enterprises are a strategic
choice as new business capability enablers. Both
cases, however, see a corporate strategy requiring an
assured and well managed EA as well. As not all of
the development resource is coming from in-house, a
re-organization of the IT function alone is not solving
our case problem. The more pertinent question is,
how to enable similar, agile strategic moves in future,
as the present EAM approach, in these enterprises and
in general, appears not to tackle the situation. The
question for this study is:
RQ How can EAM support business capability
development in an agile manner, when it involves the
building of a new system and a new unit, changing the
enterprise structure?
To understand the managerial challenge, on both
the business and the IT side, and to propose a solution
for these cases, we look at potential theoretical
explanations. Already existing solutions are screened
in a literature review for Enterprise Architecture
Management and Bimodal or Two Speed IT.
Dealing with a complex setting with business
systems embedded in an environment of an enterprise
as a system of systems, we propose a systems
theoretic explanation for the situation at hand in
Section 2, and discuss the EAM role. In section 3, we
describe two cases of new technology induced
business development, and present an analysis in
Section 4. We reflect the analysis to EAM in section
5. As a result, we propose guidelines for a business
agility enabling, dual capability EAM in Section 6.
1.1 Earlier Studies
For the literature review, conducted in early 2019, we
first checked both the IEEE Xplore portal and Google
Scholar and used the search strings i)“’Bimodal IT’
AND ‘Enterprise Architecture Management’”, and
ii)“’Two Speed IT’ AND ‘Enterprise Architecture
Management’”. As IEEEXplore did not yield results,
Google Scholar attains broader coverage for this
rather novel area. A further gain is to find non-
published scholarly work such as theses. The results
with the two search strings respectively yielded eight
and nine hits, and after deleting overlaps in the two
sets, plus excluding work not written in English, the
following items remain:
Three MSc Theses: (Boekholtz 2017; Schmid
2018; Natalucci & Manzotti 2016), the last one with
a generic stance on digitalization.
A dissertation (Andersen 2016), focusing on the
technology dimension of EA,
• Four scholarly peer-reviewed articles (Drews et
al. 2017; Fortmann et al. 2019; Keller et al. 2018;
Legner et al. 2017).
• Further three articles, published for another field
of research, appeared to be not in the scope.
The search was not limited with time of
publication meaning that this topic only has emerged.
Three empirical studies, (Drews et al. 2017; Keller et
al. 2018; Legner et al. 2017) present elaborations of
the problem area. However, first of them, as also the
MSc theses, present digital-only business cases in the
sector in the front-line of digitalization: banking and
financial. Another paper (Fortmann et al. 2019)
studies the developments over time within an IT unit
in a digitalization case, and Keller et al. (2018) collect
general practitioner knowledge from IT-departments.
Our study, on its part, investigates two cases where a
digital tool or a new service is only a part of the
business portfolio in a non-digital business, and we
go beyond the studies of the IT department/IT
function. The technologies (AI and IoT) are novel to
the enterprises, both profiling as latecomer
digitalisers (Kohli et al. 2011). For both, the project
means new business capability development.
At the same time, due to the development project,
our cases present enterprises with a challenge in the
IT governance de-/centralization question (Peterson
2004), and also defining the role of their EAM team
as part of the governance. The involvement of the IT
function during development projects low, thus not
suggesting that a dual capability or multimodal IT
function would solve all of the problem. Further, the
solutions are not built on systems already operated on,
so DevOps, or BizDevOps although interesting
approaches, are not a fitting paradigm.
Dual Capability EAM for Agility in Business Capability Building: A Systems Theoretical View
2.1 Enterprises as Systems of Systems
Beyond the practical solutions, as introducing agility
to the organization of the IT function (e.g. Haffke et
al. 2017), and methods for agile development, also
extended to EA (e.g. Drews et al. 2017), more
fundamental questions of the problem field of EAM
have been presented (Abraham et al. 2013; Buckl et
al. 2009). To solve the problem of the controversial
roles of EA or EA management: An enabler of agility
on one hand, however, on the other, questioned as a
‘bureaucratic’ and therefore slow approach, we study
the underlying controversy by examining the systems
nature of enterprises. The cases we study show the
need for an architectural governance to comply with
the ITG and corporate governance, but on the other
hand, also the urgency to rapidly respond to the
business environment change involving technology.
The latter is as compelling from the business side by
corporate governance, to sustain and improve the
value creation in the enterprise.
Systems theories give a widely embraced even
though not fully utilized theoretical scheme,
underlying the EA field, as a recent review finds
(Nurmi et al. 2018). Figure 1 presents a simple sketch
of the interacting systems in a system of systems, as
an enterprise can be analytically seen. We lean on the
main idea in the General Systems Theory (GST) and
Living Systems Theory (LST), both proposing
hierarchical levels of systems complexity (Abraham
et al. 2013; Nurmi et al. 2018). Within the enterprise,
comprising a large complex, adaptive system (CAS)
(Janssen & Kuk 2016), there are both fully
manageable, predictable technical sub-systems, some
more complex socio-technical sub-systems, as well as
adaptive sub-systems (where the decision freedom is
given by the system-of-systems management system,
controlling the systems/sub-systems within the
enterprise). A CAS is capable of directing and re-
directing their actions and resources at their disposal,
according to the signals they perceive from their
environment. The new business capability (that also
can be perceived a new “socio-technical” system),
forms a sub-sub-system under the auspices of a sub-
CAS. Its ownership is normally with a business unit
(the sub-CAS), the whole enterprise thus seen as a
CAS-of-CASs. In a similar vein, Abraham et al. (2013)
have introduced enterprises as “hierarchical, multi-
level systems”, however, leaving the adaptiveness
aspect for further study.
Capability as an “ability to execute a defined and
repeatable pattern of activities” to produce a targeted
outcome in a given environment, has been found a
practicable unit for analysing the business
architecture as part of EA (Simon et al. 2014). A
business capability entails the respective processes,
entities, organizations, people, culture, and resources
needed to successfully perform an activity for its
targeted business outcome. A business capability can
be dependent on IT (IT-enabled), or improved by IT
Figure 2: Enterprise as a collection of multiple, multi-level systems at different levels of complexity.
ICEIS 2021 - 23rd International Conference on Enterprise Information Systems
The concept of capability, however, highlights the
need for an “ensemble of resources” for building a
‘socio-technical system’ from the ‘technical system’
with the business resources before it can perform.
Where there are resources, there is also
ownership, management and decision making power.
The decision making levels (Pulkkinen 2006;
Pulkkinen & Hirvonen 2005) as well as the systems
theories analytically presenting them (Abraham et al.
2013); have been a subject of study in EAM. We see
that an evolutive, explorative EAM that allows for
piloting solutions at the business unit level (a.k.a EA
segment, or domain; see Bruls et al. 2010; Pulkkinen
2006) is a question of an instance of systems
evolution, inducing the re-structuring of the (sub-)
systems within the enterprise.
Importantly, the units of the enterprise use their
domain knowledge (Tiwana and Kim 2015), both in
capturing and interpreting signals urging for
response from their environment in environmental
scan (Tallon et al. 2019), introducing the self-
organising trait of CAS. As essential is also the
internal domain knowledge, also of the existing IT
resources, managed with EA. This is needed for the
planning and enacting the change in the systems to
respond, even proactively, to the environment
pressures, as the emergence trait in CAS: Adapting
(sub)systems to the business environment changes.
2.2 Enterprise Architecture
Reflecting on the theoretical frame in Figure 1, the
role of EAM is to attain awareness, assurance and
alignment, across all the systems, as well as the need
for analytical tools and planning aid (Ahlemann et al.
2012, Doucet et al. 2009; Aier et al. 2009). This is
needed for the IT (technical systems), together with
the business management and governance (Ahlemann
et al. 2012). The development of new capabilities
requires awareness of the existing IT (and other)
resources and architectures, as well as the alignment
of goals and resources. Analysis of both business and
IT architectures, and support for planning as the EA
techniques does, can support agility in capability
building and re-building (Pulkkinen & Hirvonen
2005). Methods for agile EA development (Boekholtz
2017, Bente et al. 2012) however, do not guide in
developing a managerial system for oversight and
control (EAM).
The EAM as a tool of ITG for both exploitation
and exploration should possess mechanisms that
allow it to put resources in conducting the
environmental scan and subsequently, to plan and
implement change as needed, however, backed up
with the corporate EA principles to ensure
compliance, interoperability and balance. The EAM
is to be equipped for firstly, enabling the architectural
flexibility needed, secondly, the re-structuring of the
systems, even reflecting to enterprise structures if
needed after new system implementation.
Our two cases faced a common problem, although
fundamentally different: “Alpha” is a large public
agency, “Beta” a private corporation. A strategic
choice in both is, to develop a new business capability
with a technology new to the enterprise, the corporate
IT and the business units. The strategic intent entails
a fast move. Alpha is building a virtual customer
service assistant leveraging AI, and aims at a ‘first
mover’ advantage with this technology. Beta
implements a new business service concept applying
IoT, to support the users of their physical technology-
intensive product customers.
Both organizations have a corporate IT
department, with an associated EAM function to
guide enterprise IT developments. In both cases alike,
a business function specific goal, sensed at the level
of the function management, triggers a new business
capability development. The business function level
technology scan (although not officially assigned to
do this!) in both cases spotted new technology
enablers (AI, IoT) on the market, not currently used
in their organization. For a rapid strategic move,
building a new IT capability within their corporate IT
units required for AI/IoT would take too much time
and is therefore rejected in both cases. The
transforming of the IT unit to bimodality would not
solve the problem. The EAM, on its part, is to ensure
compliance and risk management as the new
technological capability enablers are integrated into
the enterprise IT architectures.
Table 1: The data for the qualitative analysis.
Data sources available Case Alpha Case Beta
Strategy and plans
Yes Yes
Organizational guidelines
& standards (documents)
5 4
Project plan Yes Yes
umber of design
workshops (1-2 hours each)
21 18
umber of workshop
participants from
5-6 2-11
Dual Capability EAM for Agility in Business Capability Building: A Systems Theoretical View
Table 2: The Case Analysis: The Emerging of a New Capability as a Sub-Subsystem.
Case attribute Alpha Beta
Business driver
Strategy deployment, customer service
Strategy deployment, growth
Capability developed
ew AI-based virtual assistant service
channel for customers
ew business concept: Afte
product service with IoT support
Business goals
Service quality improvement
Cost savings
First agency to deploy AI
ew revenue fro
novel service
Customer commitment to product
Key technological goal to
develop enterprise IT
AI adoption in a pilot service area for
further deployment
IoT platform deployment
Sensor data analytics adoption
Initiative and project
Customer Service Development Unit –
to be handed over to customer channel
Business Development Unit – to be
handed over to a new unit
ovelty of the solution High (no prior AI implementations)
High (no prior implementations or IoT
/ SDA)
7 Type of solution Pilot implementation
Production quality
Table 3: The role of EAM prior to the project.
Role of EAM Alpha
Focus of the EAM team
Business systems,
Administrative systems
Administrative systems
EAM role in the project Informed Consulted
Perceived role of EAM Slow, no value Slow, limited value
EAM role in post-
implementation phase
Standardization of the solution
Created EA knowledge retention
Standardization of the solution
Created EA knowledge retention
Case attribute Alpha
Business driver
Strategy deployment, customer service
Strategy deployment, growt
Capability developed
ew service channel for customer service
ew business concept (Afte
product support service)
Research Method. The research data (see Table 1
above) used for the qualitative content analysis refers
to the work documents, interviews and workshops
during case projects. The first author was observing
the cases during the project lifetime: Alpha 6 months,
Beta 12 months. The workshop participants were
business process owners, and members of LoBs,
business development and IT departments.
As seen in Table 2, both cases examined involve the
implementation of the organization strategy.
However, the scanning and sensing that triggers the
development comes from a lower echelon. The
urgency element in both points to business agility.
Initiative Ownership. The lead in the explorative
development is with the line of business (LoB). They
have the required knowledge of the customer needs
and a vision of the new service, i.e. the understanding
what the technology can do for the business. The LoB
is also responsible of the end result: In case Alpha, an
improved customer service, and for Beta, a new
revenue creating after-sales service. The LoB as a
decision unit needs to have the necessary decision
freedom for the evolution of the systems it has
ownership on.
Pointing to a business capability perspective, it
was crucial to approach the development from the
customer and process perspective, i.e. including all
business capability elements, identifying new
processes and roles, finally creating an emerging
socio-technical system. Automated service requires a
new level of understanding the customer needs. The
AI components and content management require new
tasks, skills and tooling. Especially, for the AI
solution, managing the corpus and the ground truth
training and testing were novel additions to Alpha
Role of EA. The value of quality EA artefacts is
evident in providing the context and the new solution
content, as well as understanding the effect on
existing processes. In case Alpha, EA provided the
necessary understanding of the context of the piloted
ICEIS 2021 - 23rd International Conference on Enterprise Information Systems
solution and was the basis for the design of the to-be
architecture. In case Beta, it provided the information
of the integration requirements and data models. In
both cases, the solution architecture will evolve to be
part of the new business and IT architectures.
Role of EAM initially (depicted in Table 3)
evolves to enabling the technology transfer to diffuse
the solution in the organization, supporting to
generalize it for other use cases. The legacy role of
the EAM team, a ‘regulatory’ one as perceived in
both cases in the beginning, is therefore challenged.
EAM is extended to a supportive role for business and
systems evolution. Traditionally, EAM in general has
a role to control and ensure conformity with
standards. For fast progress, sourcing must be
extended beyond own resources. In the case of novel
technology, an organization might not have the
requisite IT knowledge, neither time to develop it.
Sourcing management can be supported by EAM as
well. Finally, incorporating the results and the new
knowledge to the EA for further use is, however,
In agile business development situations, EA is a
tool for an agile but balanced management, with
sound but flexible, dual capability EAM. The EAM
may have a consultative role during the development,
or take on only afterwards. After the project, the EAM
team retains architectural knowledge and manages
the further deployment of the developed solutions.
Both cases highlight the task of EAM to maintain and
update the EA related information (as an example of
“cartography” (Simon et al. 2014)) for further
developments. From a CAS point of view, the EAM
supports the emergence of the novel socio-technical
system, isolated for development time and afterwards
being adjusted into the new EA baseline, and a new
organization structure emerging with the
development. We discuss this next.
Enterprise Architecture and EA management relate to
the systems nature of enterprises (Abraham et al.
2013). For EAM, earlier studies suggest explaining
models (Abraham et al. 2013; Buckl et al. 2009) but
focusing on the EAM itself, leaving the enterprise as
a system of systems in the background. Theoretical
explanations give an analytical tool to understand the
problem field and further consequences:
We looked at the research question: How can
EAM support business capability development in an
agile manner, when it involves the building of a new
system and a new unit, changing the enterprise
The point of view of the EAM is an embedded
governance system for the system of systems.
Looking at the cases, we see that the incurring
phenomena can be explained as a “systemic
evolution” of the enterprise as a system of systems.
Itself being a CAS (of CASs), the enterprise contains
a number of sub-CASs. The focal point in our study
are the business line management in charge of
business performance on their own area, thus in
charge of a sub-CAS.
Within the decision freedom given in the
enterprise strategy they develop the LoB strategically.
Potential changes in the decision making structures,
and the re-structuring of the units is a delicate matter,
also in the case of the new capability building. As new
managerial tasks and roles may open with the new
business capability, and the re-organization of the
units may be necessary, a negative development may
follow in other parts. This calls for enabling the
evolution and the birth of a new sub-CAS (a unit) on
one hand (self-organising and emergence
characteristic of CAS), and on the other hand, the
revision of the enterprise structures and lines of
decision making, as needed.
IT developments normally are monitored by the
EAM function to deploy the current enterprise
strategy (from the point of view of the business), and
to follow the set EA principles and standards (from
the IT managerial viewpoint). The monitoring and
control of compliance requires formal processes,
takes time, and introduces rigidity to development
projects. A pilot project means experimental learning,
and the strategic choice in our cases was to leave the
development into the hands of the LoBs (in both cases
running a temporary project organization). In this
situation, i.e. an organizational change
(organizational re-design), an interim, development-
time structure (Pulkkinen 2006) is keeping the project
as a “development time EA segment” (or domain),
managed by the temporary team that is developing the
new capability. For development time, it is isolated
from the rest of the enterprise structures and EA. The
team engages both enterprise and outsourced
capacities (provider experts). This enables the new
capability building and testing prior to integrating it
to the rest of the enterprise and its EA, as well as a
managed transition to a new organizational structure.
This provides a method to implement emergent
behaviour of a CAS in a controlled manner.
For the IT organization and EAM, in both cases,
the solution of choice was not to establish a new
“agile IT” unit, with, or without EAM, but to employ
Dual Capability EAM for Agility in Business Capability Building: A Systems Theoretical View
resources as needed, which resembles more the
BizDevOps –type (Gruhn et al. 2015) of organizing
in a temporary team. However, the DevOps mode was
not a possibility, since there were no system operators
to be involved, as the development was not on
existing systems. The developers were to a large
extent hired. The enterprise strategic management
supports in both cases the agile piloting, justified by
the import of knowledge (use of IT providers) to
inject knowledge and to foster organizational learning
and development, since the strategy sees for further
deployment of the chosen technology. The
organization and EA design created in the
development domain can be captured as a new
version of segment business architecture and, with the
knowledge created in the pilot project, replicated as
reference architecture to other segments of this
enterprise for their capability development.
As to the explaining theories, changes in the EA
segment structures mean that the systems structure of
the enterprise evolves. New technology is the core
technical system, entailing a new socio-technical
system to emerge, with among other things a new
business process to be designed as the core of a new
capability to be established. New EA segment
structure means evolution of the sub-CASs within the
The starting point of an evolution step can be a
sub-CAS (a business unit) perceiving itself urging
signals from its environment, and – with the
management system, i.e. the top echelon, allowing
can act upon them, finally leading to modifications,
or “systemic evolution”, in the structure of sub-CASs
within the enterprise.
The signal triggering a new capability
development arises from the business environment.
For the enterprise governance, it may be not clear
which LoBs are affected. For a given signal, the LoB
whose domain knowledge understands the use case
best, is also familiar with the specific requirements,
such as legislation and industry standards. The self-
organizing behaviour according to the theory on CAS
is enabled by the flexible EAM, that considers both
the potential in achieving goals (i.e. business
performance) and the risks involved. In addition,
when the LoB is allowed to innovate, new useful
patterns might emerge, that are not part of the current
EA (requisite variety), but can be potentially useful
for further units in the enterprise. This is one of the
known benefits of a managed EA, and the
segmentation of EA as an aspect of it, allowing for
agile piloting – a capacity of the EA with defined
Concluding from the observations and their analysis,
an emergent model of a dual capability EAM for
building new capabilities can be summarized as
After consideration of business potential and
risk, a temporary team is formed, led by the
LoB that owns the case (as a self-organizing
Representatives from the affected LoBs (co-
evolution) are engaged in the team, and the
requisite architectural and technical skills are
ensured with a necessary level of outsourcing.
The context of the solution is studied,
reflecting on the current EA, necessarily
including the business architecture.
The scope of the pilot is reduced to cover only
the novel elements, as a development-time EA
segment. For technology development, a
temporary development environment is
created; Cloud and virtualization technologies
are the agility enablers here.
During the experimentation phase, necessary
changes to the business processes, ownerships
(“decision unit”) and roles are designed and
assigned, or at least drafted. This means a re-
writing of parts of the business architecture,
forming also the new or modified EA-
segmenting structures: The new organization.
At the IT architecture level, the required
systems integrations at all levels of systems
and the constraints like standards to be applied
are identified.
Work and progress are measured with
minimized management and EAM control.
The viability of the solution and the proposed
value is evaluated during and at the end of the
If the outcome is positive and value-for-
business can created, the solution will be
consolidated, and it will be standardized with
the help of the EAM team for replication in
further segments with similar use cases. This
brings in the more traditional EAM role to
ensure coherency and consistency over the
whole enterprise IT.
IT is in both cases a trigger for the strategic
development case, leading to changes in the business
portfolios, business architecture structures, roles and
responsibilities, and finally potentially the decision
units, i.e. enterprise structure. Inducing this type of
organizational change is difficult, and the temporarily
ICEIS 2021 - 23rd International Conference on Enterprise Information Systems
isolated development time segment could give the
enterprise change management the necessary space
and time for adjustments. Thus the EAM allowing for
the development-time segment enables a smooth
transition, to the use of a new operational technical
system, as well as an emerging operational socio-
technical system.
Different from earlier cases we do not suggest a
permanent “fast IT EAM” to enable emergent
capability development. Potentially, with time, such
team also runs into similar problems as pointed out
with the bimodality of IT (Haffke et al. 2017).
Instead, the existing EAM provisions EA information
(baseline), and enables the work of the temporary
team resourced with EA skills. The use of a
temporary team forms the core of this dual EAM
capability. After the project, the stabilization and
standardisation of the solutions are given over to the
EAM team.
Both cases concerned building novel capabilities
that have clear and limited integration points to the
existing architecture. When upgrading existing
systems, the effort could be more demanding, due to
existing interconnections between system elements.
The dependencies would limit the freedom.
With only two cases in study, the generalizability
of the result might be limited. On the other hand, the
organizations were fundamentally different: Their
ownership (public / private), the nature of their
business (service / manufacturing). Also, the
solutions used different technology (AI / IoT). In spite
of these differences, the new technology project
organization and extending the role of EAM to a dual
capability approach in it were similar. Further study
is needed, if e.g. the novel solution would be more
interconnected within its context, and of course with
further types of organizations.
Abraham, R., Tribolet, J., Winter, R., Transformation of
Multi-level Systems – Theoretical Grounding and
Consequences for Enterprise Architecture
Management, in: Proper, H., Aveiro, D., Gaaloul, K.
(Eds.), Advances in Enterprise Engineering VII,
Springer Berlin Heidelberg, 2013, pp. 73-87.,
Ahlemann, F., Stettiner, E., Messerschmidt, M., & Legner,
C. (Eds.). (2012). Strategic en-terprise architecture
management: challenges, best practices, and future
developments. Springer Science & Business Media.
Aier, S., Kurpjuweit, S., Saat, J., & Winter, R. (2009).
Enterprise architecture design as an engineering
discipline. AIS Transactions on Enterprise Systems,
1(1), 36-43.
Andersen, P. (2016). Managing the IT Architecture: A
Multiple Case Study (Doctoral dissertation, Aarhus
Boekholtz, V. C. M. (2017). Improving Enterprise
Architecture at Agile Working Financial Organisations
(Master's thesis). Utrecht University the Netherlands
Bente, S., Bombosch, U., & Langade, S. (2012).
Collaborative enterprise architecture: enriching EA
with lean, agile, and enterprise 2.0 practices. Newnes.
Bruls, W. A., van Steenbergen, M., Foorthuis, R., Bos, R.,
& Brinkkemper, S. (2010). Domain architectures as an
instrument to refine enterprise architecture. CAIS, 27,
Buckl, S., Matthes, F., & Schweda, C. M. (2009, October).
A viable system perspective on enterprise architecture
management. In 2009 IEEE International Conference
on Systems, Man and Cybernetics (pp. 1483-1488).
Doucet, G., Gøtze, J., Saha, P., & Bernard, S. A. (2009).
Coherency management: Using enterprise architecture
for alignment, agility, and assurance. Journal of
Enterprise Architecture, 4(2).
Drews, P., Schirmer, I., Horlach, B., & Tekaat, C. (2017,
October). Bimodal enterprise architecture management:
The emergence of a New EAM function for a
BizDevOps-based fast IT. In 2017 IEEE 21st
International Enterprise Distributed Object Computing
Workshop (EDOCW) (pp. 57-64). IEEE.
Fortmann, L., Haffke, I., & Benlian, A. (2019). Navigating
Through Digital Transformation Using Bimodal IT:
How Changing IT Organizations Facilitates the Digital
Transformation Journey at Deutsche Bahn Vertrieb
GmbH. In Digitalization Cases (pp. 393-410). Springer,
Eisenhardt, K. M., & Graebner, M. E. (2007). Theory
building from cases: Opportunities and challenges.
Academy of management journal, 50(1), 25-32.
Gruhn, V., & Schäfer, C. (2015, September). BizDevOps:
because DevOps is not the end of the story. In
International Conference on Intelligent Software
Methodologies, Tools, and Techniques (pp. 388-398).
Springer, Cham.
Haffke, I., Kalgovas, B., & Benlian, A. (2017). Options for
Transforming the IT Function Using Bimodal IT. MIS
Quarterly Executive, 16(2).
Horlach, B., Drews, P., & Schirmer, I. (2016). Bimodal IT:
Business-IT alignment in the age of digital
transformation. Multikonferenz Wirtschaftsinformatik
(MKWI), 1417-1428.
Janssen, M., Kuk, G. (2006) A Complex Adaptive System
Perspective of Enterprise Archi-tecture in Electronic
Government, Proceedings of the 39th Hawaii
International Conference on System Sciences.
Keller, T., Baumgartner, T., & Brucker-Kley, E. (2018).
Towards a multi-modal IT. e-Society 2018, 209.
Kohli, R., & Johnson, S. (2011). Digital Transformation in
Latecomer Industries: CIO and CEO Leadership
Dual Capability EAM for Agility in Business Capability Building: A Systems Theoretical View
Lessons from Encana Oil & Gas (USA) Inc. MIS
Quarterly Executive, 10(4).
Lee, O. K., Sambamurthy, V., Lim, K. H., & Wei, K. K.
(2015). How does IT ambidexterity impact
organizational agility? Information Systems Research,
26(2), 398-417.
Legner, C., Eymann, T., Hess, T., Matt, C., Böhmann, T.,
Drews, P. & Ahlemann, F. (2017). Digitalization:
opportunity and challenge for the business and
information systems engineering community. Business
& information systems engineering, 59(4), 301-308.
Natalucci, M., & Manzotti, N. (2016). IT governance: how
Italian enterprises are reacting to technological
emerging trends.
Nurmi, J., Pulkkinen, M., Seppänen, V., & Penttinen, K.
(2018, May). Systems Approaches in the Enterprise
Architecture Field of Research: A Systematic Literature
Review. In Enter-prise Engineering Working
Conference (pp. 18-38). Springer, Cham.
Op't Land, M., Proper, E., Waage, M., Cloo, J., & Steghuis,
C. (2008). Enterprise architec-ture: creating value by
informed governance. Springer Science & Business
Panetto, H., Zdravkovic, M., Jardim-Goncalves, R.,
Romero, D., Cecil, J., & Mezgár, I. (2016). New
perspectives for the future interoperable enterprise
systems. Computers in Industry, 79, 47-63.
Peterson, R. (2004). Crafting information technology
governance. Information systems management, 21(4),
Pulkkinen, M. (2006, January). Systemic management of
architectural decisions in enterprise architecture
planning. Four dimensions and three abstraction levels.
In Proceedings of the 39th Annual Hawaii International
Conference on System Sciences (HICSS'06) (Vol. 8,
pp. 179a-179a). IEEE.
Pulkkinen, M., & Hirvonen, A. (2005). EA Planning,
Development and Management Process for Agile
Enterprise Development. In Sprague, R.H. Jr:
Proceedings of the Thirty-Eighth Annual Hawaii
International Conference on System Sciences. Big
Island, Hawaii, 2005, IEEE Computer Society (pp.
223). Los Alamitos, California: IEEE Computer
Rahimi, F., Gøtze, J., & Møller, C. (2017). Enterprise
architecture management: Toward a taxonomy of
applications. Communications of the Association for
Information Systems, 40(1), 120-166.
Robson, C. (2002). Real world research: A resource for
social scientists and practitioner-researchers. Wiley-
Schmid, L. (2018). Overcoming digitalization-driven
challenges in banks: An exploration of theory and
practice towards improving Enterprise Architecture
Management’s ability to sup-port rapid change. Turku
School of Economics, Finland
Simon, D., Fischbach, K., & Schoder, D. (2013). An
exploration of enterprise architecture research. CAIS,
Simon, D., Fischbach, K., & Schoder, D. (2014). Enterprise
architecture management and its role in corporate
strategic management. Information Systems and e-
Business Management, 12(1), 5-42.
Tallon, P. P., Queiroz, M., Coltman, T., & Sharma, R.
(2019). Information technology and the search for
organizational agility: A systematic review with future
research possibilities. The Journal of Strategic
Information Systems, 28(2), 218-237.
Tallon, P. P., & Pinsonneault, A. (2011). Competing
perspectives on the link between strategic information
technology alignment and organizational agility:
insights from a mediation model. MIS Quarterly, 463-
Tiwana, A., & Kim, S. K. (2015). Discriminating IT
governance. Information Systems Research, 26(4),
Tiwana, A., & Konsynski, B. (2010). Complementarities
between organizational IT architecture and governance
structure. Information Systems Research, 21(2), 288-
Tribolet, J., Sousa, P., & Caetano, A. (2014). The role of
enterprise governance and cartography in enterprise
engineering. Enterprise Modelling and Information
Systems Architectures (EMISAJ), 9(1), 38-49.
Yin Robert, K. (1994). Case study research: design and
methods. Sage publications.
ICEIS 2021 - 23rd International Conference on Enterprise Information Systems