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.

1 INTRODUCTION

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

https://orcid.org/0000-0002-5313-8666

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

(2015).

Research has evidenced the IT corporate functions

transforming to Bi-modal or two-speed IT (Haffke et

726

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

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

727

2 KEY CONCEPTS

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

(IT-enhanced).

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

728

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

Management

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.

3 CASE STUDY

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

organization

5-6 2-11

Dual Capability EAM for Agility in Business Capability Building: A Systems Theoretical View

729

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

improvement

Strategy deployment, growth

generation

Capability developed

ew AI-based virtual assistant service

channel for customers

ew business concept: Afte

-sales

product service with IoT support

Business goals

Service quality improvement

Cost savings

First agency to deploy AI

ew revenue fro

novel service

business

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

ownership

Customer Service Development Unit –

to be handed over to customer channel

management

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

Beta

Focus of the EAM team

Business 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

Beta

Business driver

Strategy deployment, customer service

improvement

Strategy deployment, growt

generation

Capability developed

ew service channel for customer service

ew business concept (Afte

-sales

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.

4 CASE ANALYSIS

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

capabilities.

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

730

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,

essential.

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.

5 DISCUSSION

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

structure?

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

731

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

enterprise.

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

segments.

6 CONCLUSIONS

Concluding from the observations and their analysis,

an emergent model of a dual capability EAM for

building new capabilities can be summarized as

follows:

 After consideration of business potential and

risk, a temporary team is formed, led by the

LoB that owns the case (as a self-organizing

CAS).

 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

project.

 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

732

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.

REFERENCES

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.,

http://dx.doi.org/10.1007/978-3-642-38117-1_6

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

University).

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,

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).

IEEE.

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,

Cham.

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

733

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

Media.

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),

7-22.

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

Society.

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-

Blackwell.

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,

32(1).

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-

486.

Tiwana, A., & Kim, S. K. (2015). Discriminating IT

governance. Information Systems Research, 26(4),

656-674.

Tiwana, A., & Konsynski, B. (2010). Complementarities

between organizational IT architecture and governance

structure. Information Systems Research, 21(2), 288-

304.

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

734