Developing guidelines to translate CHOOSE models into...

Ghent University

Faculty of Economics and Business Administration

ACADEMIC YEAR 2015 – 2016

Developing guidelines to translate CHOOSE models into ArchiMate models

and vice versa

Thesis presented to obtain the degree of Master of Science in

Applied Economic Science: Business Engineering

Yannick Scheldeman

Under supervision of

Prof.Dr. Geert Poels & Michael Verdonck

PERMISSION

’The author gives the authorization to make this master dissertation available for consultation and to

copy parts of it for personal use. Any other use is subjected to the limitations of copyright, in particular

with regard to the obligation to explicitly mention the source when quoting results from this master

dissertation.’

Yannick Scheldeman, May 2016

I

SAMENVATTING

Deze thesis behandelt het ontwikkelen en valideren van een mapping proces en richtlijnen voor het

uitvoeren van een mapping tussen twee enterprise architecture modeling languages: CHOOSE and

ArchiMate. ArchiMate is een gevestigde waarde als enterprise architecture modeling language, het

biedt ondernemingen de mogelijkheid hun onderneming structuur uit te zetten en zodoende een

holistisch beeld te verkrijgen van hun processen, actoren, departementen, software applicaties, etc.

Als ArchiMate vooral door grote ondernemingen gebruikt wordt, biedt CHOOSE een alternatief voor

KMO’s in het modeleren van zijn enterprise architecture door te focussen op de business architecture

en minder op de onderliggende technologie.

Wanneer KMO’s meer bewust worden van het gebruik van IT of wanneer een grote onderneming nood

heeft aan een minder complexe representatie van zijn EA, kunnen beide gevallen baat hebben aan een

mapping tussen CHOOSE modellen en ArchiMate modellen. In deze thesis zal een mapping proces en

richtlijnen ontwikkeld worden die de architect in staat stelt een accurate mapping uit te voeren.

Na de ontwikkeling zal de mapping en de ontwikkelde richtlijnen met behulp van een case study getest

en gevalideerd worden. Uit onderzoek werd duidelijk dat wanneer de mapping van CHOOSE naar

ArchiMate uitgevoerd wordt, er veel tussenkomsten van de architect met extra informatie nodig zijn

maar de mapping uiteindelijk bijna volledig is. Bij de mapping van ArchiMate naar CHOOSE werd in

sommige gevallen de simpliciteit van het CHOOSE model na vertaling aangetast. Hierdoor werd er een

extra restrictie opgelegd die de mapping tot enkel de business architecture en motivation architecture

beperkt.

II

PREFACE

This master dissertation provides the last keystone to acquire the degree of Master of Science in

Applied Economics: Business Engineering at Ghent University, Belgium. The finalization of this master

dissertation enabled me to look back at a wonderful five years at the University of Ghent that were

characterized by beautiful as well as difficult moments. Thankfully, I never stood alone and could share

these moments with people around me.

This master dissertation is the result of five years of hard work, and could not be made possible without

the valuable support of a few people that I would like to thank.

First and foremost, I want to thank my parents and brother, who gave me each day the support and

confidence I needed. The opportunity to pursue a master’s degree is something that I don’t take for

granted. Therefore, Thank you dad, mom and brother!

Next, I would like to thank Prof.Dr. Geert Poels, Michael Verdonck and Maxime Bernaert. Michael was

my supervisor throughout the journey of this master dissertation and provided me with constructive

criticisms and feedback. Maxime provided me with excellent insights in CHOOSE and ArchiMate that

guided me in writing this master dissertation.

Last but not least, I want to acknowledge all of my friends, who followed me throughout the five years

with support but also with the necessary relaxation.

III

TABLE OF CONTENTS

ABBREVIATIONS ........................................................................................................................... V

LIST OF FIGURES .......................................................................................................................... VI

LIST OF TABLES ............................................................................................................................ VI INTRODUCTION ........................................................................................................................................ 1 1. ENTERPRISE ARCHITECTURE ................................................................................................................ 2

1.1 Definition of Enterprise Architecture ......................................................................................... 2 1.2 Enterprise Architecture within Information Management. ....................................................... 3

1.2.1 Strategic alignment model .................................................................................................................................. 4 1.2.2 The Amsterdam framework for information management ................................................................................ 5

1.3 Structure of Enterprise Architecture .......................................................................................... 7 1.4 Enterprise architecture frameworks .......................................................................................... 8

1.4.1 ArchiMate: EA language standard....................................................................................................................... 9 1.5. Enterprise architecture in a SME context ............................................................................... 11

1.5.1. CHOOSE: EA for SMEs ...................................................................................................................................... 12 2. MAPPING PROCESS AND GUIDELINE DEVELOPMENT .................................................................................. 16

2.1 Problem description ................................................................................................................. 16 2.2 Mapping introduction .............................................................................................................. 18

2.2.1 Mapping CHOOSE to ArchiMate ....................................................................................................................... 19 2.2.1.1.Mapping highlighted ................................................................................................................................. 20

2.2.2 Mapping ArchiMate to CHOOSE ....................................................................................................................... 23 2.3 Mapping analysis ..................................................................................................................... 26

2.3.1 CHOOSE to ArchiMate ...................................................................................................................................... 27 2.3.2 ArchiMate to CHOOSE ...................................................................................................................................... 29

3. MAPPING VALIDATION - CASE STUDY ..................................................................................................... 31 3.1 Introduction ............................................................................................................................. 31 3.2 CHOOSE to ArchiMate ............................................................................................................. 31

3.2.1 The roadmap-method ....................................................................................................................................... 33 3.2.1.1 Translation of high-level goals .................................................................................................................. 33 3.2.1.2 Brake down high-level goals into lower-level goals .................................................................................. 33 3.2.1.3 Translate the actor dimension .................................................................................................................. 34 3.2.1.4. Translation the underlying operation dimension ..................................................................................... 35 3.2.1.5. Translation the defined objects ............................................................................................................... 36 3.2.1.6. Connect all concepts and validate general model ................................................................................... 38

3.2.2 Translation analysis ........................................................................................................................................... 40 3.3 ArchiMate to CHOOSE ............................................................................................................. 40

3.3.1 The roadmap-method ....................................................................................................................................... 42 3.3.2 Translation analysis ........................................................................................................................................... 44

4. CONCLUSION ................................................................................................................................. 46 5. FUTURE RESEARCH ......................................................................................................................... 47 REFERENCES .......................................................................................................................................... 48 APPENDIX .......................................................................................................................................... 51

APPENDIX A ................................................................................................................................... 51 APPENDIX B ................................................................................................................................... 57

Appendix B.1. ............................................................................................................................................................. 57 Appendix B.2. ............................................................................................................................................................. 62

IV

ABBREVIATIONS

ADM Architecture Development Method

AIM Amsterdam framework for Information Management

ATL Architecture Transformation Language

BPMN Business Process Modeling and Notation

CEO Chief Executive Officer

CHOOSE “keep Control, by means of a Holistic Overview, based on Objectives

and kept Simple of your Enterprise”

DoDaF Department Of Defense Architecture Framework

EA Enterprise Architecture

EAF2 Enterprise Architecture Framework Framework

ERP Enterprise Resource Planning

IM Information Management

IT Information Technology

SME Small and Medium sized Enterprises

TOGAF The Open Group Architectural Framework

UML Unified Modeling Language

V

LIST OF FIGURES

Fig.1 Strategic alignment model (Henderson and Venkatraman 1993) ...................................................4 Fig.2 The Amsterdam framework for Information Management (Maes 2007) .......................................6 Fig.3 EAF2 – a classification of frameworks (Franke, Höök et al. 2009) ...................................................8 Fig.4 TOGAF-ADM (Iacob, Jonkers et al. 2012) ..................................................................................... 10 Fig.5 Analysis of EA frameworks (Bernaert, Poels et al. 2013) ............................................................. 14 Fig.6 CHOOSE metamodel (Bernaert, Poels et al. 2013) ....................................................................... 15 Fig.7 ArchiMate structure ..................................................................................................................... 17 Fig.8 Transformation between CHOOSE and ArchiMate ...................................................................... 18 Fig.9 Mapping illustration CHOOSE to ArchiMate ................................................................................. 19 Fig.10 Generic ArchiMate metamodel of Business layer(Iacob, Jonkers et al. 2012) ........................... 24 Fig.13 Translation High-level Goals ....................................................................................................... 33 Fig.14 Translation low-level goals ......................................................................................................... 34 Fig.15 Translation Actor dimension ....................................................................................................... 35 Fig.16 Translation Operation dimension ............................................................................................... 36 Fig.17 Translation Object dimension ..................................................................................................... 38 Fig.19 Extended ArchiMate model ........................................................................................................ 41 Fig.20 Translation result: CHOOSE model ............................................................................................. 43 Fig.21 Restricted CHOOSE model .......................................................................................................... 45 Fig.22 ArchiMate’s Application Layer metamodel (Iacob, Jonkers et al. 2012) .................................... 58 Fig.23 ArchiMate’s Technology Layer metamodel (Iacob, Jonkers et al. 2012) .................................... 59 Fig.24 Relationships between ArchiMate’s Business Layer and Lower Layer metamodel concepts (Iacob, Jonkers et al. 2012) .................................................................................................................... 60 Fig.25 Relationships between ArchiMate’s Application Layer and Technology Layer metamodel concepts (Iacob, Jonkers et al. 2012) .................................................................................................... 61

LIST OF TABLES

Table 1: Mapping result of the CHOOSE process concept(1) ................................................................ 21 Table 2: Mapping result of the CHOOSE process concept(2) ................................................................ 22 Table 3: Mapping result of the CHOOSE association relationship ........................................................ 22 Table 4: Mapping grid from CHOOSE to ArchiMate .............................................................................. 51 Table 5: Mapping grid from ArchiMate to CHOOSE .............................................................................. 62

VI

Introduction

The current environment where organizations operate is getting more and more complex. The

architecture of an organization and the ability of managing this architecture have obtained an

important role in management. As a result, organizations are looking for ways to visualize

those architectures. The reason behind it lies in the integrated view an architecture provides

of all systems in the organization. The ability of an organization in managing their architecture

enhances the agility of the organization and could lead on his turn to a competitive advantage.

Not only large organizations but also SME’s are looking for ways to describe their architecture,

more in particular their enterprise architecture. CHOOSE offers a solution for SME’s in

modeling and maintaining their enterprise architecture. Inherent with organizations,

successful organizations encounter continuous growth resulting in a more elaborated and

diverse enterprise architecture(Girish J. Bakshi & Dr 2014). From the moment SME’s need to

incorporate a lot of IT concepts, CHOOSE shows some limitations. Hence, the organization will

opt for a more elaborated EA modeling language. In this master dissertation, the architect will

be guided in translating his CHOOSE model towards a new model in a more elaborated EA

modeling language. In the first part, the master dissertation will be framed as an enterprise

architecture project within Information Management using the Strategic alignment model and

the Amsterdam framework for information management. Afterwards, we will narrow down to

enterprise architecture and describe why ArchiMate has been chosen as the elaborated

enterprise architecture language. The second part will describe the mapping process from

CHOOSE to ArchiMate as a solution for SME’s that encounter continuous growth, and from

ArchiMate to CHOOSE as a way to overcome strategic gaps between strategy and operations.

Furthermore, the second part contains the development of guidelines which will guide the

architect in an accurate translation of his CHOOSE model to a new ArchiMate model as well as

from ArchiMate to CHOOSE. The final part of the master dissertation will validate the mapping

process and developed guidelines using a real-life model of a tire company, after which

conclusions will be drawn and extra restrictions will be made based on the translation analysis.

1

1. Enterprise architecture

1.1 Definition of Enterprise Architecture

The term “Enterprise Architecture” as used in businesses can denote two different aspects. In

some cases it may refer to a group of people that are responsible for modeling and

documenting the organizations architecture. In another case, the term stands for the process

of performing this work. In general, when the term “Enterprise Architecture” is used, we are

referring to the models and documentation that represents the current structure and

processes of an organization (Pereira and Sousa 2004). Lankhorst (Lankhorst 2009) defines EA

as: a coherent whole of principles, methods and models that are used in the design and

realization of the enterprise’s organizational structure, business processes, information

systems and infrastructure. Further is enterprise architecture in information systems

commonly defined using the IEEE Standard 1471-2000 (Society 2000): Architecture is the

fundamental organization of a system embodied in its components, their relationships to each

other, and to the environment, and the principle guiding its design and evolution. Therefore,

EA has to capture the essentials of the business, IT and its evolution.

In search for a competitive advantage, the use of EA enables an enterprise to better align their

business with IT(Pereira and Sousa 2004). Companies tend to perform better when EA is being

used(Ross, Weill et al. 2006). One of the main characteristic of enterprise architecture is the

passiveness of it structure and the provision of a holistic view on the enterprise(Jonkers,

Lankhorst et al. 2006), consequently it offers a strong foundation in the support of information

system development and the identification of inconsistencies between all different kind of

functionalities in the organization(Braun and Winter 2005). The advantages of EA make IT an

asset rather than a liability in the current business environment. Companies that have

embedded IT technologies and implemented IT systems in their processes have a competitive

advantage. They are able to work more efficiently and focused on their core activities(Ross,

Weill et al. 2006). To obtain those advantages, EA tend to serve as a guidance tool in

redesigning all processes of an organization.

Furthermore, the main key characteristic of enterprise architecture is providing a holistic

overview of a company’s structure. EA can also represent the as-is situation of a company as

well as the to-be situation that enhances the planning of the organizational changes(Pereira

2

and Sousa 2005). Providing different views as the business-oriented view and a technical view,

EA stands for a better communication between business and IT(Ambler 2002). For the

development and visualization of the enterprise architecture, the developer need to rely on

an appropriate metamodel. After the metamodel is found, it has to be implemented using an

appropriate modeling tool in order to support the computer based architecture management

process(Braun and Winter 2005).

Important to note is that enterprise architecture is a living document and has to be developed

regarding the requirements of the specific stakeholder. EA is more and more evolving towards

an active concept that supports business systems design concerning the optimization of

business strategies, organizational structures, business processes, information flows,

application structures etc.

1.2 Enterprise Architecture within Information Management.

Over the last decades, as a consequence of major macro-economic shifts: globalization,

virtualization, customization, the decrease in transaction costs associated with information,

the over-load of information organizations are exposed and the importance of information

management results that the impact of information technology on today’s organizations has

extremely changed (Maes 2007). IM as IT have evolved from the back office, where it was

especially used to support business strategies towards a role where IM and IT assists in shaping

business strategies (Henderson and Venkatraman 1993). Consequently, more and more

organizations are nowadays being judged on the quality of their information resources. In

supporting the quality of information resources in today’s organizations, they are seeking for

a method to improve the relationship between their business and IT department. As many of

them face issues regarding the alignment of their business with their IT, a good information

system could provide organizational agility that can turn in a competitive advantage. The

source of this misalignment can for a large extend be found in the difficulties in communication

between different departments. It is the organizations responsibility to find a good fit between

their business and IT, which EA might offer.

3

1.2.1 Strategic alignment model

To overcome the problems of misalignment between business and IT, Henderson and

Venkatraman developed a first model for the business-IT relationship in 1993: Strategic

alignment model. Their intention was to support the integration of IT into the business strategy

to obtain value from IT investments now that information technology has evolved from a

supportive to a strategic role. The integration was carried out by searching for and by

promoting alignment between and within four different domains along two dimensions(Maes,

Rijsenbrij et al. 2000).

Fig.1 Strategic alignment model (Henderson and Venkatraman 1993)

The strategic alignment model is based on the concept of strategic fit between internal and

external views and the functional integration between organizational and technological views.

In turn, this leads to the current model with four quadrants: business strategy, IT strategy,

organizational infrastructure & processes and I/S infrastructure & processes. When managers

tend to use the strategic alignment model they often cope with difficulties in understanding

the positioning of their IT in the marketplace as they are more familiar in making decisions

regarding the positioning of their business. Therefore, Henderson and Venkatraman proposed

three sets of choices to overcome this difficulty. The first choice regards the information

4

technology scope, the second concerns the systemic competencies and the third concerns I/T

governance. These three choices must enable the organization to support the current business

strategy, as in shaping new business strategy initiatives. After the external domain, Henderson

and Venkatraman address three components the internal domain must include: I/S

architecture that represent the configuration of hardware and software in an organization, I/S

processes that defines the processes central to the operations of the I/S infrastructure and I/S

skills representing the skills and capabilities of the person handling the I/S infrastructure of an

organization(Henderson and Venkatraman 1993). An integrated connection between all

quadrants of the strategic alignment model is required to obtain a better alignment between

their business and IT. To help the organizations in aligning their business with IT (Henderson

and Venkatraman 1993) defined four alignment perspectives i.e. Strategy execution,

Technology transformation, competitive potential and Service level. The first two perspectives

are characterized by the business strategy as their main driver, the latter two are determined

by the IT strategy as main driver. Now it is the management’s responsibility to apply one or

many of these perspectives and obtain better business/IT alignment through automation

rather than traditional linkage(Henderson and Venkatraman 1993).

1.2.2 The Amsterdam framework for information management

The Amsterdam framework for information management is based on the vital role of

information as the glue between business, strategy, IT and operations. Hence, the AIM model

can be seen as an extension of the strategic alignment model by adding an

information/communication column and a structure row.

5

Fig.2 The Amsterdam framework for Information Management (Maes 2007)

The framework is used for different perspectives. In the first place AIM can be used as a

descriptive and orienting framework. This means the framework applies as a communication

tool between all areas and people in the organization without using technical jargon. Secondly,

AIM can be used as an organizing and designing tool intended to reshape an organizations

overall information management. Finally, AIM can be adopted as a prescriptive and normative

framework. In this manner AIM acts as a diagnosis tool to investigate and analyze the

information services of an organization. Alongside, it is important to note that the AIM model

is only meant as an integrative positioning framework rather than an alignment model. In fact,

AIM allows the user to evaluate all the different aspects of information management in terms

of business, information and technology from a strategic, structural and operational

perspective(Maes 2007).

Enterprise Architecture within information management can be located at the structure

related horizontal axis in the AIM model. In this manner, enterprise architecture takes care of

the business-IT alignment in a structural way. Enterprise architecture is not only responsible

for a logical architecture that contains relationships across business-,

6

information/communication- and technology architecture but also contains relationships to

facilitate the translation from the corporate strategy to the daily operations. (Maes 2007).

1.3 Structure of Enterprise Architecture

EA is an aggregate representation of a complex entity, it models aggregate system components

and their interrelation. EA relies on a hierarchical approach when designing the organizational

structure. It’s a multi-level framework that represents different views on an organization. The

design contains a building plan where all objects and their relationships with each other are

incorporated(Braun and Winter 2005). Braun and Winter(Braun and Winter 2005) defines the

structure of EA as: “For EA, a hierarchical approach usually applies the ‘IT follows business’

principle, starting with strategic positioning from the business management point of view, then

deriving appropriate organizational processes and structures on this basis and finally specifying

the information system, i.e. the interaction between human and technical information system

components that appropriately support business requirements.” This definition also specifies

the different levels that are present in EA.

As Braun et al. (Braun and Winter 2005) state in their research, enterprise architecture can be

differentiated in four architectural layers. First of all, they distinguish the goal of the design in

the strategy layer. The strategy layer defines the strategic position of the organization in the

value chain. The second layer that can be distinguished is the organizational layer. Here main

processes, performance indicators and organizational structure are mapped. The

organizational layer also functions as a connector between the strategy layer and the

application layer, which is the third layer specified in enterprise architecture. The goal of the

application layer is to link information systems to business requirements by creating an

application structure and design that results in the responsibility for linking an information

system to its corresponding process that it needs to support. The final layer that is addressed

in enterprise architecture is the software component layer. The software component layer

represents the organization of software services and data structures of an organization.

It’s important to note when designing an organization’s architecture that not all layers

distinguished by (Braun and Winter 2005) need to be addressed when designing an

organizational architecture. The number of layers addressed as the names given to the layers

when developing enterprise architecture depends on the applied approach. The use of a

7

specific framework depends on the purpose of an organization to model its architecture, also

the view they use may differ from framework to framework.

1.4 Enterprise architecture frameworks

When developing enterprise architecture, many frameworks can be used. It is up to the

architect to determine which framework applies for specific contexts regarding all frameworks

differ in content and targeted audience. In choosing the appropriate framework, Franke et

al.(Franke, Höök et al. 2009) developed the Enterprise architecture framework framework

EAF2 as a guidance tool for architects. EAF2 defines all different frameworks and tries to fit with

the goals and needs of the architect.

Fig.3 EAF2 – a classification of frameworks (Franke, Höök et al. 2009)

In the development of EAF2, Franke et al. searched for similarities between frameworks. The

outcome of their research distinguished two main classes (i.e. superclasses): Architecture

governance and Modeling concepts. In the Architectural governance superclass, EAF2

architectural development process can be distinguished. Which on his turn specifies TOGAF

architecture development method (ADM), MODAF architecting process and DoDAF

architecture development process are part of(Franke, Höök et al. 2009). It is to the architect to

define the specific needs of the enterprise architecture. The purpose of the architect can be

an architecture that serves as a management function or as a modeling tool. It is the architect

responsibility to determine the appropriate EA framework for his specific context.

8

In the following sections of this master dissertation, only EA frameworks classified under the

Modeling concept will be used i.e. ArchiMate and CHOOSE.

1.4.1 ArchiMate: EA language standard

ArchiMate, an Open Group Standard, is a modeling language for enterprise architecture.

ArchiMate enables the enterprise architect in describing, analyzing and visualizing all business

domains as their relationships in an unambiguous way by offering a common language for

describing the construction and operations of business processes, organizational structures,

information flows, IT systems and technical infrastructure(Iacob, Jonkers et al. 2012). As a

result, ArchiMate guides stakeholders through all struggles concerning changes within these

business domains.

The core of the ArchiMate language consists out of three structures: passive structure,

behavior structure and the active structure. These structures are related to three abstractions

of Zachman’s Framework (Zachman 2006) respectively What, How and Who abstraction. The

passive structure consists out of concepts upon behavior is performed by an active component.

The behavior structure represents the actual behavior, the processes and activities that are

being performed. The active structure components are concepts related to the execution of

behavior. Now the three structures are defined, they are on their turn divided into three layers:

Business layer, Application layer and Technology layer that are related to the architectural

layers in TOGAF. The layers work in a hierarchical way, the Business layer involves the relation

of the products within the organization by means of business processes as the interaction of

the organization with external stakeholders. The business layer is supported by the Application

layer which provides application services. On his turn, the Application layer is supported by

the Technology layer that provides the necessary infrastructural services as hardware and

software to run the applications. As of ArchiMate 2.0 extensions were provided to model the

motivations for the architecture and its implementation and migration planning. The purpose

of the Motivational extension describes in a high level strategic way how EA is aligned to its

context, persons or organizations that influence or constrain, plans or aims, by internal or

external factors. The second Implementation and Migration Extension provided in ArchiMate

2.0 applies to the transition planning and architecture governance. It assists in understanding

the programs and projects that carry out implementation. As from then, ArchiMate and TOGAF

were totally aligned. Fig.4 visualizes how ArchiMate and TOGAF are aligned. As a result of the

9

fully alignment of ArchiMate with the TOGAF standard, ArchiMate is mostly used together with

TOGAF.

Fig.4 TOGAF-ADM (Iacob, Jonkers et al. 2012)

The core of ArchiMate relates to Business Architecture, information Systems Architectures and

Technology Architecture. The Motivation Extension concept establishes the high-level goals

supports the Requirements Management, Preliminary phase and Architecture Vision of TOGAF.

The main reason why ArchiMate is widely used is because ArchiMate offers a unified way of

modeling enterprise architectures, integrating the various domains and describing them in an

easily readable way. During the development of the ArchiMate metamodel, concepts of other

languages as UML and BPMN were used. As a result, ArchiMate has clear links with other

existing approaches that makes it easy to understand. Next to the unified language and links

with existing approaches, different viewpoints are incorporated within ArchiMate and help in

providing the right information to a specific stakeholder. As such, viewpoints enhance intern

communication and decision-making.

10

1.5. Enterprise architecture in a SME context

The current environment where enterprise architecture operates is focused on large

enterprises while small- and medium sized enterprises are forgotten and often cope with

problems due to a lack of structure and overview. The reason often lies in the lack of IT

adoption within SMEs. IT in a SME environment is mostly seen as a set of tools for solving

short-term operating problems rather than long-term strategic plans that is why SMEs allocate

fewer resources to IT and cope with poverty regarding IT knowhow and need to rely on

external technical skills. The poor allocation of resources to IT not only occurs due to this

mindset but results also from different influences that characterize SMEs. So are employees

and management overloaded by the day-to-day activities of the organization that only little

time remains to look into strategic matters. SMEs are also characterized by the strong

presence of one person, the CEO who controls the enterprise and makes all decisions regarding

strategic issues(Bernaert, Poels et al. 2014). While in most of the cases the CEO’s tend to have

a good knowledge about their enterprise, they sometimes tend to lose overview across all

business processes leading to a series of business issues regarding ERP adoption, difficulties in

communication with employees about the organizations strategy, job description and

responsibilities. The most important issue is the ever-changing environment where the

organization operates(Bernaert and Poels 2012). Without a holistic overview, a company could

lose track and will suffer from less flexibility and agility.

To reduce al these problems, EA can be addressed. SMEs could benefit from EA to overcome

these issues(Bernaert 2011). EA provides a key instrument in controlling the complexity of the

enterprise and systems, a holistic overview that enables the architect as well as all important

stakeholders to structure the organizations architecture and align their business with IT. To

apply enterprise architecture in SMEs, EA should be modified to the needs and possibilities of

EA hence SMEs do not always posses the knowhow needed to elaborate their enterprise

architecture. In fact, current EA practices are categorized by a lack of simplicity. As a result, EA

is barely used in SMEs. That is why Bernaert et al. developed the CHOOSE approach consisting

out of a metamodel, model and a tool to enable SMEs in elaborating their enterprise

architecture. To guide the development and to obtain a higher fit with SMEs, six criteria were

derived which the new approach should address(Bernaert, Poels et al. 2014).

1. The approach should enable SMEs to work in a time efficient way on strategic issues.

11

2. A person with limited IT skills should be able to apply the approach.

3. It should be possible to apply the approach with little assistance of external experts.

4. The approach should enable making descriptions of how things are done in the company.

5. The CEO must be involved in the approach.

6. The expected revenues of the approach must exceed the expected costs and risks.

In addition to these six criteria, the development of the new approach will also be based on

the five criteria a EA approach should posses (Lankhorst 2009).

1.Control: “EA is a key instrument in controlling the complexity of the enterprise and its

processes and systems.”

2.Holistic Overview: “The most important characteristic of an EA is that it provides a holistic

overview of the enterprise.”, “EA has to capture the essentials of the enterprise, because they

are more stable than the specific solutions found for the problems currently at hand.”

3.Objectives: “EA facilitates the translation from corporate strategy to daily operations.”

4.Suitable for its target audience: “It is necessary to use an approach that is understood by all

those involved from these different domains.”

5.Enterprise: “This enables optimization of the company as a whole instead of doing local

optimization within individual domains.”

The targeted audience that will be addressed when developing the new EA approach will be

SMEs. When developing a new EA approach, it’s important to bear in mind that all criteria

listed above are fulfilled. In that manner, EA will provide SMEs with the possibility to clearly

define a competitive strategy as a part of the alignment of business with IT. Moreover, an

explicit enterprise architecture model can show the links between operations and strategy and

enables the CEO to easily communicate the strategy with his stakeholders. Besides the

communication aspect, EA makes it possible for the organization to perform a change impact

analysis, easily links/identifies conflicts and makes it easier for employees to gain insight in this

knowledge(Bernaert, Poels et al. 2014).

1.5.1. CHOOSE: EA for SMEs

Mentioned by (Lankhorst 2009), EA needs to be understood by all stakeholders involved from

different domains. As SMEs have different characteristics than large organizations, the

CHOOSE approach has been developed to the needs of a SME by combining the essential

dimensions and characteristics of EA bearing in mind all the criteria and characteristics the

12

new approach should possess. The result will be a new approach that will increase the

perceived usefulness, the perceived ease of use of enterprise architecture in a SME

environment. As already mentioned in the previous section, SMEs are characterized by a

strong presence that has the responsibility to make all strategic decisions and often lack in IT

skills. To overcome this issue, through development, a constant tradeoff between

comprehensiveness and simplicity occurred.

Developing the CHOOSE approach, Bernaert et al. decided to develop three artifacts, a

metamodel, a method and a software tool that is currently under construction. The name

CHOOSE is an acronym for “keep Control, by mean of a Holistic Overview, based on Objectives

and kept Simple, of your Enterprise.” As a result, CHOOSE keeps in mind the requirements for

EA for SMEs and incorporates the requirements for EA (criteria 1,2,3,5) and simplicity as main

focus for EA in a SME context(Bernaert, Poels et al. 2013).

The starting point for the development of the CHOOSE metamodel, existing frameworks were

analyzed and essentials of these frameworks were discovered. Out of these essentials, a new

metamodel was developed. The collection of EA frameworks identified for the analysis was

based on the six abstractions of the Zachman Framework respectively (What, How, Where,

Who, When, Why). After considering the different abstractions, Winter and Fischer (2007)

arised with five essential architectural layers (Business, process, integration, software and

infrastructure), these could be reduced to only three layers: Business, software and

infrastructure due to the fact process architecture layer can be integrated in business

architecture layer and integration architecture layer can be integrated in software architecture

layer.

13

Fig.5 Analysis of EA frameworks (Bernaert, Poels et al. 2013)

From the analysis in Fig.5 the conclusion could be made that most of the frameworks use four

abstractions of the Zachman framework: What, How, Who and Why. When and Where are less

addressed in EA frameworks. As a result, the four abstractions together with the three

architecture layers will be the EA essentials that the CHOOSE metamodel should

support(Bernaert, Poels et al. 2013).

The CHOOSE metamodel is mainly based on the KAOS metamodel. KAOS is based on five

viewpoints: goal viewpoint, agent viewpoint, operation viewpoint, object viewpoint and

behavior viewpoint that will not be addressed. The four viewpoints of KAOS are respectively

conform the essential EA focuses, Why, Who, How and What. That why KAOS is the perfect

starting point for the CHOOSE metamodel development. The evolution from the KAOS

metamodel to an appropriate CHOOSE metamodel was obtained through action research.

Some parts of the KAOS metamodel were deleted, others were edited and some additions

were made which resulted in the final CHOOSE metamodel Fig.6 (Bernaert, Poels et al. 2013).

14

Fig.6 CHOOSE metamodel (Bernaert, Poels et al. 2013)

Now the CHOOSE metamodel is obtained, conclusion according to the conformity with the

essential parts of enterprise architecture framework can be evaluated. First of all, the CHOOSE

metamodel is able to integrate respectively the four essential EA focuses: Why by the goal

viewpoint, who by actor viewpoint, how by operation viewpoint and what by object viewpoint.

Next to the integration of EA focuses, the CHOOSE metamodel incorporates the three EA layers

Business, Software and Technology by respectively implementing Role, Software Actor and

device for the actor dimension. Also Goal, Object and Operations can be defined within the

three different EA layers(Bernaert, Poels et al. 2013). As a result, CHOOSE is the new approach

to enable SMEs in using enterprise architecture. The goal-oriented mindset of CHOOSE and

the perfect balance between comprehensiveness and simplicity creates an environment

where business architecture comes first and CEOs can develop enterprise architecture without

the use of a specific skill set or external resources. This provides the CEO with a holistic

overview that enables to better align his business with IT, makes it easier to communicate with

employees and can lead to a competitive advantage.

15

2. Mapping process and guideline development

2.1 Problem description

In the previous section we mentioned that SMEs could benefit from using enterprise

architecture in structuring their enterprise and better aligning their strategy with IT. Now a

new EA modeling language that targets SMEs has been developed, CHOOSE could be enforced

to cover all problems SMEs could face regarding business and IT alignment. As CHOOSE

provides a solution towards SMEs, CHOOSE is characterized by limitations in situations where

the organization encounters continuous growth. Growth is inherent to all kinds of successful

organizations. Every organization wants to get big or bigger, obtain greater efficiencies from

economies of scale, increased power to withstand market fluctuations and greater

profits(Girish J. Bakshi & Dr 2014). As growth can be measured in many ways, we will focus on

those measures that let the organization grow physically i.e. number of employees and

physical expansion. Physical expansion will result in the expansion of the organization’s

architecture. At this point, CHOOSE shows limitations as an EA modeling language. Growth can

carry investments in new processes, applications and IT infrastructure. The issue regarding the

organization’s growth is that CHOOSE limitedly supports modeling the IT architecture. When

situations arises where CHOOSE thwarts in supporting the organization’s growth, SMEs benefit

to step from CHOOSE to a more elaborated EA modeling language. The opposite situation is

also possible where large organizations using an elaborated EA modeling language could

benefit from a simpler and more business oriented EA approach. The case could occur when

the whole company or a business unit wants to actively involve business experts in EA

modeling. In the latter case, IT is less important and business experts could benefit from using

CHOOSE. The relevant business architecture could be mapped on CHOOSE to provide the

business experts with essential insights. Parallel the elaborated EA modeling language can

assist in modeling the IT architecture. As such CHOOSE provides the possibility to involve

business experts with little knowledge in enterprise architecture to work along enterprise

architecture experts.

The choice for the elaborate EA modeling language we will use to perform our mapping will be

ArchiMate as ArchiMate and CHOOSE are both EA languages. ArchiMate is also an Open Group

Standard and is widely supported by different vendors and consulting firms. No BPMN or UML

will be used as we want to stay focused on a holistic overview instead of specificity. Hence

16

ArchiMate doesn’t try to accommodate all needs of all possible users, but is limited to the

concepts that suffice for modeling 80% of the practical cases (Iacob, Jonkers et al. 2012).

Related to this restriction, both ArchiMate and CHOOSE are vigorous in preserving the

simplicity of the metamodel. Besides, ArchiMate is publicly available and instantiations can be

modeled using the program Archi. Next to ArchiMate’s specifications, the structure of

ArchiMate and CHOOSE show similarities. Both ArchiMate and CHOOSE are based on the

Zachman abstractions. Respectively four abstractions used in the CHOOSE method Why, Who,

How and What are related to the ArchiMate Motivation, Active structure, Behavior and Passive

structure. Hence the similar structure and the fact that the definitions of CHOOSE concepts are

partially based on the ArchiMate definitions, ArchiMate is the perfect choice to perform our

mapping.

Fig.7 ArchiMate structure

When the mapping will be performed, our main focus will be on the business layer of

ArchiMate as CHOOSE mainly focuses on the business architecture rather than the IT

architecture of a SME(Bernaert 2011). After the translation of the CHOOSE model, the

architect will be able to extend his model with the application layer and technology layer.

Nevertheless, the mapping to the application layer and technology layer will be provided to

cover special cases.

17

2.2 Mapping introduction

To process the mapping we will focus on the metamodels of respectively CHOOSE and

ArchiMate rather than on the instantiations of the modeling languages. The metamodel

concepts and relationships will be mapped from CHOOSE to ArchiMate after which the

instantiations can be translated based on the developed guidelines.

Fig.8 Transformation between CHOOSE and ArchiMate

To process the mapping, the mapping techniques described in (Zivkovic, Kühn et al. 2007) will

guide us in finding the right ArchiMate concept for every CHOOSE concept. The mapping as

performed in this master dissertation will be based on the sematic heterogeneity of the

metamodels, as it is the main dimension to distinguish different types of mappings. The

semantic heterogeneity states that concepts originating from different metamodels can use

the same linguistic terms in describing different concepts or in the opposite way that different

terms describe the same concept. Using the semantic mismatches between the metamodels

the mapping will be achieved by defining the possible inter-relations between metamodel

concepts. Common inter-relations between metamodel concepts are: semantic equivalence,

semantic relation and non-relation. For the first inter-relation, the concepts hold the same

meaning even if synonyms are used. For the two latter inter-relations, the concepts are related

through semantic relation types as “is-a”, “has-a”, “type-of” and “associate” or can be

described by homonyms (Lopes, Hammoudi et al. 2006, Zivkovic, Kühn et al. 2007).

As a mapping represents a structural and semantic correspondence between concepts of two

metamodels, the mapping will take one concept i.e. class, attribute or relationship from one

18

source metamodel (CHOOSE) and relates it to concepts of the other source metamodel

(ArchiMate). Helping to find the links between two source metamodels, Zivkovic defines

different mapping variants i.e.: mapping structure: class-to-class (C2C), attribute-to-attribute

(A2A), relationship-to-relationship (R2R), attribute-to-class (A2C), attribute-to relationship

(A2R), relationship-to-class (R2C) and mapping cardinality: one-to-one (1-1), one-to-many (1-

N), many-to-many (M-N). For our mapping process, we will focus on class-to-class mapping,

which relates a concept from one source metamodel with one or many concepts from the

other source metamodel and relationship-to-relationship mapping, which relates concept

relationships from one source metamodel with concept relationship from the other source

metamodel. In processing our mapping from CHOOSE to ArchiMate, we will use definitions

defined for all CHOOSE and ArchiMate concepts and relationships. The definitions for the

CHOOSE concepts and relationships used are defined by Bernaert et al. CHOOSE: Towards a

Metamodel for Enterprise Architecture in Small and Medium-Sized Enterprises (Bernaert, Poels

et al. 2013). Respectively for ArchiMate the definitions used are defined in its specification

(Iacob, Jonkers et al. 2012).

2.2.1 Mapping CHOOSE to ArchiMate

Fig.9 Mapping illustration CHOOSE to ArchiMate

19

The mapping process will be executed in two stages. The first stage will define a general

mapping as for each CHOOSE concept and relationship the mapping process will try to find its

equivalent in ArchiMate guided by the mapping techniques provided by Zivkovic et al.

Searching the equivalent concepts, the mapping will use the structure similarities of CHOOSE

and ArchiMate based on the Zachman abstractions Fig.9. The second stage concerns the

development of guidelines resulting the metamodel heterogeneity. As we compare the two

enterprise architecture modeling languages, we state that both are vertically different i.e.

CHOOSE and ArchiMate both describe different levels of detail. Consequently, one-to-one (1-

1) and one-to-many (1-N) mapping will occur when mapping from CHOOSE to ArchiMate.

Hence extra information will be needed from the architect to complete the translation process.

This extra information will be obtained according to well-defined guidelines that guide the

architect towards an accurate translation of its specific model. In addition to keep the mapping

feasible, it is important to state that two concepts cannot be associated with more than one

mapping, whereas one concept can be mapped on many others(Zivkovic, Kühn et al. 2007).

2.2.1.1.Mapping highlighted

To provide the reader with insights on how the mapping was obtained, we extracted the

CHOOSE concept Process as an example for which the total mapping that can be found in

appendix A. As stated, the CHOOSE approach is more considered as a business architecture

modeling language rather than an enterprise architecture modeling language. As such, the

mapping is mainly focused to the business layer and motivational extension in ArchiMate. In

mapping the CHOOSE concept Process the mapping technique class-to-class provided by

(Zivkovic, Kühn et al. 2007) is used. Starting from the left-hand side, the CHOOSE concept

together with his definition defined by (Bernaert, Poels et al. 2013) provides the initial point in

finding the right-hand side which is the ArchiMate concept. Mapping the left-hand side Process

to its right-hand side in ArchiMate, the mapping is characterized by the mapping cardinality

one-to-many (1-N). For Process, the mapping process found more than one equivalent in

ArchiMate i.e. Business Process, Business function and Business interaction.

20

CHOOSE CONCEPT DEFINITION ArchiMate CONCEPTS

Object Type

Process A behavior element that groups behavior based on an ordering of activities with the objective of carrying out work. It is intended to

produce a defined set of products or business services.

Business Process, Business Function,

Business Interaction, Application Function,

Application Interaction, Infrastructure Function

Table 1: Mapping result of the CHOOSE process concept(1)

Now the initial mapping is obtained, and the mapping is characterized by (1-N) cardinality, the

architect will need to choose between the different ArchiMate concepts in accurately translate

his CHOOSE concept to the right ArchiMate concept. The decision process will be assisted by

guidelines that will be developed using the ArchiMate concept definitions (Iacob, Jonkers et al.

2012). As for the extracted example, Process can be mapped on three different ArchiMate

business layer concepts. The guidelines specified will guide the architect towards the right

ArchiMate concept when translating its CHOOSE model to a new ArchiMate model. Following

these guidelines, the architect will choose for the ArchiMate concept Business Process when

Process refers to a flow of activities, Business function will be used when Process stresses the

combination of resources and competences needed to perform certain behavior. Finally,

Business Interaction will be applied when Process specifies behavior of Business Collaboration.

The CHOOSE Process concept could also be mapped on the application as technology layer of

ArchiMate but is not our main focus and can be found in Appendix A to cover special cases.

21

CHOOSE CONCEPT

DEFINITION

ArchiMate CONCEPTS

ArchiMate Business layer

ArchiMate Motivation Extension

Object Type

Process

A behavior element that

groups behavior

based on an ordering of

activities with the objective

of carrying out work. It is intended to produce a

defined set of products or

business services.

Business Process, Business Function,

Business Interaction, Application Function,

Application Interaction,

Infrastructure Function

Business process

Business function

Business interaction

Table 2: Mapping result of the CHOOSE process concept(2)

Subsequent to the initial mapping of the concepts, the relationships between the concepts

need to be mapped from CHOOSE to their equivalent in ArchiMate as well. Important in

proceeding the process is that first the definitive mapping of the concepts is obtained before

the relationships can be mapped, hence the relationships are inherent to the concepts they

relate.

CHOOSE CONCEPT

ArchiMate Relationship

ArchiMate Business

ArchiMate Application

ArchiMate Technology Cross-layer Cross-layer

Object Type Business-Application

Application-Technology

Association

Access

Business Service-Business Object

Application service-Data

object

Infrastructure service-Artifact

Realization Representatio

n-Business object

Communication path-Network

Business object-Data

object

Assignment

Location-Business

object/Representation; Business service-Business Interface

Application Service-

Application Interface

Infrastructure service-

Infrastructure Interface;

System Software/Device

- Artifact

Location-Application Service/Inter

face/Work package

Location-Artifact/Network/Communication

path

Table 3: Mapping result of the CHOOSE association relationship

22

Considering the example, the Association relationship in CHOOSE relates two concepts in the

object dimension. After we mapped all possible concepts in these dimension to ArchiMate i.e.

Business Interface, Location, Business Object, Business Service, Representation, Product,

Contract, Application Interface, Data Object, Application Service, Network, Communication

Path, Infrastructure Interface, Infrastructure Service, Artifact and Deliverable, we now consider

all possible relationships between those ArchiMate concepts using the metamodel

representation in (Iacob, Jonkers et al. 2012). As a result, the Association relationship can be

mapped on three possible relationships in ArchiMate: Access, Realization and Assignment. For

each of the possibilities the occurrence is defined. For example, the relationship Access only

occurs in the Business, Application and Technology layer in ArchiMate. Respectively to the

specified layer, Access is used between Business Service and Business Object, Application

service and Data object, Infrastructure service and Artifact. In line with the previous

explanation, the same working method will be applied when mapping the other CHOOSE

relationships to their equivalent in ArchiMate. The mapping of all CHOOSE relationships to

their equivalent in ArchiMate can be found in Appendix A. Important to note, when for a

certain case no corresponding relationship is found, the association relationship in ArchiMate

can be applied.

2.2.2 Mapping ArchiMate to CHOOSE

Mapping from ArchiMate to the CHOOSE, we will mainly focus on the business layer and

motivation extension of ArchiMate as the translation of ArchiMate to CHOOSE will mainly

occur when the organization wants to actively involve business experts in EA modeling. Most

relevant for the business experts is the business architecture of the organization, as they don’t

possess the necessary knowledge to interpret the IT related concepts in ArchiMate. The

obtained model after translation could provide the business expert with the necessary insights

to make accurate decisions concerning EA.

Performing the mapping, the same mapping process will be followed as the mapping from

CHOOSE to ArchiMate. The mapping techniques from (Zivkovic, Kühn et al. 2007) will be used

to guide our mapping process. The main difference between the two mapping directions will

lie in the mapping cardinality. As ArchiMate is more elaborated than CHOOSE, the mapping

will result in a one-to-one (1-1) mapping. As such, the second part of the mapping process

considering the definition of guidelines can be dismissed. The main issue that results out of the

23

mapping will be the loss of information. During the validation, information losses will be

mapped out to warn the architects. As mentioned, we will mainly focus on the mapping of the

business layer and motivation extension of ArchiMate, Fig.10 and Fig.11 visualizes the mapping

from the ArchiMate concepts and relationships to their equivalent in CHOOSE.

Fig.10 Generic ArchiMate metamodel of Business layer(Iacob, Jonkers et al. 2012)

Fig.11 Generic ArchiMate metamodel of Motivation Extension(Iacob, Jonkers et al. 2012)

Finalizing the mapping from ArchiMate to CHOOSE, not all the ArchiMate concepts were used,

as the correctness of our mapping is essential. The concepts that were not incorporated in our

mapping are: Assessment, Driver, Meaning, Value and Business Event. The reason why these

24

concepts aren’t used in our mapping is because the definition of Assessment and driver defer

too much from the definition of the Goal concept in CHOOSE. The other concepts: Meaning,

Value and Business Event present in the business layer of ArchiMate weren’t used, as Meaning

and Value are two concepts that gives information inherent with other ArchiMate concepts,

rather than see these concepts separately, they can be incorporated in the description of those

CHOOSE concepts. The last ArchiMate concept that wasn’t used in our mapping is Business

Event, the reason behind neglecting Business Event is the nature of this concept. An event is

related to a trigger sent in order to start a process. As the trigger component cannot be found

in CHOOSE, Business Event is not used in our mapping. Besides, the total visualization of the

mapping from ArchiMate to CHOOSE can be found in Appendix B.1.

Related to the mapping from CHOOSE to ArchiMate, special cases occurred when mapping the

relationships between ArchiMate concepts. As our objective is to maintain the simplicity and

completeness of the mapping, some generalization will be formulated to reach the objectives.

One of the special cases occurs between Device and Network in ArchiMate. The relationship in

ArchiMate is defined as an association relationship as the concepts are respectively mapped

on Device and Entity in CHOOSE, the association relationship should correspond to the

Monitoring and Control relationship in CHOOSE. Now none of these relationships are

semantically similar to ArchiMate’s Association relationship, another relationship should be

assigned. Looking into the CHOOSE metamodel, we note that the Device concept in CHOOSE

is a specialization of Actor, which is a specialization of Object. Consequently, Network is

mapped on the Entity concept in CHOOSE which is also a specialization of Object. Thus,

considering that we have two Object specializations, we can use three possible relationships:

Association, Aggregation or Specialization. In this special case, we will obtain the Association

relationship between Device and Entity as it is similar to ArchiMate’s Association relationship

between Device and Network.

Next to this special case, another generalization will be made when connecting the Goal

dimension in ArchiMate specified by the Motivation Extension with the Human Actor specified

by Business Actor or Stakeholder. As ArchiMate prescribes, Stakeholder has a direct relation

with Motivational elements while this relationship with Business actor is indirect. Enhancing

the simplicity of our model. We will assume that also a direct relation between Business Actor

and a Motivational element is possible. Besides the generalization in the motivation extension,

another generalization will be made in the Technology Layer. ArchiMate prescribes System

Software and Device as a specialization of the Node concept, which results in Node as a

25

gateway towards System Software and Device. Enhancing the simplicity of our mapping, we

assume that the same relationships of Node with different ArchiMate concepts can also occur

between the specialization concepts of Node.

2.3 Mapping analysis

Given the purpose of this master dissertation to contribute with a formal translation of a

CHOOSE model with all concepts and relationships to an appropriate ArchiMate model and

vice versa, we analyze the proposed mapping as described above. First the analysis will be

performed on the mapping from CHOOSE to ArchiMate and afterwards from ArchiMate to

CHOOSE. The performed mapping analysis will be based on (Wand and Weber 1993). Wand

and Weber ((Wand and Weber 1993) state that for a grammar to be ontologically expressive,

the mapping between constructs of two reference modeling grammars should be identical.

The theory identifies four types of ontological deficiencies of a modeling languages originated

from a lack of similarity in the mapping of a modeling grammar constructs to another(Recker,

Rosemann et al. 2011).

Constructs in two modeling languages may or may not correspond. Without correspondence,

the two modeling languages may only be partly connected while only total correspondence

results in a strong relationship and interaction of both modeling languages (Wang, Chen et al.

2005). Different kind of correspondences can occur and are characterized by the mapping

cardinality: one-to-one (1-1), one-to-many (1-N) and many-to-one (N-1). Respectively, in an

one-to-one mapping, one construct of modeling language A corresponds to one construct in

modeling language B, it needs only, according to semantic corresponding relationship, to

correspond a source construct of modeling language A to relative attribute of destined

construct of modeling language B. One-to-many mapping relates to the correspondence of a

source construct of modeling language A with two or more destined constructs of modeling

language B. Finally, the many-to-one mapping relates to the correspondence of two or more

constructs of a source modeling language with only one construct of another modeling

language. In line with these cardinalities and the fact that a construct of a source modeling

language can’t be mapped on the other modeling language (Fettke and Loos 2003), (Wand and

Weber 1993) described four ontological deficiencies.

26

• Incompleteness: Can each construct from the source modeling language A be mapped

on a construct from the modeling language B? If this is not the case, the mapping is

not defined in total and hence incomplete. (1-0 mapping).

• Redundancy: Are the constructs of the source modeling language A mapped onto

exactly one construct in the source modeling language B or is it mapped onto more

than one construct? If there are such constructs, the mapping is redundant and

ambiguous. (1-N mapping).

• Excess: Can each construct of modeling language A be mapped on a construct of

modeling language B? If there is one construct in modeling language B without a

mapping on a construct of modeling language A, the mapping is excessive. (0-1

mapping).

• Overload: Can each construct of modeling language A be mapped on exactly one or

more constructs of modeling language B. The mapping is overloaded if any modeling

language B construct has more than one mapping to a modeling language A construct.

(N-1 mapping).

Incompleteness is a major issue for the mapping as it means that the mapping can’t be 100%

performed. Redundancy, excess or overload in the mapping will be inherent to the level of

abstraction of both modeling languages. In the following part, for both mapping directions,

the mapping analysis will be performed based on these four ontological deficiencies.

2.3.1 CHOOSE to ArchiMate

Incompleteness

Concerning the completeness of our mapping, we can conclude that our mapping is nearly

complete as for every CHOOSE element a counterpart can be found in ArchiMate. Only for the

supervision relationship in CHOOSE, no ArchiMate relationship was found that expresses the

same meaning. Nevertheless, supervision was translated on the general relationship in

ArchiMate: Association.

Redundancy

The second deficiency concerns the redundancy of the mapping, it occurs when one element

of the source modeling language can be mapped on two or more elements of the resulting

modeling language. When looking at the mapping from CHOOSE to ArchiMate, there is a lot of

27

redundancy present. The reason behind the redundancy can be found in the different level of

abstraction both modeling languages describe. CHOOSE is characterized by a rather limited set

of elements while ArchiMate is defined by a richer number of EA elements. More precise, the

redundancy in the mapping from CHOOSE to ArchiMate can be found for every CHOOSE

concept except: Human actor, Project and Device. Redundancy is also present in the

relationship mapping from CHOOSE to ArchiMate as operationalization, monitoring, control,

includes, input, output and association have more than one equivalent in ArchiMate.

When redundancy occurs, the architect will have to make choices to map the CHOOSE element

to the right ArchiMate element. Extra information will be needed from the architect, as he

possesses the necessary insights on the enterprise architecture of the organization. Following

the developed guidelines, the architect will be able to choose the suitable ArchiMate element.

Excess

The third deficiency considers the impossible mapping of ArchiMate elements on CHOOSE

elements. We already stated that ArchiMate is a more elaborated EA modeling language than

CHOOSE. Therefore excess elements are imaginable. However, a lot of ArchiMate elements

map on the same CHOOSE element, which means that only a few ArchiMate excess elements

are present. First, considering the business layer in ArchiMate, no CHOOSE concept was found

for Business Event, Meaning and Value. Respectively, for Business event, no CHOOSE concept

was found as the nature of CHOOSE only includes the possibility to model a process overview.

Inherent with this nature of CHOOSE, also Flow, Triggering and Junction relationship are excess.

Besides, ArchiMate’s concepts Meaning and Value are excess as both provide information

inherent with other ArchiMate concepts. In CHOOSE these information will be incorporated in

the description of those concepts rather that see it as a separate concept. Apart from the

business layer, excess elements are found in the two extensions of ArchiMate. Within the

Motivation extension, Driver and Assessment are excess as both concepts differ too much from

the Goal concept in CHOOSE. The second ArchiMate extension: Implementation and Migration

extension is characterized by two excess elements i.e. Gap and Deliverable as CHOOSE doesn’t

support implementation and migration. Finally, ArchiMate’s Grouping relationship is excess.

The occurrence of excess elements will not affect the completeness of the mapping from

ArchiMate to CHOOSE hence the purpose of the CHOOSE approach is narrower than the one

of ArchiMate. It is CHOOSE purpose to provide a simple approach for SMEs in modeling their

enterprise architecture. As the key is a simple and concise approach, not all ArchiMate

elements are supported. When translating ArchiMate models to a CHOOSE model, the solution

28

could be to first delete the excess concepts from the ArchiMate model previous to process the

translation to a CHOOSE model.

Overload

The final deficiency that will be tested in the mapping analysis is overload. Since CHOOSE only

captures the essential EA elements, only a few overload is expected. The ArchiMate concepts

that are causing overload are: Business Actor, Node, Goal, Principle, Requirement, and

Constraint. Firstly, Business Actor causes overload since the CHOOSE metamodel makes a

distinction between the general concept Actor and a Human Actor, in order to make a

distinction between organizational entities and employees within the organization. Secondly,

CHOOSE doesn’t support the Node concept, since only the specialization concepts of Node are

present, the selection need to be made between Software Actor and Device. The greater part

of the overload is found in the motivation extension as CHOOSE strongly supports goal trees,

the ArchiMate concepts Goal, Principle, Requirement and Constraint can map on both Goal

and Refinement concept in CHOOSE. The overload of concepts can cause problems when

translating ArchiMate models to an appropriate CHOOSE model. The guidelines developed

previously will guide the architect in facing these issues. Besides the concepts, a lot of overload

is present in the relationships since ArchiMate uses the same relationships between different

concepts. The only ArchiMate relationships that don’t cause any overload are composition,

specialization and influence. If looking into detail, only one ArchiMate relationship will cause

ambiguity when translating ArchiMate models to an appropriate CHOOSE model. Used by will

cause issues as CHOOSE makes an extra distinction between using an object without changing

(Monitoring) and creating and/or transforming (Control) while ArchiMate does not. Overload

doesn’t cause any issues when mapping from CHOOSE to ArchiMate, only when the mapping

is performed the other way around, choices will need to be made according to the developed

guidelines, to cope with these overloaded concepts and relationships.

2.3.2 ArchiMate to CHOOSE

The second mapping analysis concerns the mapping from ArchiMate to CHOOSE, as the

mapping is the opposite of the mapping from CHOOSE to ArchiMate, the mapping analysis will

be the inverse of the previous analysis. Consequently, incompleteness will be the inverse of

excess defined in the previous mapping analysis, and redundancy the inverse of overload.

29

Therefore, the mapping analysis will not be described in detail and can be found in the previous

section.

30

3. Mapping validation - case study

3.1 Introduction

Now the mapping is defined and the guidelines are developed, they will be validated using a

real-life model. The model that will be used is one of a tire-company modeled in the CHOOSE

tool developed by (Zutterman 2013). The first step of the validation concerns the translation

of the CHOOSE model to an appropriate ArchiMate model. Performing this translation, the

roadmap-method, used to describe the CHOOSE method (Bernaert et al. 2013) will be applied

to guide the architect towards the appropriate ArchiMate model. The roadmap-method

consists out of six consecutive steps. In the first step, the highest-level goals are mapped out

after which the second step breaks the higher-level goals down into lower-level goals. The

third step specifies the Actor dimension, the roles and human actors are added through

interviewing second sources. The fourth step determines the underlying operations related to

the satisfaction of the goals using the Porter’s Value Chain, the operations are discovered and

linked to the other two dimensions i.e. Goals and Actors. In the fifth dimension the objects and

corresponding relationships with goals are added to the model after which the entire model is

validated in the final step (Bernaert et al. 2013). In the second step of the validation, the

obtained ArchiMate model that mainly focuses on the business layer will be elaborated with

concepts in the application and technology layer. Followed by, the opposite translation of the

elaborated ArchiMate model back to an appropriate CHOOSE model.

3.2 CHOOSE to ArchiMate

The CHOOSE model that will be used for the translation is a simplified enterprise architecture

model of a tire-company Fig.12. As it has been developed in the CHOOSE syntax, we are able

to distinguish the goals (yellow), the actors (red), the objects (green) and processes (blue).

Hence, this distinction will be used when applying the roadmap-method. As the roadmap-

method describes, we first translate the high-level goals after which those will be broken down

into lower level goals. Secondly, after all the goals are defined, the actors will be translated

and linked to the goals. Followed by the processes that will be translated and the objects.

Finally, All four dimensions will be linked to each other after which the obtained ArchiMate

model will be validated.

31

Fig.12 Initial CHOOSE metamodel of a tire company

32

3.2.1 The roadmap-method

3.2.1.1 Translation of high-level goals

As the roadmap-method prescribes, we first need to translate the high-level goals from

CHOOSE to ArchiMate. The high-level goals present in our model are: Increase profitability and

Permanent innovation. These CHOOSE concepts will be translated according to the mapping

guidelines defined in this paper. Respectively, the CHOOSE high-level goals are translated on

the Goal concepts in ArchiMate hence these concepts prescribe end states. Fig.13 visualizes

the equivalent of the CHOOSE concepts in ArchiMate.

Fig.13 Translation High-level Goals

3.2.1.2 Brake down high-level goals into lower-level goals

Low-level goals in CHOOSE are defined by the refinement concept. In this step of the roadmap-

method, the refinement concepts are translated to their equivalent in ArchiMate. Following

the guidelines, the refinement concept in CHOOSE can be translated to the Goal, Principle,

Requirement, Constraint and Plateau concept in ArchiMate. As follows, respectively Increase

revenue, Decrease cost, Enhance payment system, Enhance purchase condition, Flatten out

seasonal effect, Attract new clients, Rent winter tires, Increase client retention, Order on time,

Enhance delivery agility + admin, Avoid out-of-stock winter tires, Fill shortages and Increase

interim presence are translated on the Goal concept in ArchiMate as they are part of the goal

tree but do not represent the means of the goal tree. Next, the lowest-level goals are

translated on the Requirement concept in ArchiMate i.e. Provide online platform, Provide

accurate forecast technique and work with min suppliers. Finally, the weather conditions

concept in the CHOOSE model restricts the concept Flatten out seasonal effect and is hence

translated on the Constraint concept in ArchiMate. A visualization of the three concept uses

as ArchiMate counterpart is shown in Fig.14.

33

Fig.14 Translation low-level goals

3.2.1.3 Translate the actor dimension

Translating the actor dimension from CHOOSE to ArchiMate, we were able to distinguish

different CHOOSE concepts within the actor dimension i.e. Actor, Human actor, Role, Software

actor and Device. Performing the translation, first the Actor concept will be translated. In our

model, only one Actor concept can be distinguished i.e. Reception as it represents an

organizational entity that is able to perform operations. Hence, the CHOOSE Actor concept

Reception is translated on the Business actor concept Reception in ArchiMate. Secondly, the

CHOOSE Human actor concept is translated, as there is only one choice available, the Human

actor concepts Christophe, Didier, Tom, Carl, Staff member and Client are translated on the

Business actor concept in ArchiMate. The third concept possible in the actor dimension in

CHOOSE is Role. In our model example, the Role concept is used twice, for Board and

Receptionist. As Board represents an entity only with interests in the company and do not take

part in any operations, Board is translated on the Stakeholder concept in ArchiMate. Next, the

CHOOSE concept Receptionist represents a role that can be performed by a human actor and

is therefore translated to a Business role concept in ArchiMate. Finally, two kind of concepts

rest in our model i.e. Automated invoice system and Scanner. As these concepts respectively

34

represent Software actor and Device in CHOOSE, they incorporate the second and third layer

in ArchiMate and are hence translated on the ArchiMate concept Application Component and

Device. Fig.15 visualizes an example for each concept translation.

Fig.15 Translation Actor dimension

3.2.1.4. Translation the underlying operation dimension

Step four consists of adding the underlying operations satisfying the goals. Within the

operation dimension different types of concepts can be distinguished. The concepts present

in our CHOOSE model are: Operation, Process and Project. Translating the concepts in the

operation dimension, we notice that the operation concept will always be specialized in either

Process or Project in CHOOSE. Hence, only the guidelines developed for Process and Project

will be followed. In our CHOOSE model four Operation concepts can be distinguished i.e.

Search for innovation on Internet, Go to innovation fairs, Work scheduling and Employee

planning. As prescribed, the guidelines for Process and Project are followed to translate these

35

concepts. Consequently, all Operation concepts can be translated on a Process concept in

ArchiMate as no specific knowledge is required for a certain operation (Function) or is

performed by a Collaboration (Interaction). Following, the Process concepts defined in our

CHOOSE model: Manage social media, Interim request, Change tires, Payment and Siping

process are all translated on the Business process concept in ArchiMate as these processes are

associated with a Business Actor concept in ArchiMate. The final CHOOSE concept specified in

the operation dimension of our CHOOSE model is project. As this concept specifies a temporary

endeavor, it links the core of ArchiMate to the Implementation and migration extension.

Hence, Lean management is translated to the Work package in ArchiMate present in the

Implementation and migration extension.

Fig.16 Translation Operation dimension

3.2.1.5. Translation the defined objects

The final dimension that should be added to the ArchiMate model is the object dimension.

When translating the objects dimension from CHOOSE to ArchiMate, we notice that in our

model the object dimension is specified by only one concept: Entity concept, as the definition

36

of the CHOOSE concept Entity is quite general. Hence, extra information will be needed from

the architect to properly translate the CHOOSE object dimension to ArchiMate. Obtaining the

extra information, the guidelines will be followed. As a result, the different CHOOSE Entity

concepts: Tire insurance, 24/7 service, Mobile tire changing unit, Call center, Paper contract,

Rim adjustment bank Facebook page, Train pass, Siping machine and Interim agreement are

translated on their equivalent in ArchiMate. The most general counterpart defined in

ArchiMate for the CHOOSE Entity concept is Business object as the definition states a business

object represents something that is important for the business. Hence, the major part of the

Entity concepts in our model are translated on this concepts i.e. Rim adjustment bank,

Facebook page, Train pass, Siping machine and Interim agreement. The other Entity concepts

present in our CHOOSE model define a more specific object in ArchiMate. Respectively, Tire

insurance defines a Product that can be sold to the clients and covers a range of services. Hence,

Entity concept Tire insurance is translated on the Product concept in ArchiMate and covers the

Business services: 24/7 service and Mobile tire changing unit. The final two Entity concepts

present in our CHOOSE model are Call center and Paper contract. Call center defines a point of

access to a service, here 24/7 service. Consequently, Call center is translated on the Business

interface concept in ArchiMate. Next, Paper contract defines the nature in which a contract

occurs in our business. In our business a contract occurs in the form of a paper, a page. As a

result, Paper contract represent the form of an interim agreement and is translated on the

Representation concept in ArchiMate. Fig.17 visualizes the different CHOOSE representations

with their equivalent in ArchiMate.

37

Fig.17 Translation Object dimension

3.2.1.6. Connect all concepts and validate general model

The final step consists out of relating all translated concepts and finally validating the obtained

model. As the relationships connecting concepts are inherent to those concepts, we only need

to follow the grid that prescribes in detail every possible relationship between ArchiMate

concepts for each possible relationship defined in CHOOSE. As a result, the following model in

ArchiMate is obtained Fig.18.

38

Fig.18 Translation result: ArchiMate model

39

3.2.2 Translation analysis

Now the different steps of the roadmap method are completed, the final ArchiMate model is

obtained. This enables to compare both models in finding differences as well as similarities.

The first conclusion that can be drawn is that both models are visually quite similar, the same

four quadrants i.e. Motivational, Passive, Behavior and Active can be distinguished. The reason

can be found in the nature of the CHOOSE language, as it was developed keeping the structure

of ArchiMate in mind(Bernaert, Poels et al. 2013). Looking more at the concepts than the

holistic overview both models provide, it is clear that CHOOSE is more abstract than ArchiMate

as ArchiMate provides more detail than the CHOOSE language. Especially in the object

dimension the level of abstraction of CHOOSE is clearly noticeable hence only Entity is used as

a concept. Relating Entity as the general object dimension concept in CHOOSE, with the

equivalents in ArchiMate, Entity can be mapped on 16 different concepts in ArchiMate and 7

concepts if only a mapping to the business layer is assumed. Hence the difference in the

number of concepts, extra information from the architect will be obtained in performing the

most accurate mapping. Besides the level of detail ArchiMate provides, ArchiMate copes with

issues regarding the possibility of a drill-down function when establishing a goal tree. Hence,

the mapping doesn’t completely holds when the OR-refinement is being used as a relationship

within the goal tree. In the other case, when AND-refinement is used, the aggregation

relationship in ArchiMate is sufficient to provide us an accurate goal drill-down.

3.3 ArchiMate to CHOOSE

Consistent with the first step of the validation, the second step will validate the mapping from

ArchiMate to CHOOSE. For the analysis, the obtained ArchiMate model that resulted out of

the previous mapping will be used. Important in this stage is to map an extended ArchiMate

model as the strength of ArchiMate can be found in the presence of three layers i.e. Business

layer, Application layer and Technology layer. As the current model mainly focuses on the

business layer instead of the three layers, the ArchiMate model of the tire company will be

extended with appropriate concepts and their relations in the Application layer and

Technology layer. Fig.19 visualizes the result of the extended model of the tire company in

ArchiMate.

40

Fig.19 Extended ArchiMate model

41

3.3.1 The roadmap-method

Consistent with the guidelines developed and present in Appendix B, the ArchiMate model can

be translated to his equivalent in CHOOSE. The same working method as in the first step will

be applied. Following the different steps present in the roadmap-method, respectively the

high-level goals, low-level goals, actor dimension, operation dimension and object dimension

will be translated. Finally, the concepts will be connected by the appropriate relationships. As

this mapping direction is characterized by 1-1 mapping cardinality, and no extra information is

needed by the architect to perform the translation, the translation can be automated.

Therefore, the translation process will not be provided in detail and the derived CHOOSE

model is shown in Fig.20.

42

Fig.20 Translation result: CHOOSE model

43

3.3.2 Translation analysis

The initial ArchiMate model and its resulting CHOOSE model after translation, permits to

compare and conclude differences as similarities. The conclusion can be drawn that the

mapping holds when translating small-scale models. When mapping large-scale models, the

mapping from ArchiMate to CHOOSE will affect one of the key purposes of EA: providing a

holistic overview. The reason behind this is the fact that CHOOSE is more abstract than

ArchiMate and lacks the distinction ArchiMate makes concerning the three layers: Business

layer, Application and Technology layer. As the mapping affects the main characteristic of EA,

the restriction will be made that only the business layer and motivation extension will be

translated to CHOOSE so the simplicity can be preserved. The restriction is supported by the

main purposes the business architect has to translate his ArchiMate model to a CHOOSE model.

The first purpose can be found in the fact that business experts want to be involved in EA

modeling, as business experts face issues when involving in EA according to a lack of IT

experience, business experts need a simpler approach that mainly focuses on the business

aspect of an organization. Hence, only the business layer of the ArchiMate model tends to be

relevant to perform the translation. The second purpose of translation an ArchiMate model to

a CHOOSE model is when organizations choose to focus more on their core businesses rather

than the supporting businesses. Therefore, they will opt to outsource these businesses. As a

result, these organizations don’t benefit anymore from an elaborated EA modeling language

and will prefer to use an EA modeling language that models their core businesses. Where

CHOOSE can be the solution, the remained concepts of the ArchiMate model will need to be

translated to new EA modeling language. Respectively, only the concepts present in the

business layer and motivation extension will bring value to the organization’s enterprise

architecture and will be translated accordingly. Fig.21 shows the translation of the ArchiMate

model to the CHOOSE model taking the restriction into account.

44

Fig.21 Restricted CHOOSE model

45

4. Conclusion

This master dissertation described why organizations using CHOOSE could benefit from using

a more elaborated modeling language as ArchiMate. After the problem was framed within the

topic of information management, CHOOSE and ArchiMate as an EA modeling standard were

explained in finding similarities that would enhance the mapping process. We defined the

problem and the limitations inherent with the CHOOSE metamodel in modeling the IT

architecture of an organization. When SMEs encounter continuous growth, the limitations

become visible and CHOOSE thwarts the organization in modeling their total enterprise

architecture. As a result, the SMEs could benefit from a more elaborated EA modeling language

i.e. a translation of the CHOOSE model to a new elaborated model. The opposite situation,

where organization could benefit from a simpler approach is also probable. Here, the

elaborated model will need to be translated to an appropriate CHOOSE model. Supporting

these two translation direction, the mapping between CHOOSE and ArchiMate, as a standard

for EA modeling was described. Moreover, where redundancy and overload were present,

necessary guidelines are presented in supporting the translation process. Further, the mapping

process and developed guidelines were validated using a real-life model.

We can conclude that when CHOOSE models are translated to ArchiMate, the translation holds

and is nearly complete. The only difficulty faced during the mapping concerns the goal drill-

down function CHOOSE possesses, which ArchiMate only poorly supports. Mapping ArchiMate

models to CHOOSE, we conclude that apart from the overload, the simplicity is affected when

large ArchiMate models were translated. This was a result of the fact that CHOOSE’s

metamodel is a small, essential set of elements that is opposed to ArchiMate’s richness of EA

elements. As the translation is comprehensive for small-scale models, we restrict the

translation only to the business layer and motivation extension when translating extended

ArchiMate models. The restriction is supported by the occurrence of the translation. Hence

organization will mainly opt for a translation from ArchiMate to CHOOSE when they want to

involve business experts with little IT knowledge or when they want to limit their enterprise

architecture to the core business and no IT modeling concepts are needed.

46

5. Future research

For future research, the next step could be the extension of the CHOOSE concepts that would

enable an automatic translations of CHOOSE models to ArchiMate models. The current mapping

is characterized by a lot of redundancy. Here, the guidelines provide a solution in accurate

translating those models. Currently, the translation process is only manually available, so the

architect is responsible for the decision in choosing the most suitable element from the mapping

option. Additional attributes with information about a concept could provide the solution. The

extension of CHOOSE with extra attributes would serve as a reference for future translation

towards ArchiMate, such that automatic translation becomes possible. In order to automatically

transform models, the model transformation need to be maintained according to changing

requirements as it needs to be reused. Therefore, when extending CHOOSE, the quality of the

model transformation needs to be assessed according to quality standards(van Amstel and van

den Brand 2010).

Next to the extension of the CHOOSE concepts, the CHOOSE modeling tool need to be completed.

An additional feature that needs to be incorporated in the tool is the support of an automatic

translation of a CHOOSE model to an appropriate ArchiMate. Supporting this feature, ATL could

be used to directly translate between both models(Jouault, Allilaire et al. 2006).

47

References

Ambler, S. W. (2002). "Agile Enterprise Architecture: Beyond Enterprise Data Modeling." from http://www.agiledata.org/essays/enterpriseArchitecture.html.

Bernaert, M. (2011). "De zoektocht naar know-how, know-why, know-what en know-who." Tijdschrift informatie 53: 34-41.

Bernaert, M. and G. Poels (2012). "Enterprise architecture for small and medium-sized enterprises." 7TH SIKS Conference on Enterprise Information Systems (EIS-2012).

Bernaert, M., et al. (2013). "CHOOSE: towards a metamodel for enterprise architecture in small and medium-sized enterprises." Information Systems Frontiers: 1-38.

Bernaert, M., et al. (2014). Enterprise architecture for small and medium-sized enterprises: a starting point for bringing EA to SMEs, based on adoption models. Information Systems for Small and Medium-sized Enterprises, Springer Berlin Heidelberg: 67-96.

Braun, C. and R. Winter (2005). "A comprehensive enterprise architecture metamodel and its implementation using a metamodeling platform." Desel, Jörg; Frank, Ulrich: 24-25.

Fettke, P. and P. Loos (2003). "Ontological evaluation of reference models using the Bunge-Wand-Weber model." AMCIS 2003 Proceedings: 384.

Franke, U., et al. (2009). EAF2-a framework for categorizing enterprise architecture frameworks. Software Engineering, Artificial Intelligences, Networking and Parallel/Distributed Computing, 2009. SNPD'09. 10th ACIS International Conference on, IEEE.

Girish J. Bakshi & Dr, D. J. P. (2014). "A way forward for indian SMEs - through organisational growth." Global journal of commerce & management perspective 3(4): 137-141.

Henderson, J. C. and N. Venkatraman (1993). "Strategic alignment: Leveraging information technology for transforming organizations." IBM Systems Journal 32(1): 4-16.

Iacob, M., et al. (2012). "Archimate 2.0 specification: The open group."

Jonkers, H., et al. (2006). "Enterprise architecture: Management tool and blueprint for the organisation." Information Systems Frontiers 8(2): 63-66.

Jouault, F., et al. (2006). ATL: a QVT-like transformation language. Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, ACM.

48

http://www.agiledata.org/essays/enterpriseArchitecture.html

Lankhorst, M. (2009). Communication of Enterprise Architectures. Enterprise Architecture at Work, Springer Berlin Heidelberg: 69-84.

Lopes, D., et al. (2006). Mapping specification in MDA: From theory to practice. Interoperability of Enterprise Software and Applications, Springer: 253-264.

Maes, R. (2007). "An integrative perspective on information management." Information Management: setting the scene: 11-26.

Maes, R., et al. (2000). Redefining business: IT alignment through a unified framework, Universiteit van Amsterdam, Department of Accountancy & Information Management.

Pereira, C. M. and P. Sousa (2004). A method to define an Enterprise Architecture using the Zachman Framework. Proceedings of the 2004 ACM symposium on Applied computing, ACM.

Pereira, C. M. and P. Sousa (2005). Enterprise architecture: business and IT alignment. Proceedings of the 2005 ACM symposium on Applied computing. Santa Fe, New Mexico, ACM: 1344-1345.

Recker, J., et al. (2011). "Do ontological deficiencies in modeling grammars matter?" MIS Quarterly 35(1): 57-79.

Ross, J. W., et al. (2006). Enterprise architecture as strategy: Creating a foundation for business execution, Harvard Business Press.

Society, I. C. (2000). "IEEE Recommended Practice for Architectural Description of Software Intensive Systems." IEEE Standard.

van Amstel, M. F. and M. van den Brand (2010). Quality assessment of ATL model transformations using metrics. Proceedings of the 2nd International Workshop on Model Transformation with ATL (MtATL 2010), Malaga, Spain (June 2010).

Wand, Y. and R. Weber (1993). "On the ontological expressiveness of information systems analysis and design grammars." Information Systems Journal 3(4): 217-237.

Wang, C.-B., et al. (2005). "Design of a Meta Model for integrating enterprise systems." Computers in Industry 56(3): 305-322.

Zachman, J. (2006). The zachman framework for enterprise architecture, Zachman Framework Associates.

Zivkovic, S., et al. (2007). Facilitate Modelling Using Method Integration: An Approach Using Mappings and Integration Rules. ECIS.

49

Zutterman, S. (2013). Development of a Tool for Business Architecture Modeling in Eclipse, Ghent University.

50

APPENDIX

APPENDIX A

The grid below shows the mapping from CHOOSE to ArchiMate. For every CHOOSE concept, every ArchiMate concept within the different layers is visualized. Additionally, the mapping of the relationships and the developed guidelines are present.

Table 4: Mapping grid from CHOOSE to ArchiMate

CHOOSE CONCEPT

ArchiMate CONCEPTS Guidelines ArchiMate

Business

ArchiMate Motivation Extension

ArchiMate Application

ArchiMate Technology

Implementation and Migration

layer Cross-layer Cross-layer

Object Type Business-Application

Application-Technology

Goal

Goal, Principle,

Requirement, Constraint

Goal defines an end state, where qualitative words

are used. For ex. Improve or easier.

Goal

Goal defines general property, a guideline to realize the high-level

goal Principle

low-level goal that

satisfies the end state. Requirement Goal defines a restriction to which high-level goal

is achieved Constraint

Refinement

Goal, Principle,

Requirement, Constraint,

Plateau

Goal

Requirement

51

Principle Constraint Plateau

Actor Business actor Business Actor

Human Actor Business actor Business Actor

Role

Business Role, Business

Collaboration, Stakeholder

single role Business Role

2+ roles work together Business

Collaboration

Stakeholder

Operation Specialized in either process

or project

Process

Business Process, Business Function, Business

Interaction, Application Function,

Application Interaction,


Default Business Process Application

Function Infrastructure

Function

Process stresses criteria needed to produce set of

products

Business Function Application

Interaction

Only when process specifies behavior of a business collaboration

Business Interaction

Project Work Package Work Package

Object Specialized into Entity

Entity

Business Interface, Location, Business Object,

Models access to business service

Business Interface Application

Interface Network

Entity states a physical point where business

actors, application Location Data Object Communicati

on Path

52

Business Service,

Representation, Product, Contract,

Application Interface,

Data Object, Application

Service, Network,

Communication Path,

Infrastructure Interface,

Infrastructure Service, Artifact,

Delivarable

components and devices are reside.

Entity represent imformation that is important for the

business.

Business Object Application

Service Infrastructure

Interface

Entity exposes functionality of Role to

the environment.

Business Service Infrastructure

Service

Entity represents information carried by a

Business object.

Representation Artifact

Entity represents collections of business

services Product

Entity specifies rights and obligations

associated with a Product Contract

Fact Type

OR-Ref Realization

Motivational element -

Motivational element

AND-Ref Aggregation



Plateau -

ArchiMate element

Conflict Influence



Wish Association

Stakeholder - Motivational

element

Assignment Association

Active Structure -


Operationalization

Realization, Specialization

Requirement – ArchiMate

element

53

Concern Realization

Division Aggregation

Business Actor/Business Role - Business

collaboration

Application Component-Application Collaboratio

n

Supervision Association

Performs Assignment

Business actor -

Business role

Business Actor-

Stakeholder

System software-Device

Specialization Specialization

Performance (RACI) Assignment

Business Role -

Business Process/

Function/Interaction

Application Component-Application

Function/Interaction

System Software/Devic

e - Infrastructure

Function

Business process/function/Interaction-Application Component;

Location-Application Component;

Node-Location

Monitoring Used by,

Assignment, Association

Business Actor/Role -

Business Service/Busi

ness Interface


Service/Interface

Business Actor/role-Application

Service/Interface; Business role - Work

package

Location-Business

Actor Node-Location

Device-Network

Control Used by, Realization

Business Actor/Role -

Business


Business

Actor/role-Application

54

Service/Business

Interface

Service/Interface

Service/Interface

Artifact-System Software

Includes Aggregation, Composition

If suboperation can be part of more than one

superoperation

Suboperation can be part

of +1 superoperati

on

If suboperation can be part of only one superoperation

Suboperation can be part of only one superoperati

on

Input Access, Used by

Process/Function/Inter

action-Business

object

Application Function/Interaction-Data

object

Infrastructure function-Artifact

Business Process/Function/Inter

action -Business Service

Application Function/Inte

raction- Application

service

Infrastructure Function/Softw

are System/Device-Infrastructure

Service; Software

System/Device - Infrastructure

Interface

Business Process/Function/Interacti

on-Applicition

Service

Output Access, Realization

Business object-


action

Application Service/Function/Interacti

on-Data object


Business Service-Business


action


Application Function/Inte

raction

Infrastructure Service-


55

Association Access,

Realization, Assignment

Business Service-Business Object

Application service-Data

object

Infrastructure service-Artifact

Representation-

Business object

Communication path-Network

Business object-Data

object

Location-Business

object/Representation; Business service-Business Interface


Application Interface

Infrastructure service-

Infrastructure Interface;

System Software/Devic

e - Artifact

Location-Application

Service/Interface/Work package

Location-Artifact/Network/Communication

path

Aggregation Aggregation

Product - Business

Service/Contract

Location-Data object; Application

service-Product

Product-Infrastructure

service

Specialization Specialization Business object -

Contract

EXTRA CHOOSE CONCEPTS

Software Actor

Application Component, Application

Collaboration, System Software

Software actor refers to applications supporting

the business Application

Component

Software Actor is collection of application

components

Application Collaboratio

n

Focuses only on software component supporting

the organization's applications.

System Software

Device Device Device

56

APPENDIX B

The figures below show the mappings of the ArchiMate concepts and relationships to their equivalent in CHOOSE. The architect is able to perform his translation using the figures or the grid provided in Appendix B.2.

Appendix B.1.

57

Fig.22 ArchiMate’s Application Layer metamodel (Iacob, Jonkers et al. 2012)

58

Fig.23 ArchiMate’s Technology Layer metamodel (Iacob, Jonkers et al. 2012)

59

Fig.24 Relationships between ArchiMate’s Business Layer and Lower Layer metamodel concepts (Iacob, Jonkers et al. 2012)

60

Fig.25 Relationships between ArchiMate’s Application Layer and Technology Layer metamodel concepts (Iacob, Jonkers et al. 2012)

61

Appendix B.2.

Table 5: Mapping grid from ArchiMate to CHOOSE

ArchiMate CONCEPT

CHOOSE CONCEPTS ArchiMate Business ArchiMate Motivation Extensioin ArchiMate Application ArchiMate

Technology

Implementation and Migration

layer Business layer

Business Actor Actor/Human Actor

Business Role Role Business

Collaboration Role Business Interface Entity Location Entity

Business Object Entity Business Process Process Business Function Process Business

Interaction Process Business Event --

Business Service Entity

Representation Entity Meaning --

Value -- Product Entity Contract Entity

Motivation Extension

62

Stakeholder Role Driver --

Assessment -- Goal Goal

Requirement Goal Constraint Goal Principle Goal

Application layer

Application Component Software actor Application

Collaboration Software Actor Application

Interface Entity Data Object Entity Application

Function Process Application Interaction Process Application

Service Entity Technology

layer

Node Software

Actor/Device Device Device

Network Entity Communication

Path Entity Infrastructure

Interface Entity System

Software Software Actor Infrastructure

Function Process Infrastructure

Service Entity

63

Artifact Entity Implementation and Migration

extension

Work Package Project

Deliverable -- Plateau Refinement

Gap -- Fact Type

Association

Wish Stakeholder - Motivational

element

Assignment Active Structure -


Supervision

Monitoring Communication Path-Node; Device-Network

Access

Output

Business object-Process/Function/Interaction

Application Service/Function/Interaction-

Data object


Association Business Service-Business

Object Application service-Data object Infrastructure service-

Artifact

Used by

Monitoring Active Structure - Business Service/Business Interface

Application Component-Application Service/Interface

Node-Infrastructure Interface/Infrastructure

Service Work package - Business role

Control Active Structure - Business Service/Business Interface

Application Component-Application Service/Interface

Node-Infrastructure Interface/Infrastructure

Service

Input

Business Process/Function/Interaction

-Business Service

Application Function/Interaction/Component-

Application service

Infrastructure Function-

Infrastructure Service

Realization

Operationalization

Concern

Control Artifact-System

Software

64

Output Business Service-Business

Process/Function/Interaction Application Service-Application

Function/Interaction Infrastructure Service-Infrastructure Function

Association Representation-Business

object Communication path-

Network

Assignment

Performs

Business Actor-Stakeholder, Business actor - Business

role System software-

Device

Performance

Business Role - Business Process/

Function/Interaction Application Component-

Application Function/Interaction Infrastructure Function-Node

Monitoring Location-Business Actor

Association

Location-Business object/Representation;

Business service-Business Interface

Application Service-Application Interface

Infrastructure service-Infrastructure Interface

Work package - Location

Aggregation

division

Business Actor/Business Role - Business collaboration

Application Component-Application Collaboration

Includes Suboperation can be part of

+1 superoperation

Aggregation Product - Business Service/Contract

Composition Includes Suboperation can be part of

only one superoperation

Flow --

Triggering --

Grouping --

Junction --

Specialization Specialization Business object - Contract Node-Device/System

Software

Aggregation AND-Ref Motivational element - Motivational

element

Plateau -ArchiMate

element

65

Realization OR-Ref Motivational element - Motivational

element

Influence Conflict Motivational element - Motivational

element

Business-Application alignment

Used by

Input

Business Process/Function/Interaction

- Application service

Monitoring/Control Business Actor/Role-Application Interface

Realization Association Business Object-Data object Application Component-Location

Assignment

Monitoring/Control Business Actor-Application

Service

Location-artifact/Data object/Node/Network/Communication

Path

Association Business Service-Application

Interface

Performance

Application Component - Business

Process/Function/Interaction

Aggregation Aggregation

Product-Infrastructure Service; Product-Application

Service Application-Technology Alignment

Used by

Monitoring/Control

Application Component-Infrastructure

Interface/Infrastructure Service

Output Application Function-Infrastructure Service

Realization

Association Data Object-Artifact

Monitoring/Control Application Component-

Artifact

66

Date post:	13-Apr-2018
Category:	Documents
Upload:	truongkhuong
View:	214 times
Download:	2 times

Developing guidelines to translate CHOOSE models into...

Documents