An effective Enterprise Architecture Implementation ... · An effective Enterprise Architecture Implementation ... 2.2 Enterprise Architecture Implementation Methodology ... The Open

ORI GIN AL ARTICLE

An effective Enterprise Architecture ImplementationMethodology

Fatemeh Nikpay1 • Rodina Binti Ahmad1 •

Babak Darvish Rouhani2 • Mohd Naz’ri Mahrin3 •

Shahaboddin Shamshirband4,5

Received: 14 September 2015 / Revised: 25 October 2016 / Accepted: 16 December 2016

� Springer-Verlag Berlin Heidelberg 2017

Abstract Enterprise Architecture (EA) is a holistic strategy that is commonly used

to improve the alignment of enterprise’s business and Information Technology.

Enterprise Architecture Implementation Methodology (EAIM) prepares a set of

methods and practices for developing, managing, and maintaining an EA imple-

mentation project. There is ineffectiveness in existing EAIMs due to complexities

emerging from EAIM practices, models, factors, and strategy. Consequently, EA

projects may encounter lack of support in the following areas: requirements anal-

ysis, governance and evaluation, guideline for implementation, and continual

improvement of EA implementation. The aim of this research is to develop an

effective EAIM to support EA implementation. To fulfill this objective, the first step

is to identify effective EA implementation practices and the factors that impact the

effectiveness of EAIM. In this regard, a Systematic Literature Review (SLR) was

conducted in order to identify the effective practices and factors of EAIM. Sec-

ondly, the proposed EAIM is developed based on the foundations and information

extracted from the SLR and semi-structured interviews with EA practitioners.

Finally, the proposed EAIM is evaluated by means of case study as the research

methodology. The target audience for this research is twofold: (1) researchers who

& Shahaboddin Shamshirband

[email protected]

1 Faculty of Computer Science and Information Technology, University of Malaya,

50603 Kuala Lumpur, Malaysia

2 Department of Information Technology and Communication, Payame Noor University, Tehran,

Islamic Republic of Iran

3 Advanced Informatics School, Universiti Teknologi Malaysia, Jalan Semarak,

54100 Kuala Lumpur, Malaysia

4 Department for Management of Science and Technology Development, Ton Duc Thang

University, Ho Chi Minh City, Vietnam

5 Faculty of Information Technology, Ton Duc Thang University, Ho Chi Minh City, Vietnam

123

Inf Syst E-Bus Manage

DOI 10.1007/s10257-016-0336-5

http://orcid.org/0000-0002-6605-498X

http://crossmark.crossref.org/dialog/?doi=10.1007/s10257-016-0336-5&domain=pdf

http://crossmark.crossref.org/dialog/?doi=10.1007/s10257-016-0336-5&domain=pdf

would extend the effective EA implementation and continue this research topic with

further analysis and exploration; (2) practitioners who would like to employ an

effective and lightweight EAIM for an EA project.

Keywords Enterprise Architecture � Implementation Methodology � Integration �Strategy � Information systems

1 Introduction

Enterprise Architecture (EA) provides a comprehensive strategy and environment

for aligning enterprise business and Information Technology (IT) (Ahlemann et al.

2012; Engelsman et al. 2011). Motivational factors for EA include increasing

competitiveness and coping with future changes (Wegmann et al. 2007). To provide

an appropriate environment for alignment between business and IT, EA describes

the baseline architecture (As-Is), elaborates the desired architecture (To-Be), and

represents the migration plan for transition from baseline architecture to desired

architecture for the enterprise (Finkelstein 2006). Four architectural levels including

business, data, application, and infrastructure need to be described in the three

aforementioned stages of an EA project (Rouhani et al. 2015a).

EA implementation requires two main components: an EA Framework (EAF)

and an EA Implementation Methodology (EAIM) (Pulkkinen and Hirvonen 2005).

EA employs an EAF as the underlying structure for modeling different aspects of an

enterprise; EAIM is the methodology for implementing the EA within an enterprise

(Shirazi et al. 2009; Tupper 2011). While the outputs of EAF are EA artefacts (i.e.,

diagram, model, document, and graph), an EAIM aims to implement the EA

artefacts inside an enterprise (van Steenbergen and Brinkkemper 2010; Wegmann

2003).

Effective EA implementation provides a stable and flexible environment for an

enterprise (Aier and Schelp 2010). Several EAIMs have been proposed in the

literature by practitioners and academics with different methods for implementing

the transition plan (Rico 2006; Wagter 2005).

There are several complexities in designing, modeling and implementing an EA

using existing EAIMs (Aier et al. 2009; Darvish Rouhani et al. 2014; Saat et al.

2009). There is ineffectiveness in existing EAIMs due to complexities in EAIM

practices, models, factors, and strategies (Rouhani et al. 2015b). Consequently, EA

implementation might be faced with the lack of support in requirements analysis,

governance and evaluation, guideline, and continual improvement. As such, an

effective EAIM can eliminate the ineffectiveness and mismatch between business

requirements and IT requirements and reduce the complexity of EA implementation

(Rouhani et al. 2014).

1.1 Paper goals and contributions

This research is divided into three main steps. The first step is to identify the

effective practices and factors, which affect the effectiveness of EAIM by means of

F. Nikpay et al.

123

a Systematic Literature Review (SLR) (Rouhani et al. 2015b). The second step is to

evaluate the identified factors by means of a survey of subject matter experts

(Darvish Rouhani et al. 2015b). Finally, this paper aims to describe the effective

EAIM. Each of the mentioned steps provides appropriate information for extending

the Enterprise Architecture Body of Knowledge (EABOD) (Hagan 2004).

The target audience for this research is twofold: (1) researchers who would

extend the effective EA implementation and continue this research topic with

further analysis and exploration; (2) practitioners who would like to employ an

effective EAIM in an EA project.

1.2 Paper structure

The remainder of this paper is divided into the following sections: an effective EA

implementation is described in Sect. 2; the research methodology is presented in

Sect. 3; the proposed EAIM is described in Sect. 4; the case study of the proposed

EAIM and its application, and discussion are given in Sects. 5 and 6 respectively;

and the conclusion is expressed in Sect. 7.

2 Related work

2.1 Effectiveness of enterprise architecture implementation

Several studies have been performed by both researchers and practitioners regarding

the effectiveness of EA implementation. The effectiveness refers to the degree in

which the developed EA artefacts can lead the enterprise to achieve its intended EA

objectives (van der Raadt et al. 2010; Weiss and Winter 2012). The EA

effectiveness is achieved when the developed EA artefacts inside the enterprise

meet the individual goals of stakeholders. In other words, EA function effectiveness

is: ‘‘The degree to which organizational objectives are attained through the outputs

of the EA function’’ (Morganwalp and Sage 2004).

The effectiveness of EA implementation play the key role on realizing the degree

to which EA implementation’s functions achieved the intended objectives that are

pursued. In EA implementation, the main concern is in the achievement of EA

functions. Obtaining the intended results by using the EA implementation practices

is the key concern of the effectiveness of EA implementation. Morganwalp and

Sage (2004) mentioned a number of qualitative objectives to measure the EA

effectiveness in terms of the pertinent objectives. Van der Raadt et al. (2010)

considered two dimensions, including: agility and alignment as the measurement

model of EA implementation.

According to (Darvish Rouhani et al. 2015b; Gunther 2014; van Steenbergen and

Brinkkemper 2010) the effectiveness of the EAIM reflects its objectives including:

guiding process, simplifying the process, and standardizing the process; Properties

including: customizability, compatibility, completeness, and conciseness; and

Components including deliverables, methods, techniques, and support tools.

An effective Enterprise Architecture Implementation…

123

Objectives reveal the intent of the methodology: what it claims to accomplish and

what the practitioner may expect of future releases. An effective EAIM should meet

at least three objectives as mentioned in the previous paragraph. Properties, such as

customizability, compatibility, completeness, and conciseness, reveal the inherent

qualities of an EAIM and are useful in identifying potential strengths and

weaknesses (Van Steenbergen and Brinkkemper 2010). Components are the basic

elements that represent the building blocks of the methodology (Gunther 2014).

Components help reveal the capabilities of the methodology. Components should

contain at least four parts, namely: deliverables, methods, techniques, and support

tools (Morganwalp and Sage 2004; van der Raadt et al. 2010; Van Grembergen and

Saull 2001).

2.2 Enterprise Architecture Implementation Methodology

In 1992, Steve Spewak represented the first EA methodology (Lankhorst 2012).

Spewak created the EA planning to cover all aspects of the EA lifecycle (Spewak

and Tiemann 2006). In other words, the EA methodology complements the EA

framework (Winter et al. 2010; Zachman 1987).

Several EAIMs (e.g., The Open Group Architectural Framework-Architecture

Development Method (TOGAF-ADM), Department of Defense Architectural

Framework (DoDAF), Enterprise Architecture Planning (EAP), and Federal

Enterprise Architecture (FEA)) have been proposed by academics and practitioners

in the literature (Rouhani et al. 2013; Saha 2012). Although these realizations are

different in implementation practices and development phases, they share similar-

ities in the concepts and principles of transition from As-Is to To-Be (Medini and

Bourey 2012). This transition is known as a ‘‘Migration Plan’’ (Darvish Rouhani

et al. 2014). There are two types of EAIMs: (1) EAIMs that are introduced by EAFs

such as TOGAF (which has a specific development method namely, TOGAF-

ADM), and (2) EAIMs that are developed independently from any EAFs such as

EAP.

Migration planning includes the set of methods with a clear definition for the

transitional processes to develop and implement the information systems (ISs) in

response to the business requirements (Buckl et al. 2010; Nikpay et al. 2013). EAIM

focuses more on the migration plan and provides methods and practices for

developing the To-Be architecture (Pulkkinen and Hirvonen 2005; Saha 2012).

The EAIM provides appropriate development techniques and method for EA

implementation (Agievich et al. 2012; Hirvonen et al. 2004). It covers all aspects of

the EA lifecycle, namely: planning for enterprise understanding (Malta and Sousa

2012), the analysis of business requirements, the design of systems, the evolution of

systems, and the ongoing enhancements of all of the above (Aier and Saat 2011;

Niemi 2013). EAIM provides the methods for analyzing, developing, and deploying

ISs in response to business requirements completely and concisely (Aier et al. 2009;

Winter et al. 2010).

F. Nikpay et al.

123

2.3 Comparison framework

This section defines the relevant criteria for comparing EAIMs. Table 1 shows the

description of the selected criteria.

The defined criteria are based on common practices in use by existing EAIMs

and requirements for effective EA implementation, selected based on the results of

the literature review regarding EAIM’s effective practices and interviews with EA

practitioners. Although there are several other criteria that can potentially be used

for comparison, the researchers are looking to use prevalent and simple criteria for

the research design.

This study selects the following EAIMs as examples for applying the proposed

comparison framework:

• EAP

• TOGAF-ADM

• DODAF

• FEA

Table 1 Description of criteria

Criteria Description

Iterative Refers to the iterative phases/practices of EAIM

Management process Refers to the management practices/process for managing the EA

implementation

Maintenance process Refers to the maintenance practices/process for keeping the EA

implementation up to date

Ability to work with

other EAF

Refers to the compatibility of the EAIM with other EAFs in the EA

implementation

Requirement

management process

Refers to the requirement management practices/process in order to provide

appropriate foundation and information for developing, managing,

implementing, and maintaining the EA

Step by step guideline Refers to the availability of step by step guidelines for better understanding

the implementation practices/process

Easy to understand Refers to the understandability of the practices/processes of EAIM

Non-functional

requirement

Refers to the non-functional requirements within implementation such as:

security and stakeholder satisfaction

Complexity management Refers to the complexity aspect of an EA project in order to reduce risk

Supporting tool Refers to recommending and using the appropriate tools for implementing the

EA

Governance Refers to the governance practices/process for governing the EA

Type-usage Refers to the type of usage of the EAIM, including: particular enterprises,

public/federal enterprises, private/SME, all enterprises

Repository Refers to the repository inside the practices/processes for storing EA artefacts

Easy to use Refers to the requirement and prerequisites of EAIM for use in the EA

project


123

The aforementioned EAIMs are chosen because they provide appropriate and

comprehensive plans for EA implementation, and they are employed in most EA

implementation projects.

2.3.1 EAP

Enterprise Architecture Planning (EAP) was introduced by Spewak and Hill (1993).

EAP contains activities and processes to achieve a To-Be architecture by

considering four EA architectures including: Business, Data, Application, and

Infrastructure. It is also known as the Wedding Cake. It covers the first two

perspectives of Zachman Framework (ZF) (Spewak and Tiemann 2006; Spewak and

Hill 1993).

EAP specifies a plan for subsequent design and implementation of an EA. The ZF

prepares the broad description for architectural layers, while EAP concentrates on

developing and managing the process for aligning business and IT. Moreover, EAP

is planning that concentrates on the development of matrices for comparison and

analysis of data, IS, and infrastructure. A significant part of EAP is an

implementation plan. EAP provides the process of using architectures for utilizing

IS to support business and the plan for implementing architectures. It comprises the

following phases (Spewak and Hill 1993):

• Initiation planning

• Preliminary business model

• Enterprise survey

• Current systems and technology architecture

• Data architecture

• Application architecture

• Technology architecture

• Implementation plan

• Planning conclusion

• Transition to implementation

In 2006, EAP was changed and several items were added into the prior model.

The intent of this change was to refresh one part of the EAP approach and update

the model. One of the added items was governance (Spewak and Tiemann 2006).

2.3.2 TOGAF

The TOGAF Architecture Development Method (ADM) provides iterative practices

for implementing EA (The Open Group 2009). TOGAF ADM is a methodology that

describes an iterative method for EA development. The enterprise architect must

determine some features of the TOGAF methodology not provided by the ADM,

such as: level of detail, breadth of coverage, and extent of time horizon. The ADM

phases are:

• Preliminary: Clarifies the current architecture in an organization using the

framework and concepts of EA.

F. Nikpay et al.

123

• ADM Cycle: Consists of several phases. Architecture vision describes the

current architecture and desired architecture of business and IT views. Business

architecture depicts the current architecture of business and analyzes gaps

between it and the desired one. IS Architecture specifies the desired data and IS

architecture by analyzing their requirements. Technology architecture is

employed to build up the basic implementation. It comprises eight sub-phases:

formation of current architecture of the enterprise, considering perspectives of

the enterprise, selecting services for To-Be architecture of the enterprise,

creating architecture model of To-Be systems, determining criteria, verifying

business targets, conducting gap analysis, and defining the enterprise’s

architecture. Opportunities and solutions comprise assessment and choice of

implementing options. Migration planning considers prioritizing implementing

projects in accordance with their dependencies. Implementation governance

concerns governing of an EA project particularly with respect to implementing

and deploying. Architecture change management concerns future changes by

using a repeated surveillance process in business and IT which can cause new

deployments. Requirements management identifies and maintains requirements

for other ADM Cycle phases.

While processes of each ADM phase are defined appropriately, ADM leaves

flexibility of implementation to EA architects to decide needed activities from a

distinct set of possible results. In order to trace architecture design and decisions,

ADM suggests documenting the design rationale (Ahlemann et al. 2012).

2.3.3 DODAF

The Department of Defense Architecture Framework (DODAF) is the holistic

framework and conceptual model for enabling the development of EA particularly

for DOD agencies (Sessions 2007). It is an EA framework in practice which was

developed for a specific domain and enterprises (General Accounting Office of

United States 2003). In DODAF 2.0, there are eight prescribed perspectives:

• All

• Capability

• Data and information

• Operational

• Project

• Services

• Standards

• Systems

DODAF, by using these perspectives, focuses on the supporting decision makers

to guide the development of an EA within the DOD whether the effort is on a

strategic or tactical level.


123

2.3.4 FEA

The Federal Enterprise Architecture (FEA) method is mainly concentrated on

creating an architectural method for governmental agencies and is described in the

FEA Practice Guidance (Sessions 2007). The segment-architecture development

process consists of four steps including: architectural analysis, architectural

definition, funding strategy, and program management plan (FEA 2001).

FEA, like DODAF, is an EAF-in-practice, but its enterprise encompasses the

U.S. Federal Government. FEA is one of the more fragmented EAFs and currently

spans five documents: a five-part Reference Model (RM), a methodology, a maturity

model, a best-practices guide, and guideline on how to have FEA compliant Service

Oriented Architecture (Akkasi et al. 2008).

2.3.5 Comparison results

Although there are several EAIMs in the literature, we selected some prevalent

EAIMs employed in most EA implementation projects. Table 2 shows the results of

comparison between the aforementioned EAIMs in accordance with selected

criteria. The columns of Table 2 were filled based on review papers (Goethals et al.

2006; Rouhani et al. 2013; Sessions 2007; Tang et al. 2004; Urbaczewski and

Mrdalj 2006) and a SLR (Rouhani et al. 2015b) on EAIMs. In addition, we used

practitioners’ points of view obtained through interviews conducted during the

TOGAF Conference held in August 2014 in Malaysia.

Table 2 Comparison of mentioned EAIMs

EAP TOGAF FEAF DoDAF

Iterative - ?? - -

Management process - - - -

Maintenance process - ? - -

Ability to work with other EAF ? ?? - -

Requirement management process - ?? - -

Step by step guideline ? ? ? ?

Easy to understand ? - ? ?

Non-functional requirement - ?? - ??

Complexity management - - - -

Supporting tool ? ? - ?

Governance ? ?? ? -

Type-usage ?? ?? - -

Repository ?? ?? ?? ??

Easy to implement ? - ? ?

?? Fully consider/support/exist/all/easy

? Partly consider/partly support/partial/somewhat/easy

- Not consider/not support/not exist/particular/difficult

F. Nikpay et al.

123

As shown in Table 2, although FEAF is quite similar to EAP, EAP has more

advantages in its adaptability and supporting tools. DoDAF considers non-functional

requirements such as security in its practices, whereas EAP and FEAF do not consider

requirements properly. Based on the designed criteria, TOGAF is the most

advantageous EAIM, since it is iterative and has the ability to be employed with

other EAFs, and it considers requirement management as well as using the repository.

There is a lack of consideration on reducing the complexity of implementation,

using an iterative approach, supporting EA maintenance, providing EA manage-

ment, and providing requirement management by most of the current EAIMs.

Meanwhile, governance is one of the critical parts of EA implementation that is

superficially addressed by these EAIMs.

Though this section does not cover all existing EAIMs, the selected EAIMs are

the most well-known in EA projects and some other EAIMs are inspired from them.

Furthermore, the comparison framework covers only a portion of the EAIM

lifecycle and is focused exclusively on specific aspects of the development process.

3 Research methodology

This research was divided into three main phases: preparing the foundation and

requirement, developing, and evaluating. In order to identify the effective practices of

EAIM, a SLR was conducted based on Kitechham 2007 instructions (Kitchenham and

Charters 2007). In addition, a semi-structured interview was carried out with the EA

practitioners in order to capture practical experience on developing an effective EAIM.

The combination of results of the SLR and interviews established the foundation for the

developing phase. The proposed EAIM was based on the fact that an EAIM must provide

three main stages: initiation, management and development, and maintenance. The

identified practices were categorized and span these three main stages. The proposed

methodology was evaluated by means of case study as research method. The case study

protocol was defined based on instructions of (Runeson and Host 2009).

This research uses the factors that influence the effectiveness of EAIM described

in (Darvish Rouhani et al. 2015a) as a tool for evaluating the effectiveness of the

proposed EAIM within the conducted case study. These factors are considered in

designing the data collection procedure during the case study (Sects. 5.3, 5.4).

4 Proposed EAIM

In this research the word ‘‘methodology’’ is defined as the generic reference

procedure that represents (1) the structure and condition of existing systems; (2) the

practices and descriptions to manage the step by step guidelines from current

architecture to desired one; (3) the practices and description to maintain and keep

the enterprise updated in order to cope with upcoming changes; (4) the practices and

description to supervise and govern the systems and artefacts. Moreover, ‘‘practice’’

is the set of activities and processes to define, develop, and maintain the

architecture.


123

4.1 Structure of the proposed EAIM

Since the EAIM is employed to develop, manage, and maintain the EA artefacts

within an enterprise (Lankhorst 2009; Winter and Fischer 2007) this section

describes the structure of the proposed EAIM for implementing EA artefacts.

The proposed EAIM contains the practices, phases, and components in order to

be able to develop EA artefacts. The practice refers to a set of activities and

processes in order to define, develop, and maintain the EA artefacts. The phase

refers to a set of practices, and there are meaningful relationship among those

practices. The component refers to the operational section, which contains the

phases or functional activities.

The practices and phases of the proposed EAIM are selected based on the results

of conducted SLR, carried out interviews with EA practitioners, and Agent Oriented

Methodologies’ (AOMs) practices. Besides, for each phase the proposed EAIM

considers levels of architecture in order to support all aspects of the enterprise.

Moreover, the components of the proposed EAIM are based on the conducted SLR.

Figure 1 illustrates the structure of the proposed EAIM.

4.2 Conceptual model

Figure 2 illustrates the conceptual model of the proposed EAIM. It contains five main

components including: initiation; management; maintenance; repository; and tools.

The initiation part refers to preparing the enterprise in order to start the EA

implementation. The management part refers to conducting and developing the EA

implementation within the enterprise. The maintenance part refers to controlling and

governing the EA implementation and taking appropriate actions to cope with future

changes. The repository plays a key role in the proposed EAIM. Since the proposed

methodology design is iterative, utilizing an appropriate repository is an important

capability for storing EA artefacts. The repository provides a place for the storage,

view and retrieval of EA artefacts. It is like a copy of the current and future

SLR results

Interview report

Practices Phase ….

Phase ….

Practice ….

Practice ….

Component…….Phase…….

Fig. 1 Structure of the proposed EAIM

F. Nikpay et al.

123

blueprint and remodeling plans. Finally, the tools are used for supporting the EA

modelling, managing, and maintaining.

4.3 Proposed EAIM’s phases

The proposed EAIM spans the following phases that can be used iteratively (Fig. 3):

• Planning concerns planning and documenting the required information for

starting EA implementation.

• As-Is concerns understanding the current architecture of the enterprise by

studying an organizational business and IT setting.

• To-Be concerns the description of the desired system within its operational

environment, along with relevant functions and qualities.

• Implementation concerns the appropriate implementation of systems including:

Architectural Design, where the system’s global architecture is defined in terms

of subsystems, interconnected through data, control, and other dependencies;

and Detailed Design, concerning the behavior of each architectural component

for further refinement.

• Governance concerns the governing of activities and processes in order to

prepare systems for future changes.

4.4 Description of phases

4.4.1 Planning

Planning is employed for describing the EA project. Furthermore, there are three

reasons to start the EA with initiation practices: (1) to define the vision of the EA;

(2) to identify and select project team members; and (3) to describe the milestones

Fig. 2 The proposed EAIM


123

of projects and illustrate the roadmap (Agievich et al. 2012; Giachetti 2012;

Javanbakht et al. 2008; Leist and Zellner 2006; Nakakawa et al. 2009).

This phase is concerned with planning and defining the EA implementation.

Business process efficiency is strongly linked to the IT within a firm. Consequently,

strategic business and IT alignment becomes a crucial task and one of the top

concerns of the Chief Information Officer (CIO) in an enterprise. Enterprise

architects should collaborate with business process professionals, data managers and

IT stakeholders. Business environmental trends may be of different types (e.g., new

technologies, etc.) but they are often related to the firm’s market (Wagter 2005;

Wegmann et al. 2005).

PlanningUnderstanding future

business trendEstablish business

strategyDefine business

requirementDefine IT requirementOptimizationDefine the vision of

enterprise As-IsDescribing current

business architectureDescribing current data

architecture Describing current

application architectureDescribing current

technology architectureProviding the

management plan

To-BeDescribing desired

business architectureDescribing desired data

architecture Describing desired

application architectureDescribing desired

technology architectureProviding the

integration plan

ImplementationDescribing functional

requirementDescribing non-

functional requirementArchitectural designDetail designAdaptability planTransition plan

GovernanceDefining the policiesMonitoring the

implementationEvaluationChange managementControlling the

adaptability of systemsUpdating the

repository

Fig. 3 The proposed EAIM’s phases

F. Nikpay et al.

123

This phase provides the appropriate alignment for business and IT. This phase

maps enterprise business strategies to environmental trends, business information

requirements to enterprise business strategies, and IT requirements to business

information requirements. After each mapping, a prioritization task is performed to

determine the most relevant factors among all the ones identified. Consequently, the

goals established at the end of the IT alignment consist of potential IT improvement

alternatives. Figure 4 illustrates the practices of this phase.

4.4.2 As-Is

This phase concerns understanding the environment by studying the organizational

setting. In this phase, the current enterprise architecture is determined and

expressed. Figure 5 illustrates the practices of this phase. The goal of this phase is to

depict the current enterprise structure in a model that gives a global view.

This phase provides the appropriate foundation for understanding the current

abilities of the enterprise in terms of business, data, application, and infrastruc-

ture. By understanding this information, the enterprise architects will have a

holistic view of the current situation in order to provide an appropriate

management plan.

The management plan consists of the information and modelling of four

architectural levels of the enterprise and also provides more information regarding

the interrelationships between the current enterprise architectures.

During the As-Is architecture phase, the enterprise architect identifies the domain

stakeholders and models them as social actors who depend on one another for goals

to be fulfilled, tasks to be performed, and resources to be furnished. Through these

dependencies, one can answer why questions, in addition to what and how, regarding

system functionality. Answers to why questions ultimately link system functionality

to stakeholder needs, preferences, and objectives.

Und

erst

andi

ng fu

ture

bus

ines

s tre

nd

Defin

ing

the

visio

n of

ent

erpr

ise

Esta

blish

bus

ines

s str

ateg

y

Defin

e bu

sines

s req

uire

men

t

Defin

e IT

requ

irem

ent

Opt

imiza

tion

Fig. 4 Planning’s practices


123

4.4.3 To-Be

This phase concerns understanding the desired enterprise architecture by studying

business and IT practices. In this phase, the To-Be architecture of enterprise is

determined and expressed. Figure 6 illustrates the practices of this phase.

This phase provides the appropriate foundation and information for describing

the desired enterprise architecture in terms of business, data, application, and

technology. By understanding this information, the enterprise architects will have a

holistic view of the desired situation in order to provide an appropriate integration

plan.

During the To-Be phase, the conceptual model developed during the As-Is phase

is extended to include the system-to-be as a new architecture, along with its

dependencies. These dependencies define functional and non-functional require-

ments for the system-to-be.

4.4.4 Implementation

Implementation is employed for developing and deploying the EA project.

Typically, an enterprise will have multiple ongoing projects that are remediating,

Desc

ribin

g cu

rren

t bus

ines

s ar

chite

ctur

e

Desc

ribin

g cu

rren

t dat

a ar

chite

ctur

e

Desc

ribin

g cu

rren

t ap

plic

a�on

arc

hite

ctur

e

Desc

ribin

g cu

rren

t te

chno

logy

arc

hite

ctur

e

Prov

idin

g th

e m

anag

emen

t pl

an

Fig. 5 As-Is practices

Desc

ribin

g de

sired

bus

ines

s ar

chite

ctur

e

Desc

ribin

g de

sired

dat

a ar

chite

ctur

e

Desc

ribin

g de

sired

ap

plic

atio

n ar

chite

ctur

e

Desc

ribin

g de

sired

te

chno

logy

arc

hite

ctur

e

Prov

idin

g th

e in

tegr

atio

n pl

an

Fig. 6 To-Be practices

F. Nikpay et al.

123

renovating, or replacing information systems as well as developing new systems.

Many of these projects are conducted on varying schedules. Thus, considering the

following aspects of implementation is important during the EA implementation: (1)

coordinating schedule to ensure interdependencies mesh; (2) ensuring intersystem

constraints at the interface(s) are resolved; and (3) ensuring interoperability at the

syntactic and semantic interactions between ISs (Agievich et al. 2012; Holcman

2012; Javanbakht et al. 2008; Leist and Zellner 2006; Nakakawa et al. 2009).

This phase focuses on the transition plan of EA implementation. It is concerned

with implementing the To-Be system by describing the architectural design of the

desired architecture. In this phase, the foundation of the desired architecture is

determined and expressed. It also describes the detailed design (development) of

required ISs and data architecture for the transition plan. Figure 7 illustrates the

practices of this phase.

Non-functional requirements include predictability, security, adaptability, avail-

ability, fault-tolerance, and modularity. The implementation phase is also intended

to introduce additional detail for each architectural component of a system. It

consists of defining how the goals assigned to each actor are fulfilled by actors with

respect to social patterns. Moreover, this phase is concerned with implementation

(deployment) of developed ISs.

4.4.5 Governance

Governance is employed for operational consistency while the enterprise continues

to evolve the architecture. Deploying enhanced or new system should not impact

day-to-day operations, so careful scheduling and integration of changes to the

architecture are required. Table 7 shows the classification of practices of proposed

EAIM (Agievich et al. 2012; Javanbakht et al. 2008; Leist and Zellner 2006;

Nakakawa et al. 2009; Noran 2013).

This phase concerns providing the appropriate strategy for governing the

enterprise. In this phase, governance of enterprise is determined and expressed.

Figure 8 illustrates the practices of this phase.

Desc

ribin

g fu

nctio

nal

requ

irem

ent

Tran

sitio

n pl

an

Desc

ribin

g no

n-fu

nctio

nal

requ

irem

ent

Arch

itect

ural

des

ign

Deta

il de

sign

Adap

tabi

lity

plan

Fig. 7 Implementation practices


123

4.5 Products

Table 3 shows the main products of each phase based on the proposed EAIM’s

practices. Some or all listed products in Table 3 may apply in EA implementation

projects; however, the enterprise architect may merge some reports together as one

product.

4.6 Checklist

Table 4 shows checklists to consider for each phase of the proposed EAIM. Since

maturity is defined as the degree to which all practices of the EA implementation are

fully employed in the EA project, this checklist can be considered as a maturity list

of EAIM guiding activities of the enterprise architects.

5 Case study

This section describes the application of the proposed EAIM. The project

investigated the conduct of EAIM in real-life settings, in particular the use of the

proposed EAIM within a commercial environment. One particular focus of this

research was on the effectiveness of such evaluations, for example, the benefits of

project outputs to the enterprise from applying the proposed EAIM. There is limited

published research on actual evaluations of the effectiveness of EAIM in field

settings, and the case study sought to contribute to the body of research in this area.

5.1 Case study design

A case study protocol defines the detailed procedures for collection and analysis of

the raw data (Runeson and Host 2009). Table 5 shows the designed case study

protocol of this research.

Furthermore, the following items were considered during conduct of the case

study:

Def

inin

g th

e po

licie

s

Upd

atin

g th

e re

posi

tory

Mon

itorin

g th

e im

plem

enta

tion

Eval

uatio

n

Cha

nge

man

agem

ent

Con

trolli

ng th

e ad

apta

bilit

y of

sy

stem

s

Fig. 8 Governance practices

F. Nikpay et al.

123

• In order to gain permission for access to the right people, the required

coordination was done with selected cases.

• Adequate resources such as time, paper, and others have been prepared, and

during the project the resources needed were added.

• The appropriate schedule for collecting the required interviews was set before

the project started.

• Data analysis was done by coding the transcription of interviews by means of

qualitative data analysis software Atlas.ti 7. In other words, first the data are

coded, which means that parts of the text can be given a code representing a

certain theme, area, construct, etc. One code is usually assigned to many pieces

of text, and one piece of text can be assigned to more than one code. Codes can

form a hierarchy of codes and sub-codes. In addition, the descriptive statistical

analysis was performed on the questionnaire’s data by using statistical software

such as SPSS.

5.2 Case study procedure

This research provided the guidelines for conducting the EA implementation project

based on the proposed EAIM. The guidelines were submitted to the contact person

Table 3 Main products of the proposed EAIM’s phases

Phase List of products

Initiation Business strategy

Business requirements

IT requirements

Optimized business and IT requirements

Vision of enterprise

As-Is As-Is architecture (business, data,

application, and technology)

Management plan

To-Be To-Be architecture (business, data,

application, and technology)

Integration plan

Implementation Functional requirements

Non-functional requirements

System architecture definition

Development plan

Adaptability plan

Transition plan

Governance Evaluation report

Change management document

Repository status check

Governance plan


123

Table 4 Phase checklists

Phase Checklist

Planning What is the current business trend?

Are clear vision and mission of the enterprise defined in advance?

Is the theoretical basis—in relation to existing literature or other cases—defined?

Is the business strategy clearly defined?

Are the business requirements considered in the business strategy?

Are the IT requirements well identified and described?

Are IT and business requirements appropriately prioritized?

Is IT and Business requirements well optimized?

Is the future of the enterprise well planned?

As-Is Is current business approach clearly described?

Are business entities clearly described?

Is current data structure clearly described?

Is data model well depicted?

Is the relation of data well described?

Is current application explicitly described?

Are inter-relations of current application well described?

Are the interaction of current application and business well described?

Is current technology/infrastructure clearly described?

Is management plan created explicitly?

To-Be Is desired business approach clearly described?

Are desired business entities clearly described?

Is desired data structure clearly described?

Is data model well depicted?

Is the relation of data well described?

Is desired application explicitly described?

Are inter-relations of desired application well described?

Is the interaction of desired application and business well described?

Is desired technology/infrastructure clearly described?

Is integration plan clearly determined?

Implementation Are functional requirements clearly described?

Are non-functional requirements clearly described?

Is architectural design of ISs well described?

Are desired ISs well modeled?

Are the relationships between ISs well specified?

Is comprehensive system catalogue of the implementation created?

Are required databases well designed?

Are the database’s tables, views, roles, grants, users, store procedures well designed?

Are the sub-systems of each IS explicitly described?

Are the required modules for each IS described?

Is the infrastructure architecture clearly described?

Is system specification clearly created?

Are needed organizational positions in the enterprise defined?

F. Nikpay et al.

123

of the selected case. A workshop for training the proposed EAIM’s practices,

phases, and plans was carried out for the case’s participants including a presentation

for implementing the step by step practices of the proposed EAIM. We also

provided the online version for further support. The project’s participants could also

ask questions through email.

Table 4 continued

Phase Checklist

Are the appropriate organizational charts determined?

Are appropriate adaptability plan for implementation well defined?

Is the implementation of ISs appropriately prioritized?

Is the deployment strategy for the developed ISs well defined?

Are developed applications well deployed?

Is the transition plan for implementing target architecture ISs and infrastructure well

defined?

Governance Are governance policies clearly defined?

Is the transition plan well monitored?

Is EA implementation appropriately evaluated?

Is change management well considered during the implementation?

Is change management controlling future changes?

Is the repository kept updated with latest architectural artefacts?

Is adaptability of systems appropriately checked during the implementation?

Table 5 Case study protocol

Section Description

Objective To use the proposed EAIM in industrial environment in order to evaluate the

effectiveness of proposed EAIM

General

procedure

Using the proposed EAIM in implementation phase of selected case

Case selection

criteria

Familiar with EA

Having Enterprise Architects, Business Architects, IT Architects, and so on

Interested to utilize EA

Invest in EA implementation

Supporting EA project by top management

Research

instrument

Interview and questionnaire

Data collection Semi-structured interview (open questions) and closed questions were asked from

selected case’s enterprise architects, business architects, and systems’ stakeholders

Data analysis Editing and quasi-statistical approaches used for coding, calculation of frequencies

of words and phrases

Validity Validity threats analysed based on the checklists, proposed by Runeson and Host

(2009). It would also have been possible to analyse threats according to construct

validity, internal validity, external validity, and reliability


123

The project’s outlines of the selected case defined at the beginning of the EA

project and the required activities for achieving the intended objectives based on the

proposed EAIM were described. The chief enterprise architect managed the EA

implementation and controlled the EA artefacts development.

This research asked chief enterprise architects to use the practices and

instructions of the proposed EAIM in their EA implementation projects. In this

regard, the following activities needed to be considered by chief enterprise architect

(some or all activities may be applied to the selected case):

• Understanding the business structure and strategy of enterprise

• Defining the EA objectives and enterprise’s vision

• Describing the enterprise As-Is architecture

• Describing the enterprise To-Be architecture

• Providing the enterprise integration plan

• Providing the enterprise migration plan

• Describing the enterprise governance plan

• Describing the enterprise adaptability plan

The selected case was a private Bank, which is famous in its sector in the Middle

East. The development and application of the methodology was carried out in a six

months project, starting in September 2014, which aimed to enhance and improve

EA implementation of EA artefacts, and in terms of its effectiveness in supporting

the enterprise to achieve intended goals. The project started with the following

objectives:

• To produce concise and easily understood models of high level EA

• To develop EA artefacts that depict the interrelationships between business

goals and objectives, and IT systems and services

• To use the EA to identify the impact of change

After expressing the project goals and doing the planning phase’s practices such

as the required alignment and business strategy, the project team focused on

describing the As-Is architecture by considering four levels of architecture including

Business, Data, Application, and Technology. The To-Be architecture was defined

based on requirements of defined objectives and business strategy of the Bank. The

team then represented the implementation of To-Be by doing the transition plan.

The required practices for governance were done in order to ensure continual

improvement.

The outputs of ‘Planning’ and ‘As–Is’ phases provided the basis for the

establishment of several recommendations classified in two types, functional and

technical, such as improving standardization in the practices, reducing the number

of specific applications, and developing centralized databases and repositories.

Moreover, the outputs of ‘To-Be’ and ‘Implementation’ phases provided the

foundations for developing and implementing the required IT infrastructure and ISs.

The transition plan provided the structured way for implementing the EA.

Meanwhile, the outputs of ‘Governance’ support future changes and continual

improvement.

F. Nikpay et al.

123

5.3 Data collection

This research used triangulation in order to increase precision (Runeson and Host

2009). Triangulation means taking different angles of research towards the studied

object and thus providing a broader picture (Myers and Newman 2007; Yin 2013).

This research used methodological triangulation for combining the qualitative and

quantitative methods within data collection, including questionnaires and

interviews.

The questionnaires that applied in this study are divided into two sections: closed

questions and open questions. The closed and open questions were designed based

on the effectiveness model, which contains five factors including adaptiveness,

alignment, binding, support, and innovation as described in (Darvish Rouhani et al.

2015b). These questions cover the following points:

• A general understanding of the organizational profile, organizational structure,

and the interviewee’s role in the organization.

• The interviewee’s understanding of EA methodology.

• The interviewee’s perception of proposed EAIM in terms of the effectiveness

model’s constructs (Darvish Rouhani et al. 2015b).

• General understanding of the proposed EAIM by the interviewee.

The required data for evaluation were collected by means of closed and open

questions from 10 enterprise architects and 15 business users.

5.4 Data analysis

There are two types of data collected from the selected case, including qualitative

and quantitative data. In this research the quantitative data collected from

questionnaires were analyzed statistically by assigning a weight to each answer

of questionnaire. The seven-point Likert Scale was selected for closed end questions

including: strongly disagree (weight = 1), disagree (weight = 2), somewhat

disagree (weight = 3), neither agree nor disagree (weight = 4), somewhat agree

(weight = 5), agree (weight = 6), and strongly agree (weight = 7). Figure 9

illustrates the analysis structure of the closed questions.

This research divided the closed questions into the following groups based on the

effectiveness model of EAIM as described in data collection (Sect. 5.3), including:

questions that related to binding (focus on managing EAIM practices), questions

that related to support (focus on supporting EA implementation by providing

appropriate plan, strategy, tools, and mechanism), questions that related to

innovation (focus on continuous innovation to enhance enterprise’s business,

processes, and activities), questions that related to adaptiveness (focus on

effectively and efficiently building, maintaining, and applying the whole part of

EA), and questions that related to alignment (focus on providing appropriate

business and IT practices for making alignment in EA implementation). This

research also considered questions that related to future work (focus on


123

recommendation for using the methodology in future projects) for categorizing the

closed questions.

The qualitative data, collected by means of interviews, were analyzed based on

case study protocol (Sect. 5.1). Figure 10 illustrates the procedure for the qualitative

data analysis.

The coding procedure began after getting familiar with collected data. In this

regard, the collected data were imported to Atlas.ti 7, and the predefined set of codes

were deductively developed from EAIM features and case study protocol (Myers

and Newman 2007; Yin 2013).

Similarly, inductive coding was performed during the analysis to identify key

thoughts and concepts relevant to the study questions. When potential new relevant

codes were identified, new codes were created and data coded in Atlas.ti 7. At the

same time, the code and its definition were added to the codebook (Maxwell 2012).

The analysis process is iterative in nature; therefore, multiple passes were

undertaken in order to code the data. Some codes were refined and extended during

the analysis, while others were merged with similar or redundant ones, or re-coded

if necessary (Kaplan and Maxwell 2005). Table 6 shows the codebook of open

questions. Screenshots of coding in Atlas.ti are in the ‘‘Appendix’’.

This approach provides high level analysis of data to identify themes rather than

codes. The codes used in the previous step were grouped and categorized into the

possible themes that describe them collectively. It is an iterative back-and-forth

process. Table 7 shows the identified themes of open questions and Fig. 11

illustrates the structure of themes.

5.5 Case study results

This section describes the results of qualitative and quantitative data analysis. In

quantitative data, the following sections accumulate the results of participants,

including business users and enterprise architects based on the data collection and

analysis procedure (Sects. 5.3, 5.4):

Data CollectionGiving the weight to the

feedback of each respondent

Calculating the mean of each question based on

the feedback of respondents

Categorizing the questions based on the independent factors of the effectiveness model

Describing the results of each category

Accumulating the results of business users and enterprise architects

for describing case analysis

Fig. 9 Quantitative data analysis procedure

F. Nikpay et al.

123

– In binding, the respondents agree that the proposed EAIM considers binding

items by average of over 6 (6.17) and this means that the proposed EAIM

supports binding approaches on it practices and activities.

– In support, the respondents agree that the proposed EAIM provides appropriate

support for EA implementation by average of close to 6 (5.85) and this means

that the proposed EAIM provides appropriate support by its practices and

activities for EA implementation.

– In innovation, the respondents agree that the proposed EAIM supports

innovation by average of over 6 (6.28) and this means that the proposed EAIM

supports continual improvement of EA implementation.

– In adaptiveness, the respondents agree that the proposed EAIM provides

adaptiveness by average of over 6 (6.14) and this means that the proposed EAIM

considers the effective development, maintenance, and management for EA

implementation.

– In alignment, the respondents agree that the proposed EAIM provides

appropriate alignment between IT and business by average of very close 6

(5.97) and this means that the proposed EAIM provides appropriate alignment

between enterprise’s business and IT.

– In future work, the respondents agree that the proposed EAIM can be employed

by future work by average of over 6 (6.37).

As a result, the average of closed questions is 6.37 and it means that the

participants agree that the proposed EAIM supports the effectiveness model of

EAIM and they will use it in their future work.

In qualitative data, the following sections describe the summary of analysis based

on the defined data analysis procedure (Sect. 5.4).

– The interview findings from both business user and enterprise architect groups

reveal that the proposed EAIM contains effective components in terms of

practices, methods, and deliverables. These components define the project

Getting Familiar with Data

Coding

Identifying Themes

Reporting

Developing the Code Manual

Testing the Reliability of the Codes

Deductive and Inductive Coding

Connecting the Codes

Fig. 10 Qualitative data analysis procedure


123

objectives by appropriate information based on business and IT requirement and

support the EA implementation in order to achieve the defined objectives.

Moreover, some participants also suggested that they utilize specific manage-

ment and modelling tools in order to improve the EA implementation.

– The interview analysis shows that the proposed EAIM provides appropriate

foundation for defining the EA objectives in terms of alignment of business and

IT. The proposed EAIM also supports achievement of EA objectives by

providing step by step guidelines and checklists for each phase. Moreover, the

Table 6 Codebook of open question analysis

Code name Description

Practices Practices refer to the used phrases by interview’s participants, which related to the

practices of the proposed EAIM

Deliverables Deliverables refer to the outputs of the proposed EAIM, considered as implemented

EA artefacts

Method Method refers to the provided plan for implementing the EA artefacts by practices of

the proposed EAIM

Supporting tools Supporting tools refer to provided tools by the proposed EAIM in order to support EA

implementation

Objective

definition

Objective definition refers to the practices and activities of the proposed EAIM,

employed for identifying business and IT requirements of the enterprise in order to

define clearly the objectives of EA implementation projects

Guide process Guide process refers to provided guidelines and deliverable plans by the proposed

EAIM in order to guide practitioners to implement the EA within an enterprise by

means of the proposed EAIM’s practices

Simplified

process

Simplified process refers to the simplification of the process of EA implementation by

means of the proposed EAIM’s practices

Customizability Customizability refers to the ability of the proposed EAIM to allow practitioners to

use some or add some other parts to the provided methods in order to implement the

EA

Compatibility Compatibility refers to the ability of the proposed EAIM to be compatible with other

EA implementation methods

Completeness Completeness refers to the ability of the proposed EAIM to fully implement EA

within an enterprise

Conciseness Conciseness refers to ability of the proposed EAIM to provide concise practices and

activities for EA implementation

Architectural

design

Architectural design refers to the outputs of four architectural levels including:

business, data, application, and infrastructure

Alignment Alignment refers to reducing the mismatch between business and IT

Integration Integration refers to providing integrated systems that can respond to the business

demands.

Adaptation Adaptation refers to providing a plan for accepting new ISs by enterprise’s users

Governance Governance refers to governing the EA project in order to control and manage the EA

artefacts

Others Others refer to the other artefacts of the proposed EAIM that do not consider as a

separated code, such as: requirement analysis and optimization

F. Nikpay et al.

123

proposed EAIM provides a simple environment for EA implementation by

means of its effective practices.

– The interview findings show that the proposed EAIM has the ability to support

the customizability and compatibility by its adoption plan, and provides the

dynamic environment for EA implementation. In terms of completeness, it is

possible to implement the EA by means of the proposed EAIM’s practices.

Finally, the proposed EAIM considers conciseness in its practices for supporting

business and IT requirements.

As a result, the analysis of qualitative and quantitative data reveal that the

proposed EAIM supports the factors of EAIM effectiveness model, and supports the

achievement of EA objectives by its practices and plans.

5.6 Threats to validity

In this research, validity threats were analyzed based on the followings items. In

order to reduce bias by individual researchers, the analysis was conducted by

multiple researchers.

– General validity was checked by considering the checklist items for the design

and the data collection plan proposed by Runeson and Host (2009).

– Construct validity showed that the correct operational measures are planned for

the concepts being studied. Tactics for ensuring this include using multiple

sources of evidence, establishing chains of evidence, and expert reviews of draft

protocols and reports. Construct validity is achieved by involving participants

from various backgrounds in the EA implementation case studies. Construct

Table 7 Themes of open questions analysis

Theme

name

Description Code Sub-code

Capabilities Capability refers to components of

proposed EAIM, which support EA

implementation processes and

activities; components are the basic

elements that represent the building

blocks of the methodology

Practices,

deliverables,

method, and

supporting tools

Architectural design,

alignment, integration,

governance, adaption,

others

Objectives Objective refers to the intent of the

proposed EAIM regarding what it

claims and what practitioners

expect to achieve

Objective definition,

guide process,

simplified process

Properties Property reveal the inherent qualities

of the proposed EAIM and are

useful in identifying potential

strengths and weaknesses

Completeness,

compatibility,

conciseness,

customizability


123

validity is obtained by using multiple participants in applying the proposed

EAIM.

– External validity identifies the domain to which the study finding can be

generalized. Tactics include using theory for single-case studies and using

multiple-case studies to investigate outcomes in different contexts. In this

research, external validity is supported by the fact that the proposed EAIM is

applied to different parts of the organization.

– Reliability is achieved by clearly describing the process by which the proposed

EAIM’s practices were developed and the different cases of the proposed EAIM

were implemented.

34

Capabili�es

Proper�es

Objec�ves

Suppor�ng Tools

Methods

Deliverables

Prac�ces

Conciseness

Completeness

Compa�bility

Customizability

Simplified process

Guide process

Objec�ve defini�on

Adapta�on

Integra�on

Alignment

Architectural design

Governance

Others

Theme Code Sub-code

Fig. 11 Coding style of open questions

F. Nikpay et al.

123

6 Discussion and future work

Several studies have been conducted for developing an EA methodology by both

practitioners and researchers. Most of the existing EAIMs do not suggest

appropriate requirements analysis in terms of functional and non-functional aspects.

The lack of consideration of having an appropriate requirement in EA implemen-

tation leads to insufficient and inaccurate analysis of As-Is and To-Be architectures.

Thus, the enterprise will not achieve the intended goal of the EA project. An

effective EAIM should consider comprehensive requirements analysis in terms of

functional and non-functional aspects.

EAIM should support EA project lifecycle including the design, management

(development), and maintenance. There is a lack of consideration regarding

consistency between an EAIM’s parts. Consequently, the project starts with using

one method, followed by other approaches that are not linked together.

There is no specific practice for making the alignment between business and IT

used by existing EAIMs. An effective EAIM should use specific practices for

aligning business and IT in order to provide an appropriate environment for

reaching intended goals.

Defining the monitoring and governing of the EA implementation is a critical

part of EA implementation maintenance. EAIM should provide effective and

efficient governance activities in its maintenance section. By doing so, the EAIM

assists architects and stakeholders to continue improvement of EA implementation

and increase the quality of intended EA implementation goals.

In order to compare the proposed EAIM with other existing EAIMs, we used the

aforementioned framework in related work, which consists of three main parts,

including: concepts, modelling, and process. According to the selected comparison

framework, the proposed EAIM fully supports the concept’s indicators including:

alignment, governance, repository, and strategy; in modelling, the proposed EAIM

provides easy to use and learn practices, consistency of practices, different

perspectives, flexibility and reduction in complexity; in process, the proposed EAIM

uses requirements analysis during the entire implementation, provides step by step

guidelines by its template and supports the maintenance and continual improve-

ment. Additionally, other features of the proposed EAIM include:

– Complete, which means that the proposed EAIM shows a full vision of the

enterprise and relation with other enterprise aspects. The planning phase

provides deep information regarding future trends and requirements for

enterprise business, becoming another practice responsible for optimization of

business requirements and IT requirements. In optimization, the alignment of

business and IT is created where the business requirement should meet the IT

requirement and the mismatch between business and IT is eliminated.

Alignment in the proposed EAIM is considered at the first stage of

implementation where the vision and EA objectives are defined in planning

phase. By doing so, the enterprise vision is created based on understanding the


123

future trends and requirements of business and IT capabilities, and can be seen

as the complete perspective of the enterprise.

– Support for decision making, which means that the proposed EAIM presents the

impact that concrete enterprise development generates in the enterprise,

allowing solving and selecting the one amongst other programs that improves

the performance of the enterprise. The proposed EAIM provides practices for

EA implementation which create an environment for enterprise architects for

adopting the developed EA artefacts within the enterprise and manage the

implementation of developed EA artefacts based on priority and requirement of

the enterprise. In this regard, appropriate meetings between enterprise architects

and the main stakeholders of the EA project would make a better environment

for EA implementation based on supporting the decision makers. By doing so,

the proposed EAIM represents the practices supporting decision making

throughout the enterprise architects and stakeholders.

– Multi-disciplinary coordination, which means that the proposed EAIM coordi-

nates the set of disciplines that exist in the enterprise in order to convey

decisions in one plan with common objectives. The proposed EAIM provides

the set of phases including As-Is, To-Be, and implementation, which consider

multiple perspectives on their practices. Software developers, business analysts,

enterprise architects, change manager, IT stakeholders, and business stakehold-

ers are some of roles that participate in the EA implementation based on the

structure of the proposed EAIM.

– Structured analysis and design methodology, which means that the proposed

EAIM considers all the enterprise. The proposed EAIM includes several views.

The technology, information, organization and human aspects are considered, as

well as the relationships between them and their external elements. The

practices of the implementation phase provide such consideration for EA

implementation.

– The proposed EAIM covers the gap between pure business consulting and IS

development without leaving further gaps. This means that it takes into account

aspects of both business consulting and software development to make the

transitions between levels of abstraction smooth.

– The proposed EAIM is flexible. It is iterative and provides the set of dynamic

practices such as adaptability plan, management plan and integration plan which

are flexible in order to cover new changes based on requests for updates and

modifications.

6.1 Implications for future research

This research findings can affect the related work, such as EAIMs. There are factors

like organizational culture and high management commitment that influence the

successful implementation of EA, especially for using the proposed EAIM.

Identifying the success factors for EAIM and developing appropriate management

tools are some examples of future research topics based on the results of this

research.

F. Nikpay et al.

123

Moreover, there are several opportunities for further work. First, it would be very

interesting to address the evaluation of effectiveness of EA implementation, by

using the factors and practices that influence the effectiveness of EA implemen-

tation. Second, it would be useful to develop an effective modelling language for

EAIM where the effective practice and factors were incorporated.

6.2 Implications for practice

First of all, the findings emphasize the relevance of effectiveness of EAIM due to its

impacts on an enterprise performance. The consequences are twofold: implementing

EA requires a methodology and the effective EAIM can generate additional value

for enterprises. The results of this paper have potential for effective use in the EA

implementation projects by practitioners.

7 Conclusion

This article has presented an effective methodology for implementing enterprise

architecture within enterprises. It can be used in a company to either develop EA

artefacts which do not exist yet or to improve existing ISs and EA artefacts.

The investigation on EAIM literature carried out in this study provides a better

understanding of EAIM concepts and problems. By exploring the existing EAIMs, it

was realized that there is no effective EAIM in terms of complexities of

implementation. The proposed EAIM in this study is a light and holistic

methodology that provides: alignment between enterprise’s business and IT;

integration, which indicates that the proposed EAIM presents the integration plan

for an enterprise’s application and infrastructure; structured analysis and planning,

meaning that the proposed EAIM supports the enterprise to define appropriate

objectives and vision in planning phase; governance plan, which means that the

proposed EAIM provides an holistic plan for monitoring and governing the EA

implementation and also supports future changes by continual improvement; and

ease of use and learning, meaning that the proposed EAIM provides step-by-step

guidelines for making EA implementation easier.

Moreover, in this research we represented and applied a holistic methodology

while focusing on main concepts and principles, which impact the effectiveness of

EA implementation. The results of this research would be useful for academics and

practitioners in ways of using in EA project and also extending the research on EA

implementation.

Appendix: Screenshots of Atlas.ti analysis


123

F. Nikpay et al.

123


123

F. Nikpay et al.

123


123

References

Agievich V, Taratukhin V, Becker J, Gimranov R (2012) A new approach for collaborative Enterprise

Architecture development. In: 2012 7th international forum on strategic technology (IFOST), 18–21

Sept 2012, pp 1–5

Ahlemann F, Stettiner E, Messerschmidt M, Legner C, Basten D, Brons D (2012) EA frameworks,

modelling and tools. In: Ahlemann F, Stettiner E, Messerschmidt M, Legner C (eds) Strategic

enterprise architecture management. Springer, Berlin, pp 201–227

Aier S, Saat J (2011) Understanding processes for model-based enterprise transformation planning. Int J

Internet Enterp Manag 7(1):84–103

Aier S, Schelp J (2010) A reassessment of enterprise architecture implementation. Service-Oriented

Computing. ICSOC/ServiceWave 2009 workshops. pp 35–47

Aier S, Gleichauf B, Saat J, Winter R (2009) Complexity levels of representing dynamics in EA planning.

In: Albani A, Barjis J, Dietz JLG (eds) Advances in enterprise engineering III. Proceedings of

CIAO!/EOMAS 2009. LNBIP 34. Springer, Berlin, pp 55–69

Akkasi A, Shams F, Seyyedi MA (2008). Presenting A method for benchmarking application in the

enterprise architecture planning process based on federal enterprise architecture framework.

information and communication technologies: from theory to applications, 2008. In: 3rd

international conference on ICTTA 2008, 7–11 April 2008, pp 1–6

Buckl S, Dierl T, Matthes F, Schweda CM (2010) Building blocks for enterprise architecture management

solutions. In: Harmsen F, Proper E, Schalkwijk F, Barjis J, Overbeek S (eds) Working conference on

practice-driven research on enterprise transformation. Springer, Berlin, pp 17–46

Darvish Rouhani B, Mahrin M, Nikpay F, Darvish Rouhani B (2014) Current issues on Enterprise

Architecture Implementation Methodology. In: Rocha A, Correia AM, Tan FB, Stroetmann KA

(eds) New perspectives in information systems and technologies, volume 2, vol 276, Springer,

Berlin, pp 239–246

Darvish Rouhani B, Mahrin MNR, Nikpay F, Nikfard P, Khanian Najafabadi M (2015a) Factors that

affect the effectiveness of Enterprise Architecture Implementation Methodology. Int J Soc Behav

Educ Econ Manag Eng 9(1):19–25

Darvish Rouhani B, Mahrin MNR, Shirazi H, Nikpay F, Darvish Rouhani B (2015b) An Effectiveness

model for enterprise architecture methodologies. Int J Enterp Inf Syst (IJEIS) 11(2):51–56

Engelsman W, Quartel D, Jonkers H, van Sinderen M (2011) Extending enterprise architecture modelling

with business goals and requirements. Enterp Inf Syst 5(1):9–36

FEA (2001). Federal Enterprise Architecture—Practical Guide, version 1.0, February 2001

Finkelstein C (2006) Enterprise architecture for integration: rapid delivery methods and technologies.

Artech House, Boston

General Accounting Office of United States (2003) DOD business systems modernization: improvements

to enterprise architecture development and implementation efforts needed: report to the Chairman

and Ranking Minority Member, Subcommittee on Readiness and Management Support, Committee

on Armed Services, US Senate. i

Giachetti RE (2012) A flexible approach to realize an enterprise architecture. Procedia Comput Sci

8:147–152

Goethals F, Lemahieu W, Snoeck M, Vandenbulcke J (2006) An overview of enterprise architecture

framework deliverables. ICFAI University Press, Dehradun

Gunther WA (2014) Measuring enterprise architecture effectiveness: a focus on key performance

indicators (Master’s thesis). Leiden Institute of Advanced Computer Science (LIACES), Leiden

University, Leiden

Hagan PJ (2004) Guide to the (evolving) enterprise architecture body of knowledge. MITRE Corporation,

McLean

Hirvonen AP, Oyj T, Pulkkinen M (2004) A practical approach to EA planning and development: the EA

management grid. In: 7th international conference on business information systems

Holcman SB (2012) Reaching the pinnacle: a methodology of business understanding, technology

planning, and change (implementing and managing enterprise architecture). Pinnacle Business

Group Inc, Farmington Hills

Javanbakht M, Rezaie R, Shams F, Seyyedi MA (2008) A new method for decision making and planning

in enterprises. In: 3rd international conference on information and communication technologies:

from theory to applications, 2008. ICTTA 2008, 7–11 April 2008, pp 1–5

F. Nikpay et al.

123

Kaplan B, Maxwell JA (2005) Qualitative research methods for evaluating computer information

systems. In: Evaluating the organizational impact of healthcare information systems. Springer,

Berlin, pp 30–55

Kitchenham BA, Charters S (2007) Guidelines for performing systematic literature reviews in software

engineering. Keele University and Durham University Joint Report

Lankhorst M (2009) Enterprise architecture at work: modelling, communication, and analysis, 2nd edn.

Springer, New York

Lankhorst M (2012) Enterprise architecture at work: modelling, communication and analysis. Springer,

New York

Leist S, Zellner G (2006) Evaluation of current architecture frameworks. In: Proceedings of the 2006

ACM symposium on applied computing. Dijon, pp 1546–1553

Malta PM, Sousa RD (2012) Dialogical action research for better enterprise architecture implementation.

Innovation Vision 2020: Sustainable growth, Entrepreneurship, and Economic Development,

pp 1682–1688

Maxwell JA (2012) Qualitative research design: an interactive approach: an interactive approach. Sage,

Thousand Oaks

Medini K, Bourey JP (2012) SCOR-based enterprise architecture methodology. Int J Comput Integr

Manuf 25(7):594–607

Morganwalp JM, Sage AP (2004) Enterprise architecture measures of effectiveness. Int J Technol Policy

Manag 4(1):81–94

Myers MD, Newman M (2007) The qualitative interview in IS research: examining the craft. Inf Organ

17(1):2–26

Nakakawa A, Bommel PV, Proper H (2009). Requirements for collaborative decision making in

enterprise architecture. In: Proceedings of the 4th SIKS/BENAIS conference on enterprise

information systems, Nijmegen

Niemi E (2013) Quality attributes for enterprise architecture processes. J Enterp Archit 9(1):1–8

Nikpay F, Selamat H, Rouhani BD, Nikfard P (2013) A review of critical success factors of enterprise

architecture implementation. In: 2013 International Conference on informatics and creative

multimedia (ICICM), pp 38–42

Noran O (2013) Building a support framework for enterprise integration. Comput Ind 64(1):29–40

Pulkkinen M, Hirvonen A (2005) EA planning, development and management process for agile enterprise

development. In: Proceedings of the 38th annual Hawaii international conference on system

sciences, 2005. HICSS’05, 223c–223c

Rico DF (2006) A framework for measuring ROI of enterprise architecture. J Organ End User Comput

18(2):48–56

Rouhani BD, Mahrin MN, Nikpay F, Nikfard P (2013) A comparison Enterprise Architecture

Implementation Methodologies. In: International conference on informatics and creative multimedia

(ICICM), 2013. IEEE, pp 1–6

Rouhani BD, Mahrin MN, Nikpay F, Rouhani BD (2014) Current issues on Enterprise Architecture

Implementation Methodology. New Perspect Inf Syst Technol 2:239

Rouhani BD, Mahrin MNR, Nikpay F, Nikfard P, Najafabadi MK (2015a) Factors that affect the

effectiveness of enterprise architecture implementation methodology. World Acad Sci Eng Technol

Int J Soc Behav Educ Econ Bus Ind Eng 9(1):19–25

Rouhani BD, Mahrin MNR, Nikpay F, Ahmad RB, Nikfard P (2015b) A systematic literature review on

Enterprise Architecture Implementation Methodologies. Inf Softw Technol 62:1–20

Runeson P, Host M (2009) Guidelines for conducting and reporting case study research in software

engineering. Empir Softw Eng 14(2):131–164

Saat J, Aier S, Gleichauf B (2009) Assessing the complexity of dynamics in enterprise architecture

planning–lessons from Chaos theory. In: Proceedings of 15th Americas conference on information

systems (AMCIS 2009), San Francisco

Saha P (2012) Enterprise architecture for connected e-government: practices and innovations.

Information Science Reference, Hershey

Sessions R (2007) Comparison of the top four enterprise architecture methodologies. http://www.

objectwatch.com/whitepapers/4EAComparison.pdf

Shirazi H, Rouhani B, Shirazi M (2009) A framework for agile enterprise architecture. Int J Intell Inf

Technol Appl 2(4):5

Spewak SH, Hill SC (1993) Enterprise architecture planning: developing a blueprint for data,

applications, and technology. QED Pub. Group, Boston


123

http://www.objectwatch.com/whitepapers/4EAComparison.pdf

http://www.objectwatch.com/whitepapers/4EAComparison.pdf

Spewak S, Tiemann M (2006) Updating the enterprise architecture planning model. J Enterp Archit

2(2):11–19

Tang A, Han J, Chen P (2004) A comparative analysis of architecture frameworks. In: 11th Asia-Pacific

software engineering conference, pp 640–647

The Open Group (2009) TOGAF Version 9. The open group architecture framework (TOGAF). http://

www.opengroup.org

Tupper CD (2011) Enterprise architecture frameworks and methodologies, chap 2. In: Data architecture.

Morgan Kaufmann, Boston, pp 23–55

Urbaczewski L, Mrdalj S (2006) A comparison of enterprise architecture frameworks. Issues Inf Syst

7(2):18–23

van der Raadt B, Bonnet M, Schouten S, van Vliet H (2010) The relation between EA effectiveness and

stakeholder satisfaction. J Syst Softw 83(10):1954–1969

Van Grembergen W, Saull R (2001) Aligning business and information technology through the balanced

scorecard at a major Canadian financial group: its status measured with an IT BSC maturity model.

In: Proceedings of the 34th annual Hawaii international conference on system sciences

van Steenbergen M, Brinkkemper S (2010) Modeling the contribution of enterprise architecture practice

to the achievement of business goals. In: Information systems development, Springer US,

pp 609–618

Wagter R (2005) Dynamic enterprise architecture: how to make it work. Wiley, Hoboken

Wegmann A (2003) On the systemic enterprise architecture methodology (SEAM). In: International

conference on enterprise information systems 2003 (ICEIS 2003). Angers, pp 1–8

Wegmann A, Balabko P, Le L-S, Regev G, Rychkova I (2005) A method and tool for business-IT

alignment in enterprise architecture. In: Proceedings of the CAiSE’05 Forum Faculdade de

Engenharia da Universidade do Porto. Portugal 6

Wegmann A, Regev G, Rychkova I, Le L-S, De La Cruz JD, Julia P (2007) Business and it alignment

with seam for enterprise architecture. In: 11th IEEE international enterprise distributed object

computing conference, 2007. EDOC 2007

Weiss S, Winter R (2012) Development of measurement items for the institutionalization of enterprise

architecture management in organizations. LNBIP 131:268–283

Winter R, Fischer R (2007) Essential layers, artefacts, and dependencies of enterprise architecture.

J Enterp Archit 3(2):7–18

Winter K, Buckl S, Matthes F, Schweda CM (2010) Investigating the state-of-the-art in enterprise

architecture management methods in literature and practice. In: MCIS 2010 proceedings. Paper 90

Yin RK (2013) Case study research: Design and methods. Sage, Thousand Oaks

Zachman JA (1987) A framework for information systems architecture. IBM Syst J 26(3):276–292

F. Nikpay et al.

123

http://www.opengroup.org

http://www.opengroup.org

Documents

An effective Enterprise Architecture Implementation ... · An effective Enterprise Architecture Implementation ... 2.2 Enterprise Architecture Implementation Methodology ... The Open