A Framework for Enterprise Agility

Middlesex University London Doctoral Transfer Thesis

A Framework for Enterprise Agility

Supervisors:

Author: Joshua Chibuike Nwokeji

Professor Tony Clark Professor Balbir S. Barn

A Doctoral Transfer Thesis, submitted in partial fulfilment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science Middlesex University, London

February 2015

Declaration of Authorship I, Joshua C. Nwokeji, declare that this thesis titled, A Framework for Enterprise Agility, and the work presented in it are my own. I confirm that:

This work was done wholly or mainly while in candidature for a research degree at this University.

Where any part of this thesis has previously been submitted for a degree or any other qualification at this University or any other institution, this has been clearly stated.

Where I have consulted the published work of others, this is always clearly attributed.

Where I have quoted from the work of others, the source is always given.

With the exception of such quotations, this thesis is entirely my own work.

I have acknowledged all main sources of help.

Where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed myself.

Signed: Joshua Chibuike Nwokeji

Date: February 2015

i

“You have heard that it has been said, You shall love your neighbor, and hate your enemy. But I say to you, Love your enemies, bless them that curse you, do good to them that hate you, and pray for them which spitefully use you, and persecute you;�

Abstract

Enterprise agility, generally defined as the ability of an enterprise to detect and respond to changes timely, and appropriately, has been regarded as a core imperative for enterprise performance, effectiveness and efficiency. On the other hand, lack of enterprise agility often comes with dire consequences such as loss of market share, loss of competitive advantage, and even bankruptcy. Yet, a vast majority of enterprises are yet to achieve and sustain agility, for some, agility is elusive, difficult, and challenging, while others are searching more efficient methods and technologies for achieving and sustaining enterprise agility.

Although scholars are investing on the use of enterprise modelling techniques, such enterprise architecture (EA), for the purpose of achieving and sustaining agility. But it is not clear whether or how EMFs can support enterprise agility.

To understand the role EMFs play in enterprise agility, this research consolidated and developed a requirements framework for enterprise agility. This framework is then used to review 13 popular EMFs used in research and industry. The result of the review suggests that popular EMFs do not meet the requirements for agility.

This research further identify certain gaps in these EMFs with respect to the requirements for agility.

In order fill these gaps, and enhance agility, a modelling framework for agility is developed in this research. This framework can be used by enterprise stakeholders to model change drivers, improve knowledge sharing and communication, model and relate enterprise goals to change drivers, among other uses. In this way, enterprise agility can be realised, achieved, and sustained.

Contents Declaration of Authorship

i

Abstract

iii

1 Introduction 1.1 Overview . . . . . . . . . . . .

1.2 Problem Definition . . . . . .

1.3 Hypothesis . . . . . . . . . . .

1.4 Assumptions . . . . . . . . . .

1.5 Solution . . . . . . . . . . . .

1.6 Contributions . . . . . . . . .

1.7 Research Question . . . . . .

1.8 Research Aim and Objectives 1.9 Research Methodology . . . .

1.10 Thesis Organization . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

1 1 4 5 6 7 9 11 11 11 12

2 Requirements Framework for Enterprise Agility 2.1 Enterprise Agility Concepts . . . . . . . . . . . .

2.1.1 Agility Enablers . . . . . . . . . . . . . . .

2.1.2 Change Drivers . . . . . . . . . . . . . . .

2.1.3 Change Propagation . . . . . . . . . . . .

2.2 Requirements Identification . . . . . . . . . . . .

2.2.1 Motivating Example . . . . . . . . . . . .

Case Study Question: . . . . . . . .

2.2.2 Modelling Change Drivers . . . . . . . . .

2.2.3 Goal Modelling Technique . . . . . . . . .

2.2.4 BP and IT Models . . . . . . . . . . . . .

2.2.5 Alignment and Traceability Models . . . .

2.2.6 Agile EA Model . . . . . . . . . . . . . . .

2.3 Chapter Summary . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

13 14 15 15 16 17 17 18 18 20 21 22 23 24

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

3 Literature Review 25 3.1 Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 Review Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3 Review Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 iv

3.4

3.5

3.6

3.7

3.8

Enterprise Architecture Frameworks-EAFs . . . . .

3.4.1 TOGAF . . . . . . . . . . . . . . . . . . . .

3.4.2 Zachman . . . . . . . . . . . . . . . . . . . .

3.4.3 Archimate/Armour . . . . . . . . . . . . . .

3.4.4 MoDAF/DoDAF . . . . . . . . . . . . . . .

Business-IT Alignment Models-BIAMs . . . . . . .

3.5.1 Strategic Alignment Model-SAM . . . . . .

3.5.2 Strategic Alignment Maturity Model-SAMM 3.5.3 ITIL . . . . . . . . . . . . . . . . . . . . . .

3.5.4 COBIT . . . . . . . . . . . . . . . . . . . .

Goal Oriented Models-GOM . . . . . . . . . . . . .

3.6.1 BMM . . . . . . . . . . . . . . . . . . . . .

3.6.2 KAOS . . . . . . . . . . . . . . . . . . . . .

3.6.3 I-Star (i*) . . . . . . . . . . . . . . . . . . .

GAPS in the Existing EMFs . . . . . . . . . . . . .

3.7.1 Gaps in modelling change drivers . . . . . .

3.7.2 Gaps in Goal Modelling . . . . . . . . . . .

3.7.3 Gaps in Traceability and Alignment . . . . .

3.7.4 Gaps in other domains . . . . . . . . . . . .

Chapter Summary . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

4 Research Progress, Future Work, and Contribution 4.1 Research Progress . . . . . . . . . . . . . . . . . . . .

4.1.1 February-August 2012 . . . . . . . . . . . . .

4.1.2 September 2012-February 2013 . . . . . . . .

4.1.3 February-July 2013 . . . . . . . . . . . . . . .

4.1.4 August-December 2013 . . . . . . . . . . . . .

4.1.5 January-March 2014 . . . . . . . . . . . . . .

4.2 Future Work . . . . . . . . . . . . . . . . . . . . . . .

4.2.1 Chapter 4 . . . . . . . . . . . . . . . . . . . .

4.2.2 Chapter 5 . . . . . . . . . . . . . . . . . . . .

4.2.3 Chapter 6 . . . . . . . . . . . . . . . . . . . .

4.2.4 Chapter 7 . . . . . . . . . . . . . . . . . . . .

4.2.5 Chapter 8 . . . . . . . . . . . . . . . . . . . .

4.3 Contributions . . . . . . . . . . . . . . . . . . . . . .

4.4 Research Time Plan . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

29 29 30 32 33 33 34 36 37 38 39 39 41 42 42 43 43 44 44 44

. . . . . . . . . . . . . .

45 45 45 46 47 49 50 50 50 51 51 51 51 52 53

References

55

References

55

Chapter 1 Introduction 1.1

Overview

An enterprise architecture-(EA) can be defined as a conceptual model that describes the relationships between an enterprise’s business requirements, business processes, and technologies [1]. The business requirements domain explains the motivations or whys for the existence of an enterprise in terms of (business) goals.

A goal describes what an enterprise or a stakeholder thereof intends to achieve.

Stakeholders are active entities that define business goals and carry out other functions in an enterprise. An Example of EA for a Loan company is shown in Figure 1.1. The business goal for this company as defined by stakeholders such as CEO, is to provide excellent loan services. This goal can be actualised through a set of logically coherent and stepwise activities called business process, in this case the l oan service business process. Business processes are implemented by application functions such as, a database management system (DBMS) as shown in Figure 1.1. Application functions run on technology components, for instance a database server. The technology domain describes those application functions that drives the business processes, and the technology components that run them [2].

Usually, an EA is developed using a set of principles or guidelines known as enterprise architecture frameworks (EAF) [3]. Examples of popular EAFs include the open group architecture framework (TOGAF) [4], and the ministry of defence architecture framework (MODAF) [5].

Organizations invest in EA to derive certain benefits such as managing the impact of complications due to changing market needs, government regulations, and the 1

Chapter1. Introduction

2

Figure 1.1: Example of Enterprise Architecture for a Loan Company

pervasive nature of Information Technology [6, 7]. EA helps organizations to manage legacy systems by providing a method to migrate from a current state (AS-IS) to a desired state or (TO-BE) [1, 2]. Since EA provides a holistic view of an organization’s state, it can be utilised to improve interoperability and integration especially in the case of merger, and acquisition [8]. Business requirements and processes in successful organizations can grow and become complex over time due to factors such as variable customers demands, competitions, and uncertainties [6].

Organizations react to this by acquiring more technologies to drive business processes. EA can help to manage these complexities by providing transparency between business requirements/process and information technology, this can be refereed to as business and information technology alignment (BIA) [1, 9, 10]. Organizations benefit from EA in other areas such as improved risk management, impact assessment, cost reduction, information technology (IT) governance, regulatory complaints, and competitive advantage [6].

Among the potential benefits of EA, the area of business and information technology alignment (BIA) is of interest. This is because BIA has been found to be the main objective for EA [1], invaluable for successful organizations [11, 12], yet it is

Chapter1. Introduction

3

still challenging, unattainable, and a major concern of business executives and IT managers [1, 6]. BIA has been broadly defined as the degree of fit or integration between business and technology [6, 13]. It improves an organization’s ability to maximize profit, helps in realising business mission, reduces redundancies in technology, enhances information systems usage, efficiency, and effectiveness [1, 6, 13].

In addition, BIA can potentially benefit organizations in the area of enterprise agility, defined as the ability of an enterprise perceive and respond to changes appropriately and timely [14, 15]. For instance, BIA can facilitate knowledge sharing, communication and collaboration among enterprise stakeholders, which are important enablers of enterprise agility [1, 13]. Agility enhances enterprise performance, supports customers’ satisfaction and retention, increases competitive advantage, reduces operational costs, makes an enterprise to respond to uncertainties and adapt to changes optimally, among many other benefits [13, 16, 17]. In-spite of its benefits, a vast majority of enterprises found agility very challenging and difficult to attain [16, 18].

There is an existing argument in scholarly literature [1, 13, 16, 19] that BIA in enterprise systems (ES) such as EA is a major enabler of enterprise agility. Yet recent studies show that BIA is still elusive and challenging, difficult to attain, and has become the major concern for corporate executives [20–25]. Similarly, achieving enterprise agility has remained a major problem and challenge for business organizations [13, 16, 18, 26, 27]. Till date, it is unclear how BIA can effectively be utilised to support or address the enterprise agility problems [13, 15, 19]. The position of this research is that a model driven BIA can be used to realise enterprise agility. As an extension to previous studies, this research proposes a language definition for enterprise agility using model driven approach. The contribution at hand is a BIA language that can enable agility in enterprises.

The rest of this chapter is organized as follows. The problems and challenges of enterprise agility is described in Section 1.2. Section 1.3 presents the research hypothesis, and defines the concept of enterprise agility, and perception. The assumptions made for this research are listed and explained in Section 1.4. The proposed solution for enterprise agility problem is described in Section 1.5, while the research contributions are discussed in Section 4.3. Section 1.7 presents the research question, and Section 1.8 defines the research aim and objectives. Finally, the research methodology is presented in Section 1.9.

Chapter1. Introduction

1.2

4

Problem Definition

The 21st century business environment is characterised with spontaneous changes and uncertainties that can have negative impact on enterprises. These changes are often caused by certain change (agile) drivers from within or outside the enterprise [19, 28]. Change drivers are generally defined as the events, rules, and circumstances that bring about change in an enterprise [4], for instance a new government regulation, or variable customers demands can bring about a major change in an organization. As shown in Figure 1.2 change drivers can exist at any domain of an enterprise. Change drivers bring about change, hence changes can emanate from any domain of the enterprise. Since the domains of enterprise systems are often integrated, changes in one domain will have ripple effect on other domains adversely or otherwise. For instance, a change in business requirements domain due to government legislation can cause changes in business process and technology domains.

Figure 1.2: Change Drivers in EA

Given the complex nature of today’s global market environment, enterprises are repeatedly faced with the challenge of responding to these changes, and uncertainties

Chapter1. Introduction

5

timely and appropriately [26, 29]. Inability to respond to changes appropriately (non-agile) comes with potentially dire consequences such as financial loss, loss of competitiveness, bankruptcy, loss of market share, inefficiencies, among others [26, 29]. On the other hand, enterprise agility has been considered a critical success factor to the optimal performance of an enterprise, and a core imperative for enterprise efficiency and effectiveness [13, 16, 19, 30, 31]. Yet, enterprise agility is still challenging, unattainable, difficult to achieve, and a major concern of corporate executives [13, 16, 18, 26, 27]. Van Oosterhout et al [18] believe that despite existing scholarly efforts towards actualising agility, till date no one knows how to achieve agility, while Tallon and Pinsonneault [13] observe that enterprises are still seeking for better ways to improve agility.

Perception of, and response to change (drivers) are the two fundamental factors that influence enterprise agility (problems) [14, 19, 32]. The former has been less explored, but broadly defined as the ability to detect change (drivers) timely, while the later refers to the ability to react to change (drivers) appropriately [14, 19].

Existing research [15, 16, 26, 33, 34] has considered the aspect of change response i.e, how enterprise can react to changes effectively, and how to measure those changes. For instance, Goodhue et al suggest information technology as a means for responding to changes [15]. Similarly Lin et al proposes the use of fuzzy logic to measure enterprise agility [33]. However none of these studies considers the aspect of change perception i.e, the ability to sense or detect changes timely. At the same time, technologies and modelling languages for realising change perception are not yet widely available, therefore enterprise agility still remains elusive [13, 16, 18, 26, 27].

1.3

Hypothesis

This research is based on the hypothesis that: A model driven framework and technology can support and enhance the achievement and sustenance of enterprise agility.

The term model driven is used here to imply that the proposed framework is developed by analysing, designing, and creating various models relating to EA, BIA, enterprise agility, and change drivers. A Model refers to a coherent set of concepts

Chapter1. Introduction

6

that describe a real world system [35]. Enterprise architecture alignment is taken to mean the alignment of business with information technology (BIA). Enterprise agility is defined as the timely perception or sensing of change (drivers) in an enterprise. Perception here is viewed as the prior knowledge of those domains or elements of an enterprise that will be affected by a given change driver [14, 19, 32].

For instance, given a particular change driver on the business requirements domain, say new government legislation, an enterprise should be able to detect whether this change will affect the business process domain only, technology domain only, or both. The enterprise should also be able to detect the elements of business process or technology the given change can potentially affect.

1.4

Assumptions

This research assumes that: i A simple EA can be represented in three modelling domains as (business requirements) goal oriented model, business process model, and information technology model, as already described in Section 1.1, and shown in Figure 1.1. ii There are two types of change drivers i.e external and internal change drivers.

External change drivers such as government legislation come from the external environment, while internal change drivers such as organizational politics are from the internal environment of the organization [19]. However, as shown in Figure 1.2 only external change drivers are considered in this research. This is because external change drivers have been reported in existing studies [19, 33, 34] to be the most catastrophic and frequent type of changes in today’s organizations. iii It is possible to identify and delineate EA domains, and the change drivers applicable to each of them. Only change drivers at the business requirements domain are considered in this research. The business requirements domain is considered important here because it defines the overall intention, aims, and objectives of the business, thus it can be regarded as the nucleus of the enterprise which controls and determines the functions of other domains.

Chapter1. Introduction

1.5

7

Solution

Change detection is imperative to achieving enterprise agility [14, 19, 32]. Change detection here is taken to mean the fore-knowledge of those domains of an enterprise that will be affected by a given change driver. Representing the enterprise as an integrated system consisting of those orthogonal elements that are potentially affected by change drivers, to understand how these orthogonal elements relate to, or depend on change drivers, can facilitate change detection. Equally, integrating the various domains (business goals, busies process, and technology) of an enterprise into a holistic view, to provide visibility and transparency among those domains and increase knowledge sharing among business and technology stakeholders can facilitate change detection [13, 16, 19]. A modelling framework can be useful to these ends.

Therefore, this research proposes a model driven framework for enterprise agility shown in Figure 1.3, as a potential solution to the enterprise agility problems.

Model driven approach provides an important technique known as a meta-model, which can integrate the various elements of a (complex) system, and describe their relationships and dependencies in a holistic view. In addition, a meta- model defines the rules, constraints, and a language for expressing other models [36, 37], and thus can be used to develop a modelling language for agility. Models, modelling frameworks, and meta-models can be useful approaches in designing solutions to most systems and software engineering oriented problems, especially for complex systems consisting of orthogonal parts. Modelling frameworks have been used to address systems development concerns including requirements analysis in enterprise architecture [2], transformation of manufacturing enterprise systems [38], information loss and data incompatibility in product development systems [39], and managing product life cycles [40]. A Modelling approach can provide a means of understanding the elements of a complex system, the relationships and dependencies between these elements, the changes that can occur in the system, and how the system can adapt to those changes. Models can be utilised to provide a holistic view of an enterprise, and facilitate visibility and understanding between business and It stakeholders, as required for enterprise agility. In addition, Metamodels support the automation of software systems using Model Based Software Engineering (MBSE) techniques [41].

Chapter1. Introduction

8

Figure 1.3: The proposed Model Driven Framework for Enterprise Agility

The modelling framework shown in Figure 1.3 consists of a change model which defines a new technique for modelling changes drivers, relating them to, and understanding how they impact on, business (requirements) goals. The EA (model) provides an interface where change drivers impacts on the enterprise, and consist of the business requirements or goal model, business process model, and technology model as described in Section 1.1. The alignment model defines a technique for relating business goal with business process, and information technology. When change drivers impact on an enterprise, it is expected that certain domains and elements of the enterprise will re-adjust or change in order to counter the effect of the change driver and maintain its equilibrium. Effectively, this re-adjustment creates a new architecture of the enterprise called Agile EA. Agile as used here implies that the resultant EA is resilient, and aware of the necessary changes required to respond to changes appropriately.

Chapter1. Introduction

9

Another useful aspect of this framework is the use of goal model to express business requirements for agility. Goals elaborate what an enterprise desires to achieve, and can help to clarify those business requirements that are affected by change drivers [2]. Enterprise agility can benefit from goal driven approaches in number of ways: Goals can be refined, modified, and manipulated to achieve a certain outcome [42], therefore they can provide the flexibility (in the enterprise’s requirements) required to re-adjust and respond to changes appropriately. Equally, goals are good tools for detecting changes timely, this is because an enterprise can relate to its external environment through its goals. For instance, a customer satisfaction goal, will allow an enterprise to relate to customers in its environment.

This relationship can be leveraged to detect changes timely e.g. in customers’ demand. Moreover, goals are measurable [4], therefore they can be used to evaluate enterprise agility. Finally, since goals describes what an enterprise desires to achieve, agility criteria and indicators such as flexibility, and manoeuvrability can be expressed as goal.

1.6

Contributions

The core objectives of agility are to improve enterprise efficiency and effectiveness, save cost, and remove non-value adding activities [16, 19]. The realisation of these objectives depends on the ability of the concerned enterprise stakeholders to infer in advance, how a given change driver can affect business requirements, and what kind of change will such a change driver cause. Thus, for a given change driver, it will be necessary for stakeholders to answer questions such as, what kind of readjustments are needed to respond to such a change? Which domains or elements of the enterprise will be affected by such a change? How will these domains be affected ? What options and resources are available for responding to such a change? What pre-emptive actions are to be taken? Existing enterprise agility frameworks provides little or no support for addressing these questions. A major contribution of the framework proposed in this research is to help in answering these questions.

Change drivers are the primary cause of change in enterprise, yet to date, there is scarcely any technique for modelling change drivers. This research contributes to enterprise agility by providing a technique for modelling change drivers. This

Chapter1. Introduction

10

modelling technique can potentially clarify ambiguous change drivers, help stakeholders to understand how change drivers impact on the domains of an enterprise, and make it easier to relate change drivers to the entire enterprise.

Optimal response mechanism can be applied to counter the effects of a given change driver, say, a new government regulation. Response mechanism can be defined as the ways in which the enterprise can readjust in order to respond to change drivers. For example, the enterprise can modify existing business requirements, introduce new business requirements, hire new stakeholders etc, to meet the new regulation. A wrong response mechanism will likely have cost and other implications, and influence the enterprise negatively. For instance, an enterprise will possibly incur financial and other loss if stakeholders introduce new product as a response to a change driver, when the optimal response should have been to hire a new stakeholder. Thus response mechanism is considered to be strategic.

The framework proposed in this research can support this approach by laying the foundation for new types of analysis such as: What-If Analysis for Enterprise Agility: With the proposed language, it can be possible for enterprise stakeholders to discern or derive in advance the optimal response for a given change driver. This can be done in terms of what-if-analysis, e.g what will be the appropriate response mechanism if the enterprise is impacted by new government regulations? This type of derivation can be possible because the proposed language provides a technique that should describe a change driver in form of a model, so that it can be related to other domains of the enterprise. This can help stakeholders to understand which elements (of the enterprise) will be affected, and the best way to response to any change caused by the change driver.

Goal Seeking Analysis for Enterprise Analysis: Change drivers do not only pose threats, they also provide opportunities for improvements [31]. For instance, a particular change driver, can cause an enterprise to reduce its operating cost and gain cost effectiveness. Stakeholders might be interested in knowing in advance, which change drivers can lead to reduction in operation cost. Goal seeking analysis provided by the proposed framework can help this approach. Since the proposed framework represents an enterprise as an integrated system which takes change driver as an input, undergo certain processes within the EA, and output an agile EA. It can support a goal seeking analysis.

Chapter1. Introduction

1.7

11

Research Question

The major question this research will answer is as follows: Can a modelling framework be used to facilitate enterprise agility?

1.8

Research Aim and Objectives

The aim of this research is to develop a modelling framework that can help to address enterprise agility problems.

This is will be actualised through the following objectives: i To review existing literature in order to understand the issues, problems, and state of the art in EA, BIA, Goal model, and enterprise agility. ii To get a good knowledge of technologies, such as EMF, and EuGENia, used for developing and implementing modelling frameworks. iii To gather and analyse the requirements for the proposed framework. iv To design and develop a modelling technique for describing enterprise change drivers, and alignment of enterprise domains v To implement a tool that can be used to facilitate enterprise agility. vi To design an experiment (case study) for validating the proposed framework.

1.9

Research Methodology

The proposed modelling framework for enterprise agility is considered to be a system, therefore the systems development life cycle SDLC methodology is used. The SDLC is a systems development methodology that provides a definite but iterative work phases for developing information systems [43]. Usually, requirements analysis is the first phase of the SDLC. This phase involves the gathering, elaboration, elicitation, and specification of the requirements for the proposed framework. The design phase involves the detailed description of the functions of various parts of

Chapter1. Introduction

12

the systems as realised from the requirements phase. In the implementation phase the design specification is implemented using a computer program or an a systems integrated development platform. The system is then tested using an experiment from a case study. If the implemented system does not meet the requirements, then the entire life cycle is repeated, until all the requirements are satisfied. The iteration ends when a set of requirements identified from the case study is satisfied.

Further details about the methodology are discussed in Chapter 3.

Figure 1.4: Methodology

1.10

Thesis Organization

The rest of this thesis is organised as follows. The next Chapter describes some salient agility concepts, defines enterprise agility within the context of this research, and presents a requirements framework for enterprise agility. In Chapter 3, this requirements framework is used as the basis to review popular enterprise modelling frameworks that can potentially be used for agility, and identify the gaps in them. Chapter 4 outlines the research progress, describes the future work, and explains the contributions this research intends to make.

Chapter 2 Requirements Framework for Enterprise Agility Requirements modelling (RM) is an important aspect of enterprise informations systems (IS) development, it helps stakeholders to understand, document, and clarify the various domains and elements of the system, including the relationships and dependencies between them [2]. More so, some variants of requirements modelling, such as model driven development, can provide techniques for defining abstract syntax or meta-model from where executable systems and software tools can be generated. For enterprise agility, requirements modelling is needed to specify and elaborate change drivers and change propagation, facilitate knowledge sharing among stakeholders, enhance the alignment of enterprise domains, clarify those business requirements that can be affected by change, among others. However, most enterprise agility frameworks, such as enterprise architecture frameworks, do not clearly specify the requirements for enterprise agility, i.e, how and what an enterprise must do to achieve agility, including the roles requirements modelling plays in achieving sustaining agility. Thus agility has remained challenging, elusive and difficult to attain [13, 16, 18, 26, 27].

This chapter proposes a requirements framework for enterprise agility. First the definitions of relevant enterprise agility concepts are presented. Then the enablers or facilitators of enterprise agility are identified from a systematic literature survey.

Using these enablers, a requirements framework for enterprise agility is proposed.

13

Chapter 2. Requirements Framework for Enterprise Agility

2.1

14

Enterprise Agility Concepts

The need for modern enterprises to act on sudden changes due to varying customers needs, shorter products life-cycle, government regulations, competitions, technology advances, gave rise to the concept of enterprise agility. Various scholars have defined agility in various ways, for instance Arteta and Giachetti [26] define agility as the ability to adapt to changes and make use of opportunities that changes bring, while agility is defined in [1, 15, 18, 31–33] as the ability to sense and respond to environmental change readily. Dongback and La Paz [14] identify the conditions for achieving enterprise agility to include perception of changes in the external and internal environment, processing these changes to derive intelligence, responding to changes timely and in a cost effective manner, aligning information systems to adapt to changes, learning which involves documenting and building on the experiences derived from the change, and enhancing enterprise competence with these experiences [14].

Although scholars have varying opinions in defining enterprise agility, they all agree that change response is the key prerequisite for achieving and sustaining enterprise agility. However, these definitions and approaches offer certain limitations. For instance, they focus more on reactive measures towards agility, by describing what organizations should do to respond to changes that have already taken place. Proactive and pre-emptive measures towards agility, i.e what organizations must do to forestall change drivers from impacting on the organization, are often neglected, if considered at all. This research follows a different approach, and introduces proactive and pre-emptive measures to achieving and sustaining enterprise agility. Therefore, the definition of agility in this research is as follows: Enterprise agility is the ability of stakeholders to pre-empt change drivers from impacting on the enterprise.

This definition implies that to achieve agility, enterprise stakeholders must be equipped with the necessary techniques to specify, model, view, analyse, and understand change drivers, the domains or elements of the enterprise they (change drivers) potentially affect, and the ripple effects or change propagation they can cause to other domains of the enterprise.

Chapter 2. Requirements Framework for Enterprise Agility

2.1.1

15

Agility Enablers

Agile Enablers also called agile facilitators/capabilities, are factors, processes, objects, and activities such as BIT alignment and change management, that enhance enterprise’s ability to respond to change [16]. A list of common agile enablers gathered from a systematic literature search is shown in Table 2.1. Agile enablers are important because they can provide the basis for the design and development of the requirements framework for enterprise agility.

2.1.2

Change Drivers

Change drivers, also called drivers of/for change or agile drivers are events, factors, and circumstances such as varying customers demands, technology advances, and government regulations, that bring about changes in an enterprise [4, 46, 47].

Change drivers can be categorised into external and internal change drivers. The former refers to changes drivers from outside the enterprise such as competition, and regulations, while the later refers to changes drivers from within the enterprise such as organizational politics, values, and culture [26, 76]. However, this research assumes that all change drivers are externally induced, and thus focuses on external change drivers.

In order to gain useful insight into common change drivers, a systematic literature review (SLR) was conducted in about 5 databases relating to computers science, software engineering, and enterprise information systems. The review protocol, search terms, quality criteria, selection criteria, and review method for this SLR have been discussed in Section 3.2 of Chapter 3. About to 35 scholarly publications were selected for study out of about 1089 publication returned from search strings.

As shown in Table 2.1, information technology (IT) evolution, competition, government regulations, and change propagation are among the common change drivers in modern enterprises. This insight about change drivers and enablers of agility gained from the SLR will further be useful in designing a requirements framework for enterprise agility, and developing a modelling techniques for change driver.

Chapter 2. Requirements Framework for Enterprise Agility

16

Table 2.1: Change Drivers and Agility Enablers

Change Driver

Agility Enablers

IT Changes, Upgrade of Legacy systems.

Business Changes, Competition.

BIT Alignment, Stakeholder Collaboration.

Change Management, BIT Alignment, Stakeholder Collaboration, Flexibility. Adaptation.

Customer Demands, Distributed Collaboration, Enterprise Complexity. Process Alignment.

Business dynamics, Modelling Tools, BP changes, Language Definition, Change propagation.

Change Management, BIT Alignment.

Merger/Acquisition, Flexibility/Adaptability Global Operations. of Information Systems (IS).

Changing Market, Conceptual modelling, ICT evolution.

Understanding/Modelling of business process.

Change in business Change management, requirements, BPR, Responsiveness, IT innovations.

Information/Process integration.

Changing Business Requirements/ Goal Requirements, Modelling, Competition.

Enterprise modelling.

Enterprise integration, Information sharing, Customer demands, IT transparency, Product lifecycles, Modelling techniques, Competition.

Flexibility, Responsiveness.

2.1.3

Reference [9, 48–50]

[30, 51–61]

[11, 62–64] [27, 65, 66]

[34, 67–69]

[70, 71]

[16, 72, 73]

[2, 19]

[33, 74, 75]

Change Propagation

As shown in Figure 1.1, a typical enterprise would consist of various domains such as business requirements, products and services, business process, and information technology. Ideally, these domains are represented in an architectural pattern such that they inter-relate and inter-depend on each other, e.g business process depends on technology. Therefore, when a change driver impacts on a given domain of enterprise, it causes ripple effects in other domains, this ripple effect is called

Chapter 2. Requirements Framework for Enterprise Agility

17

change propagation [65]. For instance, changes in business requirements can affect business process and results to changes in IT. Understanding the concept of change propagation can be useful in designing a requirements framework for enterprise agility. It elaborates change distribution, that is, how changes in one domain of an enterprise affect or cause changes in other domains, but also explains why collaboration, communications, and knowledge sharing among stakeholders are requirements for achieving and sustaining enterprise agility.

2.2

Requirements Identification

The term requirements can be defined as a high-level statement that describes what a system does, the services it provides, and the the conditions on the systems.

While the process of identifying, analysis, documenting, and clarifying these services, functions, and conditions of the system, is known as requirements engineering [44, 45]. Requirements can be functional, in which case it describes behaviour, service, and functionality of the system, while non-functional requirements are used to define the property, such as availability, security, and response time, of the system [44]. In the requirements identified below, functional requirements are represented with letter R, while non-functional requirements as represented with nfR. Requirements identification is important aspect of requirements engineering.

It involves analysing a business case for a system in a given domain, and discerning the requirements of such system. A motivating example of a business case is described in the section below.

2.2.1

Motivating Example

For a better understanding of the proposed requirements framework, a business case study has been described below, and used to explain certain concept of the requirements framework.

Fonny Plc and Fonz Ltd are the two major retailers of mobile phones in London with 45% and 44% market share respectively. Among the various business goals of both enterprise, the most important is to ensure

Chapter 2. Requirements Framework for Enterprise Agility

18

higher customer retention. Both companies are largely divided into business and IT departments, but rely on, and use enterprise systems and technologies to, among other reasons, integrate business functions across departments. The business team consist of stakeholders such as business analysts, and business process managers, while the IT team consist of solutions architects, enterprise architects, and database administrators. However, recently, Fonz Ltd hired Mr. Chy, an experienced business-IT specialist to be its new chief executive. Mr. Chy’s technological and managerial expertise saw a sharp decrease in price of mobile phones in Fonz Ltd. As result Fonny Plc lost 5% of its customers to Fonz Ltd, bringing down its market share to 40% from 45%.

In order to regain its market share Fonny Plc has to re-adjust and respond to this change.

Case Study Question:

What will an enterprise, in case Fonny Plc, require to

maintain agility, i.e, regain its market share?

As shown in Figure 1.3, this research proposes a model driven framework as a possible solution for enterprise agility problems. The proposition at hand is that a model driven framework can facilitate enterprise agility. Thus, for an enterprise, in this case Fonny Plc to maintain agility, it should posses certain key properties and satisfy a set of requirements, as discussed below.

2.2.2

Modelling Change Drivers

Change drivers are the major cause of changes in enterprise. However, currently there are no modelling techniques or languages for describing change drivers and how they relate to an enterprise. This research proposes that a modelling technique for change drivers is a prerequisite for achieving agility. Therefore, for a modelling framework to be suitable for enterprise agility, it should meet the following requirements: R1 -The modelling framework should provide model elements, which can be used to represent threats and opportunities offered by a given change driver.

R2 -The modelling framework should integrate the various concepts of change driver and agility into a modelling language

Chapter 2. Requirements Framework for Enterprise Agility

19

R3 -The modelling framework should provide a technique for fragmenting change drivers into constituent types.

R4 -The modelling framework should support the analysis of change driver along various dimensions such as severity, or type of change.

For Foony Plc to achieve enterprise agility, and regain their market share, its stakeholders should identify, analyse, and clarify the threats and opportunities offered by this change driver. In this case, the threat is the loss of market share, while the enterprise can use this opportunity to align its resources not only to regain, but surpass its original market share. Identifying and clarifying threats and opportunities offered by a given change driver can be a useful means to achieving agility, as it can help stakeholders to understand the negative and positive impacts of change drivers, and how they can they re-align enterprise processes for mitigating these impacts. In order to do these, certain questions are pertinent such as, what domain or domains of the enterprise will this change driver impact on?

What threats and opportunities does a particular change driver offer? What type of change, for example, operational, tactical, or strategic, can this change driver initiate? What entities for instance, product, price, and people, in the enterprise does a given change driver relate to?, etc. Modelling techniques provide a method of relating various concepts or elements in complex systems, and therefore can be useful in answering these questions, modelling change drivers, and enhancing enterprise agility.

An insight into where and how a given change driver affect an enterprise can be crucial to improving enterprise agility. It can enhance stakeholders’ understanding of the implications and effects of changes to the enterprise, and equip them with the necessary knowledge required to sustain agility. Where- refers to the domains (business, process, IT) or elements (goal, data, software) of the enterprise a given change driver can affect, while how relates to the severity (chronic or acute) of impact and type of change (operational, tactical, strategic) of the change driver can cause. Change driver fragmentation, which implies breaking down change drivers into constituent types, can be a useful means to understanding the how and where of a given change driver. In this way, it can be easier to fragment or refine a complex change driver into simpler elements, and relate them to those elements of an enterprise such as business goal, which they can possibly affect. For instance, from the above case study, the change driver competition

Chapter 2. Requirements Framework for Enterprise Agility

20

affects the business domain, and the product and price elements. It is acute and can cause operational change. With the knowledge obtained from modelling of change driver, stakeholders can then harness enterprise resources to respond to this change. Modelling techniques provide means of clarifying composite concepts by breaking them down into constituents elements, and thus will provide a useful approach for understanding agility concepts and change drivers.

In addition, modelling change drivers can enable new kind of analysis. For instance, it can be possible to analyse the impact of a given change driver, in this case, competition, along various dimensions such as severity, and type of change.

This type of analysis can further strengthen the agility process by helping stakeholders to direct enterprise resources accordingly while targeting a particular type of change.

2.2.3

Goal Modelling Technique

Goal modelling is an important aspect of requirements engineering, and can be very useful to achieving and sustaining enterprise agility. A goal is a statement of intent that describes the objectives of an enterprise or a stakeholder/system thereof [77, 78]. A parent goal may be decomposed, or refined into children or sub-goals; while a leaf goal has no children. A goal model is a directed graph consisting of nodes and links. The nodes describe model elements such as goals or sub-goals, while the links define the relationships between model elements [79, 80].

An enterprise modelling framework suitable for agility should meet the following requirements for goal modelling: R5 -The modelling framework should include a technique for expressing enterprise requirements. Such a technique can be a goal oriented model or similar modelling technique.

R6 -The modelling framework should provide model elements, such as goal, for clarifying those domains, elements or properties of an enterprise that can possibly be affected by a change driver.

R7 -The modelling framework should express agility enablers as common goals shared by enterprise stakeholders. This can be done by using model elements, such as goals, provided by the proposed modelling framework.

Chapter 2. Requirements Framework for Enterprise Agility

21

Goals help to elaborate what an enterprise or stakeholders thereof desire to achieve, defines common business objectives and requirements for enterprise stakeholders [2]. In addition, goals can help to clarify those business requirements that are possibly affected by change drivers. In this way, stakeholders can provide a targeted response to the change driver, thereby sustaining agility. From the above case study, the business requirement, ensure customer retention has been affected by the change driver, competition. Once stakeholders are able to identify the affected business requirements, they can to select an alternative business requirements using a goal modelling techniques. For example, the requirement, ensure customer retention can be refined into alternatives such as ensure customer retention by price or ensure customer retention by product differentiation. Since the price option has been affected by a change driver, stakeholders can select the second alternative i.e product differentiation, then re-engineer their product to be better than those of their competitors and regain their market share.

Since goal modelling define common objective for enterprise stakeholders, agility enablers such as information sharing can be expressed as goals, and shared by stakeholders across the domains of an enterprise. In this way, knowledge sharing and collaboration among stakeholders, which are necessary enablers of enterprise agility, can be improved and agility can be sustained.

2.2.4

BP and IT Models

As described in Section 1.2, and shown in Figure 1.2, change drivers such as business process re-engineering (BPR) and technology consolidation can impact on business process (BP), and technology (IT) domains of an enterprise respectively.

Modelling of these domains can provide a useful insight and enhance the understanding of those elements of BP or IT that can be affected by a given change driver, and how best stakeholders can respond to them using appropriate response mechanism. More so, the business and IT domains of most enterprises (EA) are often integrated in such a way that business requirements can be driven by business process applications, and implemented by IT. Although this tight integration offers more advantage, but it can make changes in one domain to have to ripple effects or cause changes in other domains of the enterprise. For instance, variation in customers demands which impacts on business requirements domain can lead to changes in BP such as BPR, and in IT such as technology integration. To manage

Chapter 2. Requirements Framework for Enterprise Agility

22

the ripple effect of changes, and improve agility, the BP and IT domains need to be expressed as models, so as to understand the relationships and interactions between respective domains, and how change in one domain can affect or result to changes in other domains. This can be written as requirements: R8 - The modelling framework should help stakeholders understand the ripple effects of changes across enterprise domain, using modelling techniques such as BP and IT models. nfR9 - The modelling framework should help stakeholders to detect and clarify the elements of BP and IT that can be affected by change drivers.

2.2.5

Alignment and Traceability Models

Enterprise architecture alignment (EAA) or business and information technology alignment (BIA) has been suggested by existing research [1, 13, 16, 19] to be a key enabler of enterprise agility. BIA refers to traceable relationship, fit or integration between business requirements (goal), information technology, and other domains of an enterprise [6, 13]. The key objectives of BIA are to integrate the domains of an enterprise, define the dependencies and interactions between the elements of these domains, and support the traceability of elements across the domains.

These objectives can be applied to support enterprise agility in various ways. For instance, the integration of enterprise domains provided by BIA can facilitate visibility and transparency of those domains and elements of an enterprise, especially those that are potential targets for change drivers. Furthermore, the dependencies, interactions, and traceability (of enterprise elements and domains) defined by BIA can enable enterprise stakeholders to collaborate, communicate effectively, share knowledge, and be prepared to detect and respond to changes timely. In this way, changes in one domain of an enterprise can be easily communicated and shared with stakeholders across other domains, and it can become easier to harmonize enterprise functions for responding to changes [13, 16, 19]. The requirements for BIA are as follows: nfR10 - The modelling framework should improve collaboration and knowledge sharing among stakeholders.

Chapter 2. Requirements Framework for Enterprise Agility

23

R11 - The modelling framework should support the modelling of dependencies among enterprise domains and elements.

R12 - The modelling framework should provide technique to trace and relate the elements of business domain and IT domain.

2.2.6

Agile EA Model

Usually, an appropriate response to a given change driver results in a new EA model, which this research termed as Agile EA. As shown in Figure 1.3, the agile EA model should describe those domains and elements of (the source) EA that need to be modified or adjusted in order to adequately respond to a given change driver. The agile EA model is useful because it can help stakeholders to take preemptive measures, and make contingency plan against known change drivers, in this way enterprise agility can be enhanced and sustained. For instance, if a change driver can be anticipated, then the agile EA model should help stakeholders to answer questions such as, What changes are required in each domain of the source EA to respond to the anticipated change, what elements of the EA need to be modified, and will the alignment model change ? By answering these questions, stakeholders will be equipped with the necessary information, intelligence, and knowledge to tackle potential change drivers. The Agile EA contains the same constituent domains and elements as a typical EA, but only used in this research to depict the changes that can occur in the baseline EA in order to respond to a given change driver. The requirements for the agile EA model are as follows: nfR13 The modelling framework should support stakeholders in taking pre-emptive measures against known change drivers. nfR14 The modelling framework should provide insight into the domains and elements of an EA that should change in order to respond to a given change driver appropriately. nfR15 The modelling framework should assist stakeholders in making contingency plans for agility.

Chapter 2. Requirements Framework for Enterprise Agility

2.3

24

Chapter Summary

This Chapter presents a requirements framework for enterprise agility. This framework is developed using certain agility enablers gathered from a semi-systematic literature search. In general, these agility drivers are consolidated into 15 requirements, i.e, R1 to R15 , five of which are non-functional requirements. While the requirements listed in this chapter may not be exhaustive, to a considerable extent, they represent the most salient requirements for enterprise agility. In addition, a useful approach to enterprise agility that considers a proactive and pre-emptive dimensions of change driver, has been introduced in this chapter. In this way, enterprise stakeholders can begin to consider what to do pre-empt change drivers, instead how to react to change drivers.

In the proceeding Chapter, these requirements are used as the basis for gap analysis on existing enterprise modelling frameworks.

Chapter 3 Literature Review 3.1

Preamble

Enterprise Agility (EAg), defined as the ability of an enterprise to detect and respond to change (drivers) appropriately and timely [14, 15], is regarded as the core imperative for organizational efficiency and effectiveness. EAg has been found to benefit modern business organizations in many ways such as, increased competitive advantage, enhancement of organizational performance, and support for customer satisfaction and retention [13, 16, 17]. On the other hand, lack of agility often comes with dire consequences such as financial loss, bankruptcy, loss of market share, among other negative effects [26, 29]. In-spite of these, a vast majority of organizations are still finding enterprise agility difficult and elusive, for others, agility is improbable and challenging, while some are searching for new methods to enhance agility [13, 16, 18, 26, 27]. This research proposes an enterprise modelling framework, discussed in Section 1.5, as a possible solution to enterprise agility problems.

Existing research, for example [1, 13, 16, 19], suggest that enterprise systems such as EA/BIA can enable enterprise agility. However, ES have not been effectively utilised to actualise agility. Moreover, it is still unclear how existing ES can enable agility, and which ES is more suitable for achieving agility [13, 15, 19]. The aim of this literature review is to study existing enterprise (modelling) systems approaches such as EA and goal oriented models, to determine the extent to which they support enterprise agility. The framework proposed by this research in Section 1.5 is used as the focal and reference point for this study. The literature 25

Chapter 3. Literature Review

26

review is intended to supports this research in the following ways: First, it provides a useful insight of the extent to which popular enterprise modelling frameworks can enable enterprise agility. Secondly, It provides a gap analysis with respect the requirements for enterprise agility. Finally, it offers guidance for the selection of an enterprise modelling framework suitable to facilitate enterprise agility.

This rest of this Chapter is organised as follows. The review method is discussed in Section 3.2. The next Section 3.4 presents a review of popular enterprise architecture frameworks (EAF) that can potentially be used realise enterprise agility.

In Section 3.5, popular business and IT alignment (BIA) models are reviewed, while Section 3.6 reviews goal oriented models popularly used in industry and research. The requirements framework for agility presented in Chapter 2 is used as the framework for these reviews.

3.2

Review Method

In order to identify a wide range of enterprise modelling frameworks that can potentially be used to realise enterprise agility, a literature search was conducted.

Although conducted in a non-systematic method, a rigorous stepwise approach was used for the literature search. First, databases relating to computer science, enterprise systems, and software engineering such as IEEE Xplore, ACM digital Library, and Springer Link were identified. Secondly, certain keywords such as EA, enterprise agility, goal oriented models, business and IT alignment, modelling frameworks, and change were used as search strings. The third step involves filtering through the search results from each database, and applying the following selection criteria: Paper published between 1994 and 2014-it is expected that selecting a wide range of papers will yield a more accurate result.

Paper must be peer reviewed, this is because peer reviewed papers are generally considered to be of high quality.

Paper must discuss at least one enterprise modelling framework Paper must be in English language

Chapter 3. Literature Review

27

Finally relevant publications are selected, and enterprise modelling frameworks (EMF) that can potentially support agility are identified for further review. As shown in Table 3.1, a total of about 13 popularly used EMF are identified and reviewed. Perhaps, there can be other EMFs not included in this research for review, but the literature search suggests that the EMFs shown in Table 3.1 are the most common and popularly used, and therefore can be sample of other EMFs. Table 3.1: Selected and Reviewed Enterprise Modelling Frameworks

EMF

Type

Main Use

Source

TOGAF

EAF

Industry

[4]

KAOS

GOMF

[42, 80–83]

ARMOR

EAF

Industry Research Research

[2, 10]

SAM

BIAF

Research

[84–86]

DoDAF

EAF

Government [87, 88]

i*

GOMF

ZACHMAN

EAF

BMM

GOMF

Industry Research Industry Research Industry

MoDAF

EAF

Government [5]

SAMM

BIAF

Research

[95–97]

ITIL

BIAF

[98, 99]

ARCHIMATE

EAF

COBIT

BIAF

Industry Research Industry Research Industry

[78, 89–91] [11, 92–94] [76]

[100, 101] [102, 103]

KEY: EMF-Enterprise Modelling Framework EAF-Enterprise Architecture Framework GOM-Goal Oriented Modelling Framework BIAF-Business and IT Alignment Framework Type-shows the type of EMF, can be EAF, BIAF, or GOMF

Chapter 3. Literature Review

3.3

28

Review Criteria

The requirements for enterprise agility discussed in Chapter 2 is used as the framework for this review. Therefore, each EMF is reviewed with regards to the requirements i.e. R1 to R15 for enterprise agility presented in Section 2.2. The following stepwise approach is followed: First, identify the aspects of the EMF that relates to enterprise agility or the requirements thereof. Second, compare these aspects with the 15 requirements for enterprise agility identified in Section 2.2. Finally, scores are assigned to each EMF using the following method: Score 2 -Assigned where the source of the EMF explicitly describe a modelling technique/approach that satisfies, or clearly meet a given requirements. For instance, the Armour framework will receive score 2 for requirements R5 because it clearly defines a goal modelling technique that can be used to elaborate enterprise requirements.

Score 1 -Assigned where the the source of the EMF needs to be extended with additional model elements, information, description, or detail before it can meet a given requirement for agility. For instance, the BMM and TOGAF identified certain change drivers common to enterprises, but do not describe how stakeholders can clarify and understand the threats and opportunities offered by those change drivers, or how change drivers can be fragmented into types. Therefore, BMM and TOGAF will receive score 1 for requirements R1 and R3 .

Score 0 -Assigned where the source of the EMF does not describe any modelling technique that meet the requirements at all. For instance, the Archimate language does not provide any technique for identifying the threats and opportunities offered by a given change driver, and therefore will get score 0 for requirements R1 .

Chapter 3. Literature Review

29

In the following Sections, these EMFs are reviewed with respect to the requirements framework for agility.

3.4

Enterprise Architecture Frameworks-EAFs

Enterprise architecture frameworks (EAF) are modelling guidelines for creating an enterprise architecture [104], and provide techniques for describing the constituent elements and domains of an enterprise, and the relationships and dependencies between them [105]. EAFs have been widely used in practice and research to design, create, develop, and maintain architecture vision, and capabilities in enterprises [104, 105]. In addition, EAFs can be used to facilitate enterprise agility.

This section reviews popular EAFs in view of how they support agility.

3.4.1

TOGAF

TOGAF is an EAF developed and maintained by The Open Group1 with key objectives of providing detailed principles, guidelines, and methods for enterprise architecture development and maintenance [4]. The core element of the TOGAF framework is the architecture development method (ADM) that provides a stepwise approach for developing and maintaining the life cycle of an EA [4]. As shown in Figure 3.1, the TOGAF ADM includes an architecture change management, which is supposed to provide techniques for enterprise agility. Additionally, the architecture change management should provide the flexibility and adaptability required to achieve enterprise agility, and supports in monitoring and managing change drivers [4].

As discussed in Section 2.2, a modelling technique for change drivers can be critical to enterprise agility. The TOGAF ADM acknowledges the importance of change drivers to enterprise agility, and further described the various types of change drivers, namely, business, and technology change drivers [4]. Nonetheless, it did not specify a modelling technique for change or change drivers, neither did it describe how change drivers can relate or interface with the domains of an enterprise.

On the other hand, the ADM [4] provides a detailed description of modelling techniques for business, IT, and information systems architecture. But, there are little 1

http://www.opengroup.org/togaf/

Chapter 3. Literature Review

30

Figure 3.1: The Architecture Development Method of TOGAF [4]

or no supports for definite modelling approaches for other elements of an agile enterprise such as alignment and traceability modelling, and goal modelling. For instance, the ADM recognizes the importance of goal requirements modelling in enterprise agility and EA, but did not define concepts and techniques for goal requirements modelling.

3.4.2

Zachman

The Zachman enterprise architecture framework (ZAF) was developed by John Zachman, following his initial research on the development of information systems architecture [92, 93]. The ZAF describes an EA as a conceptual model consisting of six by six matrix. The rows of the matrix represents perspectives or viewpoints, while the columns represents aspects. As shown in Figure 3.2, each perspective corresponds to a particular domain in an enterprise, and describes the modelling techniques and stakeholders thereof. For instance, the business model viewpoint correspond to the business domain, describes modelling techniques such as business process models, and stakeholders such as the owner of an enterprise[11, 104].

Chapter 3. Literature Review

31

Figure 3.2: The Zachman Framework for Enterprise Architecture2

The aspect in Zachman framework is describes the information such as data, function, and motivation required in each domain of an enterprise, and provide answers to stakeholders’ questions such as what, how, and why in the enterprise. The intersection between perspective and aspect or cell in the matrix represents an architectural building block (model element) of an EA [11]. Although the ZAF has been acknowledged for its strength in the analysis, design, and development of EA, including its usefulness in understanding the relationships between various building blocks of an EA [6, 104]. Yet, as shown in Table 3.2, it did not adequately define modelling techniques and concepts to support enterprise agility. This framework did not provide an insight of change drivers can affect an enterprise, or how the domains of an EA can be aligned to respond to changes appropriately and timely.

Therefore the support for enterprise agility is low in ZAF. Whereas, the framework made an attempt to introduce the aspect of motivation, which is supposed to define concepts for modelling the why, requirements, or underlying goals of the enterprise, thereby providing the flexibility required to support agility. It fails to provide a definite modelling techniques for goals, and requirements.

Chapter 3. Literature Review

3.4.3

32

Archimate/Armour

Archimate3 is an open group standard for enterprise architecture modelling, visualisation, and analysis [101]. The framework models an enterprise in two dimensions consisting of three architectural layers and aspects, effectively making the Archimate framework a three by three matrix model. Each architectural layer corresponds to the three core domains of an enterprise namely, business, application, and technology, and describes the constituent modelling elements in that particular domain. The three aspects partitions an enterprise into its information, behaviour, and structure [100, 101].

Figure 3.3: The Archimate Modelling Framework

As shown in Figure 3.3, the Archimate framework provides a useful approach for describing business process, application and technology models in terms of information, behaviour and structure [100]. However, modelling techniques for other agility elements such as change drivers, traceability, and alignment are not clearly specified, if specified at all. An extension called Armor has been proposed in [2] to complement Archimate in the area of goal and requirements modelling.

The framework combines concepts from popular goal oriented frameworks such as i*, and KAOS, with the Archimate framework, and integrate them into a language 3

http://www.opengroup.org/archimate/

Chapter 3. Literature Review

33

called Armor [10]. The aim is to enhance Archimate with goal oriented, and requirements modelling concepts, thereby encouraging goals to take part in EA process [10]. Therefore, the Armour framework provides supports for goal oriented requirements modelling but not other agility elements.

3.4.4

MoDAF/DoDAF

So far, the EAFs discussed are mostly used in industries and other non-governmental enterprises. In contrast, the United States Department of Defence architecture framework (DODAF), and the United Kingdom Ministry of Defence architecture framework (MODAF) were specifically designed to provide modelling guidance for architecture development and management, and to facilitate decision making process among military stakeholders [88, 106], but can also be used in other government departments or even industries.

The key modelling elements in DODAF and MODAF are the architecture viewpoints, and architecture data elements. The architecture viewpoints define the systematic modelling approach for creating, analysis, visualising, and understanding the architecture of the core domains in a military enterprise [88, 107]. The eight, and six architecture viewpoints respectively described by DoDAF in [87, 88], and MoDAF in [5] are quite elaborate, and have been successfully applied in developing a vast majority of military architectures in the UK and US [87, 108]. Yet, adequate support and modelling techniques for enterprise agility are noticeably lacking in the two frameworks. Whereas the DoDAF acknowledges the importance agility, and suggests that architectures should be modular and decomposable in order to achieve agility. It did not specify modelling concepts or techniques for most agility elements.

3.5

Business-IT Alignment Models-BIAMs

Business and information technology alignment(BIA), broadly defined as the degree to which information technologies fit or support business requirements and processes [6, 20, 22, 24], has been regarded as a key enabler of enterprise agility [1, 13, 109]. But the extent to which existing BIA frameworks satisfy the requirements for enterprise agility is still vaguely understood [13, 15]. This section provides a

Chapter 3. Literature Review

34

Table 3.2: The support of EAFs for Enterprise Agility EAFs Requirements for Agility R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R14

TOGAF

ZAF

ARCHIMATE

ARMOR

MoDAF

DoDAF

0 0 1 0 1 1 0 1 1 1 1 1 1 1 1

0 0 0 0 1 1 0 1 1 1 1 0 0 1 1

0 0 0 0 1 0 0 1 1 1 1 0 0 1 1

0 0 0 0 2 2 2 1 1 1 1 0 0 1 1

0 0 0 0 0 0 0 1 1 1 1 0 0 1 1

0 0 0 0 0 0 0 1 1 1 1 0 0 1 1

review of four major BIA frameworks found in literature, to determine if or how they meet the requirements for enterprise agility described in Section 2.2.

3.5.1

Strategic Alignment Model-SAM

The strategic alignment model (SAM), developed by Henderson and Venkatraman [84, 85], is a conceptual model for realising the alignment of business strategy with information technology. As shown in Figure 3.4, the strategic alignment model partitions an enterprise into external and internal components. The external component consist of business strategy-which describes domain elements such as business scope, and IT strategy-which describes IT domain elements such as technology scope. Similarly, the internal component describes the organizational and information systems (IS) infrastructure and process such as organizational skills and information systems architectures respectively [84]. SAM proposes two major types of alignment, namely, strategic fit and functional integration. Strategic fit refers to the vertical alignment between external and internal components i.e, the business and IT strategies must match with the organizational and IS infrastructure and process respectively. Functional integration defines the horizontal alignment between business and IT at each of the components i.e, an integration of business/IT strategies externally, and organizational/IS infrastructure and process internally [84, 85].

Even though SAM did not satisfy certain requirements for enterprise agility such as modelling technique for agile driver, and goal. Yet, it is a useful approach for

Chapter 3. Literature Review

35

Figure 3.4: The Strategic Alignment Model

achieving organizational efficiency, and gaining high competitiveness [86], and can also support enterprise agility in many ways. For instance, the strategic fit and functional integration methods provided by SAM can be used to elaborate relationships between domains/elements of an enterprise, so that it can be easier for stakeholders to understand how changes in one domain can relate to, affect, or cause changes at other domains, and how various elements of an enterprise inter-depend or relay on each other to respond to change drivers. Furthermore, the holistic alignment (alignment across all the domains of the enterprise) proposed in SAM can facilitate synergy, knowledge sharing, and collaboration among stakeholders at different domains. In this way, changes and intelligence required to respond to change drivers appropriately can be communicated and shared among stakeholders effectively, and enterprise functions can be harnessed to sustain agility.

Chapter 3. Literature Review

3.5.2

36

Strategic Alignment Maturity Model-SAMM

The strategic alignment model (SAMM), proposed by Jerry Luftman [95], is a methodology for evaluating the maturity of business and IT alignment (BIA).

The SAMM methodology involves two stages. In the first stage, Luftman defines six major components upon which an enterprise can measure the its BIA, namely, communications, value, governance, partnership, scope and architecture, and skills. Each of these components are further assessed using certain criteria as shown in Figure 3.5. For instance, the communication component can be evaluated based on criteria such as the degree of understanding between business executives and IT, and knowledge sharing [96, 97]. The second stage involves determining the level of maturity by assigning scores to each component using the alignment maturity metrics proposed by Luftman. The alignment maturity metrics defines five levels of BIA maturity an enterprise can attain, these are, level 1 (initial or ad-hoc process), level 2 (committed process), level 3 (established focused process), level 4 (improved manged process), and level 5 (optimised process). Level 1 and 5 represent the lowest and highest level of BIA maturity respectively [95–97]

Figure 3.5: The Strategic Alignment Maturity Model

Chapter 3. Literature Review

37

The communication, partnership, and scope and architecture components of the SAM model contain certain criteria that can enable agility. For instance, as discussed in Chapters 1 and 2, knowledge sharing and understanding between IT and business defined in the communication component, and IT flexibility criteria defined in the scope and architecture component are critical enablers of enterprise agility. However, the SAM model did not still meet the other requirements for enterprise agility defined in Chapter 2 such as goal modelling and business process modelling technique.

3.5.3

ITIL

The information technology infrastructure library (ITIL) is a framework for IT service management (ISM) currently managed by the UK office of government and commerce (OGC). ITSM describes how best IT infrastructure can be harnessed to realise business goals, clarifies business and IT alignment processes, and defines the best practice in business and IT change management, among others [98]. The core of the ITIL framework is the service principles, which provides five service guidelines for the best practice in ISM, these include service strategy, service design, service transition, service operation, and continual service improvement [98, 99].

Service transition and service operation are the two services guidelines that relate to enterprise agility. The service transition principle provides guidelines on how an enterprise can detect and manage changes, and defines how changes can be managed at strategic, tactical and operational levels [98]. On the other hand, the service operation principle describes incident and problem management processes as critical activities in ITSM. It defines an incident as a spontaneous interruption to an IT service, while a problem is an event that can lead to an incident [98].

However, both the service transition and operation principles did not describe how complex or ambiguous change drivers, incidence, and problems can be clarified or resolved, e.g through the use of (change) modelling techniques, and thus did not satisfy certain requirements for enterprise agility.

Chapter 3. Literature Review

3.5.4

38

COBIT

The control objectives for information and other related technology (COBIT) is a framework developed by ISACA (information systems audit and control association) for IT governance in enterprise. The major goals of IT governance are to derive business values from IT through BIA, and reduce IT risk to an optimised level, among others [103]. COBIT 5 framework provides five principles shown in Figure 3.6, for managing and governing enterprise IT.

Figure 3.6: The COBIT 5 Framework

With regards to enterprise agility, the COBIT 5 first principle of meeting stakeholder needs acknowledges that response to changing business environment, and IT agility are important goals to enterprise stakeholders for effective IT governance and management [102]. However, it does not provide a specific guidelines on how stakeholders can response to changes, and how IT agility can be achieved and sustained. The fifth principle of the COBIT 5 framework, i.e. separating governance from management, defines a process reference model. This reference model provides a set of activities and processes used for managing enterprise IT. These activities are as follows, APO (align, plan, and organize), BAI (build, acquire, and implement), DSS (deliver, service, and support), MEA (monitor, evaluate, and assess) [102]. Although change management is central to the BAI activity, yet the framework did provide answers to questions such as, how are causes of

Chapter 3. Literature Review

39

change modelled, and how can stakeholders understanding of change drivers be enhanced?

Table 3.3: The support of BIAFs for Enterprise Agility BIAMs Agility Requirements R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R14

3.6

SAM

SAMM

ITIL

COBIT

0 0 0 0 0 0 0 0 0 2 2 2 0 0 0

0 0 0 0 0 0 0 0 0 2 2 2 0 0 0

1 1 1 1 0 0 0 0 0 1 1 1 1 1 1

1 1 1 1 0 0 0 0 0 1 1 1 1 1 1

Goal Oriented Models-GOM

Goal oriented modelling-GOM is a requirements engineering method concerned with the identification, analysis, elaboration, and documentation of systems or enterprise requirements [77]. Actors and goals are the key model elements in GOM. An actor is an entity, human or machine, capable of performing action in a system, while a goal is a statement that describes what an actor or a system tends to achieve [77–79]. GOM possess certain properties that potentially benefit enterprise agility. For instance, the goal refinement property, which uses the ’and/or’ refinement links to define alternative goals, can be utilised to provide flexibility, especially in business requirements, needed to sustain agility. However, it is not yet very clear how GOM techniques can be effectively utilised to support enterprise agility. This section reviews three popular goal oriented modelling frameworks, to determine if and how they support enterprise agility.

3.6.1

BMM

The business motivation model-BMM is an object management group (OMG) standard for developing and managing business plans. The fundamental idea behind the BMM is that organizations must identify and define the goal or why behind its

Chapter 3. Literature Review

40

business activities [76]. As shown in Figure 3.7, identifies four major elements that support business planning, namely, means, ends, assessment, and influencers. The means element defines the mission,course of actions, and directives for achieving a desired result. Ends are the desired state of an enterprise such as goals and visions, while assessment provides a method for performing SWOT analysis on the means and ends. Influencers, similar to change drivers, are events that can cause unanticipated change. There are two types of influencers, external influencers which are events outside the organizations boundary, and internal influencers, which are events within the organizations boundary [76].

Figure 3.7: The Business Motivation Model

Even though the BMM clearly identifies drivers of change, and recognises that influencers must be elaborated and explicitly defined in order to assist stakeholders to react to changes effectively [76]. Yet, it does not define adequate modelling techniques for these influencers, neither does it describe how drivers of change can be related to other domains of the enterprise. In addition, the model only describes the business domain of an enterprise, and has no definite method on how this business domain can be aligned with other domains for an enterprise to facilitate effective collaboration and knowledge sharing between stakeholders.

Chapter 3. Literature Review

3.6.2

41

KAOS

KAOS4 is a requirements engineering methodology for analysis and documenting the requirements of a system. The methodology consist of a goal, objects, responsibility, and operations models. A goal model is a directed graph consisting of nodes and links, where each node represents model objects such as goals and obstacles.

An obstacle is a hindrance to the satisfaction of a goal. The links represent the relationships between the nodes. The object model is an entity-relationship type of diagram that describes various elements relevant to the system and the relationships between them. A responsibility model describes the actors/agents that are responsible for each goal, while the operations model describes the activities each actor/agent perform to achieve its goals [42, 81, 82].

Figure 3.8: The KAOS Model

Taken alone, the KAOS model does not describe a technique for modelling change driver, business process, and alignment of the domains of an enterprise. However, KAOS gaol modelling technique can be very useful to enterprise agility, especially when integrated into an enterprise architecture. For instance, the links in a goal model can be used to define dependencies between, and relate business requirements to other domains or elements of an enterprise. In addition, a parent goal can be refined into many children (leaf or sub-goals), providing alternative goals or requirements for stakeholders to select from in case of uncertainties. In this way, enterprise requirements are made flexible, and ready to respond adequately to change.

4

http://www.objectiver.com/fileadmin/download/documents/KaosTutorial.pdf

Chapter 3. Literature Review

3.6.3

42

I-Star (i*)

The i* framework is a requirements engineering method that emphasises on the autonomy and intentionality of actors-defined as entities capable of performing actions in a system. The concept of autonomy implies that actors are solely responsible for their actions, while intentionality implies that each actor must have a motivation for performing actions. These motivations such as goals are called intentional properties [78, 89]. The i* framework consist of two distinct models, which are the strategic dependency and strategic rational models. The Strategic dependency-SD model uses the dependency link to describe how actors collaborate to achieve their intentions. A dependency link describes how an actor called depender, depends on another actor called dependee, to achieve an intentional property called dependum. The intentional properties are used to define the type of dependency that exist between actors. The strategic rationale-SR model provides a descriptive view of the intentional properties such as goals, of each actor, and the relationships between these intentional properties using association links.

An association link shows the relationship between two or more actors, and/or intentional properties [90, 110].

Even though the i* framework scarcely satisfies most requirements for enterprise agility such as change modelling technique, alignment of domains or elements of an enterprise, and does not provide a method for a holistic view of an enterprise. The dependency links in the SD model of i* framework can be integrated into an enterprise agility framework, and used to model the collaboration between stakeholders at various domains of an enterprise. Thereby facilitating knowledge sharing and communication between enterprise stakeholders. In this way, information about drivers of change can be shared and enterprise resources can be harnessed effectively to sustain agility.

3.7

GAPS in the Existing EMFs

The key aim of this literature survey is to identify the gaps in popular enterprise modelling frameworks (EMF) with respect to the requirements for achieving and sustaining enterprise agility. The gaps identified below can be very useful when designing and implementing a new modelling framework and language to support the achievement and sustenance of enterprise agility.

Chapter 3. Literature Review

43

Table 3.4: The support of GOM for Enterprise Agility GOMs Agility Requirements R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15

3.7.1

KAOS

i*

BMM

0 0 0 0 2 2 2 1 1 0 0 0 0 0 0

0 0 0 0 2 2 2 1 1 0 0 0 0 0 0

1 1 1 1 2 2 2 1 1 0 0 0 0 0 0

Gaps in modelling change drivers

As discussed earlier, change drivers are the major causes of changes in modern day enterprise. Modelling support can offer certain advantages such as improving stakeholders understanding of the threats and opportunities offered by a given change driver, and supporting new kind of analysis. Nonetheless, as shown in Tables 3.2, 3.3, and 3.4, none of the enterprise modelling frameworks reviewed in this chapter described a technique for modelling change drivers. Although TOGAF and BMM recognise that understanding change drivers is useful for achieving and maintaining agility, and identified various types of change drivers. Yet, neither TOGAF nor BMM describe an approach to model change drivers, and relate them to other elements of an enterprise.

3.7.2

Gaps in Goal Modelling

Goal modelling can be an important approach in achieving and sustaining enterprise agility, for instance, agility enablers such as knowledge sharing, can be expressed as a business goal, and shared by all stakeholders across the enterprise.

The results in Tables 3.2, 3.3, and 3.4, show that with the exception of KAOS, i*, BMM, and ARMOR, the vast majority of enterprise modelling frameworks do not provide techniques for goal modelling. While others, such as TOGAF recognise the importance of goal and requirements modelling but do not how these goals can be modelled. Even though goal oriented models in general provide techniques for gaol modelling, yet, taken alone, they may not be suitable for achieving agility

because they do not explicitly define how the other elements of an enterprise such as business process, can be modelled.

3.7.3

Gaps in Traceability and Alignment

Traceability and BIA can facilitate enterprise agility by enhancing visibility, and transparency of enterprise domains, in this way it can be easier for stakeholders to visualise and understand how changes in a given domain can propagate to other domains of the enterprise. However, according the review results in Tables 3.2, 3.3, and 3.4, modelling methods for traceability and BIA are only implied in most enterprise modelling frameworks.

3.7.4

Gaps in other domains

Modelling support for other domains of an enterprise such as business process, applications, and IT systems can be very useful in enhancing agility. Modelling techniques provide a means of breaking down and clarifying complex concepts or systems, and improving the over all insight of the stakeholders of an enterprise.

Although the vast majority of enterprise modelling frameworks recognise the importance of, and also provide methods for modelling of domains of an enterprise such as business process and IT systems. However, few of them such as GOM and BIA frameworks, do not explicitly describe a method for modelling these domains.

3.8

Chapter Summary

This chapter has identified the popular and vastly used enterprise modelling frameworks (EMFs), and review them using the framework for enterprise agility proposed in Chapter 2. This review reveals certain gaps in the existing EMFs. These gaps, identified in Section 3.7, can be contributing factors to the difficult and challenge in achieving and sustaining enterprise agility. The next chapters of this thesis will be dedicated to designing and developing modelling approaches to fill these gaps. These modelling techniques that will be developed in subsequent chapters can be useful in improving and sustaining enterprise agility.

Chapter 4 Research Progress, Future Work, and Contribution 4.1

Research Progress

As stated in Chapter 1, the aim of this research is to design and develop a modelling framework to support the attainment of enterprise agility. The objectives for achieving this aim have been listed in Section 1.8, and the method for developing the proposed modelling framework has been discussed in Section 1.9. This chapter will discuss the research progress, and how the work done so far relate to the research aim, objectives, and method.

4.1.1

February-August 2012

Although the official start date of this research is dated January 2012, research activities formally started in February 2012. The month of January was used for enrolment, induction program, and other activities such as getting a students ID card.

Primary reading and studies started in February 2012, which involves foundational studies of enterprise architecture, which can be considered as the major research area. Other areas of primary studies relating to this research include, introduction to higher conceptual modelling, universal modelling language-UML, and meta object facility-MOF. Materials consulted include, journals, conference proceedings, 45

PartB. Research Progress, Future Work, and Contribution

46

workshops, symposiums, textbooks, and other non-academic but useful materials on-line such as tutorials, and industrial blogs. This period was also used to learn some software tools such as ArgoUML, and yEd–used for conceptual modelling, and Latex, and Beamer–used for research text editing.

Registration into MPhil/PhD also took place during this stage. Time was spent writing the registration report and meeting weekly with my supervisor for feedback and review. After various iteration process, the registration report was submitted, and the panel was set up, and the registration process was successful.

4.1.2

September 2012-February 2013

This period was spent on further studies, research, and learning additional software tools relevant for the research. Quality time was devoted to studying two three popularly used goal oriented modelling techniques, namely, KAOS, BMM and i*. Goal modelling is an vital technique for this research, it is a constituent part of an enterprise architecture, and largely used in enterprise modelling. Since models and modelling are integral parts of this research, time was spent in gaining basic understanding of model driven engineering (MDE) techniques such as model transformation, model integration, and model extension.

Another important objective of this research is to gain, at least, a basic understanding of some of the software tools used for developing meta-models, e.g., EMF, GMF, EMFatic, and EuGENia. A brief description of each of these are described below.

Eclipse Technology-EMF and GMF: The eclipse modelling framework (EMF)1 is an integrated platform for model driven development. It provides two core capabilities. The first is the EMF core (ecore) modelling capability, which allows the core elements or domain data of a language to be structured as a set of inter-related classes called an ecore or a meta-model. The EMF also has a code generation capability called genmodel, which allows source codes to be generated from an ecore model, and then used to develop software tool [111].

EMF technologies can be applied in this project, for instance to design a new language for change drivers, or even develop a software tool. The graphical 1

http://www.eclipse.org/modeling/emf/?project=emfemf

PartB. Research Progress, Future Work, and Contribution

47

modelling framework (GMF)2 is an extension of EMF that provides runtime platform for developing graphical editors from ecore models. The Author has also used EMF in similar project to design a new modelling language called CiML in [79].

EuGENia and EMFatic: EuGENia is a development tool used to generate a software, particularly a graphical editor from an EMFatic file [112]. EMFatic file is the concrete syntax for ecore models, but it can be annotated with Java to describe the properties of a graphical editor. Additional functionality such as checking the completeness of a requirement specification can be added to EuGENia as a plug-in, using the object constrain language (OCL) or epsilon validation language (EVL). Some of these tooling technologies have been used by the author in similar projects such as [79][41].

4.1.3

February-July 2013

This time was dedicated for publications, preparing and attending conferences.

A total of four publications were produced, two of which are peer reviewed papers accepted and published in international workshops, one was not accepted for publications but came back with useful comments, while the last one was a presentation made during the research students summer conference at Middlesex University. A description of each of these publications is given below: A Proposal for an Intentional Modelling Language: In this paper [79], an intentional modelling language was designed and developed, and a software tool for editing the language was implemented using Eclipse EMF, and EuGENia. The method used include, studying three popularly used goal oriented modelling languages, eliminating redundant model elements from them, and consolidating the often used model elements into an intentional modelling language. The contribution of this paper is to provide a richer but a less cumbersome modelling language that can assist requirements analysts in goal oriented modelling. The paper published in the ACM digital library and is contained the proceedings of 2nd international workshop on graphical modelling language development (GMLD–2013), co-located with 2

http://www.eclipse.org/modeling/gmp/

PartB. Research Progress, Future Work, and Contribution

48

9th ACM European conference on modelling foundations and applications (ECMFA–2013), held in Montpelier France.

Towards a Comprehensive Meta-Model for KAOS: The aim of this paper [41] is to develop an integrated Meta-model for KAOS goal model. KAOS is one of the most popularly used goal oriented languages, however, there is no generally accepted meta-model for KAOS. Various versions of the metamodel exist to address specific problems, with some version lacking vital concepts of the KAOS language. To address this problem, this paper integrates 6 existing versions of the KAOS meta-model into a comprehensive meta-model, and implements a graphical editor for KAOS. This paper is published in IEEE xplore, and contained in the proceedings of the 3rd international workshop on model driven requirements engineering (MoDRE– 2013), co-located with 21st IEEE International Requirements Engineering Conference (RE–2013), held in Rio-de Janeiro, Brazil.

Automated Completeness Check in KAOS: This paper was submitted to an A-rated conference, i.e., 28th IEEE/ACM International Conference on Automated Software Engineering. Although it was not accepted, but it came back with a useful feedback.The aim was to implement a software tool to automate and facilitate completeness check-which involves checking that a requirements specification is complete. Incomplete requirements can lead to systems failure, therefore completeness check is a vital activity in requirements engineering, and most be carried out with limited or no error.

Although completeness check can be done manually, but this can lead to error, and usually time costly. This tool was developed using Eclipse EMF, GMF, and epsilon validation language (EVL).

CiML: A consolidated intentional modelling language: This a presentation made during the 2013 research students summer conference held at Middlesex University, London. It is a little modification of the paper-A Proposal for an Intentional Modelling Language:[79]. The abstract of this presentation is included in the Middlesex University summer conference booklet, 2013.

This presentation also won an award for excellent presentation.

PartB. Research Progress, Future Work, and Contribution

4.1.4

49

August-December 2013

This period was spent on three core activities, which are, consolidating and modifying the research questions, hypothesis, and problems, developing a requirements framework for enterprise agility, and carrying out an extensive literature survey.

Although the research questions, hypothesis, and problem were initially identified at the commencement of this research, and during the registration phase. However, after further studies and a series of feedback loop, especially from my supervisory team, it becomes necessary to modify them to capture additional details. For instance, the six research questions in the registration report was consolidated into one questions, while additional detail included in the research problem. In addition, further reading was carried out at this phase to determine the research method.

Another important progress made at this stage includes developing a requirements framework for enterprise agility. Requirements modelling is a critical and all important step and stage during systems development. Since this project aims at developing a modelling framework, it becomes necessary to precisely articulate the requirements of such framework. These requirements was gathered from literature that relates to enterprise agility, and consolidated into 15 requirements for enterprise agility. It is expected that this requirements framework will yield a research output. The basic gaol of this requirements specification is to use it as the framework for the literature survey, and as the basis for comparing other enterprise modelling frameworks used for agility.

The literature survey involves the review of 13 popularly used enterprise modelling frameworks. These include: 6 enterprise architecture (EA) frameworks, namely, the open group architecture framework (TOGAF), the Zachman architecture framework (ZAF), the Archimate, the ministry of defence architecture framework (MODAF)M, the department of defence architecture framework (DODAF), and Armor; 4 business and IT alignment (BIA) frameworks, namely, strategic alignment model (SAM), strategic alignment maturity model (SAMM), information technology infrastructure library (ITIL), and COBIT 5; and 3 goal oriented modelling frameworks, namely, KAOS, i*, and the business motivation model (BMM).

PartB. Research Progress, Future Work, and Contribution

4.1.5

50

January-March 2014

This period was primarily spent on writing up for the transfer, and building up bibliography using bibtex. The transfer report includes an abstract, three chapters, and a reference section. The abstract is a summary of the work. Chapter 1 is an introductory chapter, which gives an overview of the research, and defines the research aims, objectives, method, problem, questions, hypothesis, assumptions, and contributions. Chapter 2 provides an overview of agility concepts, and discusses the requirements framework for enterprise agility with a motivating example. Chapter 3 is the literature review, where the requirements framework is used as the criteria to study and compare 13 enterprise modelling frameworks, and identify the gaps in them.

4.2

Future Work

It is anticipated, that about 5 more chapters are required to complete this research.

Chapters 4, 5, 6 will describe the various modelling techniques, abstract syntaxes, and language definitions, that can enhance stakeholders understanding of change drivers, and support them in achieving enterprise agility. A software tool will be developed in Chapter 7, and used to validate the requirements specification.

Chapter 8 is the concluding chapter. A brief explanation of each chapter is given below.

4.2.1

Chapter 4

In this Chapter, an overview of the proposed framework will be described. This will include defining what this thesis meant by an enterprise model, how goals and business requirements places constraints on enterprise model, and how change drivers causes ripple effects on the enterprise. An important output from this chapter will be an abstract syntax, implemented in Eclipse-emf, of an enterprise model.

PartB. Research Progress, Future Work, and Contribution

4.2.2

51

Chapter 5

This Chapter will reflect the design and implementation phases of SDLC as described in Section 1.9. The aim of this chapter will be to describe the various concepts in change driver and agility, gathered from the literature survey and requirements specifications, and integrate them into a modelling language. The concept of goal oriented modelling, especially those that relate to enterprise agility, will also be integrated into a modelling language. An important output from this chapter will be a candidate modelling language for describing the various concepts of change drivers in enterprise agility.

4.2.3

Chapter 6

This chapter will describe how the business, IT, and other domains can be related, in form of a model, to achieve agility. It will also show dependencies, relationships, and traceability of elements across enterprise domains, and how enterprise domains can relate to change a model. A meta-model and language definition will be produced.

4.2.4

Chapter 7

This Chapter will develop a software tool for enterprise agility, and show how the proposed solution satisfies requirements R1 to R15 . This tool will be evaluated using a case study. While Chapters 4, 5, and 6 reflect the design and implementation phases of the SDLC discussed in Section 1.9, this chapter will implement a tool which will be used in the experiment phase.

4.2.5

Chapter 8

This Chapter concludes the work done, describes the scope and limitation of this research, and presents a critical analysis and self evaluation of the work done. In addition, it describes in form of future work, how the framework developed can be tested with real industry data with a possible prospects of attracting industrial collaborations.

PartB. Research Progress, Future Work, and Contribution

4.3

52

Contributions

The core objectives of agility are to improve enterprise efficiency and effectiveness, save cost, and remove non-value adding activities [16, 19]. The realisation of these objectives depends on the ability of the concerned stakeholders enterprise to infer in advance, how a given change driver can affect business requirements, and what kind of change will such a change driver cause. Thus, for a given change driver, it will be necessary for stakeholders to answer questions such as, what kind of readjustments are needed to respond to such a change? Which domains or elements of the enterprise will be affected by such a change? How will those domains be affected ? What options and resources are available for responding to such a change? What pre-emptive actions are to be taken? Existing enterprise agility frameworks provides little or no support for addressing these questions. A major contribution of the framework proposed in this research is to help in answering these questions.

Change drivers are the primary cause of change in enterprise, yet till date, there is scarcely any technique for modelling change drivers. This research contributes to enterprise agility by providing a technique for modelling change drivers. This modelling technique can potentially clarify ambiguous change drivers, help stakeholders to understand how change drivers impact on the domains of an enterprise, and make it easier to relate change drivers to the entire enterprise.

When a particular change driver, say new government regulation, impacts on an enterprise. There exist variable response mechanism-various ways in which the enterprise can readjust in order to respond to change drivers. For instance, the enterprise can modify existing business requirements, introduce new business requirements, hire new stakeholders etc. A wrong response mechanism will likely have cost and other implications, and influence the enterprise negatively. For instance, an enterprise will possibly incur financial and other loss if stakeholders introduce new product as a response to a change driver, when the optimal response should have been to hire a new stakeholder. Thus response mechanism is considered to be strategic. The framework proposed in this research can support this approach by laying the foundation for new types of analysis such as: What-If Analysis for Enterprise Agility: With the proposed language, it can be possible for enterprise stakeholder to input a certain change driver, and

PartB. Research Progress, Future Work, and Contribution

53

simulate which part of the enterprise will change. This can be done in terms of what-if-analysis, e.g What will be the appropriate response mechanism if the enterprise is impacted by new government regulations?

Goal Seeking Analysis for Enterprise Analysis: Agile drivers do not only pose threats, they also provide opportunities for improvements [31]. For instance, a particular change driver, can cause an enterprise to reduce its operating cost and gain cost effectiveness. Stakeholders might be interested in knowing in advance, which change drivers can lead to reduction in operation cost. Goal seeking analysis provided by the proposed framework can help this approach. Since the proposed framework represents an enterprise as an integrated system which takes change driver as an input, undergo certain processes within the EA, and output an agile EA. It can support a goal seeking analysis.

4.4

Research Time Plan

Figure 4.1 below shows a proposed time plan for the remaining work in this research. The proposed date for the final submission of thesis is February 2016. The ’implement Change Driver Meta-model shown at the top of the chart, implies that the task is a crucial one, and an important aspect of the distinctive contribution of this research. The shaded bars show the critical path to be followed to complete this research.

PartB. Research Progress, Future Work, and Contribution

Figure 4.1: Gantt Chart Showing Research Time Plan

54

References [1] Randy V. Bradley,

Renee M. E. Pratt,

Terry Anthony Byrd,

Christina N. Outlay, and Donald E. Wynn, Jr.

Enterprise ar-

chitecture, it effectiveness and the mediating role of it alignment in us hospitals.

ISSN 1365-2575.

Information Systems Journal, 22(2):97–127, 2012. doi:

10.1111/j.1365-2575.2011.00379.x.

URL

http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?vid=16&sid= 2c8f7850-a902-493c-8e46-b0768f285ede%40sessionmgr111&hid=108.

[2] Wilco Engelsman, Dick Quartel, Henk Jonkers, and Marten van Sinderen.

Extending enterprise architecture modelling with business goals and requirements.

Enterprise Information Systems, 5(1):9 – 36, 2011.

ISSN

17517575.

URL http://search.ebscohost.com/login.aspx?direct=

true&db=bth&AN=55816051&site=ehost-live.

[3] Agnes Nakakawa, Patrick Van Bommel, and H.A. Proper. inition

and

validation

of

requirements

for

collaborative

making in eenterprise architecture creation.

Defdecision-

International Journal

of Cooperative Information Systems, 20(1):83 – 136, 2011.

02188430.

ISSN

URL http://search.ebscohost.com/login.aspx?direct=

true&db=bth&AN=74219669&site=ehost-live.

[4] TOGAF The Open Group. The Open Group Standard, TOGAF Version 9.1: Evaluation Copy. Van Haren Publishing, 2011. URL http://pubs. opengroup.org/architecture/togaf9-doc/arch/.

[5] UK Ministry of Defence. of

Public

Sector

Version 1.2,

Information,

1.2:1–152,

23 june 2008.

2008.

URL

Office https:

//www.gov.uk/government/uploads/system/uploads/attachment_ data/file/63979/20130117_MODAF_M3_version1_2_004.pdf.

55

References

56

[6] Thanos Magoulas, Aida Hadzic, Ted Saarikko, and Kalevi Pessi. Alignment in enterprise architecture: A comparative analysis of four architectural approaches. Electronic Journal of Information Systems Evaluation, 15(1):88 – 101, 2012. ISSN 15666379. URL http://search.ebscohost.com/login. aspx?direct=true&db=bth&AN=87403051&site=ehost-live.

[7] Wiel A. G. Bruls, M. van Steenbergen, R. M. Foorthuis, R. Bos, and S. Brinkkemper. Domain architectures as an instrument to refine enterprise architecture. Communications of the Association for Information Systems, 27:517 – 540, 2010. ISSN 15293181. URL http://search.ebscohost.com/ login.aspx?direct=true&db=bth&AN=70400146&site=ehost-live.

[8] S. M. Lehong, E. Dube, and G. Angelopoulos. An investigation into the perceptions of business stakeholders on the benefits of enterprise architecture: The case of telkom sa. South African Journal of Business Management, 44 (2):45 – 56, 2013. ISSN 03789098. URL http://search.ebscohost.com/ login.aspx?direct=true&db=bth&AN=87930183&site=ehost-live.

[9] Dick Quartel, Maarten W.A. Steen, and Marc M. Lankhorst. Application and project portfolio valuation using enterprise architecture and business requirements modelling. Enterprise Information Systems, 6(2):189 – 213, 2012. ISSN 17517575. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=71116547&site=ehost-live.

[10] Wilco Engelsman and Roel Wieringa.

Goal-oriented requirements engi-

neering and enterprise architecture: Two case studies and some lessons learned.

In Bjorn Regnell and Daniela Damian, editors, Requirements

Engineering: Foundation for Software Quality, volume 7195 of Lecture Notes in Computer Science, pages 306–320. Springer Berlin Heidelberg, 2012. ISBN 978-3-642-28713-8. doi: 10.1007/978-3-642-28714-5 27. URL http://dx.doi.org/10.1007/978-3-642-28714-5_27.

[11] Tanja Ylimaki and Veikko Halttunen. Method engineering in practice: A case of applying the zachman framework in the context of small enterprise architecture oriented projects. Information Knowledge Systems Management, 5(3):189 – 209, 2006. ISSN 13891995. URL http://search.ebscohost. com/login.aspx?direct=true&db=bth&AN=22976181&site=ehost-live.

[12] Llanos Cuenca, Andres Boza, and Angel Ortiz. An enterprise engineering approach for the alignment of business and information technology strategy.

References

57

International Journal of Computer Integrated Manufacturing, 24(11):974 – 992, 2011. ISSN 0951192X. URL http://search.ebscohost.com/login. aspx?direct=true&db=bth&AN=66581875&site=ehost-live.

[13] Paul P. Tallon and Alain Pinsonneault. Competing perspectives on the link between strategic information technology alignment and organizational agility: Insights from a mediation model. MIS Quarterly, 35(2):463 – 486, 2011. ISSN 02767783. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=60461965&site=ehost-live.

[14] Seo Dongback and Ariel I. La Paz. Exploring the dark side of is in achieving organizational aagility. Communications of the ACM, 51(11):136 – 139, 2008. ISSN 00010782. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=35211915&site=ehost-live.

[15] Dale L. Goodhue, Daniel Q. Chen, Marie Claude Boudreau, Ashley Davis, and Justin D. Cochran. Addressing business agility challenges with enterprise systems.

15401960.

MIS Quarterly Executive, 8(2):73 – 87, 2009.

ISSN

URL http://search.ebscohost.com/login.aspx?direct=

true&db=bth&AN=42093790&site=ehost-live.

[16] Yi-Hong Tseng and Ching-Torng Lin.

Enhancing enterprise agility by

deploying agile drivers, capabilities and providers. Information Sciences, 181(17):3693 – 3708, 2011. ISSN 0020-0255. doi: http://dx.doi.org/10.

1016/j.ins.2011.04.034. URL http://www.sciencedirect.com/science/ article/pii/S0020025511002088.

[17] Minglun Ren and Kalle Lyytinen.

Building enterprise architec-

ture agility and sustenance with soa.

Association for Information Systems, 15293181.

Communications of the

22:75 – 86,

2008.

ISSN

URL http://search.ebscohost.com/login.aspx?direct=

true&db=bth&AN=34260470&site=ehost-live.

[18] Marcel van Oosterhout, Eric Waarts, and Jos van Hillegersberg. Change factors requiring agility and implications for it. European Journal of Information Systems, 15(2):132 – 145, 2006. ISSN 0960085X. URL http: //fkaouane.free.fr/EJIS/3000601a.pdf.

[19] Trinh-Phuong Thao, Alemayehu Molla, and Konrad Peszynski. Enterprise systems and organizational agility: A review of the literature and conceptual

References

58

framework. Communications of the Association for Information Systems, 31:167 – 193, 2012. ISSN 15293181. URL http://search.ebscohost.com/ login.aspx?direct=true&db=bth&AN=86652303&site=ehost-live.

[20] A.J.G. Silvius and J. Smit. Maturing business and it alignment capability; the practitioner’s view. In System Sciences (HICSS), 2011 44th Hawaii International Conference on, pages 1–10, 2011. doi: 10.1109/HICSS.2011.

302.

[21] A.J.G. Silvius. Business it alignment in theory and practice. In System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, pages 211b–211b, 2007. doi: 10.1109/HICSS.2007.119.

[22] Wang Nianxin, Xue Yajiong, Liang Huigang, and Ge Shilun. The road to business-it alignment: A case study of two chinese companies. Communications of the Association for Information Systems, 28:415 – 436, 2011. ISSN 15293181. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=70400209&site=ehost-live.

[23] Paul P. Tallon. Value chain linkages and the spillover effects of strategic information technology alignment:

A process-level view.

nal of Management Information Systems, 28(3):9 – 44, 2011.

07421222.

JourISSN

URL http://search.ebscohost.com/login.aspx?direct=

true&db=bth&AN=70989254&site=ehost-live.

[24] Alain Wegmann, Pavel Balabko, Lam-Son Lˆe, Gil Regev, and Irina Rychkova. A method and tool for business-it alignment in enterprise architecture.

In CAiSE Short Paper Proceedings, volume 2005. Citeseer,

2005. URL http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.

1.1.91.5316&rep=rep1&type=pdf.

[25] J. Saat, R. Winter, U. Franke, R. Lagerstrom, and Mathias Ekstedt. Analysis of it/business alignment situations as a precondition for the design and engineering of situated it/business alignment solutions. In System Sciences (HICSS), 2011 44th Hawaii International Conference on, pages 1–9, 2011. doi: 10.1109/HICSS.2011.63.

[26] B.M. Arteta and R.E. Giachetti. A measure of agility as the complexity of the enterprise system. Robotics and Computer-Integrated Manufacturing, 20(6):495 – 503, 2004. ISSN 0736-5845. doi: http://dx.doi.org/10.

References

59

1016/j.rcim.2004.05.008. URL http://www.sciencedirect.com/science/ article/pii/S0736584504000717. ¡ce:title¿13th International Conference on Flexible Automation and Intelligent Manufacturing¡/ce:title¿.

[27] Bohdana Sherehiy, Waldemar Karwowski, and John K. Layer.

A re-

view of enterprise agility: Concepts, frameworks, and attributes. International Journal of Industrial Ergonomics, 37(5):445 – 460, 2007. ISSN 0169-8141. doi: http://dx.doi.org/10.1016/j.ergon.2007.01.007. URL http: //www.sciencedirect.com/science/article/pii/S0169814107000236.

[28] Ozgur Erol, Brian J. Sauser, and Mo Mansouri. A framework for investigation into extended enterprise resilience. Enterprise Information Systems, 4 (2):111 – 136, 2010. ISSN 17517575. URL http://search.ebscohost.com/ login.aspx?direct=true&db=bth&AN=49459865&site=ehost-live.

[29] Giorgio De Michelis, Eric Dubois, Matthias Jarke, Florian Matthes, John Mylopoulos, Joachim W. Schmidt, Carson Woo, and Eric Yu. A threefaceted view of information systems. Commun. ACM, 41(12):64–70, December 1998. ISSN 0001-0782. doi: 10.1145/290133.290150. URL http: //doi.acm.org/10.1145/290133.290150.

[30] Jan Hoogervorst. Enterprise architecture::enabling integration, agility, and change. International Journal of Cooperative Information Systems, 13(3): 213 – 233, 2004. ISSN 02188430. URL http://search.ebscohost.com/ login.aspx?direct=true&db=bth&AN=14261618&site=ehost-live.

[31] Yang Chyan and Liu Hsian-Ming.

Boosting firm performance

via enterprise agility and network structure. cision, 50(6):1022 – 1044, 2012.

Management De-

ISSN 00251747.

URL http:

//www.emeraldinsight.com/journals.htm?issn=0025-1747&volume= 50&issue=6&articleid=17038577&show=html.

[32] Eric Overby, Anandhi Bharadwaj, and V. Sambamurthy. Enterprise agility and the enabling role of information technology. European Journal of Information Systems, 15(2):120 – 131, 2006. ISSN 0960085X. URL http: //fkaouane.free.fr/EJIS/3000600a.pdf.

[33] Ching-Torng Lin, Hero Chiu, and Yi-Hong Tseng. Agility evaluation using fuzzy logic. International Journal of Production Economics, 101(2): 353 – 368, 2006. ISSN 0925-5273. doi: http://dx.doi.org/10.1016/j.ijpe.

References 2005.01.011.

60 URL http://www.sciencedirect.com/science/article/

pii/S0925527305000514.

[34] Anirban Ganguly, Roshanak Nilchiani, and John V. Farr.

Evaluating

agility in corporate enterprises. International Journal of Production Economics, 118(2):410 – 423, 2009. ISSN 0925-5273. doi: http://dx.doi.org/10.

1016/j.ijpe.2008.12.009. URL http://www.sciencedirect.com/science/ article/pii/S092552730800385X. [35] S.J. Mellor, A.N. Clark, and T. Futagami. Model-driven development - guest editor’s introduction. Software, IEEE, 20(5):14–18, 2003. ISSN 0740-7459. doi: 10.1109/MS.2003.1231145.

[36] C. Atkinson and T. Kuhne. Model-driven development: a metamodeling foundation. Software, IEEE, 20(5):36–41, Sept 2003. ISSN 0740-7459. doi: 10.1109/MS.2003.1231149.

[37] Gonzalo Genova.

What is a metamodel: the omgs metamodeling in-

frastructure. Software and Systems Modeling, 4(2):171–188, 2005. URL http://www.ie.inf.uc3m.es/ggenova/Thessaloniki/Part3.pdf.

[38] Tariq Masood and Richard H. Weston. Modelling framework to support decision-making in manufacturing enterprises. Advances in Decision Sciences, 2013:1 – 23, 2013. ISSN 20903359. URL http://search.ebscohost. com/login.aspx?direct=true&db=bth&AN=90060727&site=ehost-live.

[39] S. Q. Xie, W. Z. Yang, and Y. L. Tu. Towards a generic product modelling framework. International Journal of Production Research, 46(8):2229 – 2254, 2008. ISSN 00207543. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=29991929&site=ehost-live.

[40] Q. Shu and C. Wang.

A conceptual framework for product lifecycle

modelling. Enterprise Information Systems, 1(3):353 – 363, 2007. ISSN 17517575.

URL http://search.ebscohost.com/login.aspx?direct=

true&db=bth&AN=26386650&site=ehost-live.

[41] J.C. Nwokeji, T. Clark, and B.S. Barn. Towards a comprehensive metamodel for kaos. In Model-Driven Requirements Engineering (MoDRE), 2013 International Workshop on, pages 30–39, 2013. doi: 10.1109/MoDRE.2013.

6597261.

References

61

[42] Axel van Lamsweerde and Emmanuel Letier. Handling obstacles in goaloriented requirements engineering.

Software Engineering, IEEE Trans-

actions on, 26(10):978–1005, 2000. URL http://ieeexplore.ieee.org/ stamp/stamp.jsp?tp=&arnumber=879820.

[43] David Avison and Guy Fitzgerald.

Information systems development:

methodologies, techniques and tools. McGraw Hill, 4th edition, 2006.

[44] Sommerville Ian. Software Engineering. Addison Wesley, 6th edition, 2006.

[45] D.T. Ross and Jr. Schoman, K.E. Structured analysis for requirements definition. Software Engineering, IEEE Transactions on, SE-3(1):6–15, Jan 1977. ISSN 0098-5589. doi: 10.1109/TSE.1977.229899.

[46] Riccardo Vecchiato and Claudio Roveda. Strategic foresight in corporate organizations: Handling the effect and response uncertainty of technology and social drivers of change. Technological Forecasting and Social Change, 77 (9):1527 – 1539, 2010. ISSN 0040-1625. doi: http://dx.doi.org/10.1016/ j.techfore.2009.12.003.

URL http://www.sciencedirect.com/science/

article/pii/S0040162509002091. Strategic Foresight.

[47] Caron H St. John, Alan R Cannon, and Richard W Pouder. Change drivers in the new millennium: implications for manufacturing strategy research.

Journal of Operations Management, 19(2):143 – 160, 2001. ISSN 0272-6963. doi: http://dx.doi.org/10.1016/S0272-6963(00)00054-1. URL http://www. sciencedirect.com/science/article/pii/S0272696300000541.

[48] Adina Aldea, Maria-Eugenia Iacob, Dick Quartel, and Henry Franken.

Strategic planning and enterprise achitecture. In Enterprise Systems Conference (ES), 2013, pages 1–8, 2013. doi: 10.1109/ES.2013.6690089.

[49] Per Narman, Hannes Holm, Pontus Johnson, Johan Konig, Moustafa Chenine, and Mathias Ekstedt. terprise architecture.

Data accuracy assessment using en-

Enterprise Information Systems, 5(1):37 – 58,

2011. ISSN 17517575. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=55816057&site=ehost-live.

[50] Vadim Agievich, Victor Taratukhin, Jorg Becker, and Rinat Gimranov.

A new approach for collaborative enterprise architecture development. In Strategic Technology (IFOST), 2012 7th International Forum on, pages 1–5, 2012. doi: 10.1109/IFOST.2012.6357672.

References

62

[51] P. Gustafsson, D. Hook, E. Ericsson, and J. Lillieskold. Analyzing it impact on organizational structure: A case study. In Management of Engineering Technology, 2009. PICMET 2009. Portland International Conference on, pages 3197–3210, 2009. doi: 10.1109/PICMET.2009.5262275.

[52] O.E. Balcicek, M. Gundebahar, and S. Cekerekli. An agile approach for converting enterprise architectures. In Technological Advances in Electrical, Electronics and Computer Engineering (TAEECE), 2013 International Conference on, pages 380–386, 2013. doi: 10.1109/TAEECE.2013.6557305.

[53] P. Gustafsson, D. Hook, U. Franke, and P. Johnson. Modeling the it impact on organizational structure. In Enterprise Distributed Object Computing Conference, 2009. EDOC ’09. IEEE International, pages 14–23, 2009. doi: 10.1109/EDOC.2009.27.

[54] Stephan Aier and Bettina Gleichauf. Applying design research artifacts for building design research artifacts: A process model for enterprise architecture planning. In Robert Winter, J.Leon Zhao, and Stephan Aier, editors, Global Perspectives on Design Science Research, volume 6105 of Lecture Notes in Computer Science, pages 333–348. Springer Berlin Heidelberg, 2010. ISBN 978-3-642-13334-3. doi: 10.1007/978-3-642-13335-0 23.

URL http://dx.doi.org/10.1007/978-3-642-13335-0_23.

[55] Tae-Young Kim, Sunjae Lee, Kwangsoo Kim, and Cheol-Han Kim. A modeling framework for agile and interoperable virtual enterprises. Computers in Industry, 57(3):204 – 217, 2006. ISSN 0166-3615. doi: http://dx.doi.org/ 10.1016/j.compind.2005.12.003.

URL http://www.sciencedirect.com/

science/article/pii/S0166361506000121. Advanced Computer Support of Engineering and Service Processes of Virtual Enterprises Advanced Computer Support Special Issue.

[56] F.B. Vernadat. Enterprise modeling and integration (emi): Current status and research perspectives. Annual Reviews in Control, 26(1):15 – 25, 2002.

ISSN 1367-5788.

doi: http://dx.doi.org/10.1016/S1367-5788(02)

80006-2. URL http://www.sciencedirect.com/science/article/pii/ S1367578802800062.

References

63

[57] E. Hermansen and J.-P. Caron. Organizational agility: kicking the culture ”crutch”. In Engineering Management Conference, 2003. IEMC ’03. Managing Technologically Driven Organizations: The Human Side of Innovation and Change, pages 181–185, 2003. doi: 10.1109/IEMC.2003.1252256.

[58] K. Medini and J.P. Bourey. Scor-based enterprise architecture methodology.

International Journal of Computer Integrated Manufacturing, 25(7):594 – 607, 2012. ISSN 0951192X. URL http://search.ebscohost.com/login. aspx?direct=true&db=bth&AN=76633728&site=ehost-live.

[59] Heekwon Chae, Younghwan Choi, and Kwangsoo Kim. Component-based modeling of enterprise architectures for collaborative manufacturing.

INTERNATIONAL

JOURNAL

OF

ADVANCED

ING TECHNOLOGY, 34(5-6):605–616, SEP 2007. doi:

{10.1007/s00170-006-0620-5}.

MANUFACTURISSN 0268-3768.

URL http://download.springer.

com/static/pdf/771/art%253A10.1007%252Fs00170-006-0620-5.pdf? auth66=1391091117_93e15c2cc66f9422cacff8dfaf33868d&ext=.pdf.

[60] Dieter Nuffel, Philip Huysmans, David Bellens, and Kris Ven. Towards deterministically constructing organizations based on the normalized systems approach. In Robert Winter, J.Leon Zhao, and Stephan Aier, editors, Global Perspectives on Design Science Research, volume 6105 of Lecture Notes in Computer Science, pages 242–257. Springer Berlin Heidelberg, 2010. ISBN 978-3-642-13334-3. doi: 10.1007/978-3-642-13335-0 17. URL http://dx.doi.org/10.1007/978-3-642-13335-0_17.

[61] N. Alexopoulou, M. Nikolaidou, N.Y. Chamodrakas, Y. Chamodrakas, and D. Martakos. Enabling on-the-fly business process composition through an event-based approach.

In Hawaii International Conference on Sys-

tem Sciences, Proceedings of the 41st Annual, pages 379–379, 2008. doi: 10.1109/HICSS.2008.144.

[62] P.J. Boxer and S. Garcia. Enterprise architecture for complex system-ofsystems contexts. In Systems Conference, 2009 3rd Annual IEEE, pages 253–256, 2009. doi: 10.1109/SYSTEMS.2009.4815807.

[63] D. Ebneter, S.G. Grivas, T.U. Kumar, and H. Wache. Enterprise architecture frameworks for enabling cloud computing. In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pages 542–543, 2010. doi: 10.

1109/CLOUD.2010.47.

References

64

[64] C.A. Hoyland. An analysis of enterprise architectures using general systems theory. In Systems, Man, and Cybernetics (SMC), 2011 IEEE International Conference on, pages 340–344, 2011. doi: 10.1109/ICSMC.2011.6083688.

[65] Hoa Khanh Dam, Lam-Son Le, and A. Ghose. Supporting change propagation in the evolution of enterprise architectures.

In Enterprise Dis-

tributed Object Computing Conference (EDOC), 2010 14th IEEE International, pages 24–33, 2010. doi: 10.1109/EDOC.2010.23.

[66] Tobias Bruckmann, Volker Gruhn, and Max Pfeiffer. Towards real-time monitoring and controlling of enterprise architectures using business software control centers. In Ivica Crnkovic, Volker Gruhn, and Matthias Book, editors, Software Architecture, volume 6903 of Lecture Notes in Computer Science, pages 287–294. Springer Berlin Heidelberg, 2011. ISBN 978-3-64223797-3. doi: 10.1007/978-3-642-23798-0 31. URL http://dx.doi.org/ 10.1007/978-3-642-23798-0_31.

[67] T. Kamogawa and H. Okada. A framework for enterprise architecture effectiveness. In Services Systems and Services Management, 2005. Proceedings of ICSSSM ’05. 2005 International Conference on, volume 1, pages 740–745 Vol. 1, 2005. doi: 10.1109/ICSSSM.2005.1499575.

[68] Wayne Robbins. Achieving dodaf-driven simulations through executable architectures. In Proceedings of the 2009 Spring Simulation Multiconference, SpringSim ’09, pages 57:1–57:8, San Diego, CA, USA, 2009. Society for Computer Simulation International. URL http://dl.acm.org/citation. cfm?id=1639809.1639868.

[69] K. Valtonen, I. Korhonen, R. Rekonen, and M. Leppanen. Ea as a tool in change and coherency management - a case of a local government. In System Sciences (HICSS), 2010 43rd Hawaii International Conference on, pages 1–10, 2010. doi: 10.1109/HICSS.2010.166.

[70] Brenda Scholtz, Andre Calitz, and Anthea Connolley. An analysis of the adoption and usage of enterprise architecture. In Enterprise Systems Conference (ES), 2013, pages 1–9, 2013. doi: 10.1109/ES.2013.6690087.

[71] B. Unhelkar and A. Ginige. A framework to derive holistic business transformation processes. In e-Business (ICE-B), Proceedings of the 2010 International Conference on, pages 1–7, 2010.

References

65

[72] R.D. Zota and A. Fratila. Toward the selection of an enterprise architecture model for a cloud environment. In Roedunet International Conference (RoEduNet), 2013 11th, pages 1–6, 2013. doi: 10.1109/RoEduNet.2013.6511753.

[73] G. Motta, D. Sacco, and T. Barroero. General enterprise framework (gef).

In Service Operations and Logistics, and Informatics (SOLI), 2012 IEEE International Conference on, pages 54–59, 2012. doi: 10.1109/SOLI.2012.

6273504.

[74] B. Chakravarti and V. Varma. An enterprise architecture framework for building service oriented e-governance portal. In TENCON 2008 - 2008 IEEE Region 10 Conference, pages 1–6, 2008. doi: 10.1109/TENCON.2008.

4766563.

[75] T. Knothe, T. Kahl, D. Boell, and K. Schneider. Framework for establishing enterprise modeling in the context of collaborative enterprises. In System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, pages 10–10, 2007. doi: 10.1109/HICSS.2007.234.

[76] Team Bmm Version 1.2. Business motivation model (bmm) version 1.2 beta 2 specification. Technical report, Technical Report dtc/2013-08-24, Object Management Group, Needham, Massachusetts, 2013. URL http://www. omg.org/spec/BMM/1.1/PDF. [77] A. Van Lamsweerde. Goal-oriented requirements enginering: a roundtrip from research to practice [enginering read engineering]. In Requirements Engineering Conference, 2004. Proceedings. 12th IEEE International, pages 4–7, Sept 2004. doi: 10.1109/ICRE.2004.1335648.

[78] S Yu Eric. Social modeling and i*. In Conceptual Modeling: Foundations and Applications, pages 99–121. Springer, 2009. URL http://mis.sauder. ubc.ca/files/2011/08/JMfest09-soc-modeling-istar.pdf.

[79] Joshua C. Nwokeji, Tony Clark, and Balbir S. Barn. A proposal for consolidated intentional modeling language. In Proceedings of the Second Workshop on Graphical Modeling Language Development, GMLD ’13, pages 12–22, New York, NY, USA, 2013. ACM. ISBN 978-1-4503-2044-3. doi: 10.1145/ 2489820.2489826. URL http://doi.acm.org/10.1145/2489820.2489826.

[80] R. Monteiro, J. Araujo, V. Amaral, M. Goulao, and P. Patricio. Modeldriven development for requirements engineering: The case of goal-oriented

References

66

approaches. In Quality of Information and Communications Technology (QUATIC), 2012 Eighth International Conference on the, pages 75–84, Sept 2012. doi: 10.1109/QUATIC.2012.38.

[81] W. Heaven and A. Finkelstein. engineering with kaos.

Uml profile to support requirements

IEE Proceedings – Software, 151(1):10 – 27,

2004. ISSN 14625970. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=12309781&site=ehost-live.

[82] A. Van Lamsweerde, R. Darimont, and E. Letier. Managing conflicts in goaldriven requirements engineering. Software Engineering, IEEE Transactions on, 24(11):908–926, 1998. ISSN 0098-5589. doi: 10.1109/32.730542.

[83] Objectiver.

IT, 2007.

A kaos tutorial version 1.0.

Technical report, Respect-

URL http://www.objectiver.com/fileadmin/download/

documents/KaosTutorial.pdf.

[84] J.C. Henderson and H. Venkatraman. Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, 32(1):472–484, 1993. ISSN 0018-8670. doi: 10.1147/sj.382.0472.

[85] John C Henderson and N Venkatraman. Strategic alignment: a model for organizational transformation through information technology. Oxford University Press, New York, 1992. URL http://18.7.29.232/bitstream/ handle/1721.1/49184/strategicalignme90hend.pdf?sequence=1.

[86] David Avison, Jill Jones, Philip Powell, and David Wilson. Using and validating the strategic alignment model.

The Journal of Strategic In-

formation Systems, 13(3):223 – 246, 2004. ISSN 0963-8687. doi: http: //dx.doi.org/10.1016/j.jsis.2004.08.002. URL http://www.sciencedirect. com/science/article/pii/S0963868704000356.

[87] US Departmen of Defence.

Dodaf architecture framework version 2.02.

Department of Defense, USA, 2.02:1–200, 2010.

URL http://dodcio.

defense.gov/dodaf20/dodaf20_viewpoints.aspx.

[88] USA Department of Defence. Dod architecture framework, version 1.5.

Department of Defense, USA, 1(1.5):1–200, 2007. URL http://dodcio. defense.gov/Portals/0/Documents/DODAF/DoDAF_Volume_I.pdf.

References

67

[89] E.S.K. Yu. Towards modelling and reasoning support for early-phase requirements engineering. In Requirements Engineering, 1997., Proceedings of the Third IEEE International Symposium on, pages 226–235, Jan 1997. doi: 10.1109/ISRE.1997.566873.

[90] Eric Yu and Lin Liu.

Modelling trust for system design using the i*

strategic actors framework. In Trust in Cyber-societies, pages 175–194.

Springer, 2001. URL http://download.springer.com/static/pdf/35/ chp%253A10.1007%252F3-540-45547-7_11.pdf?auth66=1392383819_ 5970e08efe840a08b652cbd41b8a15ce&ext=.pdf.

[91] E. Yu, M. Strohmaier, and Xiaoxue Deng. Exploring intentional modeling and analysis for enterprise architecture. In Enterprise Distributed Object Computing Conference Workshops, 2006. EDOCW ’06. 10th IEEE International, pages 32–32, 2006. doi: 10.1109/EDOCW.2006.36.

[92] J.A. Zachman. A framework for information systems architecture. IBM Systems Journal, 38(2.3):454–470, 1999. ISSN 0018-8670. doi: 10.1147/sj.

382.0454.

[93] J.F. Sowa and J.A. Zachman. Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3):590–616, 1992. ISSN 0018-8670. doi: 10.1147/sj.313.0590.

[94] Edmund F. Vail III. Casual architecture: Bringing the zachman framework to life.

10580530.

Information Systems Management, 19(3):8, 2002.

ISSN

URL http://search.ebscohost.com/login.aspx?direct=

true&db=bth&AN=6654720&site=ehost-live.

[95] Jerry Luftman. Assessing business-it alignment maturity. Commun. AIS, 4 (14):1–51, December 2000. URL http://www.sba.oakland.edu/Faculty/ LAUER/downloads/MIS625/Readings/IT-Business%20Alignment.pdf.

[96] Jerry Luftman, John Dorociak, Rajkumar Kempaiah, and Eduardo Henrique Rigoni. Strategic alignment maturity: A structural equation model validation. In American Conference On Information Systems (AMCIS), pages 1–16, 2008.

URL http://aisel.aisnet.org/cgi/viewcontent.

cgi?article=1047&context=amcis2008.

[97] Jerry Luftman and Rajkumar Kempaiah. An update on business-it alignment: ”a line” has been drawn. MIS Quarterly Executive, 6(3):165 – 177,

References

68

2007. ISSN 15401960. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=27763834&site=ehost-live.

[98] Alison

Cartlidge,

Ashley

John Windebank, of

itil

v3.

Hanna,

Colin

and Stuart Rance.

Rudd,

Ivor

Macfarlane,

An introductory overview

The UK Chapter of the itSMF,

v3:1–56,

2007.

URL https://www.best-management-practice.com/gempdf/itSMF_An_ Introductory_Overview_of_ITIL_V3.pdf.

[99] Jimmy Heschl.

Mapping itil v3 to cobit.

COBIT Focus, 2008(1):13

– 16, 2008. URL http://search.ebscohost.com/login.aspx?direct= true&db=bth&AN=34904987&site=ehost-live.

[100] Marc M. Lankhorst. of integration.

Enterprise architecture modelling:

the issue

Advanced Engineering Informatics, 18(4):205 – 216,

2004.

ISSN 1474-0346.

01.005.

URL http://www.sciencedirect.com/science/article/pii/

S1474034605000054.

doi:

http://dx.doi.org/10.1016/j.aei.2005.

¡ce:title¿Enterprise Modelling and System Sup-

port¡/ce:title¿.

[101] Marc M Lankhorst, Henderik Alex Proper, and Henk Jonkers. The architecture of the archimate language. In Enterprise, Business-Process and Information Systems Modeling, pages 367–380. Springer, 2009.

[102] Isaca and Cobit5. Cobit 5: A Buiness Framework for the Governance and Management of Enterprise IT. Isaca.org/cobit, 2012. URL http://www. isaca.org/COBIT/Documents/COBIT5-Ver2-FrameWork.pdf.

[103] Steven De Haes, Wim Van Grembergen, and Roger S. Debreceny. Cobit 5 and enterprise governance of information technology: Building blocks and research opportunities. Journal of Information Systems, 27(1):307 – 324, 2013. ISSN 08887985. URL http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=88181972&site=ehost-live.

[104] A. Tang, J. Han, and P. Chen. A comparative analysis of architecture frameworks. In Software Engineering Conference, 2004. 11th Asia-Pacific, pages 640–647, 2004. doi: 10.1109/APSEC.2004.2.

[105] Roger Sessions. Comparison of the top four enterprise architecture methodologies.

Technical report, Microsoft, may 2007.

microsoft.com/en-us/library/bb466232.aspx.

URL http://msdn.

References

69

[106] Ulrik Franke, Pontus Johnson, Evelina Ericsson, Waldo Rocha Flores, and Kun Zhu. Enterprise architecture analysis using fault trees and modaf. In CAiSE 2009 Conference Proceedings. Vol, volume 453, pages 61–66, 2009.

URL http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/ Vol-453/paper11.pdf.

[107] E. Baumgarten and S.J. Silverman. Dynamic dodaf and executable architectures. In Military Communications Conference, 2007. MILCOM 2007.

IEEE, pages 1–5, 2007. doi: 10.1109/MILCOM.2007.4455237.

[108] Ian Bailey. Brief introduction to modaf with v1.2 updates. In Enterprise Architecture Frameworks, 2008 IET Seminar on, pages 1–18, 2008. URL http: //ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4784446.

[109] Daniel One-Ki Lee, Probir Banerjee, Kai H. Lim, kuldeep Kumar, Jos Van Hillegersberg, and Wei Kwok Kee. Aligning it components to achieve agility in globally distributed systems development. Communications of the ACM, 49(10):49 – 54, 2006. ISSN 00010782. URL http://search.ebscohost. com/login.aspx?direct=true&db=bth&AN=22665304&site=ehost-live.

[110] Xavier Franch, Gemma Grau, Enric Mayol, Carme Quer, Claudia Ayala, Carlos cares, Fredy Navarrete, Mariela Haya, and Pere. Botella. Systematic construction of i* strategic dependency models for socio-technical systems.

International Journal of Software Engineering & Knowledge Engineering, 17 (1):79 – 106, 2007. ISSN 02181940. URL http://search.ebscohost.com/ login.aspx?direct=true&db=bth&AN=24476016&site=ehost-live.

[111] Ed Merks, berg.

R Eliersick,

T Grose,

F Budinsky,

The eclipse modeling framework.

tal, 1:37, 2003.

and D Stein-

retrieved from,

to-

URL http://www.eclipse.org/modeling/emf/docs/

presentations/JavaOne/JavaOnePresentation.pdf.

[112] Dimitrios S Kolovos, Louis M Rose, Saad Bin Abid, Richard F Paige, Fiona AC Polack, and Goetz Botterweck. Taming emf and gmf using model transformation.

In Model Driven Engineering Languages and Systems,

pages 211–225. Springer, 2010.

URL http://download.springer.com/

static/pdf/216/chp%253A10.1007%252F978-3-642-16145-2_15.pdf? auth66=1383504335_9602885c7b0f0e445bfe58db4606675a&ext=.pdf.