Enterprise Architecture Model Transformation

Exploring the possibilities to transform an architecture created by using the Integrated Architecture Framework approach into an ArchiMate architecture

i

Enterprise Architecture Model Transformation Exploring the possibilities to transform an architecture created using the Integrated Architecture Framework approach into an ArchiMate architecture

Location and date: Utrecht, 25 February 2009

Author: S.M. (Stein) Welberg University of Twente Student nr: 0063169 1st Supervisor University: Dr. M.E. (Maria) Iacob 2nd Supervisor University: Dr. P.A.T. (Pascal) van Eck Company supervisor: B. (Barry) de Vries Document: Master Thesis

ii

“Lasagne eet gemakkelijker dan spaghetti” (Eating Lasagne is easier than eating Spaghetti)

– Herman Hartman, 22 October 2008, Papendorpseweg, Utrecht

iii

Abstract During engagements by Capgemini, many architecture models are created. Each of them is unique, because of the influence of people, their way of interpreting the IAF (Integrated Architecture Framework), and the lack of a standard documentation approach. However, some engagements are homogenous, which create the possibility to reuse former work. Nevertheless, since many architects have a different modelling approach, they create different models of an architecture in general and reusability is greatly hindered. Therefore, Capgemini is looking for a way to create homogeneous models in order to facilitate reuse, shorten project life cycle, and create best practices.

One approach to homogenous models is the ArchiMate modelling language. This language is specifically created to model enterprise architectures. ArchiMate only provides a modelling language and not a process or methodology to guide the development of an architecture. Hence, Capgemini wants to know whether it is possible to visualise and document IAF architectures using ArchiMate models. Our approach is to transform IAF models into ArchiMate models to evaluate the possibilities to use ArchiMate as the modelling language for the IAF.

The research goal is to evaluate the possibilities to transform an architecture created using the IAF approach into an architecture using ArchiMate models for visualisation and documentation, by creating a mapping between IAF and ArchiMate based on a meta-model matching, identify the discrepancies, and provide recommendations on how to overcome the identified discrepancies.

Our first result is the mapping of IAF and ArchiMate, which we use to transform an IAF architecture into an ArchiMate one. The mapping consists of IAF and ArchiMate concepts that are semantically the same. Not all IAF concepts could be mapped onto an ArchiMate equivalent concept; this resulted in some problem areas.

The identified problem areas are the second result of this research. The IAF information aspect area concepts and IAF collaboration contracts could not be included into the mapping, since ArchiMate does not incorporate such concepts.

By proposing changes to ArchiMate, we have tried to overcome the identified problem areas. The possible solutions are the third result of this research. In order to cover the collaboration contract problem area, we suggested adding a business service contract, an information contract, and an application contract to ArchiMate. For the information aspect area problem, we suggested changing the ArchiMate business object definition and adding an information object and an information service to ArchiMate. These propositions resulted in an extended version of ArchiMate, which we called ArchiMate++.

To validate whether it is possible to transform an IAF architecture into an ArchiMate one, a survey was used. The models were transformed using the created mapping and, both standard ArchiMate and ArchiMate++ were used for the transformations. This resulted in a survey displaying a number of IAF models and their corresponding ArchiMate and ArchiMate++ variants.

From the survey results can be concluded that an IAF architecture cannot be transformed into a standard ArchiMate architecture. Nevertheless, with only a minor amount of adjustments to ArchiMate it becomes very well possible to transform an IAF architecture into ArchiMate within the scope of the IAF we took into consideration in this research project.

iv

Preface “Lassagne eet gemakkelijker dan Spaghetti” is what Herman Hartman wrote for a “Loesje” kaart at the Dutch National Architecture Conference 2008. It emphasizes that architecture facilitates structure and structure makes things easier. This research project is also about structure, both in the sense that I compared the structure (and meaning!) of IAF and ArchiMate and that structure kept the subject understandable for me.

When I started my master’s thesis project at Capgemini, I did not know neither what to expect of the research assignment nor what to expect from the work at Capgemini. Both turned out to be great.

The assignment was a challenge, for the assignment demanded a good understanding of the subject, which I did not have in the beginning. In addition, I never conducted such a large project all by myself... I experienced some trouble writing everything it all down in a comprehensible way, so other people can understand what I have written. However, many people have helped me during the seven months I took for conducting this research project.

The work at Capgemini inspired in what I want to do after my graduation. Both the assignment, especially the validation, and the many talks with Capgemini employees made me enthusiastic for the work conducted by Capgemini architects.

I could not have finished this thesis without the help of many people! I want to thank all the great colleagues at P30 who treated me as their equal and helped me whenever I had a question. I hope this continues in the future when we will be colleagues. Especially Herman Hartman did a great job in helping me in the beginning. Furthermore, I want to thank my fellow graduation students for the great lunches and laughs we had, this made the days seem a lot shorter! In addition, I want to thank my supervisors who provided me with the needed feedback and guidance. Pascal and Maria gave very good feedback and advice on my work and often responded very quickly to my emails and Barry, my Capgemini supervisor, often came with hands-on advice.

Finally, I want to thank my girlfriend, or actually fiancée, for her great moral support and her inexhaustible confidence in me!

Utrecht, 30 January 2009

Stein Welberg

v

Table of Contents

1 INTRODUCTION ....................................................................................................................................... 1

1.1 BACKGROUND ..................................................................................................................................... 1 1.2 RESEARCH GOAL ................................................................................................................................... 2 1.3 RESEARCH QUESTIONS ........................................................................................................................... 3 1.4 RESEARCH APPROACH ............................................................................................................................ 3 1.5 STRUCTURE OF THE THESIS ...................................................................................................................... 5

2 ENTERPRISE ARCHITECTURE .................................................................................................................... 6

2.1 WHAT IS ENTERPRISE ARCHITECTURE ........................................................................................................ 6 2.2 THE IAF (INTEGRATED ARCHITECTURE FRAMEWORK) .................................................................................... 8 2.3 ARCHIMATE...................................................................................................................................... 14

3 MAPPING APPROACH ............................................................................................................................ 20

3.1 CRITERIA .......................................................................................................................................... 20 3.2 MAPPING METHOD ............................................................................................................................. 26 3.3 METHOD FOR EVALUATING THE MAPPING ................................................................................................. 29 3.4 CONCLUSION ..................................................................................................................................... 30

4 BEST MAPPING ALTERNATIVE ............................................................................................................... 31

4.1 MAPPING OF THE CORE CONCEPTS .......................................................................................................... 31 4.2 MAPPING OF LAYER SPECIFIC IAF CONCEPTS ONTO ARCHIMATE CONCEPTS ....................................................... 33 4.3 MAPPING OF RELATIONS ...................................................................................................................... 47 4.4 BEST MAPPING ALTERNATIVE ................................................................................................................. 49 4.5 CONCLUSION ..................................................................................................................................... 50

5 MAPPING EVALUATION ......................................................................................................................... 51

5.1 EVALUATION MAPPING RESULTS ............................................................................................................. 51 5.2 PROBLEM AREAS ................................................................................................................................ 53 5.3 POSSIBLE SOLUTIONS ........................................................................................................................... 55 5.4 IMPROVED MAPPING ........................................................................................................................... 68 5.5 CONCLUSION ..................................................................................................................................... 69

6 VALIDATION .......................................................................................................................................... 71

6.1 THEORETICAL MODEL........................................................................................................................... 71 6.2 VALIDATION DESIGN ............................................................................................................................ 72 6.3 SURVEY APPROACH ............................................................................................................................. 74 6.4 RESULTS ........................................................................................................................................... 78 6.5 VALIDITY .......................................................................................................................................... 83 6.6 CONCLUSION ..................................................................................................................................... 84

7 CONCLUSIONS AND RECOMMENDATIONS ............................................................................................ 85

7.1 CONCLUSIONS ................................................................................................................................... 85 7.2 RECOMMENDATIONS ........................................................................................................................... 86 7.3 IMPLICATIONS.................................................................................................................................... 86 7.4 FUTURE WORK ................................................................................................................................... 87

8 REFERENCES .......................................................................................................................................... 89

APPENDIX A : SURVEY RESULTS DUTCH NATIONAL ARCHITECTURE CONGRESS (LAC) 2008 ............................ 91

vi

APPENDIX B : IAF CONCEPTS ........................................................................................................................ 100

APPENDIX C : ARCHIMATE CONCEPTS .......................................................................................................... 116

APPENDIX D : SUMMARY OF CRITERIA......................................................................................................... 128

APPENDIX E : MAPPING OF CONCEPTS IAF TO ARCHIMATE ......................................................................... 130

APPENDIX F : PROPOSED ARCHIMATE META MODEL ................................................................................... 131

APPENDIX G : UPDATED MAPPING IAF TO ARCHIMATE ............................................................................... 132

APPENDIX H : VALIDATION SURVEY ............................................................................................................. 133

vii

List of Figures FIGURE 1: POSITIONING OF IAF, ARCHIMATE AND TOGAF IN ENTERPRISE ARCHITECTURE ELEMENTS ......................................... 2 FIGURE 2: SOFTWARE ENGINEERING CYCLE (WIERINGA, 2007) ........................................................................................ 4 FIGURE 3: THEORETICAL MODEL ............................................................................................................................... 4 FIGURE 4: CATEGORIES OF EA FRAMEWORKS AND MODELS (WU, 2006) ............................................................................ 8 FIGURE 5: FOURTH REVISION OF THE INTEGRATED ARCHITECTURE FRAMEWORK.................................................................... 9 FIGURE 7: SAMPLE OF BUSINESS SERVICE INTERACTION MODEL ...................................................................................... 11 FIGURE 6: LEGEND IAF CONCEPTS ........................................................................................................................... 11 FIGURE 8: SAMPLE OF LOGICAL BUSINESS COMPONENT INTERACTION MODEL ................................................................... 12 FIGURE 9: SOLUTION ALTERNATIVES AND PRINCIPLES .................................................................................................... 12 FIGURE 10: GENERIC CONCEPTS IAF, EXTRACTED FROM: (HUC, 2006)............................................................................. 13 FIGURE 11: THE ARCHIMATE FRAMEWORK (SOURCE: IACOB ET AL. (2007)) ...................................................................... 15 FIGURE 12: ARCHIMATE EXAMPLE: LAYERED VIEW ...................................................................................................... 17 FIGURE 13: GENERIC CONCEPTS ARCHIMATE (SOURCE: (H. JONKERS ET AL., 2008, 2009) ................................................... 18 FIGURE 14: INCORPORATING DETAIL IN THE IAF .......................................................................................................... 23 FIGURE 15: ONTOLOGICAL ANALYSIS ACCORDING TO WEBER (1997) ............................................................................... 25 FIGURE 16: MDA META-LAYERS ............................................................................................................................ 27 FIGURE 17: POSSIBLE MODEL ADAPTATIONS .............................................................................................................. 28 FIGURE 18: BUSINESS INFORMATION SERVICE MAPPING ............................................................................................... 37 FIGURE 19: ARCHIMATE CONCEPTS BUSINESS LAYER.................................................................................................... 41 FIGURE 20: PATTERN MAP TO LOGICAL BUSINESS INFORMATION COMPONENT ................................................................... 42 FIGURE 21: COMPOSITION OF RELATIONSHIPS IN ARCHIMATE ........................................................................................ 47 FIGURE 22: IAF AREAS WHERE MAPS TO ARCHIMATE CONCEPTS EXIST ............................................................................. 55 FIGURE 23: EXAMPLE IAF BUSINESS SERVICE COLLABORATION CONTRACT ......................................................................... 56 FIGURE 24: PORTION OF PROPOSED ARCHIMATE META MODEL, FIRST SCENARIO ................................................................ 56 FIGURE 25: PRODUCT CONTRACT NOTATION .............................................................................................................. 57 FIGURE 26: EXAMPLE PRODUCT CONTRACT ................................................................................................................ 57 FIGURE 27: NOTATION BUSINESS SERVICE CONTRACT ................................................................................................... 58 FIGURE 28: EXAMPLE OF SERVICE CONTRACT ............................................................................................................. 59 FIGURE 29: NEW PROPOSED GENERIC ARCHIMATE META MODEL ................................................................................... 59 FIGURE 30: PORTION OF PROPOSED ARCHIMATE META MODEL, SECOND SCENARIO ............................................................ 60 FIGURE 31: NOTATION CONTRACT .......................................................................................................................... 60 FIGURE 32: EXAMPLE CONTRACT ............................................................................................................................ 60 FIGURE 33: INFORMATION OBJECT RELATIONS ............................................................................................................ 61 FIGURE 34: GROUPING OF INFORMATION OBJECTS INTO LOGICAL INFORMATION COMPONENTS............................................... 61 FIGURE 35: GROUPING OF BUSINESS INFORMATION SERVICES INTO LOGICAL BUSINESS INFORMATION COMPONENTS .................... 62 FIGURE 36: NOTATION BUSINESS OBJECT .................................................................................................................. 63 FIGURE 37: EXAMPLE BUSINESS OBJECT .................................................................................................................... 64 FIGURE 38: NOTATION INFORMATION SERVICE CONTRACT ............................................................................................. 65 FIGURE 39: NOTATION INFORMATION OBJECT ............................................................................................................ 65 FIGURE 40: NOTATION INFORMATION SERVICE ........................................................................................................... 66 FIGURE 41: EXAMPLE INFORMATION SERVICE ............................................................................................................ 66 FIGURE 42: PROPOSED INFORMATION LAYER META MODEL ARCHIMATE .......................................................................... 67 FIGURE 43: RELATIONS INFORMATION LAYER CONCEPTS WITH OTHER LAYERS ..................................................................... 67 FIGURE 44: PROPOSED CHANGES ARCHIMATE META MODEL TECHNOLOGY LAYER ............................................................... 68 FIGURE 45: IAF AREAS COVERED BY MAPS TO ARCHIMATE WITH THE PROPOSED CHANGES OF ARCHIMATE TAKEN INTO ACCOUNT ... 69 FIGURE 46: THEORETICAL MODEL VALIDATION APPROACH ............................................................................................. 71 FIGURE 48: DESIRED APPLICATION LANDSCAPE IVW .................................................................................................... 73 FIGURE 47: FOCUS AREA IVW PROJECT .................................................................................................................... 73

viii

FIGURE 49: IAF COVERAGE SURVEY ......................................................................................................................... 76 FIGURE 50: IAF MODEL: BUSINESS INTERACTION MODEL .............................................................................................. 77 FIGURE 51: EXTENDED ARCHIMATE MODEL: BUSINESS INTERACTION MODEL ..................................................................... 77 FIGURE 52: COMBINED SURVEY RESULTS MODEL 1 ...................................................................................................... 80 FIGURE 53: COMBINED SURVEY RESULTS MODEL 2 ...................................................................................................... 81 FIGURE 54: COMBINED SURVEY RESULTS MODEL 3 ...................................................................................................... 81 FIGURE 55: COMBINED SURVEY RESULTS MODEL 4 ...................................................................................................... 81 FIGURE 56: COMBINED SURVEY RESULTS MODEL 5 ...................................................................................................... 81 FIGURE 57: COMBINED SURVEY RESULTS MODEL 6 ...................................................................................................... 82 FIGURE 58: COMBINED SURVEY RESULTS MODEL 7 ...................................................................................................... 82 FIGURE 59: COMBINED SURVEY RESULTS MODEL 8 ...................................................................................................... 82 FIGURE 60: COMBINED SURVEY RESULTS MODEL 9 ...................................................................................................... 83 FIGURE 61: COMBINED SURVEY RESULTS MODEL 10 .................................................................................................... 83 FIGURE 62: SURVEY RESULTS STANDARD ARCHIMATE AND ARCHIMATE++ COMBINED ......................................................... 84 FIGURE 63: IAF MODEL: BUSINESS INTERACTION MODEL ............................................................................................ 134 FIGURE 64: IAF MODEL: BUSINESS OBJECT USAGE BY BUSINESS SERVICES ........................................................................ 135 FIGURE 65: IAF MODEL: LOGICAL BUSINESS COMPONENTS .......................................................................................... 135 FIGURE 66: IAF MODEL: INFORMATION INTERACTION MODEL ...................................................................................... 136 FIGURE 67: IAF MODEL: LOGICAL INFORMATION COMPONENTS .................................................................................... 137 FIGURE 68: IAF MODEL: LOGICAL BUSINESS INFORMATION COMPONENT INTERACTION MODEL ............................................. 138 FIGURE 69: IAF MODEL: BUSINESS INFORMATION SERVICE - INFORMATION SYSTEM SERVICE XREF ........................................ 140 FIGURE 70: PHYSICAL INFORMATION SYSTEM COMPONENTS ........................................................................................ 140 FIGURE 71: IAF MODEL: SOLUTION ALTERNATIVES LOGICAL INFORMATION SYSTEM COMPONENTS ......................................... 141 FIGURE 72: STANDARD ARCHIMATE MODEL: BUSINESS INTERACTION MODEL................................................................... 142 FIGURE 73: STANDARD ARCHIMATE MODEL: LOGICAL BUSINESS COMPONENTS ................................................................ 142 FIGURE 74: STANDARD ARCHIMATE MODEL: INFORMATION INTERACTION MODEL ............................................................ 143 FIGURE 75: STANDARD ARCHIMATE MODEL: LOGICAL INFORMATION COMPONENTS .......................................................... 144 FIGURE 76: STANDARD ARCHIMATE MODEL: INFORMATION OBJECT - INFORMATION SYSTEM SERVICE XREF ............................ 145 FIGURE 77: STANDARD ARCHIMATE MODEL: PHYSICAL INFORMATION SYSTEM COMPONENTS .............................................. 145 FIGURE 78: STANDARD ARCHIMATE MODEL: SOLUTION ALTERANTIVES LOGICAL BUSINESS COMPONENTS ................................ 146 FIGURE 79: EXTENDED ARCHIMATE MODEL: BUSINESS INTERACTION MODEL ................................................................... 148 FIGURE 80: EXTENDED ARCHIMATE MODEL: BUSINESS OBJECTS USED BY BUSINESS SERVICES ............................................... 148 FIGURE 81: EXTENDED ARCHIMATE MODEL: LOGICAL BUSINESS COMPONENTS ................................................................ 149 FIGURE 82: EXTENDED ARCHIMATE MODEL: INFORMATION INTERACTION MODEL ............................................................. 150 FIGURE 83: EXTENDED ARCHIMATE MODEL: LOGICAL INFORMATION COMPONENTS .......................................................... 151 FIGURE 84: EXTENDED ARCHIMATE MODEL: LOGICAL BUSINESS INFORMATION COMPONENT INTERACTION MODEL .................... 152 FIGURE 85: EXTENDED ARCHIMATE MODEL: INFORMATION SYSTEM SERVICE – INFORMATION OBJECT XREF ........................... 152 FIGURE 86: EXTENDED ARCHIMATE MODEL: BUSINESS INFORMATION SERVICE - INFORMATION SYSTEM SERVICE XREF............... 153 FIGURE 87: EXTENDED ARCHIMATE MODEL: PHYSICAL INFORMATION SYSTEM COMPONENTS ............................................... 153 FIGURE 88: EXTENDED ARCHIMATE MODEL: SOLUTION ALTERNATIVES LOGICAL BUSINESS COMPONENTS ................................ 154 FIGURE 89: IAF MODEL: BUSINESS INTERACTION MODEL ............................................................................................ 155 FIGURE 90: EXTENDED ARCHIMATE MODEL: BUSINESS INTERACTION MODEL ................................................................... 155

ix

List of Tables TABLE 1: TRACEABILITY MATRIX RESEARCH QUESTIONS ANSWERED IN CHAPTERS .................................................................... 5 TABLE 2: SUMMARY OF INTERVIEW CRITERIA ............................................................................................................. 24 TABLE 3: SUMMARY OF LITERATURE CRITERIA ............................................................................................................. 26 TABLE 4: CRITERIA ADDRESSING FOR THE MAPPING ...................................................................................................... 29 TABLE 5: GENERIC MAPPING ................................................................................................................................. 32 TABLE 6: POSSIBLE MAP TO BUSINESS ROLE ............................................................................................................... 34 TABLE 7: POSSIBLE MAP TO BUSINESS GOAL .............................................................................................................. 34 TABLE 8: POSSIBLE MAPS TO BUSINESS ACTIVITY ......................................................................................................... 35 TABLE 9: POSSIBLE MAP TO BUSINESS SERVICE ........................................................................................................... 36 TABLE 10: POSSIBLE MAPS TO INFORMATION OBJECT ................................................................................................... 37 TABLE 11: POSSIBLE MAP TO BUSINESS INFORMATION SERVICE ...................................................................................... 38 TABLE 12: POSSIBLE MAPS TO INFORMATION SYSTEM SERVICE ....................................................................................... 38 TABLE 13: POSSIBLE MAP TO TECHNOLOGY INFRASTRUCTURE SERVICE ............................................................................. 39 TABLE 14: POSSIBLE MAPS TO ACTOR....................................................................................................................... 40 TABLE 15: POSSIBLE MAP TO LOGICAL BUSINESS COMPONENT ....................................................................................... 40 TABLE 16: POSSIBLE MAP TO LOGICAL PROCESS COMPONENT ........................................................................................ 41 TABLE 17: POSSIBLE MAP TO LOGICAL INFORMATION COMPONENT ................................................................................. 41 TABLE 18: POSSIBLE MAP TO LOGICAL BUSINESS INFORMATION COMPONENT .................................................................... 42 TABLE 19: POSSIBLE MAP TO LOGICAL INFORMATION SYSTEM COMPONENT ...................................................................... 43 TABLE 20: POSSIBLE MAP TO LOGICAL TECHNICAL INFRASTRUCTURE COMPONENT............................................................... 43 TABLE 21: POSSIBLE MAP FOR PHYSICAL BUSINESS COMPONENT..................................................................................... 44 TABLE 22: POSSIBLE MAPS TO PHYSICAL INFORMATION SYSTEM COMPONENT .................................................................... 46 TABLE 23: POSSIBLE MAPS TO PHYSICAL TECHNOLOGY INFRASTRUCTURE COMPONENT ......................................................... 46 TABLE 24: MAPPING OF RELATIONS ......................................................................................................................... 48 TABLE 25: BEST MAPPING ALTERNATIVES .................................................................................................................. 52 TABLE 26: NOT MAPPED IAF CONCEPTS .................................................................................................................... 54 TABLE 27: ATTRIBUTE SPECIFICATION SERVICE CONTRACT .............................................................................................. 58 TABLE 28: RELATIONS BUSINESS INFORMATION SERVICES - INFORMATION OBJECTS .............................................................. 62 TABLE 29: ADDITIONAL MAPS FOLLOWING FROM PROPOSED ARCHIMATE CHANGES............................................................. 68 TABLE 30: IAF MODELS INCORPORATED IN THE SURVEY ................................................................................................ 75 TABLE 31: EXAMPLE SURVEY ANSWER ...................................................................................................................... 77 TABLE 32: NUMERICAL SCORES FOR THE POSSIBLE ANSWERS .......................................................................................... 78 TABLE 33: SURVEY RESULTS COMPARISON IAF – STANDARD ARCHIMATE MODELS .............................................................. 79 TABLE 34: SURVEY RESULTS COMPARISON IAF – ARCHIMATE++ MODELS ......................................................................... 80 TABLE 35: SUMMARY OF CRITERIA ........................................................................................................................ 129 TABLE 36: IAF MODEL: INPUT INFORMATION OBJECTS – INFORMATION SYSTEM SERVICES XREF ........................................... 139 TABLE 37: IAF MODEL: OUTPUT INFORMATION OBJECTS – INFORMATION SYSTEM SERVICES XREF ........................................ 139

1

1 Introduction Architecture is a discipline that already has quite a long history in the IT community. Enterprise Architecture on the other hand is something from the last decades and involves a holistic view (considering all aspects of an organisation) on an organisation. Capgemini has created an approach incorporating a holistic view, the Integrated Architecture Framework (from now on, it is recalled to as the IAF).

This framework supports a holistic view on an entire organisation, gives decision support, and provides a way to communicate architecture to stakeholders. Capgemini architects have used the IAF in many engagements in order to help clients align their business and IT and/or govern their IT. This research evaluates the possibility of transforming an architecture created using the IAF approach and into an architecture, which uses ArchiMate for visualisation and documentation. ArchiMate is an enterprise architecture modelling language created by a mixture of Dutch research institutes, companies, and the Dutch government.

1.1 Background During engagements by Capgemini, many architecture models are created. Each of them is unique, because of the influence of people, their way of interpreting the IAF, and the lack of a standard documentation approach. However, some engagements are homogenous, which create the possibility to reuse former work. Nevertheless, since many architects have a different modelling approach, they create different models of an architecture in general and reusability is greatly hindered. Therefore, Capgemini is looking for a way to create homogeneous models in order to facilitate reuse, shorten project life cycle, and create best practices.

Many approaches have been created in order to model enterprise architectures. These all incorporate a different interpretation on enterprise architecture, possibly making them useless in order to model architectures created using the IAF approach. Therefore, comparing such an approach with the IAF is necessary in order to validate the compatibility of visualising and documenting an IAF architecture using such an approach.

One Dutch approach, developed by a mixture of research institutes, companies and government, is the ArchiMate language. This language is specifically created to model enterprise architectures. In 2004, it became an open standard and lately it is adopted by the Open Group, a worldwide standardization organization. In the Netherlands, it has already gained some momentum, since more and more companies have started to use it. ArchiMate only provides a modelling language and not a process or methodology to guide the development of an architecture1. Hence, Capgemini wants to know whether it is possible to visualise and document IAF architectures using ArchiMate models. Therefore, they can complement each other. In this way, the IAF provides the methodology, while ArchiMate can be used to model this visually and document it. Figure 1 depicts how they complement each other. Roughly, four elements can be distinguished when developing an

1 We surveyed this at the Dutch National Architecture Congress (LAC) 2008. 86% of the respondents agreed that another framework/methodology is needed in combination with ArchiMate against 14% who said it was not necessary. Even though the way the question was asked results in biased answers, most respondents indicated that ArchiMate lacks a process to guide the development of an architecture. The total survey results are provided in Appendix A.

2

enterprise architecture. First, the process of developing an architecture, defining what steps you take to develop an architecture, and in what order you take them. Second, the structure of developing an architecture, defining the means to handle the complexity of an architecture. Third, the used methodology, defining with what you develop an architecture. Finally, registering, defining how you specify, or document an architecture.

Figure 1: Positioning of IAF, ArchiMate and TOGAF in enterprise architecture elements

The interest of Capgemini in ArchiMate is twofold. On the one hand, they want to be possible to tender both the IAF and ArchiMate at the same time. This expands their customer base with customers that already use the ArchiMate language but not the IAF. On the other hand, Capgemini is trying to make the IAF an open standard by incorporating it in The Open Group Architecture Framework (TOGAF) version 9 (See Figure 1 for the positioning of TOGAF in relation with IAF). With the adoption of ArchiMate by the Open Group, it is very likely that this is going to be the modelling approach for TOGAF. Therefore, by already looking at IAF and ArchiMate they have a head start and possibly could propose some adjustments to ArchiMate and/or the IAF in order to better align them.

1.2 Research goal Capgemini wants to know whether IAF architectures can be visualised and documented using ArchiMate. Our approach is to transform IAF models into ArchiMate models to evaluate the possibilities to use ArchiMate as the modelling language for the IAF. To realise this, we need to compare the IAF and ArchiMate in such a way that we know how well they match. By mapping the IAF and ArchiMate Meta models and then try to transform an IAF architecture model into an ArchiMate one, we can identify this. This brings us to the main research goal:

To evaluate the possibilities to transform an architecture created using the IAF approach into an architecture using ArchiMate models for visualisation and documentation, by creating a mapping between IAF and ArchiMate based on a meta-model matching, and identify the discrepancies, and provide recommendations on how to overcome the identified discrepancies.

Process

Structure

Methodology

Registration

IAF

3

1.3 Research Questions In order to meet this research goal, a main question, divided in sub questions is set up to address the problem and meet the goal. The main question is; what are the possibilities to transform an IAF architecture into an ArchiMate one? This question is further derived into more specific sub questions, which are answered throughout this research.

In order to transform an IAF architecture model into an ArchiMate one, we need to compare IAF and ArchiMate by creating a mapping. This mapping most likely has multiple correct solutions, wherefore we identify criteria to select the best mapping alternative.

1 How can the Integrated Architecture Framework and ArchiMate Meta models best be mapped? (descriptive) a. What are the criteria for mapping the IAF and ArchiMate Meta models? (prescriptive) b. What is the best approach to map the IAF and ArchiMate Meta model concepts?

(prescriptive)

The created mapping forms the basis to complete the research goal. The next step is to identify the possibilities to transform an IAF architecture model into an ArchiMate one. The transformations are carried out using the created mapping. In order to end up with feasible results, the created ArchiMate models must be equivalent to their IAF parents. We are striving for models that represent the same architecture, which means that they are semantically the same. In addition, it is possible that the best mapping alternative still shows some flaws. We try to address these with possible solutions to improve the best mapping alternative.

2 To what extend is it possible to transform IAF architecture models into ArchiMate architecture models and do the possible solutions improve the transformation possibilities? (evaluative) a. What are the problem areas in the mapping of IAF and ArchiMate Meta models? (evaluative) b. What are the possible solutions to avoid or overcome the problem areas? (prescriptive)

1.4 Research approach This research focuses on creating a mapping between the Meta models of the IAF and ArchiMate, to evaluate whether an IAF architecture can be visualised and documented using ArchiMate models. This research can be categorised as practical research, and more specifically this research is design research, serving a design problem, since it is creating an artefact (which is the mapping) (Hevner, March, Park, & Ram, 2004). Wieringa (2007) described the software engineering cycle (see Figure 2), which is used for solving design problems. By using this cycle the problem solving process is structured. The cycle consists of five interrelated steps. The steps are:

§ Problem investigation: What is the problem? § Solution design: which solution alternatives are available? § Solution validation: Which alternative best solves the problem? § Solution implementation: implement the selected solution § Implementation evaluation: how well did the implemented solution solve the problem?

4

Figure 2: Software engineering cycle (Wieringa, 2007)

The above steps are used as a guide throughout this thesis. First, criteria on a mapping are identified by interviewing Capgemini architects. After that, different kinds of mapping approaches are discussed in literature and the most appropriate one is selected, this can be defined as the problem investigation. Second, in the solution design phase different mappings are identified, being the solution alternatives. Third, based on the mapping criteria and the mappings, the best mapping is selected during the solution validation phase. Fourth, the solution is implemented during the solution implementation phase, using a pilot project in order to transform an IAF architecture into an ArchiMate one. Finally, the results of the project are validated and conclusions and recommendations are drawn. Figure 3 depicts these steps visually.

Figure 3: Theoretical model

5

1.5 Structure of the thesis This thesis starts with an introduction on enterprise architecture in chapter 2, this chapter also explains the IAF and ArchiMate in sections 2.2 and 2.3. Next, Chapter 3 discusses the mapping approach and identifies the mapping criteria. After this, chapter 4 presents the best mapping alternative, which is evaluated in chapter 5 by identifying the problem areas and possible solutions. Next, chapter 6 validates whether and to what extend it is possible to transform an IAF model into an equivalent ArchiMate model. Finally, this thesis is concluded with the overall conclusion in chapter 7 by answering the main research question and recommend on improving the results and by discussing future work. Table 1 depicts which research question is answered in what chapter.

Chapter Answers research question 3 1a, 1b 4 1 5 2a, 2b 6 2 7 Main RQ

Table 1: Traceability matrix research questions answered in chapters

6

2 Enterprise Architecture This research is concerned with the topic of enterprise architecture, and specific with the Integrated Architecture Framework and ArchiMate. The goal of this chapter is to elaborate on enterprise architecture (EA) to create an understanding on the Integrated Architecture Framework (IAF) and ArchiMate. First, in section 2.1 enterprise architecture is defined and elaborated. After this, sections 2.2 and 2.3 introduce the IAF and ArchiMate respectively.

2.1 What is Enterprise Architecture Organisations nowadays can have hundreds of applications, thousands of pc’s and so on. Hence, the level of complexity in organisations is very high. In order to get a grip on this complexity, using architecture is often suggested, especially when you need to control changes that take place in such an organisation. Therefore, in the Architecture and IT domain what exactly is the meaning of IT architecture and especially Enterprise Architecture? The term architecture originates from civil engineering. There, the architecture specifies the construction of a building with its dimensions, functions, materials, colours, etc complying with regulations and the requirements of the future owners and/or users. However, also in the building industry this term is ambiguous. It can signify the art and science of designing the built environment, or the product of such a design. Hence, the term architecture encompasses both the blueprint for a building and the general underlying principles such as style, as in for instance ‘gothic architecture’ (Henk Jonkers et al., 2006).

In IT, a commonly used definition of architecture is the following definition, which is incorporated in the IEEE 1471-2000 standard:

“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 (IEEE Computer Society, 2000).”

This definition of architecture provides several insights into architecture, but it mainly focuses on an architecture with the scope of a single project (i.e. a solution architecture) and not on architecture as a holistic approach. Hence, the above definition provides the view on architecture on a solution level. Another definition of architecture, by Capgemini, is:

“Architecture shows the relations and interdependencies between the organization with its processes, the information, the IT systems and the infrastructure. Architecture is an effective and consistent set of principles, models and guidelines that give direction and set boundary conditions for programs, projects or systems (Capgemini, 2007c).”

Architecture at the level of an entire organisation is commonly referred to as “enterprise architecture” (EA). The above definition is more EA oriented. Iacob et al. provide another EA definition. In their book about Enterprise Architecture: The Enterprise Architecture Handbook, they refer to EA as:

“Enterprise Architecture (EA) is the complete, consistent and coherent set of methods, rules, models and tools which will guide the (re)design, migration, implementation and governance of business processes, organizational structures, information systems and the technical infrastructure of an organization according to a vision (Iacob, Franken, & van den Berg, 2007).”

7

The above definitions have a difference. The EA definition by Iacob et al. approaches architecture from a process perspective, for they refer to the (re)design, migration, implementation and governance of business processes. The IAF definition on the other hand does not explicate that it changes business processes. Therefore, their focus is not on the business processes but on the activities that occur in an organisation. However, managing an architecture most certainly has an impact on business processes, but the focus is not on the process.

Both definitions have in common that they capture the essentials of the business, IT and its evolution and management through a set of methods and rules (guidelines) resulting in what they call an EA. These essentials provide a much more stable view of an enterprise than compared to the specific solutions. Hence, an EA can capture and guard the essentials of a business, and additionally facilitate for maximal flexibility and adaptability. The last two are crucial, seen the pace the market changes nowadays. Organisations need to react to changes otherwise their opponents will.

According to Jonkers et al. (2006) EA provides the “blueprint” for systematically defining an organisation’s current or future environment, coupled with a process for development and maintenance. This means that EA, as a key planning discipline, helps to guide and optimise an organisation’s IT investments and translate business strategies into implementable technology solutions.

By providing a blueprint for the organisations current and future environment, it provides a holistic view on an organisation. Since, the whole organisation is more than the sum of its parts; this holistic view is the most important characteristic of an architecture. In organisations not providing this holistic view, often multiple architectures exist within different parts (domains) of the organisation. No matter how optimal these architectures may be for a certain domain. They may not fit in the entire picture, because they are not linked to other domains. EA provides the overview of all these domains but more importantly, it provides the means to link the different domains in an organisation. By creating the link, the bigger picture can be kept in mind. For instance, a technical infrastructure can be very cost effective and fast, but it is very rigid and does not support fast changes in the business. A good EA can overcome this by providing insight at all levels of the architecture, and thus consider all the requirements ranging from corporate strategy to daily operations.

Another important factor for EA is that EA facilitates decision-making and traceability. In order to make decisions, the consequences need to be known. By having the total picture in mind, but not losing the details either, complexity is manageable. This means that the consequences of a single decision are traceable throughout the entire organisation. Thus, when the change is made at the top or at the bottom of the organisation, its consequences can be traced back respectively to the bottom or top.

Finally, EA is not something that you can do once and then discard. This is already suggested by the EA definition, because it incorporates governance of business processes, organizational structures, information systems and the technical infrastructure. This says that, EA is a process as well as a product. It is a product for managers and system developers, because it facilitates the design of business processes and applications in a way that is in line with both business objectives and policies.

8

Incorporating Enterprise Architecture into an organisation by an ongoing process is a must. By rising the awareness of EA by actively involving all the stakeholders and communicating the relevant part of the architecture to them, an EA can become part of the organisation. The above part reflects the most important role of an architecture, communication, which is supported by literature (Iacob et al., 2007). EA facilitates heavily in the communication to stakeholders, and other interest groups. Hence, it provides a common ground for discussion and decision-making.

The above describes Enterprise Architecture theoretically. However, this concept is not directly applicable in practice. Several frameworks are proposed, which guide the practical design and implementation of architectures. These frameworks have been categorized by Wu (2006). The picture below gives a good overview of the different EA frameworks that exist.

Figure 4: Categories of EA frameworks and models (Wu, 2006)

2.2 The IAF (Integrated Architecture Framework) The Integrated Architecture Framework was developed by Capgemini in 1993 (Mulholland & Macaulay, 2006). It is based on the Zachman framework by Sowa & Zachman (1992; Zachman, 1987). Figure 5 depicts the fourth, and most recent, revision of the IAF. As we write this report, revision 4.5 is in the make.

The philosophy and mindset behind the IAF positions the way Capgemini communicates about enterprise architecture. “Capgemini has viewed architecture as providing a comprehensive and coherent view across Business, Information, Systems and Technology—not just to deliver IT systems but to deliver business change supported by IT (Mulholland & Macaulay, 2006).”

9

When looking at the IAF structure, it is a matrix consisting of four rows and six columns. The rows represent different levels of abstraction and the columns break down the architecture in several aspects, concentrating on specific areas, such as business, information, etc. See Appendix A for an elaboration of all the IAF concepts.

2.2.1 Levels of abstraction (rows) The rows provide the following information. The contextual row represents the WHY question. Why does an organisation require an architecture? What is needed to achieve the objectives? It clarifies the long-term strategy and determines the focus of the architecture-study to give a clear boundary on the activities that need to be conducted. The conceptual row asks the WHAT question, what is my business? This row determines the services, actors, objectives and their relations. At the logical row, the HOW question is asked. How can the architecture optimally be structured (independent from the implementation)? This row determines components (which are groupings of services) and the most optimal structure of these components in order to meet the long-term strategy. At last, at the physical row the WITH WHAT question is asked. What are things I need to reach my goals for a given migration step (towards the long-term strategy). This determines the physical objects, processes, information structures, and application structures, such as computers, servers, routers, service busses, packages, etc that are needed. The horizontal rows are used to focus on a certain level of abstraction, simplifying the structure for stakeholders.

Figure 5: Fourth revision of the Integrated Architecture Framework

2.2.2 Aspect areas (columns) As mentioned earlier, the columns, which are called aspect areas, divide the framework into aspects concentrating on specific type of issues. The aspects, which the architecture distinguishes, are business, information, information systems, technical infrastructure, security, and governance. These last two aspect areas present in all the other aspect areas, these are security and governance they represent a set of quality aspects that span across all core aspect areas, and may significantly change the architecture structure across one or more core aspect areas. The business aspect area

10

describes the business architecture in terms of business sub-aspects representing business goals, business activities, roles, and resources. The outcome of the business aspect area is typically a series of business architecture components that describe process, organization, people, and resources (Capgemini, 2007c). The information aspect area describes the information the business uses, the information structure, and relationships. The outcome from the information aspect area is typically information architecture and a series of business information components that describe what and how information is used and flows around the business. Furthermore, it describes what the ideal structure of this information is without taking the physical limitations into consideration (Capgemini, 2007c). The information systems aspect area describes the information systems (packaged or bespoke) that will automate and support the processing of the information used by the business. The outcome from the information system aspect area is typically a series of information system architecture components that describe how the information systems will be used to support the automated aspects of the information architecture and business information architecture components (Capgemini, 2007c). The technology infrastructure aspect area describes the technology infrastructure needed to support the automated business information architecture components and information systems architecture components (Capgemini, 2007c). The security aspect area adds knowledge to the core aspect areas in terms of risk and integrity of the core architecture components. The outcome of the security aspect area is typically a set of refinements to the core architecture components and the addition of architecture artifacts to specifically support security objectives (Capgemini, 2007c). Finally, the governance aspect area adds knowledge to the core aspect areas in terms of quality and manageability of the core architecture components. The outcome of the governance aspect area is typically a set of refinements to the core architecture components and the addition of architecture artifacts to specifically support the governance objectives (Capgemini, 2007c).

2.2.3 Artifacts According to Wu (2006) the IAF is an artefact framework, which means that the architecture contains a collection of artifacts, as Capgemini calls them. “Artifacts are the core elements of the IAF and fundamentally describe the architecture” (Capgemini, 2007c). So to model an architecture using the IAF, different artifacts are used to describe the parts that an architect wants to address. The entire architecture framework is built up of approximately fifty artifacts. In order to create a holistic view, the artifacts are connected to each other by cross references (called Xrefs in IAF). These Xrefs are also artifacts, in the IAF Meta model defines the technical framework where the relationships between all the artifacts are defined.

2.2.4 Views Another fundamental part of the approach defined in the IAF are its views. Views allow architects to inspect and validate an architecture as a whole from one perspective, a view represents a complete, compound, and sound picture of the solution across all areas (Capgemini, 2007a). Architects use views to communicate a certain part of the architecture to stakeholders involved in a specific piece of the architecture. This way the stakeholder is not burdened with the complexity of the entire architecture. Hence, different views help communicating the architecture to different stakeholders and views can be created based upon the needs and/or interests of a stakeholder.

11

2.2.5 What IAF is not The IAF is not a method, so no stepwise manual exist on how to use the IAF. The IAF can be used in a lot of different ways and for a lot of different purposes. An architect determines what parts of an architecture needs attention and therefore he selects a set of artifacts he thinks are appropriate to use. In addition, the order in which to model the artifacts is not determined. There are some predefined sets of artifacts and order to create them; these are called roadmaps in IAF. Although typically you start with determining the vision of an organisation, since according to Capgemini: “Vision drives strategy and strategy drives architecture” (Huc, 2006). Hence, without a vision the architecture cannot be correctly designed.

2.2.6 Example Above, only a textual description of the IAF is given. For the purpose of this research, it is interesting to look at the deliverables of the IAF. They also give a better image of the IAF in general. The following example is adopted from course material of the IAFWorkbench2 and comprises a fictive organisation. The example deliverables were all modelled using the IAFWorkbench.

The IAF does not have one deliverable, but many. Therefore, some interesting deliverables are elaborated here. The deliverable below (Figure 7) depicts how services interact with each other and by what terms (defined by a contract). This is called a business service interaction model. See the legend (Figure 6) for the meaning of the concepts. The edges denote what concepts are related to one another. For readability, the depicted models only show a sample of the entire model.

Figure 7: Sample of Business Service Interaction Model

The above model resides at the business conceptual block of the IAF. This displays what services can be distinguished in the organisation. The model below on the other hand, resides at the business logical layer; it groups conceptual business services into logical business components. It shows how the conceptual business services are ideally structured into logical business components according to criteria derived from the business principles.

2 The IAFWorkbench is a tool specifically created to model an IAF architecture. The tool is developed by BiZZdesign.

Process outgoing paymentsRegister invoice Validate outgoing payments

Outgoing payments processingOutgoing payments validation Payments processing

Figure 6: Legend IAF concepts

Principle

Business service

Logicalbusiness component

Solution alternative

Service contract

Legend

12

Figure 8: Sample of Logical Business Component Interaction Model

The model below depicts the solution alternatives related to the principles that a certain solution alternative complies with. The figure comprises two solution alternatives. This model is used to show how solution alternatives are structured when aiming to comply with a certain set of principles. It is most effective to construct solution alternatives where the principles of the solution alternatives are contrary to or at least not compatible with each other. This shows what consequences a choice for a certain (set of) business principle(s) implies.

Figure 9: Solution alternatives and principles

2.2.7 Putting it all together Until now, this chapter has given an overview of the IAF. However, it still did only grasp the surface of it. Therefore, this last paragraph is introduced. Here we try to give a more extensive picture of the IAF by describing its core constructs and why the IAF is divided into columns and rows. First, the core constructs are described. After this, the rationale behind the columns and layers is explained. With explaining this rationale, the generic constructs of the IAF are revealed and elaborated. The generic concepts for IAF were identified using the course material for the IAF essentials course (Huc, 2006) and from discussions with Dave van Gelder, an IAF lecturer and architect at Capgemini.

Although the IAF consists of a four-by-four matrix, one should not expect to find the same generic concepts throughout all the cells. The same concepts are found in each column (aspect area) (except for the security and governance aspect areas, which do not have their own concepts. The generic concepts for IAF are depicted in Figure 10.

Validate outgoing payments

Manage debtors

Administer finances

Debtors managementOutgoing payments processing

Process outgoing payments

Financial administration

Report unit results

Unit reporting

Unit results reconcilement

Payments processing

Invoice administration

Register invoiceInvoicing

Outgoing payments validation

Cost value thinking

Effectiveness

Proven solutionsProven technology

Technology standards

High securityEfficient handlingFlexibility

Global alignment

Service delivery

Proposal management

Invoicing

Financial administration

Project cost allocation Request processing

Unit reporting

Archiving

Time & expenses administration

Market planning

Delivery preparation

Alternative 2 - Secure

Time & expense administration

Service delivery

Proposal managementKnowledge management

Archiving management

Request processing

Account management

Financial administration

Alternative 1 - Effective, flexibel and global

13

These core concepts describe the essentials of IAF. The focal point in IAF is a service. Most people think of a service in terms of a SOA service, where it represents a discreet domain of control that contains a collection of tasks to achieve related goals (Jones, 2005). However, in IAF a service is the most elementary unit of behaviour in an organisation that is performed by a maximum of one role, realizes only one goal and consists of only one activity. This concept shows the essential way of thinking incorporated in IAF. By defining the most elementary units of behaviour these units can be grouped based on principles given by the organisation. A grouping of services according to some grouping criteria based on the principles is called a component in IAF. A collaboration contract describes how a service or component is used by respectively another service or component. Such a contract describes the non-functional requirements between these concepts. The last concept is the solution alternative, a solution alternative can depict several possible architectures in terms of components structured according to different criteria, for it can very well be that certain principles thwart each other. With solution alternatives, the consequences of different possible groupings of services can be elaborated, which helps customers to take decisions.

To translate this back to the four-by-four matrix of IAF, the rows group and the columns identify different aspects. The conceptual row defines the services and thus the activities in the organisation, both for the as-is and the to-be situation. The logical row structure these services into logical components creating the ideal situation, thus not looking at physical or other constraints. The physical row structures the components of the logical row into physical components again based on criteria derived from the principles.

Figure 10: Generic concepts IAF, extracted from: (Huc, 2006)

The four aspect areas (without security and governance) shed light on four different aspects of an organisation. The first aspect area, the business aspect area depicts the business side of an organisation, representing everything in a business. The information aspect area represents the information in a business that is used by business service and components. The information systems aspect area represents the services/components that are automated based on the information

Service

Component

Collaboration Contract

Solution alternative

+has

+applies to2

0..*

+applies to

+has0..*

2

0..11..*

+has alternative

+belongs to

+is clustered into

+clusters1..*

0..*

Role Goal Activity

+has

+is part of

0..*

0..1 +has

+is part of 0..*

0..1 +has

+is part of0..*

0..1

Principle0..*0..*+influences +is influenced by

0..*

0..* +influences

+is influenced by

14

aspect area. Thus, the choice between automation and no automation is made between the information and information systems aspect area, meaning that the business aspect area also represents the non-automated parts of an organisation. Finally, the technical infrastructure aspect area represents the services that support the information system services. Generally, services belong to the technical infrastructure aspect area when they support an entire organisation and a service belongs in the information systems aspect area when it only supports a small part of the organisation. Therefore, email and data storage services, which are used throughout the entire organisation, belong to the technical infrastructure aspect area. In addition, an invoicing service, which uses the data storage and email systems, belongs to the information systems aspect area.

2.3 ArchiMate In this section, we elaborate what ArchiMate is and where it can be used for. ArchiMate is an architectural modelling technique (“language”) that provides a comprehensive approach for modelling an Enterprise Architecture. ArchiMate was originally developed 2002 in the Netherlands as part of a collaborative research project on Enterprise Architecture funded by the Dutch Government involving several Dutch research institutes, major corporations and governmental and financial institutions. In 2004, the project was finished and from then on ArchiMate was tested and used in practice. The group of users is still expanding. After the project ended the ArchiMate foundation (2008) was established to make it an open standard. Very recently, the 29th of may 2008, ArchiMate is officially transferred to the Open Group, a large vendor neutral consortium. This consortium, among other things develops and maintains standards for the IT community (Open Group, 2008).

Supporting the communication of EA is one of the most important goals of the ArchiMate language. Hence, it is structured in such a way that it contributes to communication of an Enterprise Architecture to its stakeholders. Views are the most important component that support the communication. The total language consists of five primary components (Iacob et al., 2007):

§ a framework; § an abstract syntax; § the language semantics; § a concrete syntax; § views.

Below, an elaboration of each of these components is given. For, these explanations only give a description of what ArchiMate is. Section 2.3.7 provides an example of an ArchiMate model, showing the layered view model of a fictive insurance company. The layered view incorporates concepts throughout all the layers of the ArchiMate framework, and therefore depicts the overview of an architecture.

2.3.1 Framework The ArchiMate language has an underlying conceptual framework consisting of rows (layers) and columns (aspects), which allows classification of architectural phenomena. This framework is the basis and defines a theory about how organisations are structured. Figure 11 depicts the ArchiMate framework; consisting of three vertical columns and four horizontal layers. The horizontal layers define the dimension of the architecture. The environment layer defines the highest dimension and

15

the technology layer provides the lowest dimension. The vertical layers represent the three basic modelling concepts of an organisation from the viewpoint of an actor. An actor is assumed as being the core concept for modelling systems and organisations, hence a system or organisation is seen as primarily consisting of a set of actors. The structure, behaviour, and information layers define the three main aspects of these actors. Actors have structure in the sense of relations between actors and additionally the decomposition of actors into sub actors. They show behaviour by performing processes and services and finally they exchange and use information. Because ArchiMate models the structure of the EA and the scope dimension defines the structure in which an EA is modelled this dimension shows the structure of the ArchiMate models. Hence, it is an important dimension of the ArchiMate modelling language (Iacob et al., 2007). See Appendix C for a description of all the ArchiMate concepts.

2.3.2 Abstract syntax ArchiMate provides an abstract syntax in the form of a Meta model, which defines the formal definition. This Meta model defines the characteristics of each language constructs but also specifies the relationships with other language constructs. The most important point of this Meta model is that it shows the dependencies between the different layers of the ArchiMate framework. By doing this the different layers become interrelated and form a coherent whole of models which describe the entire Enterprise Architecture (Iacob et al., 2007).

2.3.3 Language semantics This defines the meaning of each of the language constructs and relationship types.

2.3.4 Concrete syntax The ArchiMate concrete syntax is defined in terms of a visual notation. It defines the graphical representation of the language constructs and their relations that are defined in the Meta model.

Figure 11: The ArchiMate framework (source: Iacob et al. (2007))

16

2.3.5 Views A view is a visual representation of a selection of the language constructs and their relations defined in the Meta model. The views are mainly used to specifically elaborate a certain part of the EA, which is then used for communication to its stakeholders.

2.3.6 What ArchiMate is not ArchiMate does not provide an architecture method that will guide an organization through the entire architecture development process. ArchiMate provides the means to model an architecture, making it possible to combine ArchiMate with existing methods in order to have the best of both worlds.

2.3.7 Example The next page depicts the layered view of the architecture of a fictive insurance company, modelled using the BiZZdesign Architect3. The example shows the relationships between the different layers. The three grey top blocks comprise the business layer, divided into two external and one internal block. The fourth and fifth blocks comprise the application layer, divided into external and internal application layer. Finally, the technology layer is comprised of the last two blocks. In addition, this layer is divided into an external and internal block. With this layered view, one gets insight into how information systems (application layer) and physical devices (infrastructure layer) support the business.

3 A tool which implemented the ArchiMate modeling language, created by BiZZdesign. More info, see: http://www.bizzdesign.nl/joomla/products/architect.html

17

ClientInsurant asso-ciation

External Roles and Actors

ClaimRegistration

Service

CustomerInformation

Service

ClaimsPaymentService

External Business Services

Register Accept Valuate Paytrigger

Handle Claim

Insurer Archisurance

Business processes and internal actors / roles

PremiumPaymentService

Customerdata mutation

Service

InsuranceApplication

Service

External Application Services

Policy DataManagement

CRMSystem

FinancialApplicationCIS Claim

InfoServ

Application Components and Services

ClaimFiles Service

CustomerFile Service

External infrastructure services

NAS FileServer

CICS

DBMS

MessageQueing

Mainframe

UnixServer

UnixServer

Unix Server Farm

Infrastructure

uses uses

uses uses uses

realisation

realisationrealisation

Realisationrealisation

uses

Realisation

realisationrealisation

Realisation

uses uses

Figure 12: ArchiMate example: layered view

Business Actor

Business Role

Business Service

Business Process

Application Service

Application Component

Infrastructure Service

Node

System Software

Legend

18

2.3.8 Putting it all together So far, this chapter has given a high-level overview of ArchiMate. This paragraph intends to give a more detailed view of ArchiMate, by explaining its core constructs, and the way these form the entire ArchiMate model. Figure 13 depicts the generic concepts of ArchiMate. These are derived from the ArchiMate standard (H. Jonkers, Lankhorst, Iacob, & Proper, 2008, 2009).

Figure 13: Generic concepts ArchiMate (source: (H. Jonkers et al., 2008, 2009)

ArchiMate is developed to visualise and document an enterprise architecture. How such an architecture should be developed is left untouched. In ArchiMate there are three concepts from which all the other concepts are derived. Informative elements (also called passive structure), behavioural elements, and structural elements (also called active structure). The choice for these concepts comes from the developers’ wish to balance between specificity and generality in their concepts in such a way that a good set of concepts emerges to model the enterprise architecture domain.

ArchiMate distinguishes between three types of concepts, active structure, passive structure, and behaviour. Structural concepts are assigned to behavioural concepts to denote whom or what displays the behaviour in an organisation. Behavioural aspects represent the principles of service orientation. The concept of a service in ArchiMate represents a unit of essential functionality that a system exposes to its environment through an interface, and it provides a certain value, which provides the motivation for the services’ existence. The fact that ArchiMate distinguishes between an internal and external view on systems, supports this. The external view emphasizing on meaningfulness to the environment, and the internal view more focussed on the behaviour and structure inside a system, such as an information system.

The total ArchiMate structure consists of three layers, that all represent the generic concepts of ArchiMate combined with some layer specific concepts. The general structure and relationships inside different layers is therefore almost identical.

§ The business layer models products and services offered to external customers, realised by business process performed by business actors.

§ The application layer supports the business layer with application services realised by software applications.

§ The technology layer realises the application services by representing infrastructural services, which are realised by system software and computer and communication hardware.

19

The general structure that is the result of this division in layers is depicted in Figure 11. The main relationship that resides between the layers is a “uses” relationship, meaning that the concepts on a layer use the concepts on a lower layer. A second type of relationships between concepts on different layers is the “realisation” relation, meaning that concepts on a higher layer are realised by concepts on a lower layer, e.g. a business object (business layer) is realised by a data object (application layer).

20

3 Mapping approach This chapter is concerned with the mapping approach. There are several possibilities to create a mapping between the IAF and ArchiMate, these are discussed in this chapter, and the best suitable method is selected. First in section 3.1, the mapping criteria are determined for selecting the best possible mapping in section 4.4. In section 3.2, a mapping method is selected based on possible approaches from literature. Finally, this chapter is concluded with the answer to research questions 1a and 1b.

3.1 Criteria Criteria are used to define the correct mapping, for it is likely that mapping the IAF onto ArchiMate can be done in several ways. Therefore, the criteria are used to determine what mapping has the best fit with the IAF. These criteria are based on interviews with Capgemini architects and on literature.

Several different types of criteria can be identified for mapping the IAF onto ArchiMate. Since, the goal of the mapping is to evaluate how well an IAF architecture can be visualised and documented using ArchiMate models, we want to know what defines a good visualisation and documentation of the IAF. Furthermore, we want to know what the mapping has to comply to, for instance how the mapping should be conducted. Therefore, we distinguish between the following two main categories of criteria:

§ Criteria for creation of the mapping § Criteria for visualisation and documentation of the IAF

For both categories sources of information need to be identified, in order to determine the criteria. The criteria for describing the mapping will be mainly derived from interviews, for they are very specific to the IAF and this knowledge resides in the minds of Capgemini architects. The visualisation and documentation criteria are derived from literature and interviews. The literature is used to identify the generic criteria, and the interviews provide specific criteria.

The literature criteria are derived from the Krogstie quality framework (Krogstie, Lindland, & Sindre, 1995) for testing the quality of models. In a later paper (Nysetvold & Krogstie, 2005), this quality framework is tailored to test the quality of modelling languages. This research uses the tailored model to further categorise the visualisation and documentation criteria and derive criteria.

Nysetvold and Krogstie identified six quality areas, which in this research define the subcategories of the criteria for visualisation and documentation of the IAF:

§ Domain appropriateness, this area is considers the things specified in the domain, one should be able to express all the necessary concepts in the domain, but on the other hand not able to express things that are not in the domain.

§ Participant language knowledge appropriateness, this area relates stakeholder knowledge to the language. The conceptual basis should correspond as much as possible to the way individuals perceive reality.

§ Knowledge externalisability appropriateness, in this area the language is related to the knowledge of the modeller. The goal is that the modeller can express everything in his explicit knowledge using the modelling language.

21

§ Comprehensibility appropriateness, this area relates the language to social actor interpretation.

§ Technical actor interpretation appropriateness, here the language is related to technical actor interpretation. The importance for these technical actors is that the language lends itself to automatic reasoning.

§ Organizational appropriateness, this area relates the language to standards and other organizational needs within the organizational context of modelling, for organizational quality support.

3.1.1 Interview organisation Before an interview can be conducted, preparations are needed. First, the goal has to be defined. Second, the interview audience need to be defined, because we want to interview people that have the knowledge we want to acquire. Finally, the interview questions need to be defined.

The goal of the interviews is to gather information in order to specify criteria for creation of the mapping and criteria for visualisation and documentation of the IAF. Hence, most preferably we want to interview people who are experts on the IAF and who have used it in practice, teachers of the IAF are preferred as interview candidates. Since, Capgemini architects extensively use the IAF in practice and some of them happen to be lecturers of the IAF, these make the perfect interview candidates. Therefore, the following people were selected for the interviews:

§ Herman Hartman (co-developer of the IAF, architect at Capgemini); § Joop Hoefnagels (IAF lecturer, architect at Capgemini); § Eric Onderdelinden (architect at Capgemini); § Barry de Vries (architect at Capgemini); § Erik Proper (architect at Capgemini).

In order to acquire the necessary information we want to know two things. First, what is important when visualising and documenting the IAF using another modelling approach? Second, what do we have to account for when conducting a mapping? In order to achieve this, the following questions were asked during the interviews:

1. How do you use the IAF? a. Artifacts b. Models c. Views

2. What level of detail do you incorporate in your architecture models? 3. What is important when visualising an IAF architecture using a modelling language? 4. What is important when documenting an IAF architecture using a modelling language?

3.1.2 Criteria In this subsection, the criteria are described. First, the criteria derived from the interviews are discussed. Second, the criteria from the literature are elaborated.

Criteria from interviews During the interviews all architects stated that they use the IAF in a very flexible manner, they all applied their own experience in their cases. Recall from section 2.2.3, that the IAF is an artifact framework; it is not a process model. Therefore, there is not a single “correct” way to use it; leaving

22

many choices up to the architect. This results in a lot of flexibility when using the IAF. Architects for instance can choose what artifacts to include, what level of detail they include in these artifacts, etc. Sometimes, this flexibility even goes beyond the borders of the intended use of the IAF. It may occur that extra artifacts are added, or existing artifacts are interpreted differently. Therefore, depending on the customer’s needs, Capgemini architects adapt the IAF to meet the customer’s goals. This leads us to the impact of this flexible use to the mapping. When aiming to incorporate a lot of flexibility it is possible that the mapping is not correct. This is something that has to be avoided. Therefore, ad hoc changes to the IAF are discarded in the mapping. So, the first criterion (C1) is: the mapping is based on the definition of the artifacts that are described in the IAF reference manual (Capgemini, 2007c).

Mr. De Vries pointed out that decision support is one of the key facets of the IAF. It is enabled by showing the consequences of a certain decision, so that the decision with the best (or least worse) consequences can be made. In order to identify consequences of a certain decision, traceability of choices throughout an architecture is crucial. Therefore, traceability for the mapping is also considered important. One needs to know the rationale behind a certain decision in order to re-evaluate it in a later point of time to improve the mapping or to explain the mapping to others. Hence, the third criterion is (C2): clearly document the choices and the rationale behind the choices when mapping the concepts of IAF and ArchiMate.

Another point that came up during the interviews was that very close attention needs to be paid to the objective of the mapping. This means that, close attention needs to be paid to the manner the mapping is defined to solely achieve the objective. Since, the overall purpose of the mapping is to evaluate whether it is possible to visualise and document an IAF architecture using ArchiMate a unidirectional mapping from IAF to ArchiMate has to be conducted, and not the other way around. This is also the third criterion (C3).

Mr. Onderdelinden pointed out that the IAF only incorporates two levels of abstraction, namely services and components. The concepts at the logical and physical layer do not represent another level of abstraction. However, they have a different meaning and serve a different purpose. This means that they can be mapped onto another concept (in ArchiMate). Hence, criterion five is (C4): carefully distinct between logical and physical layer concepts.

In the interview with Mr. De Vries, he pointed out that relations are the facilitators of traceability. Therefore, they are one of the key facets of the IAF. In addition, ArchiMate considers relationships between concepts. Relationships tell how different concepts are related, influencing the expression power of a model. Furthermore, different relations have different properties. Hence, using these relations in a model has a lot of influence on the meaning of such a model. Therefore, (C5) consider the types of relations used in the IAF and ArchiMate models and their mapping.

Furthermore, Mr. Hartman pointed out that the IAF is used at multiple levels in an organization. The IAF can for instance be used at enterprise level where only the very high-level concepts of the architecture are modelled, or at a business domain where much more detail is required. Therefore, there exist relationships between higher and lower level iterations of the IAF. Figure 14 depicts these layers. As can be seen, at every level the IAF can be used totally, but at another level of granularity. Hence (C6), the modelling language should support a low level of detail as well as a high level of detail.

23

Figure 14: Incorporating detail in the IAF

Another observation depicts that the IAF considers the automated as well as the non-automated parts of an organisation. Organisations are a combination of automated and non-automated parts working together to achieve the organisation’s goals. By also modelling the non-automated parts, the choices for not automating these parts can be reconsidered and changed based on principles. In addition, changes in technologies make it possible to automate things that were not possible to automate before. This supports that architecture has a holistic view of an organisation. Therefore, criterion seven (C7) defines that the modelling language should be able to model non-automated as well as automated parts of an organisation.

Mr. Onderdelinden stated that the IAF uses contracts to describe how different concepts work together. These contracts are very important deliverables, for they describe the functional requirements. Hence, they provide a lot of information about an architecture. Therefore (C8), ArchiMate needs to be able to represent IAF contracts.

Mr. Onderdelinden also pointed out that the IAF incorporates only two abstraction levels, namely services and components. Difference in abstraction in this case represents the types of concepts that are represented. For instance a service is grouped into components, which means that the component has a higher level of abstraction. The levels of abstraction help architects to structure the complexity. On the other hand, the limitation to only incorporate two abstraction levels makes it necessary to identify multiple types of architectures, such as, enterprise architecture, domain architecture, and project architecture (the last one is not depicted in Figure 14). Therefore (C9), a modelling language should minimally be able to consider two levels of abstraction.

Related to the previous criterion, it is important that (C10) if two concepts are mapped then they must have the same level of abstraction.

With respect to the level of abstraction, Mr. Proper mentioned that the main difference between the logical and physical layer is the implementation dependency. This defines whether choices for specific vendors to implement an architecture with are already made or not. The logical layer is implementation independent, whereas the physical layer is implementation dependent. Because these layers both define components, they have the same level of abstraction. Therefore when

Relations

Enterprise layer

Businessdomains

24

mapping, close attention needs to be paid to the implementation dependency of concepts. Hence, the following criteria are identified. (C11) A concept that represents an IAF logical layer concept should be implementation independent. (C12) A concept that represents an IAF physical layer concept should be implementation dependent.

No. Name Classification Source Description C1. Artifact definition Mapping creation

criteria I The mapping should be based on the

definition of the artifacts that are described in the IAF reference manual.

C2. Documentation Mapping creation criteria

I Clearly document the choices and the rationale behind the choices when mapping the concepts of IAF and ArchiMate

C3. Unidirectionality Mapping creation criteria

I Define a unidirectional mapping, from IAF to ArchiMate.

C4. Logical/physical layer Mapping creation criteria

I Carefully distinct between logical and physical layer concepts.

C5. Relation types Domain appropriateness

I Consider the types of relations used in the IAF and ArchiMate models in the mapping.

C6. Detail support Domain appropriateness

I the modelling language should support a low level of detail as well as a high level of detail.

C7. Automation Domain appropriateness

I The mapping should be able to address non-automated as well as automated parts of an organisation.

C8. Collaboration Contracts

Domain appropriateness

I ArchiMate needs to be able to represent IAF collaboration contracts.

C9. Levels of Abstraction domain appropriateness

I A modelling language should minimally consider two levels of abstraction.

C10. Same level of abstraction

Domain appropriateness

I Two concepts that are mapped must have the same level of abstraction.

C11. Implementation dependent physical layer

Domain appropriateness

I Any concept that represents an IAF logical layer concept should also be implementation independent.

C12. Implementation dependent logical layer

Domain appropriateness

I Any concept that represents an IAF physical layer concept should be implementation dependent.

Table 2: Summary of interview Criteria

Criteria from literature In this section the criteria adopted from literature are presented. These criteria are diverted from three sources, namely from a master’s thesis on an evaluation framework for architecture modelling methods (Cloo, 2007), from the criteria defined by Nysetvold & Krogstie (2005) in an implementation of the Krogstie quality framework, and from the Ontological foundations of information systems, a book by Weber (1997).

Weber describes a method for ontological analysis (Figure 15). In fact, this is the comparison of a finite set of modelling grammar constructs with a finite set of ontological constructs. With this methodology, one can find a correspondence between constructs with equivalent, similar, or

25

different semantics. By comparing, the commonalities and differences between de modelling grammar and the ontology are examined. This results in a 1:1 mapping or a deviation thereof, called a deficit. Weber distinguishes between two comparison directions. The representation mapping describes the comparison of the ontology with the modelling grammar. The interpretation mapping describes comparison the other way around. Weber further distinguishes between four kinds of deficits, which are elaborated next:

1. Construct deficit: an ontological construct is not present in the modelling grammar. 2. Construct redundancy: there is more than one grammatical construct for at least one

ontological construct. 3. Construct overload: there is more than one ontological construct for one modelling

grammar construct. 4. Construct excess: a grammatical construct with no corresponding ontological equivalent.

Figure 15: Ontological analysis according to Weber (1997)

Since the IAF and ArchiMate are compared in this research, we are going to compare constructs. Therefore, we use the model by Weber to derive additional criteria. Mapping IAF to ArchiMate will most certainly not result in a 1:1 mapping, and will therefore display some kind of deficit, which we will explicate with the model provided by Weber.

26

The criteria below are extracted from the above referred to literature; therefore, the source is not extensively described, for that can be looked up.

No. Name Classification Source Description C13. Hierarchy Domain

appropriateness L It must be possible to make

hierarchical models C14. Guidelines Participant language

knowledge appropriateness

L It should have good guidelines for the use of the language.

C15. Representation Participant language knowledge appropriateness

L The external representation of concepts should be intuitive to the stakeholders.

C16. Number of concepts

Comprehensibility appropriateness

L The number of concepts should be reasonable.

C17. Simplicity Comprehensibility appropriateness

L One should strive for graphical simplicity.

C18. Syntax Technical actor interpretation appropriateness

L The language should have a formal syntax.

C19. Semantics Technical actor interpretation appropriateness

L The language should have formal semantics.

C20. Tool support4 Organisational appropriateness

L The language must be supported by tools that are either already available or can be made easily available in the Organisation.

C21. Construct deficit Comprehensibility appropriateness

L All IAF constructs can be mapped to an ArchiMate equivalent

C22. Construct redundancy

Comprehensibility appropriateness

L There is only one ArchiMate construct mapped to one IAF construct.

C23. Construct overload

Comprehensibility appropriateness

L There is only one IAF construct mapped to one ArchiMate construct.

C24. Construct excess Comprehensibility appropriateness

L All the ArchiMate constructs are mapped to a corresponding IAF construct.

Table 3: Summary of literature criteria

3.2 Mapping method In practice, many different types of models are created, for describing all kinds of real life situations, things, etc. In Computer Science, models have rather been used for a long time to solely document a system instead of using them as a basis for a system. The latter is much more common for instance in the civil engineering discipline, where architecture drawings (i.e. building models) are used for constructing a building.

4 This criterion is not taken into account during the selection of the best mapping alternative, since it cannot be used on separate concepts. However, both IAF and ArchiMate have tool support. For ArchiMate there are several vendors that provide ArchiMate tools, such as TROUX, IDS Scheer, BiZZdesign, Telelogic, Casewise. For IAF there is only one tool called IAFworkbench, which is based on the BiZZdesign Architect.

27

Lately, the Model Driven Architecture (MDA) (Mukerji & Miller, 2003) approach has changed this. MDA uses models to describe architectures, distinguishing four meta-layers: Metameta model, Meta model, model and information, see Figure 16 (Lopes, Hammoudi, Bézivin, & Jouault, 2006). The bottom layer represents the real world, for instance a system. Going up a Meta model describes the collection of available concepts with their properties and relations for the construction of a model. Therefore, a Meta model defines the correspondence between a model and a system. At the top level, the Metameta model describes the language to define a set of Meta models, it gives an abstract syntax of concepts and relationships, and a concrete syntax of shapes, layout, and physical interchange formats.

Figure 16: MDA Meta-layers

In order to protect business logic against changing technologies, MDA uses models to separate platform independent characteristics from platform dependent characteristics. Since MDA is relying on models, different models are constructed and the relations between these models somehow need to be clarified, or models need to be transformed into other models. Hence, MDA uses model transformations and model mappings to realise this.

Model mapping is widely used in order to transform one model into another. A model mapping provides the rules and techniques to do this. Hence, a mapping is referred to as: “a set of rules and techniques used to modify one model in order to get another model.” (Caplat & Sourrouille, 2002). In the MDA domain, a mapping is mainly used for transformation of a Platform Independent Model (PIM) into a Platform Specific Model (PSM). But, also transformations between PIMs and PSMs are considered (Mukerji & Miller, 2003). A PIM is a formal system specification of the structure and functions of a system. A PSM on the other hand, is a formal specification of the implementation of that functionality on a specific technology platform.

In order to obtain the rules and techniques to modify one model in order to get another model the different concepts of both models need to be matched. In this matching process, similar objects and structures of both models are identified. Usually the two different models in the matching process are referred to as a left-hand side and a right-hand side model in order to make it possible to describe bidirectional mappings. In the database domain, model matching is known as schema matching, whereas in the MDA domain it is referred to as model matching. Because manual mapping and matching is a very time consuming and error prone task, an increasing amount of research is conducted on the automatic creation of matches and mappings, both in the MDA and the database domain. On automatic schema matching Rahm & Bernstein (2001) and Shvaiko & Euzenat (2005)

28

provide a good survey. Czarnecki & Helsen (2006) provide a comprehensive survey on model transformation. In order to classify the different approaches the authors all provide a taxonomy.

Figure 17 summarizes the possible model adaptations (matching, mapping and transformation. The arrows represent the order in which these adaptations are carried out. This research considers all three types of model adaptations. First, the IAF and ArchiMate Meta models are matched. Second, from this matching the mapping is created. Finally, the mapping is used to transform an Architecture (system) created using the IAF approach into an ArchiMate one.

Figure 17: Possible model adaptations

In these surveys, the authors make the case for the need for automatic schema matching and model mapping. However, this research is concerned with the matching and mapping of two Meta models, which is always conducted manually, since computers cannot interpret the meaning of concepts. The result of this mapping can be used to automatically transform an IAF model into an ArchiMate model. Nonetheless, since IAF does not have a predefined way to create architecture models, an IAF documented architecture model cannot automatically be transformed into an ArchiMate architecture model. Therefore, automatic mapping is not further considered. However, before throwing all the mapping literature overboard, we consider the essence of the automatic model matching approaches. All the model matching approaches (Shvaiko & Euzenat, 2005) have the same goal; they check if model A and B are semantically and syntactically the same. Since, both the IAF and ArchiMate have Meta models describing their concepts, these are taken as the basis for the matching. By identifying the IAF and ArchiMate concepts that are semantically the same, a mapping of concepts can be created. A similar approach, used to map ArchiMate to UML, is demonstrated by Iacob, Jonkers, and Wiering (2004). This paper demonstrates how the ArchiMate concepts are mapped to the UML concepts. Hereby, the authors make it possible to express ArchiMate models with UML. Since Capgemini wants to know the possibilities of transforming an IAF architecture model into an equivalent ArchiMate model, a similar approach is taken in this research. Therefore, the concepts in the IAF Meta model are matched onto the ArchiMate Meta models. Hereby, selecting the concepts that are semantically the same, this is mapping is presented in section 4.1. The results will most certainly show us areas that deliver challenges in either IAF or ArchiMate; these are further discussed in section 5.2.

In section 3.1 criteria for creation of the mapping have been identified. These criteria define how the mapping should be set up; therefore, they need to be addressed before the mapping is conducted. The remaining criteria are addressed during the mapping. Table 4 gives an overview of the mapping criteria and how they will be addressed during the mapping in section 4.1.

Matching Mapping Trans-formation

29

Mapping criterion How to satisfy? C1. Artifact definition For mapping the IAF onto ArchiMate, only the reference manual and

training material are used as a source of information about concepts. This rules out any deviations of the theory caused by personal interpretations of concepts by Capgemini architects.

C2. Documentation All the choices for possible or not possible maps are extensively described in chapter 4. This assures traceability of the entire mapping so decision motivations can be traced back afterwards.

C3. Unidirectionality The mapping is conducted starting with the IAF concepts and evaluating, which ArchiMate concept could represent this, leaving the unmapped ArchiMate concepts be. This assures that the focus remains on investigating the possibility to transform an IAF architecture model into an equivalent ArchiMate model.

C4. Logical/physical layer

One of the biggest differences between the logical and physical layer in IAF is the implementation dependent character of the physical components. Therefore, it is very important to consider this during the mapping process. This way no implementation independent IAF concepts are mapped to implementation dependent ArchiMate concepts and vice versa.

Table 4: Criteria addressing for the mapping

The essence of a framework is the structured approach, which clarifies complexity, in order to solve a problem or perform a task. Therefore, the structure is often shown as a kind of matrix. See for instance the IAF, which incorporates a 4 by 4 matrix (Figure 5). The individual cells in the matrix represent a small piece of the entire puzzle. When looking closely at the cells of the matrix, it shows that all the cells comprise a number of core concepts describing an entire framework. This is done on purpose. The usage of many different concepts complexity increases and usability reduces, which is something we want to avoid at all times. Hence, these generic concepts describe the essence of an entire framework. However, concepts are specialised or added at specific layers in order to offer sufficient expressive power for particular modelling domains.

This line of thought can be very well used in mapping IAF and ArchiMate to get a quick peak whether the essence of IAF and ArchiMate are the same. This gives a good first insight in mapping IAF and ArchiMate and whether there are challenges, which have to be overcome.

Based on the above argumentation first a mapping of the core concepts of IAF and ArchiMate is created. Depending on the outcome of this preliminary mapping, an overall mapping is done including all concepts of both IAF and ArchiMate. This, as we stated earlier, will probably result in a set of correct mappings. Now the remaining criteria come into play to select the best possible mapping. After this the entire mapping is evaluated, how we are going to do this is stated in the next section.

3.3 Method for evaluating the mapping This subsection describes how the mapping results are evaluated. The ontological analysis approach by Weber describes the quality of a mapping in a structured way; hence, we use this as the basis for the evaluation of the mapping. Weber bases the conclusions of a mapping on the following identified deviations of a 1:1 mapping: construct deficit, construct overload, construct redundancy, and construct excess. We use these deviations in order to assess the best mapping alternative. After this, we try to address and solve these deviations.

30

3.4 Conclusion The goal for this chapter was to answer research question 1a by defining the criteria to assess the mapping:

“What are the criteria for mapping the IAF and ArchiMate Meta models? (prescriptive)”

The criteria of the mapping have been defined by interviewing a number of architects at Capgemini who are involved in lecturing the IAF to other architects. See Appendix D for a summary of all the identified criteria.

Furthermore, research question 1b is answered by defining the mapping approach for the mapping of the IAF and ArchiMate concepts:

“What is the best approach to map the IAF and ArchiMate Meta model concepts? (prescriptive)”

A manual mapping approach is most appropriate. Since, Meta models are always mapped manually. Furthermore, automatic mapping is not considered to transform an architecture model created using the IAF into an ArchiMate architecture model, for there is not a predefined way to create an IAF architecture model.

Both IAF and ArchiMate consist of a set of core concepts describing the essence of respectively the framework and the language. By first mapping these core concepts, the essence of IAF and ArchiMate is mapped. This preliminary mapping provides a first insight in the possibilities of visualising an IAF architecture model using ArchiMate models.

In the next chapter, the mapping approach is applied to create mappings of the IAF and ArchiMate Meta models. The best mapping is selected by validating that mapping best suits the identified criteria.

31

4 Best mapping alternative This chapter presents the best mapping alternatives based on the mapping alternatives and the criteria. First, in section 4.1 a mapping of generic concepts is conducted. This mapping gives a first insight in the mapping of the IAF onto ArchiMate. Second, section 4.2 elaborates the mapping of all the IAF and ArchiMate concepts. Third, the IAF relationships are mapped onto the ArchiMate relationships in section 4.3. Fourth, section 4.4 elaborates the assessment of the mapping based on the criteria from chapter three, which results in the best mapping alternative. Finally, this chapter is concluded with the answer to research question 1.

4.1 Mapping of the core concepts This subsection elaborates the mapping of generic concepts. The mapping can be found in Table 5. The result of the generic mapping is discussed in the remainder of this subsection.

By mapping the generic concepts, the essence of the IAF and ArchiMate is compared. Table 5 shows that most of the IAF core concepts can be mapped onto an ArchiMate equivalent. This means that the core concepts of an IAF architecture can be represented using the core concepts of ArchiMate. However, these results do not give a solid base to draw conclusions on the possibilities to visualise and document an IAF architecture using ArchiMate. It only makes it likely that there are good possibilities to visualise and document an IAF architecture using ArchiMate. The challenge is that both IAF and ArchiMate distinguish multiple rows or layers and columns or aspect areas. These layers comprise of concepts that are slightly adapted to meet the purpose of the layer. The particular division in layers can hugely influence the outcome of the entire mapping.

IAF concept – definition

ArchiMate concept – definition

Rationale

Role – There is no exact definition provided.

Active Structure element – The active structure elements are the business actors, application components and devices that display actual behaviour, i.e., the ‘subjects’ of activity.

In IAF a role executes an activity, which represents behaviour and therefore an IAF role also represents an entity that performs behaviour.

Goal – Goals define what the business needs to achieve in order to fulfil its Objectives

Not represented by a generic concept in ArchiMate. Can be represented by an ArchiMate value.

In the ArchiMate standard there does not exist a generic concept that represents a goal. However, an ArchiMate value, which is not a generic concept, can be mapped to an IAF goal. See subsection 4.2.2.1 for the rationale behind this mapping.

Principle – A statement that defines an objective (or constraint) that is used to determine the organisation and structure of an architecture

Not represented in ArchiMate

In IAF, principles are used for traceability and decision support for customers. This concept is not provided in ArchiMate, but again it is addressed as a possible extension of ArchiMate (H. Jonkers et al., 2008).

32

IAF concept – definition

ArchiMate concept – definition

Rationale

Activity – represents behaviour, consisting of one or a group of tasks to achieve a well-defined goal.

Behavioural element – Represents a unit of internal behaviour.

Both concepts represent behaviour in an organisation, only the relation with a goal is not stated in the ArchiMate definition.

Service – This is a unique element of behaviour in terms of one activity, undertaken by one specific role and that support only one goal.

Service – An externally visible unit of functionality, which is meaningful to the environment and is provided by a business goal. One can distinguish between internal and external services.

Both the IAF and ArchiMate definitions represent behaviour and are provided by a goal. The only point of consideration is the fact that according to the ArchiMate definition of a service, it must be meaningful to the environment. The environment includes behaviour of users outside and inside the organisation. Hence, services that are unique units of behaviour, which are undertaken by at most one role, support a maximum of one goal and are supported by a maximum of one activity. The only constraint is the fact that a service in ArchiMate is not undertaken by a role, but a service realises a behavioural element and a behavioural element is a process, function or interaction. Thus, Indirectly a service in ArchiMate is undertaken by a role. Summarizing, subject to the fact that you have to interpret the ArchiMate definition rather broad, the concept of service in IAF matches the concept of service in ArchiMate.

Component – The basic element of an “ideal” or “To Be” structure created by the grouping of one or more Services.

Service – An externally visible unit of functionality, which is meaningful to the environment and is provided by a business goal. One can distinguish between internal and external services.

Recall that the concept of service in IAF and ArchiMate matches. Note that in IAF, a component is a clustering of services and in ArchiMate, services can be aggregated. This means that the concept of a component in IAF matches the concept of a service in ArchiMate.

Collaboration contract – A Collaboration Contract describes the collaboration and behaviour between Services or between Components.

Not represented in ArchiMate

ArchiMate does not have a core concept that specifies such information.

Solution Alternative – To indicate component or component structure variants for decision support.

Represented by drawing multiple models

There is no concept in ArchiMate, which represents this, but solution alternatives can be easily modelled using ArchiMate by creating multiple models.

Table 5: Generic Mapping

Table 5 shows that the a few generic IAF concepts cannot be mapped to an ArchiMate equivalent. The goal, principle, and collaboration contract concepts are not mapped to an ArchiMate generic concept. Concluding, there are a few areas that might deliver problems, but in general the concepts

33

match. The next section presents the mapping of the layer specific IAF concepts onto ArchiMate concepts.

4.2 Mapping of layer specific IAF concepts onto ArchiMate concepts Since IAF consists of about fifty concepts, it is necessary to have a good structure in this chapter to improve the readability. Since the goal is to examine whether IAF concepts can be mapped onto ArchiMate concepts, the structure of the IAF framework is leading for the arrangement of the remaining subsections. First, the concepts are grouped by layer and then by aspect area within a layer, making it easier to locate concepts.

Another interesting consideration is to use a pattern or group of ArchiMate concepts to represent an IAF concept. This approach is also taken into consideration in this section.

4.2.1 Contextual layer The context in IAF represents the environment of an architecture engagement, consisting of a business mission, vision, and strategy, principles, objectives, constraints and assumptions. This information is not included in ArchiMate on purpose. For, at the time of development it was not considered that these concepts where part of an architecture model. However, there are plans to extend ArchiMate with contextual concepts such as goals, principles, and requirements (H. Jonkers et al., 2008). Therefore, no maps are possible on the contextual layer. Since, ArchiMate does not comprise any concepts on this layer.

4.2.2 Conceptual layer In this subsection IAF concepts residing at the conceptual layer are mapped to ArchiMate concepts, where possible. The conceptual layer in IAF describes an organisation based on the scope, defined in the contextual layer. This layer is divided into four aspect areas, which all have specific concepts. The remainder of this subsection discusses the possible maps of IAF concepts onto ArchiMate concepts at the four aspect areas.

4.2.2.1 Business aspect Business Role In IAF, a business role represents the entity that performs a business activity and can be grouped in an actor. In other words, it represents the business behaviour that is performed by that role. A similar concept exists in ArchiMate. It even has the same name, business role. In ArchiMate, it represents business behaviour that can be grouped by an actor. Hence, both concepts represent business behaviour, which can be grouped by an actor. Therefore, they can be mapped.

ArchiMate does incorporate another concept that represents an entity that performs business behaviour, namely the ArchiMate business actor. However, this concept represents an entity that is able to perform behaviour that is assigned to one or more business roles. Furthermore, the ArchiMate business actor represents physical things, such as people or organisational units. The IAF business role is meant to represent the most elementary unit of business behaviour within the scope of a certain architecture project. Therefore, the IAF business role cannot be mapped to an ArchiMate business actor. Table 6 gives an overview of the possible map.

34

ArchiMate concepts Rationale Business Role Both concepts represent business behaviour, which can be grouped by an

actor. Therefore, they can be mapped. Table 6: Possible map to Business Role

Business Goal IAF business goals define what the business needs to achieve in order to fulfil its business objectives. It therefore, describes the desirable state that is reached when the goal is met. Hence, it describes the value of that action. The value of a service or product can be captured by the ArchiMate value concept. Value in ArchiMate can be specified from two viewpoints, the customers and the organisation. The customer is the person who acquires the service, and the organisation the one providing the service. Hence, an IAF business goal can be mapped to an ArchiMate value.

No additional maps exist, since the ArchiMate value is the only concept that meets the semantical definition of the IAF business goal. Table 7 summarises the above.

ArchiMate concepts Rationale Value IAF business goals define what the business needs to achieve in order to fulfil

its business objectives. Therefore, it describes the desirable state that is reached when the goal is met. Hence, it actually describes the value of that action. The value of a service or product can be captured by the ArchiMate value concept.

Table 7: Possible map to Business Goal

Business Activity A business task or a group of business tasks undertaken to achieve a well-defined goal are defined as business activities in the IAF. They are the most elementary units of behaviour contained in an IAF architecture. Two concepts in the ArchiMate language closely match the above IAF definition of a business activity, the first is a business function and the second a business process.

In ArchiMate, a business function represents a unit of internal behaviour that groups behaviour according to for instance required skills, knowledge, resources, etc. Compared to the IAF Business activity, both concepts represent behaviour in an organisation. Both concepts can group behaviour (IAF groups tasks, and ArchiMate groups behaviour according to a certain property). Finally, both concepts are performed by a maximum of one role. Only the relation with a goal is not stated in the definition. However, it indirectly supports a goal because a business service supports a goal and is constructed of one or more business functions.

A business process also represents a unit of internal behaviour or a collection thereof, intended to produce a defined set of products or services. In addition, an ArchiMate business process is linked to a role. Furthermore, a business process is not directly linked to a business goal, but indirectly. However, a business process in ArchiMate is possibly linked to multiple roles where a business activity in IAF can only be linked to a single role, and a process represents an order of events, which is not meant by the IAF business activity concept. Because of the above argumentation, an IAF business activity does not map to an ArchiMate business process, but only to an ArchiMate business function. Table 8 summarises the possible map.

35

ArchiMate concepts Rationale Business Function In ArchiMate, a business function represents a unit of internal behaviour that

groups behaviour according to e.g. required skills, knowledge, resources, etc. Compared to the IAF business activity, both concepts represent behaviour in an organisation. Both concepts can group behaviour (IAF groups tasks, and ArchiMate groups behaviour according to a certain property). Finally, both concepts are performed by a maximum of one role. Only the relation with a goal is not stated in the definition, but it indirectly supports a goal. For, a business service supports a goal and is constructed of one or more business functions.

Table 8: Possible maps to Business Activity

Business Object There are multiple resources that are used by a business, which can be represented in multiple ways. An IAF business object represents a non-human resource used by the business that is significant to the architecture. This means that this concept does not represent the information of a resource, but the resource itself. It represents for example an insurance policy, but not the information (for instance the rights and obligations) on that policy. In ArchiMate these information carrying objects are not represented. ArchiMate identifies business objects. However, according to the definition, these represent the information of a resource rather than the resource itself. In practice, ArchiMate business objects are used as both the resources and the objects carrying the information. Nevertheless, since this mapping focuses on mapping concepts that are semantically the same, according to their theoretical meaning, an IAF business object cannot be mapped to an ArchiMate business object.

Object Contract How a business service uses a business object is specified in an object contract. It defines the non-functional requirements of a business object. Figure 23 in section 5.3.1 gives an example of a business service collaboration contract, which is comparable to an object contract, but between business services instead of between business services and business objects. ArchiMate contains contracts, but they represent the rights and obligations associated with an ArchiMate product. According to the definition they specify the rights and obligations that a consumer of a product needs to entail to. An IAF object contract specifies the communication properties between a unique set of one IAF business service and one IAF business object. On the contrary, an ArchiMate contract is identical for every customer that consumes a certain product. (Multiple contracts for a single product can be specified, but usually not every customer has a unique contract). Most importantly nevertheless, the IAF object contract is important when designing an architecture and not at runtime in an organisation. Therefore, an IAF object contract cannot be mapped to an ArchiMate equivalent.

Business Service Collaboration Contract An IAF business service collaboration contract specifies how one business service uses another, by defining the non-functional requirements. Figure 23 in section 5.3.1 gives an example of a business service collaboration contract. The name suggests that it could be mapped to an ArchiMate contract. However, according to the ArchiMate definition a contract specifies the legal contract of a service or product. For, it describes the rights and obligations associated with a product or service. This means that the ArchiMate contract is important in the daily (at runtime) organisation. Therefore, it is also a specialisation of a business object. An IAF collaboration contract on the other hand, describes the non-functional requirements between business services. Hence, this type of contract is useful when

36

designing and implementing an architecture. Therefore, a business service collaboration contract does not map to the ArchiMate contract.

Business Service A business service in IAF characterises a unique element of business behaviour in terms of one activity, undertaken by one specific role and that supports only one goal.

The ArchiMate definition on the other hand, is more general. Nevertheless, also models business behaviour and is supports a business goal. The only point of consideration is the fact that according to the definition a business service in ArchiMate must be meaningful to the environment. According to the description of a service in ArchiMate, the environment includes behaviour of users outside and inside the organisation. Hence, services that are unique units of behaviour and are only undertaken by one role, support one goal, and are supported by one activity can be represented. The only constraint is the fact that a service in ArchiMate is not undertaken by a role. But, a service realises a behavioural element and a behavioural element is a process, function, or interaction. Thus, indirectly a service in ArchiMate is undertaken by a role. Summarizing, subject to the fact that one has to interpret the ArchiMate definition rather broad, the concept of service in IAF matches the concept of service in ArchiMate. Below, this is summarised in Table 9.

ArchiMate concepts Rationale Business Service A business service in IAF characterises a unique element of business

behaviour in terms of one activity, undertaken by one specific role and that supports only one goal. The ArchiMate definition on the other hand, is more general. But, also models business behaviour and is supports a goal. The only point of consideration is the fact that according to the definition a business service in ArchiMate must be meaningful to the environment. According to the description of a service in ArchiMate, the environment includes behaviour of users outside and inside the organisation. Hence, services that are unique units of behaviour which are only undertaken by one role, support one goal and are supported by one activity can be represented. The only constraint is the fact that a service in ArchiMate is not undertaken by a role. But, a service realises a behavioural element and a behavioural element is a process, function, or interaction. Thus, indirectly a service in ArchiMate is undertaken by a role. Summarizing, subject to the fact that you have to interpret the ArchiMate definition rather broad, the concept of service in IAF matches the concept of service in ArchiMate.

Table 9: Possible map to Business Service

4.2.2.2 Information aspect Information Object The information in an IAF business object is represented by an information object. Recall that according to the definition, an ArchiMate business object represents the information of a resource, rather than the resource itself. Hence, an ArchiMate business object maps to an IAF information object. An ArchiMate data object could also possibly map to an IAF information object. Since, it also represents information. But, according to the definition of an ArchiMate data object, the information in a data object must be suitable for automated processing. The information in an IAF information object represents all kinds of information either suitable or unsuitable for automated

37

processing. Hence, an ArchiMate data object does not match with an IAF information object. Table 10 summarises the above.

ArchiMate concepts Rationale Business Object The business object in ArchiMate and the Information object in IAF both

represent information that is important to a business. Table 10: Possible maps to Information Object

Business Information Service Business information services describe how a business service uses an information object. It extends a business service with communication behaviour. There exists a one to one relationship between business services and business information services. ArchiMate does describe the way a business service uses a business object. However, these relations are not grouped in a concept. Moreover, the business information service contains some extra information, considering security and governance. It is not possible to specify this information in ArchiMate. Hence, there are no feasible maps between a business information service and any of the ArchiMate concepts.

Another possible map would be an ArchiMate application service. This concept represents an externally visible unit of functionality, which is realized by one or more application functions that are performed by an application component. It may require, use, and produce data objects. When closely looking at the scope of the application service, we see that it specifies automated functionality. In IAF, a business information service represents both behaviour that can be automated, and behaviour that cannot be automated. This is a major difference. Therefore, an IAF business information service cannot be mapped to an ArchiMate application service.

However, when considering a pattern of ArchiMate concepts to represent this concept, it can be represented using an ArchiMate business service, business object and access relationships. For, an IAF business service maps to an ArchiMate business service. Furthermore, an IAF information object maps to an ArchiMate business object. Finally, how the two former IAF concepts use each other can be represented using the access relationship type in ArchiMate. However, ArchiMate does not provide a concept in which these services can be grouped. To illustrate such a pattern, an example of is depicted in Figure 18. This picture is modelled using the BiZZdesign Architect tool. The above is summarised in Table 11.

Figure 18: Business Information Service mapping

Transport fishEnvironment Log

Route

get transform

get

Business Information Service

38

ArchiMate concepts Rationale Business Service, Business Objects, access relationships

Business information services describe how a business service uses an information object. It can be represented using a pattern of the following ArchiMate concepts: business service, business objects, and access relationships, for an IAF business service maps to an ArchiMate business service and an IAF information object maps to an ArchiMate business object, and how the two former IAF concepts use each other can be represented using the access relationship in ArchiMate. However ArchiMate does not provided a concept in which these services can be grouped.

Table 11: Possible map to Business Information Service

Business Information Service Collaboration Contract The business information service collaboration contract is comparable to the business service collaboration contract. However, it considers business information services instead of business services. ArchiMate does not specify any concepts that are comparable to a business information service collaboration contract. Therefore, no maps are possible.

4.2.2.3 Information System aspect Information System Service An information system service describes an element of behaviour of information automation, required to support automated business information services. Thus, it describes behaviour that is automated by an information system.

This concept possibly maps to a few ArchiMate concepts. First, an information system service could possibly map to an application service. For, they both represent behaviour that is meaningful to the environment for information automation. Second, an information system service could possibly map to an application function. For, it equally to the information system service represents behaviour that is automated by an information system or information system component. Below, the possible maps are summarised in Table 12.

ArchiMate concepts

Rationale

Application Service

Both the application service and information system service represent behaviour that is meaningful to the environment and meant for information automation.

Application Function

Both an application function and a information system service represent behaviour that is automated by an information system (component).

Table 12: Possible maps to Information System Service

Information System Service Collaboration Contract The information system service collaboration contract is comparable to the business service collaboration contract. However, it considers information system services instead of business services. ArchiMate does not specify any concepts that are comparable to an information system service collaboration contract. Therefore, no maps are possible.

4.2.2.4 Technology Infrastructure aspect Technology Infrastructure Service A technology infrastructure service describes the behaviour of services that primarily support the information system services and may directly support generic business objectives. An ArchiMate concept that matches this definition is an infrastructure service. For, they both represent behaviour. Another point is that Infrastructure services in ArchiMate support application services, because

39

ArchiMate infrastructure services are used by ArchiMate application services. This matches with IAF technology infrastructure services that support IAF information system services. Hence, an IAF technology infrastructure service is mapped to an ArchiMate infrastructure service. Below, Table 13 summarises the possible map.

ArchiMate concepts Rationale Infrastructure Service

An ArchiMate concept that matches the technology Infrastructure service definition is an infrastructure service. For, they both represent behaviour. Another point is that Infrastructure services in ArchiMate support application services, because ArchiMate infrastructure services are used by ArchiMate application services. This matches with IAF technology infrastructure services that support IAF information system services.

Table 13: Possible map to Technology Infrastructure Service

Technology Infrastructure Service Collaboration Contract The technology infrastructure service collaboration contract is comparable to the business service collaboration contract. However, it considers technology infrastructure services instead of business services. ArchiMate does not specify any concepts that are comparable to a technology infrastructure service collaboration contract. Therefore, no maps are possible.

4.2.3 Logical layer The logical layer in IAF describes the ideal situation of an organisation, based on the principles and concepts defined in the conceptual layer. This layer is divided in four aspect areas, which all have specific concepts. In the remainder of this subsection, these concepts are discussed and possibly mapped to ArchiMate concepts.

4.2.3.1 Business aspect Actor In IAF, an actor represents a grouping of roles. In ArchiMate there also exists an actor, this actor is defined as an organisational entity that is capable of performing behaviour. An ArchiMate business actor does not directly group roles. But, it is assigned to one or more roles. Thus, it represents a group of business roles. Therefore, it is a possible map to an IAF actor. Another possible map is a business role. Since, an IAF actor is a grouping of business roles. Thus, it is still a business role. To represent this, ArchiMate must grouping of ArchiMate business roles. ArchiMate supports this by the possibility to aggregate ArchiMate business roles. The third possible map would be a business collaboration, since it also groups two or more business roles. However, this results in specific collective behaviour in a particular context. A grouping of business roles in IAF does not result in specific behaviour. But, only groups the behaviour of the included roles. Hence, this concept is not considered a possible map. Below, the possible maps are summarised in Table 14.

ArchiMate concepts

Rationale

Business Actor

In IAF, an actor represents a grouping of roles. In ArchiMate there also exists an actor, this actor is defined as an organisational entity that is capable of performing behaviour, an ArchiMate business actor does not directly group roles, but it is assigned to one or more roles. Thus, it represents a group of business roles and therefore it is a possible map to actor.

40

ArchiMate concepts

Rationale

Business Role

An IAF actor is a grouping of business roles. Thus, still a business role, and in ArchiMate, it is possible to aggregate several business roles into one business role.

Table 14: Possible maps to Actor

Logical Business Component A logical business component is a grouping of business services based on principles, in such a way that the ideal groups are formed. Since, an IAF business services maps to an ArchiMate business service it is very likely that a grouping of business services in IAF is also represented by an ArchiMate business service. The ArchiMate structure allows us to aggregate concepts, including business services. Hence, an ArchiMate business service also possibly maps to an IAF logical business component. Below, the above map is summarised in Table 15.

ArchiMate concepts Rationale Business Service A logical business component is a grouping of business services based on

grouping criteria created from the principles, in such a way that the ideal groups are formed. Since, an IAF business services maps to an ArchiMate business service it is very likely that a grouping of business services in IAF is also represented by an ArchiMate business service. The ArchiMate structure allows us to aggregate concepts, including business services. Hence, an ArchiMate business service also possibly maps to an IAF logical business component.

Table 15: Possible map to Logical Business Component

Logical Business Component Collaboration Contract This concept represents the aggregation of business service collaboration contracts that reside between the grouped business services (in IAF called components). Since, nor a business service collaboration contract is mapped to an ArchiMate concept, neither the logical business component collaboration contract does.

Logical Process Component A process component in IAF represents a group of business activities, which are logically grouped together. Logically, one would say that this concept maps to an ArchiMate business process. But, this is not as straightforward as it seems. The granularity of both concepts plays a crucial role. A logical process component in IAF groups business services according to grouping criteria, derived from the principles. A business process in ArchiMate defines a unit of internal behaviour, or collection of causally related units of internal behaviour intended to produce a defined set of products and services. The picture below shows how business process and business services are related in ArchiMate. In the figure, a dashed line with a closed arrow represents a realisation relation, and a closed line with an open arrow represents a used by relation. From the figure follows, that an internal business service is used by a business process. Recall that a business service in ArchiMate maps to an IAF business service. From the picture below follows, that an ArchiMate business process uses one or multiple ArchiMate business services. Hence, the granularity of both the ArchiMate and IAF concepts are the same and an ArchiMate business process maps to an IAF Logical Process Component. Table 16 summarises the above.

41

Figure 19: ArchiMate concepts Business layer

ArchiMate concepts Rationale Business Process A logical process component in IAF groups business services according to

grouping criteria, derived from the principles. A business process in ArchiMate defines a unit of internal behaviour, or collection of causally related units of internal behaviour intended to produce a defined set of products and services. Recall, that a business service in ArchiMate maps to an IAF business service, and from Figure 19 follows that an ArchiMate business process uses one or multiple ArchiMate business services. Hence, the granularity of both the ArchiMate and IAF concept are the same and an ArchiMate business process maps to an IAF Logical Process Component.

Table 16: Possible map to Logical Process Component

4.2.3.2 Information aspect Logical Information Component This concept represents grouped information objects. These information objects have been clustered into ideal groups, according to grouping criteria based on the principles. Thus, it does not represent any more than an aggregation of information objects. Hence, a logical information component maps to an ArchiMate business object. Another ArchiMate concept that possibly could represent the logical information component is a data object. However, the data object in ArchiMate represents information that is suitable for automated processing. An IAF logical information component can represent information that is either suitable or unsuitable for automated processing. It can represent all types of information in the business. Therefore, the map to an ArchiMate data object is not possible. Table 17 summarises the above.

ArchiMate concepts Rationale Business Object A logical information component represents a group of information objects.

Since an information object is possibly mapped to a business object and business objects can be aggregated in ArchiMate, business objects possibly also map to logical information objects.

Table 17: Possible map to Logical Information Component

Logical Business Information Component As we earlier mentioned, IAF components group IAF services. This concept groups business information services. Because a business information service cannot be represented using a single ArchiMate concept. It is also not possible to map the logical business information component to a single ArchiMate concept. However, when considering a pattern of concepts, a logical business information component can be mapped to the pattern consisting of the following ArchiMate concepts: business services, business objects, and access relationships. An example of such a pattern is depicted in Figure 20.

ExternalBusiness Service

Business Function InternalBusiness Service

Business Process

Business Layer

42

Figure 20: Pattern map to Logical Business Information Component

ArchiMate concepts Rationale Business Services, Business Objects, and access relationships

A logical business information component groups business information services, which are represented by a description of how they use IAF information objects. In ArchiMate there does not exist a single component to do this. However, recall from a business information service that it can be represented using a pattern of ArchiMate business services, business objects and access relationships. Because, a component is nothing more than a grouping of services, the logical business information component can be represented using the same concepts as for a business information service, with one major change. In the component multiple business services are used to represent the component. This is in contrast with the business information service, where only one business service is used.

Table 18: Possible map to Logical Business Information Component

Logical Business Information Collaboration Contract This concept represents the aggregation of business information service collaboration contracts that reside between the grouped business information services (in IAF called components). Since, nor a business information service collaboration contract is mapped to an ArchiMate concept, neither the logical business information component collaboration contract does.

4.2.3.3 Information System aspect Logical Information System Component The logical information system component represents ideally clusters of information system services, grouped according to grouping criteria (based on the principles). Recall, that an information system service is possibly mapped to an ArchiMate application service. Hence, a logical information system service is also possibly mapped to an application service, because of the possibility to aggregate application services in ArchiMate.

Other than the application service, an information system service can also be mapped to an ArchiMate application component. An ArchiMate application component represents a modular, deployable, and replaceable part of a system. In practice, this component represents implementation independent parts of a software system, such as a customer management component. This is similar to the IAF logical information system component. This concept groups information system services into a component. This component represents a part of a system, for instance a customer management component. Hence, these two concepts form a possible map. Table 19 summarises the above.

Transport fishEnvironment Log

Route

Catch fish

Fish

get transform

get write

write

Logical Business Information Component

43

ArchiMate concepts Rationale Application Service The logical information system component represents ideal clusters of

information system services, grouped according to grouping criteria (based on the principles). Recall, that an information system service is possibly mapped to an ArchiMate application service. Hence, a logical information system service is also possibly mapped to an application service, because of the possibility to aggregate application services in ArchiMate.

Application component

An ArchiMate application component represents a modular, deployable, and replaceable part of a system. In practice, this component represents implementation independent parts of a software system, such as a customer management component. This is similar to the IAF logical information system component. This concept groups information system services into a component. This component represents a part of a system, for instance a customer management component.

Table 19: Possible map to Logical Information System Component

Logical Information System Collaboration Contract This concept represents the aggregation of information system service collaboration contracts that reside between the grouped information system services (in IAF called components). Since, nor an information system service collaboration contract is mapped to an ArchiMate concept, neither the logical information system component collaboration contract does.

4.2.3.4 Technology Infrastructure aspect Logical Technology Infrastructure Component This concept represents clustered technology infrastructure services. These technology infrastructure services have been clustered into ideal groups, according to grouping criteria based on the principles. In ArchiMate, technology infrastructure services are possibly mapped to infrastructure services. As mentioned earlier, it is possible to aggregate concepts in ArchiMate. Hence, IAF logical technical infrastructure components can be possibly mapped to ArchiMate infrastructure services. Table 20 summarises the above.

ArchiMate concepts Rationale Infrastructure Service

This concept represents clustered technology infrastructure services. These technology infrastructure services have been clustered into ideal groups, according to grouping criteria based on the principles. In ArchiMate, technology infrastructure services are possibly mapped to infrastructure services. As mentioned earlier, it is possible to aggregate concepts in ArchiMate. Hence, IAF logical technical infrastructure components can be possibly mapped to ArchiMate infrastructure services.

Table 20: Possible map to Logical Technical Infrastructure Component

Logical Technology Infrastructure Component Collaboration Contract This concept represents the aggregation of technology infrastructure service collaboration contracts that reside between the grouped technology infrastructure services (in IAF called components). Since, nor a technology infrastructure service collaboration contract is mapped to an ArchiMate concept, neither the logical technology infrastructure component collaboration contract does.

44

4.2.4 Physical layer This layer determines the physical objects, processes, organisation structures, information structures, and application structures, such as computers, servers, routers, service busses, packages, etc that are needed to reach an organisations’ goals. Here, the logical components may be changed due to for instance physical limitations, technological limitations, limited availability resources, etc. Hence, the physical layer describes the feasible situation.

The physical layer represents three concepts that are present in every aspect area. These concepts are specifications, guidelines, and standards. These concepts are discussed below, for there are not any ArchiMate concepts that can be possibly mapped to a specification, guideline, or standard at none of the aspect areas.

Specification A specification in IAF specifies what the design and implementation of the concepts on the different aspect areas will be realised with. ArchiMate is limited to describing the elements of an architecture and does not describe the development properties.

Guidelines Guidelines define what flexibility is allowable with the design and implementation. The ArchiMate concepts do not specify what the guidelines for concepts are; only the concepts themselves are specified.

Standards This concept specifies what the design and implementation of the architecture must conform and comply with. The ArchiMate concepts only specify the physical IT concepts such as a server. However, they do not specify what such a server has to conform to or comply with. Therefore, there are no possible maps.

4.2.4.1 Business aspect Physical Business Component Physical business components consist of several artifacts that describe the physical business side of an organisation. Such artifacts are for instance organisation models, governance models, process models, job specifications, etc. Actors in ArchiMate can be physical entities according to the definition. Hence, they are a possible map to an IAF physical business component. Nevertheless, an actor just forms a very small part of a physical business component in ArchiMate. Wherefore, the map is just partial. Table 21 summarises the above.

ArchiMate concepts Rationale Business Actor Actors in ArchiMate can be physical entities according to the definition.

Hence, they are a possible map to business component. Nevertheless, an actor just forms a very small part of a physical business component in ArchiMate. Wherefore, the possible map is just partial

Table 21: Possible map for Physical Business Component

Physical Business Component Collaboration Contract The physical business component collaboration contract consists of one or more logical business component collaboration contracts that have been grouped according to grouping criteria derived from the principles. Only this time the aim is to define the feasible situation instead of the ideal situation, which was aimed for at the logical layer. Since, nor a logical business component

45

collaboration contract can be mapped to an ArchiMate concept, neither can the physical business component collaboration contract.

4.2.4.2 Information aspect Physical Information Component A physical information component represents the implementation dependent description of a structured physical component that comprises one or more Logical Information Components. On first sight, this matches with the description of an artifact in ArchiMate. For, according to the definition, an ArchiMate artifact is a physical piece of information. However, the information characterised with this component is at a different abstraction level. Furthermore, an artifact only represents information that is considered in an automated environment. On the other hand, an IAF physical information component also considers information that will not be automated. Hence, there is no possible map.

Physical Business Information Component This concept clusters one or more logical business information components. Since, it is not possible to map a logical business information component to an ArchiMate concept, the logical business information component also cannot be mapped to an ArchiMate equivalent..

Physical Business Information Component Collaboration Contract The physical business information component collaboration contract consists of one or more logical business information component collaboration contracts that have been grouped according to grouping criteria derived from the principles. Only this time the aim is to define the feasible situation instead of the ideal situation, which was aimed for at the logical layer. Since, nor a logical business information component collaboration contract can be mapped to an ArchiMate concept, neither can the physical business information component collaboration contract.

4.2.4.3 Information System aspect Physical Information System Component A physical information component represents the implementation dependent description of a structured physical component (for instance a software component) that comprises one or more Logical Information System Components. An ArchiMate application service possibly maps to this IAF concept. For, they both represent software system components.

However, this is not the only possible map. It is also possible to represent an IAF physical information system component using an ArchiMate artifact. This concept is defined as a physical piece of information that is used or produced in a software development process, or by deployment and operation of a system. According to this definition an ArchiMate artifact can represent a software product. This is exactly what we want to represent using a physical information system component. Hence, an IAF physical information system component possibly maps to an ArchiMate artifact. Table 22 summarises the above.

ArchiMate concepts Rationale Application Component

A physical information component represents the implementation dependent description of a structured physical component (for instance a software component) that comprises one or more Logical Information System Components. An ArchiMate application service possibly maps to this IAF concept. For, they both represent software system components.

46

ArchiMate concepts Rationale

Artifact An artifact is defined as a physical piece of information that is used or produced in a software development process, or by deployment and operation of a system. According to this definition an ArchiMate artifact can represent a software product. This is exactly what we want to represent using a physical information system component.

Table 22: Possible maps to Physical Information System Component

Physical Information System Component Collaboration Contract The physical information system component collaboration contract consists of one or more logical information system component collaboration contracts that have been grouped according to grouping criteria derived from the principles. Only this time the aim is to define the feasible situation instead of the ideal situation, which was aimed for at the logical layer. Since, nor a logical information system component collaboration contract can be mapped to an ArchiMate concept, neither can the physical information system component collaboration contract.

4.2.4.4 Technology Infrastructure aspect Physical Technology Infrastructure Component This concept defines the implementation dependent description of a structured infrastructure component that comprises one or more logical technology infrastructure components. These implementation dependent components can be network nodes, such as firewalls, servers, etc. ArchiMate specified a number of concepts that describe an implementation dependent infrastructure, namely system software, node, device, communication path, and network. These ArchiMate concepts are extracted from the UML 2.0 standard, and according to their definitions describe an infrastructure very specific. An IAF infrastructure component does not describe individual devices, hence an IAF infrastructure component does not map to an ArchiMate device. Also ArchiMate networks describe too specific information compared to the IAF infrastructure components, hence it cannot be mapped to an ArchiMate network. Table 23 summarises the above.

ArchiMate concepts Rationale Node A node in ArchiMate represents a computational resource, which is e.g. used

to model application servers, database servers or client workstations. The IAF physical technology infrastructure component also represents these types of concepts (servers, computers, etc).

System Software An ArchiMate software system represents the software environment for specific types of components and objects that are deployed on it in the form of artifacts. Physical business components also represent software systems, such as operating systems, hence these two concepts are mapped.

Communication path

ArchiMate communication paths describe the communication relations between two nodes, such as message queuing between them. IAF uses physical technology infrastructure components to describe this.

Table 23: Possible maps to Physical Technology Infrastructure Component

Physical Technology Infrastructure Component Collaboration Contract The physical technology infrastructure component collaboration contract consists of one or more logical technology infrastructure component collaboration contracts that have been grouped according to grouping criteria derived from the principles. Only this time the aim is to define the feasible situation instead of the ideal situation, which was aimed for at the logical layer. Since, nor a

47

logical technology infrastructure component collaboration contract can be mapped to an ArchiMate concept, neither can the physical technology infrastructure component collaboration contract.

4.3 Mapping of relations Both IAF and ArchiMate consider relations between concepts as very important. Relationships in IAF are used to deliver traceability throughout the layers and link related concepts to each other. To link concepts to each other, the IAF defines only a single type of relationship, the association relationship. So for a business information service interaction model where business services are linked with information objects or for the grouping of services into components the same type of relationship is used. ArchiMate on the other hand, has defined several types of relationships:

§ (G) Aggregation relationship § (C) Composition relationship § (I) Assign relationship § (R) Realisation relationship § (U) Uses relationship § (A) Access relationship § (O) Association relationship § (S) Specialisation relationship § (T) Triggering relationship § (F) Flow relationship

These relationships are used in order to link the different concepts to each other. Each relationship type has different properties defining their strength. The strength is defined in order to provide the possibility to compose multiple relationships into a single one, between two concepts that have no direct relationship according to the Meta model (van Buuren, Jonkers, Iacob, & Strating, 2004). For example, there is no direct relationship between system software and an infrastructure service in ArchiMate. However, both concepts have a relationship with node. In order to derive relationships, the strength of the different types of relationships is specified. The direct relationship between system software and an infrastructure service is equivalent to the weakest relationship that resides between a software component, node, and an infrastructure service. In this case, the direct relationship between a software component and an infrastructure service is a specialisation relationship, because according to the picture below, this is the weakest relationship. The multiple different relationships and the possibility to combine them give ArchiMate a high expressive power.

Figure 21: Composition of relationships in ArchiMate

Table 24 shows what types of relationships are possible between the ArchiMate concepts. The depicted ArchiMate concepts all have an IAF concept mapped to them. The IAF concepts also have possible relationships between them. The grey coloured relations depict relations that are possible

NodeInfrastructure Service

System Software

Strength: 7

Strength: 4

Hence, a specialisationrelationship

48

between ArchiMate concepts. In order to create a correct model of an IAF architecture using ArchiMate, these relations between IAF concepts need to be expressed in ArchiMate. Therefore, the black coloured relations indicate the relationships between the ArchiMate concepts that are necessary to correctly model an IAF architecture. The types of relationships are depicted below. No relationships were missing, so all the necessary relationships between IAF concepts could be modelled using ArchiMate. This shows us that the expressiveness of ArchiMate is much higher, when comparing it to the IAF. In the first place, in ArchiMate many more relationship types are identified. These relationship types gives a greater flexibility in expressing the kind of relationship between two concepts.

AM – IAF concept

Busi

ness

Rol

e –

Role

Busi

ness

Obj

ect –

In

form

atio

n O

bjec

t

Busi

ness

Ser

vice

– B

usin

ess

Se

rvic

e /

Com

p.

Busi

ness

Fun

ctio

n –

Busi

ness

Act

ivit

y

Val

ue –

Bus

ines

s G

oal

App

licat

ion

Ser

vice

– IS

Se

rvic

e

App

licat

ion

Com

pone

nt –

IS

Com

pone

nt

Infr

astr

uctu

re S

ervi

ce –

TI

Serv

ice

/ Co

mpo

nent

Nod

e –

Phys

ical

TI

Com

pone

nt

Syst

em S

oftw

are

– Ph

ysic

al

TI C

ompo

nent

Art

ifact

– P

hysi

cal I

S Co

mpo

nent

Com

mun

icat

ion

path

–

Phys

ical

TI C

ompo

nent

Business Role – Role cfgiostu

ao ioru fiou o oru fotu o o o o o

Business Object – Information object

o cgos o o o o o o o o o o

Business Service – Business Service / Comp.

ou ao cfgostu

ou o fotu ou o o o o o

Business Function – Business Activity

fou ao ou cfgostu

O oru ou o o o o o

Value – Business Goal o o o o cgos

o o o o o o o

Application Service – IS service

ou ao fotu ou o cfgostu

ou o o o o o

Application Component – IS component

fotu ao ioru iou o ioru cfgostu

o o o o o

Infrastructure Service – TI Service / Component

aou aou aou aou o aou aou cfgostu

ou ou aou ou

Node – Physical TI Component

aou aoru aoru aoru o aoru aoru ioru cfgostu

cfgiostu

aiou ioru

System Software – Physical TI Component

aou aoru aoru aoru o aoru aoru ioru cfgostu

cfgiostu

aiou Ioru

Artifact – Physical IS component

ou aoru oru oru o oru oru o o o cgos o

Communication path – Physical TI Component

o o o o o o o o o o o cgos

Possible relations ArchiMate Necessary relations for mapping IAF

Table 24: Mapping of relations

49

Concluding, because the expressiveness of ArchiMate is much higher, all the possible IAF relationships can be mapped to ArchiMate. However there are some deficits in the mapping. Table 24 shows a relation redundancy and relation excess according to Weber. The relation excess comes from the fact that there are multiple possible relationship types in ArchiMate and only one in IAF. The relationship redundancy is due to the fact that some IAF relationships between concepts can be represented by multiple ArchiMate relationship types.

4.4 Best mapping alternative In this section, the possible mapping alternatives are evaluated, and the best mapping is chosen based on the criteria defined in section 3.1. There are also IAF concepts that have only one possible ArchiMate map. Automatically these concepts represent the best mapping alternatives. Table 25 shows the possible mappings and depicts the criteria that are satisfied by a possible mapping. A checkmark specifies that a criterion is met, a dash indicates that the criterion is not applicable to a certain concept, and an X indicates that a criterion is not satisfied. Based on the results the best mapping alternatives are selected. The best mapping alternatives are depicted using white rows. A graphical image of the total mapping is depicted in Appendix E. Recall from section 3.1.2, that the criteria grouped under the category ‘mapping criteria’ are only applicable to the entire mapping and not to the individual concepts. Therefore, only the visualisation and documentation criteria are taken into consideration in the remainder of this chapter. The remainder of this chapter discusses the IAF concepts that have multiple possible maps to ArchiMate concepts.

Information System Service All services on the logical layer have the same level of abstraction. Therefore, it is important that the ArchiMate concept that is mapped to that IAF concept also considers the same level of abstraction throughout the layers. This is derived from criterion C10. Since, an ArchiMate business service and infrastructure service respectively map to an IAF business service and technology infrastructure service. The ArchiMate application service maps to an IAF information system service, in order to meet criterion C10. Hereby, criterion C23 is ignored because all other concepts at the logical layer are represented by the same concepts as the conceptual layer.

Actor Recall that an IAF actor has two possible ArchiMate maps. Both ArchiMate concepts do not satisfy all the criteria. A business actor in ArchiMate represents physical organisational entities, which do not belong at the logical layer, but at the physical layer. Hence, criterion C10 is not satisfied. An IAF business role is also mapped to an ArchiMate business role. Therefore, it does not satisfy criterion C23. However, for the same reasons as the information system service, this criterion is neglected. Thus, the map between an IAF actor and an ArchiMate business role is considered the best match.

Logical Information System Component This concept possibly maps to two ArchiMate concepts: an application service, or an application component. The application component satisfies all the criteria. Because the application service is used to represent multiple concepts when mapped to logical information system component, it fails criterion C23. The application component on the other hand satisfies all the criteria. Therefore, the application component is the best possible match.

50

Physical Information System Component Because an application component is implementation independent, criterion C12 is not satisfied. In addition, criterion C23 is not satisfied, because it is already considered the best map for the logical information system component. The artifact on the other hand satisfies all the criteria. Hence, a physical information system component is best mapped to an Artifact.

Physical Technology Infrastructure Component A physical technology infrastructure component can represent multiple things. In ArchiMate some of these concepts have been split. Therefore, both the ArchiMate node and system software concepts are possible representations of an IAF physical technology infrastructure component.

4.5 Conclusion The goal for this chapter was to answer research question 1 by discussing the mapping alternatives and selecting the best one:

How can the Integrated Architecture Framework and ArchiMate Meta models best be mapped? (descriptive)”

In order to identify the best mapping alternative (see Table 25), all the possible mapping alternatives were discussed. This best mapping alternative is based on what alternative satisfies the most criteria. However, even the best mapping alternative does not satisfy all criteria. An overview of the criteria satisfaction by the mapping alternatives is depicted in Table 25. The results are further evaluated in the next chapter.

51

5 Mapping evaluation This chapter discusses the mapping results presented in chapter 4. This chapter’s goal is to identify problem areas and possible solutions to overcome the problem areas. First, section 5.1 discusses the mapping results. Second, section 5.2 identifies the problem areas. After this, section 5.3 describes the possible solutions to overcome or avoid the identified problem areas. Finally, this chapter is concluded with the answer to research question 2.

5.1 Evaluation mapping results In order to draw conclusions on the proposed mapping, the results need to be evaluated. This is achieved by discussing the best mapping alternative based on the criteria, presented in Table 25. Special attention goes to criteria C21-C24, distracted from the literature by Weber. We start by discussing oddities in the results of Table 25.

5.1.1 Discussion criteria One thing that is directly noticed is that criteria C8, C14, C16, C17, and C20 are not applicable to any of the possible maps. This is due to the fact that these criteria are not applicable to single maps but to the entire mapping. Therefore, these are discussed below.

Criterion C8 addresses the importance of collaboration contracts. Since, collaboration contracts are not represented in ArchiMate. This criterion is not met in the mapping. Criterion C14 addresses that the modelling language should have good usage guidelines. At this moment a technical standard is produced for ArchiMate, furthermore there are some books and multiple articles on the usage of ArchiMate. Hence, this criterion is met for the ArchiMate language. On the other hand, the usage guidelines for the IAF are much more ambiguous, due to the fact that the way to use the IAF is not strictly specified. Therefore, knowledge about the IAF as well as knowledge about architectures in common is necessary to create an architecture using to the IAF.

Criterion C16 defines that the number of concepts must not be excessive, because this negatively influences the usability of a framework or modelling language. Both IAF and ArchiMate consist of about fifty concepts, which is not an excessive amount. Hence, the mapping also does not exceed that amount. Criterion C17 specifies that one should strive for graphical simplicity. This is something that is extensively covered in ArchiMate. For instance, the possibility to compose relationships between concepts is positively influencing the simplicity of ArchiMate models. IAF on the other hand does not specify a standard way to model an architecture. Therefore, an architecture modelled using the IAF can vary in simplicity depending on the chosen way to visualise it. This is also considered one of the reasons for this research. Hence, this criterion gives us some insight in the usability of ArchiMate as a modelling language.

52

Table 25: Best mapping alternatives

5.1.2 Discussion Weber criteria In this subsection, the criteria from the ontological analysis method by Weber are evaluated.

Detail support – C6Autom

ation – C7Collaboration Contracts – C8

Levels of Abstraction – C9

Same level of abstraction - C10

Impl. indep. logical layer - C11

Impl. D

ep. Physical layer - C12H

ierarchy - C13G

uidelines - C14Representation - C15

Num

ber of concepts - C16Sim

plicity - C17Syntax – C18

Semantics – C19

Construct deficit – C21

Construct redundancy – C22

Construct overload – C23

Construct excess – C24

IAF Concept ArchiMate concept

IAF concepts with multiple possible maps1 Information System Service

Application Service

√ √ - √ √ - - √ - √ - - √ √ √ √ √ √

Application function

√ √ - √ X - - √ - √ - - √ √ √ √ √ √

Actor

Business Actor √ √ - √ X X - √ - √ - - √ √ √ √ √ √

Business Role √ √ - √ √ √ - √ - √ - - √ √ √ √ X √

Logical Information System Component

Application Service

√ √ - √ √ √ - √ - √ - - √ √ √ √ X √

Application Component

√ √ - √ √ √ - √ - √ - - √ √ √ √ √ √

Physical Information System Component

Application Component

√ √ - √ √ - X √ - √ - - √ √ √ √ X √

Artefact √ √ - √ √ - √ √ - √ - - √ √ √ √ √ √

Physical Technology Infrastructure Component2

Node √ √ - √ √ - √ √ - √ - - √ √ √ X √ √

System Software √ √ - √ √ - - √ - √ - - √ √ √ X √ √

Comm. path √ √ - √ √ - - √ - √ - - √ √ √ X √ √

IAF concept with single possible map1 Business Role Business Role √ √ - √ √ - - √ - √ - - √ √ √ √ X √

Business Activity Business Function √ √ - √ √ - - √ - √ - - √ √ √ √ √ √

Business Service Business Service √ √ - √ √ - - √ - √ - - √ √ √ √ X √

Business Goal Value √ √ - √ √ - - √ - √ - - √ √ √ √ √ √

Information Object Business Object √ √ - √ √ - - √ - √ - - √ √ √ √ X √

Technical Infrastructure Service

Infrastructure Service

√ √ - √ √ - - √ - √ - - √ √ √ √ X √

Logical Business Component Business Service √ √ - √ √ √ - √ - √ - - √ √ √ √ X √

Logical Process Component Business Process √ √ - √ √ √ - √ - √ - - √ √ √ √ √ √

Logical Information Component

Business Object √ √ - √ √ √ - √ - √ - - √ √ √ √ X √

Logical Technology Infrastructure Component

Infrastructure Service

√ √ - √ √ √ - √ - √ - - √ √ √ √ X √

Physical Business Component Business Actor √ √ - √ √ - √ √ - √ - - √ √ √ √ √ √ 1The WHITE lines represent the best mapping alternative 2All alternatives are part of the best mapping alternative

53

Construct deficit The construct deficit criterion (C21) states that all IAF constructs should be mapped to at least one ArchiMate construct. Table 25 projects a wrong image, because it states that all IAF concepts have one or more ArchiMate equivalents mapped to it, since all the concepts comply with the construct deficit criterion (C21). However, only the concepts that have one or more possible maps are included in this table. There are actually 39 IAF concepts that cannot be mapped to an ArchiMate equivalent, against 16 IAF concepts that can be mapped. Hence, only approximately 41% of the IAF concepts could be mapped. In addition, some of the IAF concepts with only one possible ArchiMate map do not even meet all criteria. Because some IAF concepts are mapped to the same ArchiMate concept, the construct redundancy (C22) and construct overload (C23) criteria are not always met. However, since there are no other possible ArchiMate concepts where these IAF concepts can be mapped to, these maps are still considered the best possible mapping alternative.

Construct overload Construct overload can influence the usability of ArchiMate as the modelling language for IAF, because one ArchiMate concept is used to represent multiple IAF concepts, which can lead to misunderstandings. However, this can be prevented by clearly (re)naming the concepts.

Construct redundancy Construct redundancy can be caused by two different types of redundancy (Opdahl & Henderson-Sellers, 2001; Opdahl, Henderson-Sellers, & Barbier, 2001). The first type of concepts is redundant ArchiMate concepts that represent subtypes of IAF concepts. This means that they specialise an IAF concept. The second type of concepts represents genuinely redundant ArchiMate concepts. Only concepts of the first type are found in this mapping. These concepts do not necessarily form a problem. An ArchiMate node, system software, and communication path are all subtypes of an IAF physical technical infrastructure component. This means that the ArchiMate concepts at the technical layer are more specific in relation to the equivalent IAF concepts.

Construct excess There also exists a construct excess over the entire mapping, because not all ArchiMate concepts have an IAF concept mapped to it. However, this is not of great influence to the mapping, since we have conducted a unidirectional mapping (or a representation map according to Weber) from IAF to ArchiMate. Therefore, we can discard the ArchiMate concepts that do not have an equivalent IAF concept mapped to it.

5.2 Problem areas From the previous paragraph follows that the mapping is far from 1:1. The construct deficit is directly linked to gaps in the proposed mapping. This section tries to address the main gaps that have an origin in the proposed mapping of IAF onto ArchiMate. The gaps are mainly the consequence of not mapped IAF concepts. This hinders the possibility to visualise and document an IAF architecture using ArchiMate models. Appendix E depicts a graphical notation of the mapping, showing what IAF concepts are mapped to which ArchiMate equivalents. Figure 22 shows a simplified version of this, it depicts roughly what areas of the IAF are covered by ArchiMate concepts.

From Figure 22 follows that there are almost no IAF concepts at the information aspect area that map to an ArchiMate equivalent. Because many clients of Capgemini process information instead of

54

deliver tangible products, this information aspect is very important in IAF. For this type of companies, not only the structure of information is important, but also how information is used and communicated about. Since this aspect is lacking in ArchiMate, the usability of it to visualise and document an IAF architecture using ArchiMate models is affected.

In addition, Collaboration contracts in IAF could not be mapped, since ArchiMate does not facilitate such concepts. These contracts are very important in IAF, for they describe how services or components use each other. They describe the non-functional requirements. These non-functional requirements are very important when an architecture is implemented, or further decisions need to be taken, taking these non-functional requirements into consideration. With this, criterion C8 is not satisfied.

Additionally, Table 26 states a list of IAF concepts not mapped. Since we now identified the problem areas, the next section focuses on solving these problem areas.

IAF artifact Contextual Concepts Physical Concepts

Business Mission Physical Business Component Collaboration Contract

Business Principle Physical Information System Component Collaboration Contract

Business Driver Physical Technology Infrastructure Component Collaboration Contract

Constraint Business Standard Assumption Business Specification

Conceptual Concepts Business Implementation Guideline Business Goal Physical Business Information Component Business Object Physical Business Information Collaboration

Contract Business Service Collaboration Contract Communication Standard Information System Service Collaboration Contract

Communication Specification

Object Contract Communication Guideline Business Information Service Information Standard Business Information Service Collaboration Contract

Information Specification

Technology Infrastructure Service Contract Information Guideline Logical Concepts Information System Standard

Logical Information Component Information System Specification Logical Business Information Component Information System Guideline Logical Business Information Component Collaboration Contract

Technology Infrastructure Standard

Logical Business Component Collaboration Contract

Technology Infrastructure Specification

Logical Information System Component Collaboration Contract

Technology Infrastructure Guideline

Logical Technical Infrastructure Component Collaboration Contract

Table 26: not mapped IAF concepts

55

Figure 22: IAF areas where maps to ArchiMate concepts exist

5.3 Possible solutions This section focuses on proposing possible solutions to overcome the identified problem areas. There are a few possibilities when trying to close the identified gaps. First, additional concepts for ArchiMate could be proposed. This is an easy approach, since no major changes occur to the existing structure of the language. Second, changes to the meaning or structure of the ArchiMate Meta model or concepts could be proposed. Third, changes the meaning or structure of the IAF Meta model could be proposed. Off course, also combinations of all or some of the above are possible.

One note needs to be placed before continuing with the possible solutions. We try to change ArchiMate as minimally as possible. With smart additions or changes, we try to improve ArchiMate in such a way that it is still usable as it was before these changes. Additionally, we try to emphasize the usefulness of the proposed changes. The discussions about the problem areas could on the other hand also lead to the proposition of possible changes to the IAF. However, since the transformation under consideration is unidirectional our main goal is to ensure that IAF models can be transformed fully and accurately into ArchiMate models, which assures the existence of a solution for the lack of expressiveness of ArchiMate compared to IAF. In the remainder of this section, we suggest possible changes for the main problem areas, stated below:

§ the lack of collaboration contracts in ArchiMate; § the missing Information aspect area; § other improvements.

Another IAF area where not many ArchiMate concepts can represent the IAF equivalents is the physical layer. Due to time constraints, this layer is left out of the scope for the possible solutions. Appendix F summarises all the proposed changes to the ArchiMate Meta model in a figure.

56

ATTRIBUTE SPECIFICATION Name : Raw product’ reception Expression : ‘First step production’ enables Base

production Service times : During daytime Peak times : month numbers 2-5, 7-10 Throughput : 100 items an hour Characteristics : Stock based production Importance : Critical path for Delivery of food Security : Beware of spy

Supply raw fish Food preparationRaw product reception

5.3.1 Collaboration contracts Recall that collaboration contracts in IAF describe how one service or component uses another, specifying the non-functional requirements. Below, an example of a collaboration contract in IAF is given.

Figure 23: Example IAF Business Service collaboration contract

The non-functional requirements can for instance provide insight in the development of the critical operation path (Capgemini, 2007b). This critical operation path could influence the way services are grouped into components. Furthermore, the non-functional requirements are used when implementing an architecture, for they guide certain implementation choices. For instance, availability (service times) can be specified in a collaboration contract. There is a possibility that the availability influences the choice for hardware, this is why it has to be taken into account when designing and implementing an architecture. Concluding, IAF collaboration contracts are important, not only for the IAF but in the creation of architectures overall. Therefore, collaboration contracts could enrichment ArchiMate.

Below, an elaboration on the possibilities to incorporate collaboration contracts in ArchiMate is given.

Introduction collaboration contract: first scenario

Figure 24: portion of proposed ArchiMate Meta model, first scenario

The first scenario only adds one concept. ArchiMate already defined a concept that denotes contracts. However, these contracts specify the rights and obligations associated with a product. Thus, specifying the contract of a product. Collaboration contracts do not describe a product

57

contract, but the collaboration and behaviour between two services. Therefore, every distinct pair of services has a different collaboration contract. This is something different then the rights and obligations associated with a product. In this case, all customers that purchase a product are obligated to comply with the same or a few contracts. Therefore, we propose to rename the ArchiMate concept contract into product contract and add an extra concept named service contract. This type of contract denotes the collaboration and behaviour between two services. This service contract has an aggregation relation to the service concept in ArchiMate. Figure 24 depicts the scenario for the business layer. The new concepts are emphasized in (diagonal-striped) green, and the changed concepts in (crossed-striped) orange.

Product Contract (former ArchiMate contract) A formal or informal specification of agreement that specifies the rights and obligations associated with a product. The contract concept may be used to model a contract in the legal sense, but also a more informal agreement associated with a product. It may also be or include a Service Level Agreement (SLA), describing an agreement about the functionality and quality of the services that are part of a product. A contract is a specialization of a business object.

The relationships that apply to a business object also apply to a contract. In addition, a contract may have an aggregation relationship with a product.

Figure 25: Product contract notation

Example The model below shows a Telebanking contract associated with the product Telebanking account. The contract consists of two parts (subcontracts): the Service Conditions and a Service Level Agreement.

Figure 26: Example product contract

Business service contract (based on the IAF collaboration contract definition) A specification of the collaboration and behaviour between two services that define the behaviour, quality, security, and governance aspects of the communication between two services.

Product Contract

Telebanking account

Telebanking contract

Service conditions Service level agreement

58

A business service contract is used to model the behaviour between two services in terms of the non-functional requirements. Every distinct service pair can have a service contract. Several attributes can be specified in a service contract stated in Table 27.

Attribute Description Name A suitable preferably unique short form name for the artifact Description A narrative of what the artifact is and what it does and its relevance to the

architecture Source The source of this artifact which may be a person or a document along

with a date to support traceability of the architecture Owner The owner of the artifact is the name (person or group) who validates the

details of this artifact. Behaviour Characteristics

The criteria and conditions for successful interaction, any dependencies (on other service interactions etc)

Service Quality Characteristics

A description of the quality characteristics that the contract is expected to conform to.

Governance Characteristics

A description of the policies the contract is expected to conform to.

Security Characteristics A description of the security characteristics that the contract is expected to conform to.

Service name „caller‟ The service who is the caller of the service. Service name „called‟ The service on who the service is called. Throughput The amount of items, information, etc that is put through over a specified

amount of time. Throughput period The period (in time) over which the throughput send. Growth Specifies the growth of the throughput. Growth period The period over which the growth is specified. Service times The times the service must be operational. Peak profile short term The short term time indication of the maximal throughput. Peak profile long term The long term time indication of the maximal throughput . Response requirements The requirements, which the response has to comply with. Quality of information required

Specifies the quality of the required information.

Contract control requirements

Specifies the requirements of the contract between the two services.

Result control requirements

Specifies the requirements of the output.

Importance The importance of the service. (for instance, yes, no, or critical) Table 27: Attribute specification service contract

A business service contract may have association, specialization, aggregation, or composition relationships with other service contracts. In addition, it may be assigned to business services.

Figure 27: Notation business service contract

Business service contract

59

Example This example depicts a service contract in a fishing company between the supply fish service and the food preparation service. It describes when fish is delivered, what the quality of the delivered fish is, how much fish is delivered, etc.

Figure 28: Example of service contract

The proposed Meta model change of the first scenario also has some impact for the generic Meta model of ArchiMate; extending it with a contract. Since, contracts for services can be identified at all ArchiMate layers. Figure 29 depicts the new proposed generic ArchiMate Meta model, emphasizing the new concepts in (diagonal-striped) green.

Figure 29: New proposed generic ArchiMate Meta model

Introduction collaboration contract: second scenario The second scenario takes it a little further by also grouping the two types of contracts (product and service contracts) into a super type named contract. Since, both types of contracts depict a kind of contract they could have some similar properties. A contract is then be used to specify the generic properties. Figure 30 depicts a portion of the new proposed ArchiMate Meta model, emphasizing the new concepts in (diagonal-striped) green, and the changed concepts in (crossed-striped) orange.

Raw product receptionSupply raw fish Food preparation

60

Figure 30: Portion of proposed ArchiMate Meta model, second scenario

Contract A formal or informal specification of properties that define the usage of a service or product.

A contract is the super type of a service contract and a product contract. It can specify common properties shared by services or products or a combination thereof. A contract never directly linked to a product or service, because here a product or service contract need to be defined in order to specify the specific properties associated with a product or service. Contracts can be aggregated, or can be linked to multiple service or product contracts.

Figure 31: Notation contract

Example This example depicts a contract, which has two service contracts as subtypes. The “product state” specifies the common properties the “raw product delivery” and “raw product’ reception” have. For instance, the service quality characteristics are shared between both service contracts.

Figure 32: Example contract

5.3.2 Information aspect area Since not many concepts of the IAF information column (aspect area) could be mapped to an ArchiMate equivalent, the second problem is more serious. Recall from Figure 22 that layers in

Contract

Product state

Raw product delivery Raw product reception

Food delivery Supply raw fish Food preparation

61

ArchiMate correspond to columns in IAF. This forms the source of this problem; IAF consists of four aspect areas, while ArchiMate only consists of three layers. Hence, a possible solution is to changing the ArchiMate Meta model by adding another layer, which represents the IAF information aspect area. However, before elaborating on the changes, we describe the necessity of the information aspect area for both IAF and ArchiMate.

Before explaining the necessity of the information aspect area in IAF, we give an example of the information aspect area, extracted from the same example as subsection 2.2.6. The figures below show only a sample of the entire model. Figure 33 shows how information objects interact with each other, Figure 34 shows how these information objects are grouped into logical information components based on grouping criteria, and Figure 35 shows how business information services are grouped into logical business information components based on grouping criteria. Finally, Table 28 shows the relations between information objects and business information services.

Figure 33: information object relations

Figure 34: Grouping of information objects into logical information components

AssignmentFinancial fulfilment

Management report

ResourceService

Information object

Business information service

Log. business information component

Log. information component

Legend

Agreement

Proposal

Acquisition

Management report

Management report

Service

Resource

Delivery content

Financial fulfilment

Financial fulfilment

Objective

Market plan

Assignment

Delivery resource

RequestCustomer

Customer request

62

Figure 35: Grouping of business information services into logical business information components

Information object

Business information Service

Ass

ignm

ent

Fina

ncia

l ful

film

ent

Man

agem

ent r

epor

t

Org

anis

atio

nal u

nit

Reso

urce

Report unit results V V V V V

Send invoice V

Validate invoice V

Validate outgoing payments V

Validate time & expenses V Table 28: Relations Business information services - information objects

Information is very important in organisations nowadays, since it gives them competitive advantage, defines their organisation, they communicate it, sell it, buy it, etc. In a word, companies cannot do without information. The information aspect area in IAF is used to separate the business and the information in that business, thereby explicating the information needs of the business. Now, one can develop an architecture based upon the information needs, thereby focussing on information. Summarising, the business logic is shaped around the information, since information system services bring together the business (logic) and information (data). In IAF, there is a distinction between passive information structure and active information structure. Information objects, logical information components, and physical information components represent passive information structure. In contrast, active information structure is represented by business information services, logical business information components, physical business information components, and the collaboration contracts (see Figure 34, Figure 35, and Table 28). On the other hand, passive information structure describes how information is structured. In other words, it specifies what the data model looks like (see Figure 33). On the other hand, the active structure determines what information is used by the business and how it is used (see Table 28). Hereby, making it easier to decide on what information should be automated using information systems. Therefore, in IAF there is an extra step added to go from the business to information systems. This supports decision support, clarifies the information in an organisation by the distinction between the business and information. Furthermore, traceability is enhanced throughout the architecture because the extra step enlightens how information is generated and used throughout the organisation without involving information systems. In ArchiMate, information is addressed, but not merely as extensive compared to the IAF. ArchiMate only addresses information objects (the passive information

Process outgoing payments

Provide invoice info

Manage debtors

Administer finances

Validate invoice

Send invoiceCreate invoice

Validate time & expensesAdminister time & expenses

Report unit resultsValidate outgoing payments

Report time & expenses

Register invoice

Financial administration

63

structure), which represent the information in the business. However, it does not specifically distinguish how services use information to get an insight in the non-automated flows of information upon which automation decisions can be taken. Therefore, extending ArchiMate with an information layer could be beneficial.

When proposing to add an extra layer to ArchiMate, one must first consider the current structure. In the current structure of ArchiMate, three layers are identified. These layers are all constructed of a set of generic concepts, completed with some layer specific concepts. To add an information layer, this same concept is followed in order to keep the ArchiMate structure consistent. So, the same generic concepts are used to construct an information layer. This layer is be placed between the business and application layers, for it represents the information in the business, which is possibly automated by an information system. The current mapping from IAF onto ArchiMate suggests that an IAF information object maps to an ArchiMate business object. IAF also distinguishes business object, which represent the resource instead of the information of that resource may be constructed. For consistency, it would be logical to suggest that the definition of an ArchiMate business object is changed in such a way that it meets the IAF definition of a business object. Then, at the information layer an information object can be introduced.

Business Object We propose to change the definition of an ArchiMate business object; since we do not want that the business object represents information, which is relevant from a business perspective, but solely want to represent the object that contains the information. We use the term resource for this. We define a resource as a source of wealth or revenue. The grey definition denotes the old definition:

Old definition A unit of information that has relevance from a business perspective. New definition A resource that has relevance from a business perspective.

Business objects represent the important “informational” or “conceptual” elements in which the business thinks about a domain, but not the information in those elements. Generally, a business object is used to model an object type (cf. a UML class), of which several instances may exist within the organization. A wide variety of types of business objects can be defined. Business objects are passive in the sense that they do not trigger or perform processes.

A business object may be accessed (e.g., created, read, written) by a business process, function, a business interaction, a business event, or a business service. A business object may have association, specialization, aggregation, or composition relationships with other business objects. A business object may be realized by a representation or by an information object (or both).

Figure 36: Notation business object

Business object

64

Example The model below shows a business object Invoice, which aggregates (multiple) information objects Invoice line. Two possible realizations of this business object exist: an Electronic invoice (data object) and a Paper invoice (representation). The business process Create invoice creates the invoice and the invoice lines, while the business process Send invoice accesses the business object Invoice.

Figure 37: Example business object

By proposing to add an information layer to ArchiMate a number of concepts are created based on the generic ArchiMate concepts. In essence, the information layer is nothing but the business layer but now specifically focussed on the information in the business. The IAF concepts at the information aspect area focus on the information and on the services that use this information. Concepts describing behaviour specifically from an information perspective are not used. This means that a role, process, function, interaction collaboration, and interface are concepts that are not represented in IAF. Hence, we do not propose to introduce these concepts at the new ArchiMate information layer in this thesis. It is another question whether such behaviour and structure concepts are necessary at the information layer in ArchiMate.

Therefore, we propose to introduce the following concepts at the information layer, based on the business layer concepts:

§ Information Service Contract § Information Object § Information Service

The remainder of this section states clarifications for all the new concepts.

Information Service Contract

A specification of the collaboration and behaviour between two information services.

An information service contract is derived from the generic concept of service contract proposed in the previous subsection. This concept specifies the collaboration and behaviour between two information services. Therefore, it is important for the same reasons as for the service contract at the business layer.

A service contract is used to model the behaviour between two services in terms of the non-functional requirements. Every distinct service pair can have a service contract. An information service contract identifies the information that forms the relationship between Business Information

InvoiceInvoice line

Electronic InvoicePaper invoice

Create invoice Send invoice

65

ATTRIBUTE SPECIFICATION Name : Catch reception Expression : First stage fish product-.. Triggers

Fish product- production timestamps Service times : During daytime Characteristics : Stock based triggering Importance : Critical path for Delivery at required

freshness rates Security : Beware of spy Creates : Fish Uses : Stock Updates : Stock Deletes : -

Services. In addition, it describes the attributes of that relationship (quality, security, frequency, accuracy etc).

An information service contract may associate with information services. In addition, it may have association, specialization, aggregation, or composition relationships with other information service contracts.

Figure 38: Notation information service contract

Example

Information Object A unit of information that has relevance from a business perspective. The newly proposed information object actually represents the old business object in ArchiMate. It represents a unit of information that has relevance from a business perspective. This concept is introduced in order to model the passive information structure of an architecture.

Information objects represent the important information in which the business uses in domain. Generally, an information object is used to model the information of a business object, of which several instances may exist within the organization. A wide variety of types of information objects can be defined. Information objects are passive in the sense that they do not trigger or perform processes.

An information object may be accessed (e.g., created, read, written) by an information process, function, a information interaction, or an information service. An information object may have association, specialization, aggregation, or composition relationships with other information objects. A data object may realize an information object.

Figure 39: Notation information object

Example See example business object.

Informationservice contract

Clean fish Prepare fishCatch reception

Information object

66

Information Service A service that describes the information need of a business service in order to realise that business service. A business information service in IAF represents the service that describes the information need of a business service in order to realise that same business service. It is for this reason that Information services and business services have a relationship with each other. It is not a one to one relationship, but it is possible that a business service is related to multiple information services. For instance, a business service called customer management can be related to two information services. The first information service characterises what and how information is used by the corresponding business service. The second service represents actions that are taken in order to guarantee the security of the customer information. An information service should provide a unit of information functionality that is meaningful from the point of view of the environment. It has a purpose, which states this utility. The environment includes the (behaviour of) information users from outside as well as inside the organization.

An information service may be used by an information process, information function, or information interaction. An information process, information function, or information interaction may realize an information service. An information interface or application interface may be assigned to an information service. An information service may access information objects.

Figure 40: Notation information service

Example The model below shows three information services, clean fish, manage fish stock, and prepare fish. These information services access (get, write, transform) multiple information objects. In addition, these information objects are associated to each other.

Figure 41: Example information service

Information service

Clean fish Manage fish stock

Prepare dish

Fish type

Fish type characteristics

Processing guidelines

Processing requirementsFish product

Characteristics

Freshness qualifiers

Stock

Timestamp

get

getget

get

write

writewrite

write

get/transform

get

67

Figure 42: Proposed information layer Meta model ArchiMate

Figure 43: Relations information layer concepts with other layers

5.3.3 Additional ArchiMate propositions In this section, additional changes to ArchiMate are proposed. Recall that ArchiMate is constructed out of generic concepts. When looking at the overall structure of ArchiMate, one sees that the business and application layer comply with this generic structure. The technology layer on the other hand, differs from the other two layers. In detail, the technology layer is not composed of the generic set of ArchiMate constructs, but comprises UML2.0 concepts. The choice for UML 2.0 concepts is logical, since this is a well-known modelling standard. However the level of granularity the UML 2.0 concepts comprise is not appropriate in this case. These concepts describe physical devices (servers, work stations, etc), system software installed on these devices, the physical networks of these devices. In short, it is possible to model a network topology with the provided UML 2.0 concepts at the ArchiMate technology layer. This contrasts with ArchiMate’ main goal, to facilitate to model an enterprise architecture, which should provide a high-level overview the architecture of an organisation. The level of granularity that the UML 2.0 concepts provide does not make this possible, since models will easily get unreadable if they grow bigger. Therefore, we find the UML 2.0 concepts not appropriate at the technology layer in ArchiMate. With respect to the granularity, the UML 2.0 concepts are better usable for the implementation of an architecture. Therefore, we suggest the following change to the ArchiMate Meta model in order to create consistency in the level of granularity.

We suggest replacing the following UML concepts, node, communication path, system software, device, and network with an infrastructure component.

The remainder of this thesis will discard the proposed changes to the ArchiMate technology layer, since we only focus on the business, information, and information systems aspect areas.

68

Figure 44: Proposed changes ArchiMate Meta model technology layer

5.4 Improved mapping In section 5.3, we introduced possible solutions to overcome the identified gaps. This section presents the improved mapping, which is based on the possible solutions.

Section 5.3 presents possible solutions for two of the identified problem areas: collaboration contracts and the information aspect area of IAF. By changing existing and adding additional ArchiMate concepts, we tried to improve the mapping. Table 29 shows the IAF concepts that could be mapped according to the changes we proposed.

IAF concept ArchiMate concept Conceptual layer

Business Object Business Object Business Service Collaboration Contract Service Contract Information Object Information Object Business Information Service Information Service Business Information Service Collaboration Contract Information Contract Information System Service Application Contract Technology Infrastructure Collaboration Contract Infrastructure Contract

Logical layer Logical Business Service Collaboration Contract Business Service Logical Information Component Information Object Logical Business Information Component Information Service Logical Business Information Component Collaboration Contract Information Contract Logical Information System Service Contract Application Contract Logical Technology Infrastructure Service Collaboration Contract Infrastructure Contract Table 29: Additional maps following from proposed ArchiMate changes

Appendix G depicts the updated mapping, which includes the above maps.

69

Figure 45: IAF areas covered by maps to ArchiMate with the proposed changes of ArchiMate taken into account

5.5 Conclusion This goal for this chapter was to answer research questions 2a and 2b. First, we will provide the answer to research question 2a; Let us recall this research question:

“What are the problem areas in the mapping of IAF and ArchiMate Meta models? (evaluative)”

In order to identify the problem areas, first, the mapping is evaluated; this shows that there are some criteria that are not satisfied. Especially the criteria derived from Weber show some defects and identify that the mapping is not perfect. The main problems lie in the construct overload and construct deficit. The construct overload is caused by IAF concepts, which are mapped to the same ArchiMate concept. This influences the consistency and as a cause of this, it can influence the comprehension of a model. However, the huge construct deficit is the most dramatic problem of the proposed mapping. Only 41% of the IAF concepts can be mapped to an ArchiMate equivalent. This means that the proposed mapping result does not even closely show a perfect, 1:1 map. Thus, according to the mapping evaluation, there are several problem areas. The biggest are located in the IAF information aspect area, at the IAF physical layer, and with the collaboration contracts, that ArchiMate does not incorporate.

This brings us to the second part of this conclusion, the answer to research question 2b, Let us recall what research question 2b is:

“What are the possible solutions to avoid or overcome the problem areas? (prescriptive)”

Section 5.3 provides the possible solutions for the not mapped concepts in the information aspect area, and for the collaboration contracts. This section does not provide possible solutions for the physical layer due to time limitations of this research project. The possible solutions aim to enrich ArchiMate; therefore, we reason why the proposed concepts should be added to ArchiMate or why

70

changes should be made. The possible solutions propose to add a generic ArchiMate contract to facilitate contracts for services at all ArchiMate layers. In addition, an information layer is added to put more focus on information, since this is the core business of many organisations nowadays. The next chapter describes the validation of this research, including the proposed solutions.

71

6 Validation The goal for this chapter is to validate whether and how well IAF architecture models can be transformed into ArchiMate architecture models, in a practical setting. First, the theoretical model for the validation is presented in section 6.1. Second, the validation design method is presented in section 6.2. Third, section 6.3 introduces the survey approach. Fourth, section 6.4 elaborates on the results of the validation. Next, the validation of the results is discussed in section 6.5. Finally, this chapter is concluded (section 0) with the answer to research question 2.

6.1 Theoretical model So far, IAF and ArchiMate have been only theoretically compared. This has given us an answer whether ArchiMate has enough expressive power to represent the concepts needed in an IAF architecture. However, we do not know what the possibilities are to transform an architecture model visualised and documented using the IAF (from now we refer to this as an IAF architecture) into an equivalent ArchiMate architecture model. The transformation from IAF into ArchiMate models can be influenced by multiple factors. For instance, the concepts of IAF and ArchiMate and the types of relationships that are possible between concepts in both IAF and ArchiMate. Hence, we proposed the mapping of IAF and ArchiMate to combine all these factors into one, the accuracy of the mapping. Therefore, since we want to use the mapping as a basis to transform IAF architecture models into ArchiMate equivalent ones, the accuracy of this mapping influences the results. However, before we proceed we need to define what the term equivalence means within the scope of this research project. The word equivalent can have many different meanings. Therefore, stating that we want to know the possibilities to transform an IAF architecture into an equivalent ArchiMate one is too generic. For instance, semantical equivalence, or syntactical equivalence can be meant by the expression equivalence. These expressions both have very different appropriate types of validation. In order to validate all the different types of equivalence it would take a very extensive validation approach. Due to time constraints, this is not feasible for this research project. Hence, we are going to investigate the level of equivalence that experts perceive. Experts that compare IAF with ArchiMate models score the level of equivalence that they perceive. Figure 46 summarises the above in a theoretical model.

Figure 46: Theoretical model validation approach

The theoretical model proposes that the accuracy of the mapping positively influences the perceived equivalence. The construct deficit, construct redundancy, construct overload, and construct excess measure the accuracy of the mapping. In addition, experts comparing IAF models with ArchiMate models score the level of equivalence that they perceive. Concluding, the perceived equivalence gives us an image of how well an IAF architecture model can be transformed into an ArchiMate architecture model. In addition, we can also see what the difference of standard ArchiMate is

72

compared to ArchiMate++ with the proposed additions, since the accuracy of the mapping varies between ArchiMate and ArchiMate++.

6.2 Validation design This section elaborates the research design for this validation. First, the most appropriate research method for the validation (subsection 6.2.1) is selected. Next, in subsection 6.2.2 the data source for the validation is presented.

6.2.1 Validation method Since we want to measure the equivalence that experts perceive of IAF and their corresponding ArchiMate models, we need a method that allows us to gather the needed information. In order to make sure we do not bias the experts, we need the researcher’s role to be passive. An active role for the researcher could cause him to unintentionally influence the experts. In addition, it must be possible to gather information from multiple experts, and it must be possible that it is conduct it in the field. An experiment would be a possibility to gather the needed data. However, when using an experiment the researchers’ role would be active. A survey is the other possibility. When using a survey, the researcher has a passive role. All the other requirements are also in favour of the survey. Hence, a survey is the most favourable approach to gather the needed information. In order to transform IAF models into ArchiMate models, we need IAF models. The next subsection describes the source of IAF models for this validation.

6.2.2 Data source In order to create a survey consisting of both IAF and ArchiMate models, we need IAF models, which we can transform into ArchiMate. A few approaches to gather the data to form a survey are possible.

The first approach uses the results of an architecture project already conducted by Capgemini. The results, which are the IAF models, are transformed into ArchiMate models using the proposed mapping. To validate whether the transformed models are semantically equivalent, the ArchiMate models will be compared with the IAF ones, using a survey. The people that performed the project fill out the surveys based on their knowledge of the project.

The second approach is almost identical to the first one. The difference is that we develop the Architecture models ourselves. This way we can develop the IAF architecture models that are most interesting for the comparison with ArchiMate. Experts that have worked with both IAF and ArchiMate fill out the survey.

The second approach is the most favourable, since it gives the most flexibility and lets the researcher limit the external influences. The second approach implies that we need a case for which we can create models. The remainder of this section describes the case from which we will create the IAF models.

73

6.2.3 Architecture case The transport and water management inspectorate in the Netherlands (called ‘Inspectie Verkeer en Waterstaat’ or short IVW) is an independent regulatory body. It is part of the Netherlands Ministry of Transport, Public Works, and water management. Their mission is to monitor and promote the safe, sustainable use of Dutch roads, water, airspace, aerodromes and railways for people and businesses, and to issue public reports on the outcomes of its work (Transport and Water Management Inspectorate, 2008). IVW has three areas where they inspect: air, land, and sea. Each area has three sub-inspectorates that carry out the actual inspections. The core activity of IVW is the inspection process. In order to support the inspection process, IVW deduced the generic inspection process from all the specific sub-inspectorate processes. In order to support this process with IT as good as possible, the desired application landscape is developed, which is depicted as a landscape map (Torre van der, Lankhorst, Doest ter, Campschroer, & Arbab, 2006) in Figure 48. The application landscape could also be depicted using IAF or ArchiMate. However, we chose to display the original IVW model, because this figure (among other documents) is used to create the IAF models for the survey.

Figure 48: Desired application landscape IVW

The purpose of this project is to support Figure 48 by developing the architecture to show whether and how the applications support the inspection process. In order to investigate how the processes are supported by applications, we have to look at the business, information, and information system aspect areas of the IAF. Furthermore, the contextual, conceptual, and logical layers are addressed

communitygoederen en

personen

communityrail

communitylucht

communityzeevaart enbinnenvaart

communitywaterbeheer

Inspectie en handhaving

Planning• opstellen jaarplan• opstellen jaarwerkplan• opstellen operationele planning

Voorbereiding• bepalen product• bepalen objecten• bepalen aanpak• verzamelen objectgegevens• verzamelen historische gegevens

Constateren• waarnemen• registreren gegevens• verifiëren gegevens

Beoordelen• analyseren• toetsen aan norm• vastleggen oordeel• bespreken oordeel

Interveniëren • beslissen• handelen• verstrekken bewijs / rapport• terugkoppelen

Nazorg• opstellen rapportage• evalueren en bijstellen aanpak• opstellen risicoanalyse en -beeld

Control• verantwoorden• archiveren• monitoren voortgang productie• monitoren vervolgacties

HoofdprocesTe ondersteunen functies

Planningstool

Analyse + rapportageomgeving: Datawarehouse + Business Intelligencetool (project W IM, ISI -> SAP BW of Oracle)

RisicoAnalyse TAMARA

Kantoor-inspectieapplicatie: SAP CRM (project Digit@L, Rail) +

Veld-inspectieapplicatie (Rail)

Dianta+(Project

BCT, BID)

Interventiesystemen (project BB / LOD etc.)

Analyse + rapportageomgeving: Datawarehouse + Business Intelligencetool (project W IM, ISI -> SAP BW of Oracle)

Documentmanagement: TRIM

Hoofdlijnen applicatielandschap IVW per 31-12-2011

PIRATE

BIC/Dianta, Scan etc.

Rail/Sigmax

BRES, IAS,PRES, BRILInspect etc.

APR, BRS, Dacon etc.

APR

Tijdschrijven: SAP CATSChronos All Solutions Timewriter

Toekomstvaste applicaties

Te migreren applicaties

Issue 3 informatie-uitwisseling: Enterprise Service Bus (ESB) + Overheids Service Bus (OSB)

Financieel / HRM etc: SAP R3

Bezwaar en beroep (project JZ)

CODA

Ontsluiting van wet- en regelgeving (project EasyRules)

Dianta

Figure 47: Focus area IVW project

Focus area

74

and for the information system aspect area, the physical layer is addressed in order to represent applications. Because the remaining parts of the IAF are out of scope, they will not be validated during this research project. The next section describes the survey in more detail.

6.3 Survey approach This section describes the survey approach. First, in subsection 6.3.1 the survey type is discussed. Second, in subsection 6.3.2 the questionnaire design is presented. Third, subsection 6.3.3 presents the survey implementation. Finally, subsection 6.3.4 introduces the sampling for this survey.

6.3.1 Survey type There are some choices to make when designing a survey. This subsection discusses what type of survey best suits this validation. There are three different possible types:

§ Self-administered § Telephone § Face-to-face interviews

With a face-to-face interview survey, the interviewer asks the questions and writes down the answers given by the interviewee. This way the interviewer possibly could bias the interviewee by the questions he asks. However, we only give a brief explanation of the survey and the models and the interviewee then has to fill out the survey by him/herself. In addition, the interviewee is asked to give any additional comments that he/she might have. Hence, we chose for a face-to-face survey. In addition, face-to-face surveys have the highest response rates of all survey types. However, a downside is that face-to-face surveys take up a lot of time and may be costly due to travel expenses.

6.3.2 Questionnaire design Designing the questions is one of the most important parts of designing a survey. The type of questions determine what information we are going to gather. Generally, two types of questions can be asked, open questions and closed questions. Closed questions are most suitable for this survey, since they are more easily coded and analysed compared to open questions. However, in order to gather some qualitative data, we ask the respondents to speak out any comment that they may have, about the survey or about the survey questions. Normally, a survey consists of questions. However, in order to validate to what extend an IAF architecture can be transformed into an ArchiMate equivalent one, we need to use architecture models (figures) to let the participants compare IAF architecture models with ArchiMate architecture models. In addition, an architecture usually consists of several models. With the IAF it is therefore also possible to create multiple models. Hence, in order to validate whether an architecture created using the IAF approach can be transformed into an ArchiMate equivalent architecture, we need to construct the survey out of multiple different IAF models. However, the IVW case, on which the survey’s models are based, does only consider a part of the IAF as can be seen in the case introduction (subsection 0). Therefore, we have incorporated ten different IAF models into the survey to guarantee the IAF coverage as presented in Figure 47. Table 30 shows which models are incorporated in the survey and why they are incorporated.

75

Survey Model Rationale Model 1 – Business interaction model

In IAF, the most elementary constructs of the business (called business services in IAF) are identified and the communication between business services is very important in designing solution alternatives. The business interaction model visualises the communication between the business services. In addition, it covers a great deal of the IAF concepts residing at the business conceptual area of the IAF.

Model 2 – Business objects used by business services

This model is important in order to show because it shows how resources are used by business services. Furthermore, it almost rounds up all the concepts residing at the business conceptual area of the IAF. Only the business object contract is not covered by the survey, because this concept was not in the scope of the IVW case.

Model 3 – Logical business components

These concepts are crucial in IAF in order to structure the business services into components according to criteria derived from the principles. These components are then used to form the solution alternatives.

Model 4 – Information interaction model

In correspondence to the business interaction model the information interaction model visualises communication. However, this time the communication is between business information services. This model helps to view how information is used throughout the organisation to form an image of the information need and is therefore very important.

Model 5 – Logical information components

The logical information components structure the information objects according to criteria derived from the principles. These components form the ideal information structure of an organisation and create the basis for the final information structure of an organisation.

Model 6 – Logical business information component interaction model

In correspondence to the business interaction model the logical business information component interaction model visualises communication. However, this time the communication is between business information services. This model helps to view how information is used throughout the organisation to form an image of the information need and is therefore very important. In addition, it covers a great deal of the IAF concepts residing at the information logical area of the IAF.

Model 7 – Information object – Information system service XREF

IAF uses some cross references to internally validate an architecture. Model 7 is one of this cross references (XREFS). In order to transform an IAF architecture to ArchiMate it should also be possible to transform the XREFS. Therefore, we incorporated this model in the survey.

Model 8 – Automated business information services

This model covers both information objects and information system services, which are both important concepts at the conceptual layer of the IAF. Therefore, this model is incorporated in the survey. Depicting the relationships between these concepts shows what elementary constructs are automated.

Model 9 – Physical information system components

The physical information system components depict the applications of an organisation and are one of the crucial concepts of an architecture. Hence, it is incorporated in the survey.

Model 10 – Solution alternatives logical information system components

Solution alternatives are a very important concept in IAF giving architects the possibility to construct several scenarios based on the principles. Therefore, this model is incorporated in the survey.

Table 30: IAF models incorporated in the survey

76

Figure 49: IAF coverage survey

Figure 49 shows what areas of the IAF are covered by the ten survey models. In correspondence to the IAF models, ArchiMate and ArchiMate++ models are constructed. The ArchiMate models are constructed only of the standard ArchiMate concepts, included in the standard (H. Jonkers et al., 2009). The ArchiMate++ models are constructed of the standard ArchiMate concepts complemented with the proposed changes of section 5.3. Because the results of the standard ArchiMate will most definitely differ from the ArchiMate++ results, the survey is divided into two separate parts to show this difference. The first part handles the comparison of the IAF models with the standard ArchiMate models, the second part handles the comparison of the same IAF models but now with the ArchiMate++ models. The model transformations that are necessary in order to construct the survey are all based on the proposed mapping that was introduced in section 4.4 and on the proposed extensions to ArchiMate that were introduced in section 5.3. All the models are created using the BiZZdesign Architect. For the IAF models we use a version of the BiZZdesign Architect called the IAFworkbench, for the ArchiMate models we used the standard BiZZdesign Architect, and for the ArchiMate++ models we made some adjustments to the standard BiZZdesign Architect to incorporate the added concepts.

The survey questions form a set of statements that let the survey respondents compare the IAF models with their ArchiMate variants. The survey participants then score to what extent they find the meaning of the IAF model compared with the corresponding ArchiMate or ArchiMate++ model equal. There are five response categories, which reach from totally unequal to totally equal, with corresponding scores in between (unequal, undecided, and equal). This way we minimise the risk of biased responses due to closed questions.

In order to give the participants an easy job when comparing the models, we constructed the survey in such a way that we have four separate packages. One with the IAF models, one with the ArchiMate models, one with the ArchiMate++ models, and finally one with the answer sheet. This gave the participant the opportunity to lay multiple packages next to each other on a desk to minimise page turning and ease the comparison between the models.

77

Example survey question An example survey question is presented below, the total survey can be found in Appendix H. The example below shows a small part of a business interaction model in IAF (Figure 50) and the ArchiMate++ variant is depicted in Figure 51. We chose to use this model as an example model, because it is a very important model in IAF. It visualises the communication between business services and the contracts model the non-functional requirements between these services. Therefore, this model forms the basis for the structuring of business services into business components. Next, we give an example rationale and score.

Figure 50: IAF model: Business interaction model

Figure 51: Extended ArchiMate model: Business interaction model

The concepts and their meanings are the same. An IAF business service corresponds to an ArchiMate business service, an IAF service contract corresponds to an ArchiMate business service contract, and an IAF role corresponds to an ArchiMate business role. However, the relationships between the concepts are different. The relationships in the ArchiMate model mean that a business service is assigned to a contract. However, the direction of the relationship is not specified in the ArchiMate++ model. Therefore, these models are marked unequal.

Comparison Tota

lly u

nequ

al

Une

qual

Und

ecid

ed

Equa

l

Tota

lly e

qual

Example IAF model compared to example Extended ArchiMate model X Table 31: Example survey answer

Outline solutionSolution outlining

Proposal creationReceive service request

External Supplier

Create proposal

External resource request reception

Business service

Service contract

Role

Legend

Receive service request

Outline solution Create proposal

External supplier

Solution outlining

Proposal creation

External resource request reception

Business Service

Business Service Contract

Business Role

Legend

78

6.3.3 Survey Implementation This subsection describes how we conducted the survey. First, we describe how the participants were contacted. Second, we describe how we conducted the surveys with the participants.

All the appointments were scheduled within three days and were at the participant’s location. In order to assure that the survey participants were willing to participate in the survey, we contacted them in multiple ways. First, we have sent them an email with the question whether they would like to participate in the survey and when they were available. Next, we called the survey participants with the question whether they wanted to participate. If they were willing to participate, we directly scheduled an appointment.

When conducting the survey we first explained why this survey was held and gave a brief explanation of the models in the survey. Then the participant filled out the survey and throughout the entire process, we encouraged the participants to speak out any comments they had. Most of the comments that the participants gave were about the models. For instance, they suggested improvements to the models. With the presentation of the results in section 6.4, we also discuss the comments placed by the participants.

6.3.4 Sampling In order to evaluate the perceived equivalence, we want participants that have worked with both IAF and ArchiMate to fill out the survey. We need the participants to have experience with both IAF and ArchiMate, because the participants need to compare the two types of models. Hence, they need to know the meaning of IAF and ArchiMate concepts and understand how IAF and ArchiMate are applied and used. In the ideal situation, we would like all people that have experience with IAF and ArchiMate to fill out the survey. However, due to time constraints this is not possible. In addition, we do not know how many people have experience with both IAF and ArchiMate. Therefore, we choose a sample size of six people to fill out the survey.

6.4 Results This section presents the survey results, which are divided into three subsections. First, the results for the comparison of the IAF models with the standard ArchiMate models are presented. Second, the results for the ArchiMate++ models are presented. Finally, the combined results are presented.

For each model comparison, there are five possible answers ranging from totally unequal to totally equal. We have assigned a numerical score to the possible answers in order to be able to calculate a score. Table 32 depicts the numerical scores. One can see that a negative number represents inequality and a positive score represents equality. The maximum negative score that is possible is 6 respondents times 10 questions times -2 points. This results in a score of -120. Correspondingly, the maximum positive score is +120.

Possible Answer Numerical Score Totally unequal -2 Unequal -1 Undecided 0 Equal +1 Totally equal +2

Table 32: Numerical scores for the possible answers

79

6.4.1 ArchiMate As mentioned before, the standard ArchiMate models incorporate only the standard ArchiMate concepts that are recorded in the standard (H. Jonkers et al., 2009). Table 33 presents the survey results of the comparison of IAF models with standard ArchiMate models.

Answers Models to

tally

une

qual

uneq

ual

unde

cide

d

equa

l

tota

lly e

qual

TOTA

L

Model 1 -6 -6

Model 2 -12 -12

Model 3 -2 0 3 1

Model 4 -10 -1 -11

Model 5 -2 3 2 3

Model 6 -10 -1 -11

Model 7 -2 3 2 3

Model 8 -8 -1 0 -9

Model 9 2 8 10

Model 10 -4 0 2 -2

TOTAL -44 -16 0 12 12 -34 Table 33: Survey results comparison IAF – standard ArchiMate models

When looking at the results, you see that some of the models have a very bad score. This is because not all of the concepts incorporated in the IAF can be mapped to an ArchiMate equivalent concept. A consequence of this is that not all the IAF models in the survey can be transformed into ArchiMate models. This goes for models 1, 2, 4, 6, and 8. Because these models cannot be transformed or only partially transformed, the overall score of the comparison of IAF models with standard ArchiMate models is negative. On the other hand, according to the survey attendants some models can be transformed into ArchiMate. For example, model 9 is a good example of such a model. Finally, there are also some models that have mixed scores, some architects scored those models equal, while other scored them unequal. An explanation of this is that the architects did not interpret the models in the same way. Overall, we can say that the perceived equivalence for standard ArchiMate when transforming IAF models to ArchiMate is very limited, since some important concepts are missing and therefore some critical models cannot be transformed.

From subsection 5.1.2 follows that the accuracy of the mapping for standard ArchiMate is not very high, since quite a few concepts cannot be mapped, which results in a high construct deficit. In addition, there is also a construct redundancy. Next, we present the ArchiMate++ results.

6.4.2 ArchiMate++ The ArchiMate++ models are created using the standard ArchiMate concepts in combination with the proposed changes to ArchiMate presented in section 5.3. Table 34 presents the survey results of the comparison of IAF models with ArchiMate++ models.

80

Answers Models to

tally

une

qual

uneq

ual

unde

cide

d

equa

l

tota

lly e

qual

TOTA

L

Model 1 6 6

Model 2 4 4 8

Model 3 -2 0 3 1

Model 4 -2 4 2

Model 5 -2 3 2 3

Model 6 -2 0 2 2 2

Model 7 -2 3 2 3

Model 8 2 8 10

Model 9 2 8 10

Model 10 -4 0 2 -2

TOTAL -4 -10 0 30 26 42 Table 34: Survey results comparison IAF – ArchiMate++ models

When we look at the above table, we see that almost all transformed ArchiMate++ models are scored equal or totally equal to their corresponding IAF models, this results in a positive overall score. However, there are some defects. Some models show mixed scores (both unequal and equal), possibly due to different interpretations by architects. In order to understand these differences we need to dig deeper into the scores. In the next subsection, we will compare the ArchiMate and ArchiMate++ scores per model, allowing us to analyse in more detail the differences of each model and possibly explain why some models have mixed scores. Overall, we can say that the perceived equivalence for ArchiMate++ when transforming IAF models to ArchiMate++ is average, according to the survey results.

Section 5.4 discusses the improved mapping. From this follows that many more IAF concepts have an ArchiMate concept mapped to them compared to the mapping of IAF on standard ArchiMate. Therefore, the mapping accuracy of ArchiMate++ and IAF is higher. This results in a much lower construct deficit. However, there is still a construct small construct deficit and the construct redundancy is also not solved, hence the mapping accuracy is not very high. This corresponds to the perceived equivalence, since it has gone up a lot, but it is still not very good.

6.4.3 Combined results This section compares the standard ArchiMate and ArchiMate++ survey results. We will provide a brief discussion of the results per model. Figure 62 depicts the combined survey results.

6.4.3.1 Model 1 The comparison of IAF and ArchiMate models shows a score of minus six (-6), see Figure 52. On the other hand, the results of the ArchiMate++ model show a positive score of six. The difference between the two models is that the ArchiMate++

-6

6

Mod

el 1

ArchiMate ArchiMate++

Figure 52: Combined survey results Model 1

81

1 1

Model 3ArchiMate ArchiMate++

Figure 54: Combined survey results model 3

-11

2

Mod

el 4

ArchiMate ArchiMate++

Figure 55: Combined survey results model 4

3 3

Model 5

ArchiMate ArchiMate++

variant of model 1 incorporates collaboration contracts, which are lacking in the ArchiMate variant. This means that with the addition of the collaboration contracts, the ArchiMate++ model is almost equal to the IAF variant. However, the architects did not score the ArchiMate++ model as totally equal. One of the architects noted that he missed direction specification of the relationships between the services and contracts.

6.4.3.2 Model 2 Again, Figure 53 shows us a great improvement of the results over the comparisons of the ArchiMate and ArchiMate++ variants with the IAF models. The ArchiMate variant lacks business objects, and thus the IAF variant of the second model could not be transformed to ArchiMate. This resulted in no ArchiMate variant of the second model and therefore a maximum negative score. With the changed definition of the business object in ArchiMate++ so that it matches the IAF definition of a business object, this problem is solved. This is clearly reflected in the outcome of the ArchiMate++ comparison.

6.4.3.3 Model 3 The results of the third model, depicted in Figure 54 are identical, which is logical, since the ArchiMate and ArchiMate++ models are identical. The reason why some of the architects found the IAF and ArchiMate models not equal is that both ArchiMate models do not identify an extra concept to represent business components, but in Archimate you can use an aggregation relationships to group business services. However, one architect said when doing this, you use a behaviour concept for structuring purposes.

6.4.3.4 Model 4 When you look at Figure 55, there is a clear distinction in scores between ArchiMate and ArchiMate++. The ArchiMate variant scores badly, because the IAF model cannot be transformed into ArchiMate, for the IAF business information service cannot be transformed into an ArchiMate concept. However, the ArchiMate++ score on the other hand is not very good either. According to comments by the architects, this is because ArchiMate++ lacks the transform relationship type. In addition, ArchiMate++ does not support bidirectional relationships between two concepts.

6.4.3.5 Model 5 The ArchiMate and ArchiMate++ variants of model five are identical, which is reflected in their identical scores. This is depicted in Figure 56. The score is not very high, which means that the architects have a mixed opinion whether the

-12

8

Mod

el 2

ArchiMate ArchiMate++

Figure 53: Combined survey results model 2

Figure 56: Combined survey results model 5

82

-11

2

Mod

el 6

ArchiMate ArchiMate++

Figure 57: Combined survey results model 6

3 3

Model 7

ArchiMate ArchiMate++

Figure 58: Combined survey results model 7

-9

10

Mod

el 8

ArchiMate ArchiMate++

transformed variants are equal to the IAF model, or not. The reason for this score is analogous to the reason of the mixed score at the third model. This model shows the grouping of information objects into information components. Neither ArchiMate nor ArchiMate++ has an extra concept to represent such an IAF component, but rather represent it as an information object, which aggregates other information objects.

6.4.3.6 Model 6 When you look at Figure 57, there is a clear distinct in scores between ArchiMate and ArchiMate++. The ArchiMate variant scores badly, because the IAF model cannot be transformed into ArchiMate, for the IAF business information service cannot be transformed into an ArchiMate concept. However, the ArchiMate++ score on the other hand is not very high either. This is for the same reason as the fifth model. Again, ArchiMate++ does not incorporate an extra concept that represents an IAF component, but rather represents it as a business information service, which aggregates other business information services.

6.4.3.7 Model 7 Figure 58 depicts the scores for both the ArchiMate and ArchiMate++ variants of model seven, which have an identical score. This is a consequence of both variants being identical. Again, we see a mediocre score in both variants, which means

that some architects scored the models unequal while other scored them equal. This is because some architects said that ArchiMate and ArchiMate++ lack the transform relationship type. However, others said that this relationship type is represented in both variants of ArchiMate by a read and write relationship type on a single information object.

6.4.3.8 Model 8 Model eight shows a great improvement of the results over the comparisons of the ArchiMate and ArchiMate++ variants with the IAF model when looking at the combined results in Figure 59. The ArchiMate variant scores badly, because the IAF business information service concept cannot be transformed into an ArchiMate concept, which results in a not transformable model. The ArchiMate++ variant of model eight on the other hand scores very well, because ArchiMate++ is extended with an information service, which maps to an IAF business information service.

Figure 59: Combined survey results model 8

83

-2 -2Model 10

ArchiMate ArchiMate++

6.4.3.9 Model 9 Figure 60 depicts that both the ArchiMate and ArchiMate++ variants of model nine have an identical score, which is a consequence of both variants being identical. The score is high, thus both the ArchiMate and ArchiMate++ models are equal to their corresponding IAF model.

6.4.3.10 Model 10 The results for the final model comparison depicted in Figure 61 shows for both ArchiMate variants a negative score. Since both the ArchiMate and ArchiMate++ models are identical, the score is identical. As the architects filled out the survey, they noted that the solution alternative concept is missing in both ArchiMate variants of model nine. This means that components cannot be related to a solution alternative and thus it is not traceable for instance what components together form a certain solution alternative.

6.5 Validity The internal and external validity are discussed in this section. First, the internal validity (subsection 6.5.1) is discussed. Second, the external validity (section 6.5.2) is elaborated.

6.5.1 Internal validity Using a survey as a validation method means that we can only collect the meaning of the respondents. Hence, we cannot conclude that transforming IAF models into ArchiMate models results in equal models. Furthermore, we packed several variables that can influence the perceived influence together in the accuracy of the mapping. Hence, we took multiple variables into consideration, which increases the internal validity. In addition, we also guaranteed the internal validity by choosing for the second data source, which lets us control the influence of factors better compared to the first data source. Furthermore, we tried not to bias the results by influencing participants. However, from the results follows that some of the models are sometimes interpreted in a different way, this does bias the results to some extent.

6.5.2 External validity Six Capgemini architects have filled out the survey. This number is not very high, and a higher number would result in better external validity, because then we would have a better sample of all architects that have experience with both IAF and ArchiMate. However, due to time constraints, we were not able to let more architects to fill out the survey. Our response rate on the other hand was very high, 100%. This was because we contacted the survey participants in multiple ways and we held the surveys face-to-face.

10 10

Model 9

ArchiMate ArchiMate++

Figure 60: Combined survey results model 9

Figure 61: Combined survey results model 10

84

6.6 Conclusion The goal for this chapter was to answer research question 2. First, we will recall the second research question:

“To what extend is it possible to transform IAF architecture models into ArchiMate architecture models and do the possible solutions improve the transformation possibilities? (evaluative)”

Figure 62: Survey results Standard ArchiMate and ArchiMate++ combined

We evaluated the possibilities using a survey, which incorporated a series of IAF and corresponding ArchiMate and ArchiMate++ models. Figure 62 depicts the combined survey results. The perceived equivalence when using standard ArchiMate is low, since some crucial IAF concepts cannot be transformed into ArchiMate, which leaves some models impossible to transform. ArchiMate++ on the other hand scores much better, because it has been complemented with concepts in order to fill the identified gaps of section 5.2. Therefore, the perceived equivalence of the IAF models and the ArchiMate++ models is much higher. However, we need to consider some remarks. First, ArchiMate does not incorporate an extra concept for grouping of concepts, but uses the aggregation relationship for this. Sometimes when transforming IAF models to ArchiMate++ models, this results in behaviour concepts being used for structure purposes. Second, the transform relationship type is not incorporated in ArchiMate++, which should be represented in an ArchiMate++ model by a bidirectional access relationship. Third, the solution alternative concept is not incorporated in ArchiMate++, limiting the traceability throughout an architecture. Overall we can say that the possibilities to transform IAF architecture models into ArchiMate++ models is much higher compared to transforming IAF models into ArchiMate models, because of the higher perceived equivalence.

-6

-12

1

-11

3

-11

3

-9

10

-2

68

1 2 3 2 3

10 10

-2

Mod

el 1

Mod

el 2

Mod

el 3

Mod

el 4

Mod

el 5

Mod

el 6

Mod

el 7

Mod

el 8

Mod

el 9

Mod

el 1

0

Standard ArchiMate ArchiMate++

85

7 Conclusions and recommendations In the final chapter, we will conclude this research by providing the answer to the main research question, give recommendations, provide the research implications, and future work. First, in section 7.1 we provide the answer to the main research question and assess the overall research goal. Next, in section 7.2 we state how to improve the transformation of IAF models into ArchiMate models. Further, Section 7.3 provides the research and practical implications. Finally, this thesis is concluded by identifying future work in section 7.4.

7.1 Conclusions First, let us recall the main research question.

“What are the possibilities to transform an IAF architecture into an ArchiMate equivalent one?”

In chapter 6 we identified to what extend it is possible to transform IAF architecture models into ArchiMate architecture models. The answer to that question provides the basis for the answer to the main research question. We identified that there are several problems when transforming IAF models into Standard ArchiMate, mostly because there are concepts missing. These problem areas were identified in section 5.2. The previous chapter proves that the identified problem areas are real problem areas in practical situations. Let us recall that the identified gaps are the missing collaboration contracts and the missing information aspect area. When looking at the survey results of the previous chapter, we see that the transformation of models 1, 2, 4, 6, and 8 is not or very badly possible, according to the results. These models are all positioned in the identified problem areas, where some IAF concepts could not be mapped to ArchiMate equivalents. This is quite logical, since the transformations are carried out based on the mapping. However, the bad overall score indicates that the problem areas are such a big issue that it is not possible to transform an IAF architecture into an ArchiMate equivalent one, simply because too many concepts are missing. Thus, when transforming an IAF architecture into a standard ArchiMate one this results in two different architectures.

In order to fully examine to possibilities to transform an IAF architecture into an ArchiMate equivalent one, we identified possible solutions (section 5.3) to overcome the identified problem areas. These possible solutions form an extended version of ArchiMate, which we called ArchiMate++. The second part of section 6.4 provides the results of the comparison of IAF and their corresponding ArchiMate++ models. The results show a significant improvement over the standard ArchiMate results. The improvements can be found in the following models: 1, 2, 4, 6 and 8. These are precisely the models where ArchiMate scored very badly on. However, the previous chapter also identified some concerns. First, ArchiMate does not incorporate an extra concept for grouping of concepts, but uses the aggregation relationship for this. Sometimes when transforming IAF models to ArchiMate++ models, this results in behaviour concepts being used for structure purposes. Second, ArchiMate does not incorporate a concept to represent solution alternatives, which reduces the traceability throughout an architecture. Finally, ArchiMate does not support bidirectional access relationships and a transform relationship type. Concluding, we can say that the possibilities to transform an IAF architecture into an ArchiMate equivalent one greatly improved after a small number of concept additions/changes to ArchiMate. However because the scope of the validation did not cover the entire IAF, we have to conclude that only within the scope of this research our

86

conclusion is valid. The next section discusses the recommendations to improve the transformation possibilities even more.

7.2 Recommendations During this research, we have looked at different ways to transform an IAF architecture into an equivalent ArchiMate one. To do this, we compared the IAF and ArchiMate in order to discover similarities and differences. During this research, we addressed some of these differences by defining some propositions to change ArchiMate. In the survey, we validated whether these propositions really improved the possibilities of transforming an IAF architecture into an ArchiMate equivalent one. The results showed that the adjustments resulted in a great improvement. Thus, in order to transform an IAF architecture into an ArchiMate equivalent one, we suggest to make the following additions/changes to ArchiMate according to the propositions in section 5.3:

§ add a concept named service contract to ArchiMate; § rename the ArchiMate contract into product contract; § change the definition of an ArchiMate business service to make it represent business objects

instead of information objects; § add an information object concept; § add an information service concept; § add an information service contract concept; § add an application service contract concept.

During surveying, participating architects noted that some additional concepts are missing for a correct transformation of IAF models into ArchiMate models. Therefore, we recommend also adding these concepts to extend the possibilities for transforming an IAF architecture into an ArchiMate one. We recommend adding the following extra concepts:

§ add solution alternative concept to ArchiMate; § add component concepts for business services, information services and application

services.

7.3 Implications This section of the final chapter describes the implications of this research. First, the research implications are discussed in subsection 7.3.1. Second, subsection 7.3.2 presents the practical implications.

7.3.1 Research implications Since this research is design research and quite specific, it was hard to find a lot of scientific literature about the subject. However, we tried to build as much of the research on literature and known theories, to make it as sound and reproducible as possible. Therefore, this research setup could for instance be used to evaluate the possibilities to transform an IAF architecture into an architecture model using another modelling language.

By conducting the survey at the Dutch National Architecture congress (LAC) 2008, we identified that there is a need for another framework/methodology next to ArchiMate. This research provides an example of a framework next to ArchiMate, but it could also be a possibility to combine other frameworks with ArchiMate.

87

During this research project, we found out that communicating with people is very hard, even when you have specified clear boundaries, such as a set of concepts with a definition. On example hereof is the following: many architects interpret the IAF in their own way. Therefore, it was very hard to construct the survey models in such a way that the architects interpreted them in the same way. In practice on the other hand, architects do interpret models in their own way, which means that our survey probably closely matches a practical situation. In addition, we did identify the models that were interpreted in a different way by looking at the answers given by the architects.

7.3.2 Practical implications During this research, ArchiMate was deeply investigated and compared with the IAF. One of the main considerations that we identified is that ArchiMate does not distinguish between the business perspective and the business from an information perspective. This is also one of the main reasons why the possibilities of transforming IAF architecture models into standard ArchiMate architecture models are so slim. The proposed changes to ArchiMate suggest such an information perspective. However, more research needs to be conducted here in order to extend ArchiMate in such a way that the generic ArchiMate Meta model is still valid.

By identifying the possibilities to transform an IAF architecture into ArchiMate, architects could use ArchiMate as the modelling language of IAF when they consider the mapping to translate IAF concepts into their ArchiMate equals. Thus, Capgemini could offer the IAF in combination with ArchiMate to customers, based on this research.

In order to create the ArchiMate++ models, we have adapted the BiZZdesign Architect tool to suit our needs. We adapted the ArchiMate Meta model with the additions and changes that we proposed in section 5.3.

7.4 Future work As with every research, some ends need further research. This research has covered quite a big area, from creating the mapping until testing the transformation possibilities. Therefore, quite a few ends need more research.

First, we identified that none of the IAF contextual layer concepts could be mapped to an ArchiMate equivalent. Hence the time constraints of this research, we left the contextual layer of the IAF out of this research. To fully transform an IAF architecture into an ArchiMate one, also the contextual layer needs to be addressed.

Next, we identified that the IAF physical layer is almost entirely missing in the mapping. However, we did not propose any changes to ArchiMate in order to enhance the mapping. In addition, the physical layer has not been validated in the survey, since it was out of scope of the project at IVW. So, further research is needed on the IAF physical layer to both enhance the mapping and validate the transformation possibilities.

Next, the technology infrastructure aspect area of the IAF has not been validated in the survey, for it was out of scope of the project at IVW. Transforming the technology infrastructure aspect area concepts is also necessary, for only then a total IAF architecture can be transformed into ArchiMate.

88

In addition, the validation approach we took in this research needs more respondents in order to gain a better external validity. Therefore, more architects need to fill out the survey, and their results need to be added to the current results.

Next, we proposed some changes to ArchiMate in this research. However, we did not look from the ArchiMate perspective at these changes. For instance, we suggested adding an information layer to ArchiMate, but we only suggested adding three concepts to this layer: information service, information contract, and the information object. However, the ArchiMate business layer consists of a lot more generic concepts. These generic concepts could also be added to the information layer, but since this was out of our scope, we did not propose to add these to ArchiMate. So, more research is needed on the proposed information layer.

In addition, we identified that the expressive power of ArchiMate is much higher than the expressive power of the IAF, which is because the IAF only incorporates one type of relationship. In order to extend the expressive power of the IAF, it could be extended with different types of relationships.

Finally, we conducted a survey at the Dutch National Architecture Congress (LAC) 2008, see Appendix A for the results. The survey results indicate that there is a need for a framework/methodology next to ArchiMate. In this thesis, we suggested only one possibility. However, there are a lot more frameworks/methodologies, which could be used in combination with ArchiMate. Since there apparently is a need for this, more research could be conducted on combining different frameworks with ArchiMate to deliver good support when developing an architecture and ArchiMate models are used for the visualisation and documentation.

89

8 References ArchiMate Foundation. (2008). ArchiMate foundation webpage. Retrieved July 10, 2008, from

http://www.archimate.org Capgemini. (2007a). Enterprise, Business and IT Architecture and the Integrated Architecture

Framework. Retrieved July 16, 2008, from http://www.capgemini.com/resources/thought_leadership/enterprise_business_and_it_architecture_and_the_integrated_architecture_framework/

Capgemini. (2007b). IAF v4 Meta Model for Architecture Tooling. Unpublished Meta Model. Capgemini.

Capgemini. (2007c). Integrated Architecture Framework Version 4. Capgemini N.V. Caplat, G., & Sourrouille, J.L. (2002). Model Mapping in MDA. Workshop in Software Model

Engineering. Cloo, J. (2007). Framework for evaluating architecture modeling methods. Radboud Universiteit,

Nijmegen. Czarnecki, K., & Helsen, S. (2006). Feature-based survey of model transformation approaches. IBM

Systems Journal, 45(3), 621-645. Hevner, A.R., March, S.T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research.

MIS Quarterly, 28(1), 75-105. Huc, B. (2006). Architecture Learning Program Essentials. Unpublished Lecture notes. Capgemini. Iacob, M.E., Franken, H., & van den Berg, H. (2007). Enterprise architecture handbook (Vol. 1).

Enschede: Bizzdesign Academy Publishers. Iacob, M.E., Jonkers, H., & Wiering, M. (2004). Towards a UML profile for the ArchiMate language.

Enschede: Telematica Instituut. IEEE Computer Society. (2000). IEEE Std 1471-2000: IEEE Recommended Practice for Architectural

Description of Software Intensive Systems. Jones, S. (2005). Toward an acceptable definition of service [service-oriented architecture].

Software, IEEE, 22(3), 87-93. Jonkers, H., Lankhorst, M., ter Doest, H., Arbab, F., Bosma, H., & Wieringa, R. (2006). Enterprise

architecture: Management tool and blueprint for the organisation. Information Systems Frontiers, 8(2), 63-66.

Jonkers, H., Lankhorst, M.M., Iacob, M.E., & Proper, E. (2008). ArchiMate 1.0 Standard Specification. Jonkers, H., Lankhorst, M.M., Iacob, M.E., & Proper, E. (2009). ArchiMate 1.0 Standard Specification

(No. C091): The Open Group. Krogstie, J., Lindland, O.I., & Sindre, G. (1995, march 28-30). Defining Quality Aspects for Conceptual Models. Paper presented at the IFIP8.1 working conference on Information Systems Concepts

(ISCO3); Towards a consolidation of views, Marburg, Germany. Lopes, D., Hammoudi, S., Bézivin, J., & Jouault, F. (2006). Mapping Specification in MDA: From

Theory to Practice. In Interoperability of Enterprise Software and Applications (pp. 253-264). Mukerji, J., & Miller, J. (2003). MDA Guide V1.0.1. Retrieved July 31, 2008, from

http://www.omg.org/cgi-bin/doc?omg/03-06-01 Mulholland, A., & Macaulay, A.L. (2006). Architecture and the Integrated Architecture Framework.

Retrieved July 10, 2008, from http://www.capgemini.com/resources/solution_material/architecture_and_the_integrated_architecture_framework/?d=1

Nysetvold, A.G., & Krogstie, J. (2005). Assessing business processing modeling languages using a generic quality framework. Proceedings of the CAiSE’05 Workshops, 1, 545–556.

Opdahl, A.L., & Henderson-Sellers, B. (2001). Grounding the OML metamodel in ontology. Journal of Systems and SOftware, 57(2), 119-143.

Opdahl, A.L., Henderson-Sellers, B., & Barbier, F. (2001). Ontological analysis of whole-part relationships in OO models. Information and Software Technology, 43(6), 387-399.

Open Group. (2008). The Open Group. Retrieved July 10, 2008, from http://www.opengroup.org

90

Rahm, E., & Bernstein, P.A. (2001). A survey of approaches to automatic schema matching. The VLDB Journal The International Journal on Very Large Data Bases, 10(4), 334-350.

Shvaiko, P., & Euzenat, J. (2005). A Survey of Schema-Based Matching Approaches. In Journal on Data Semantics IV (pp. 146-171).

Sowa, J.F., & Zachman, J.A. (1992). Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3), 590-616.

Torre van der, L., Lankhorst, M.M., Doest ter, H., Campschroer, J.T.P., & Arbab, F. (2006). Landscape Maps for Enterprise Architectures. Paper presented at the 18th International Conference Advanced Information Systems Engineering (CAiSE 2006), Berlin, Heidelberg.

Transport and Water Management Inspectorate. (2008). Supervision in Safe hands. The Hague: Transport and Water Management Inspectorate the Netherlands.

van Buuren, R., Jonkers, H., Iacob, M.-E., & Strating, P. (2004). Composition of Relations in Enterprise Architecture Models. In Graph Transformations (pp. 39-53).

Weber, R. (1997). Ontological Foundations of Information Systems: Coopers and Lybrand. Wieringa, R. (2007). Problem analysis and Solution requirements: Problem-Solving. Unpublished

Lecture slides. University of Twente. Wu, J. (2006). Frameworks and Models : The categories Retrieved July 10, 2008, from

http://www.liteea.com/lea.php?catid=3&blogid=1 Zachman, J.A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal,

26(3), 276–292.

91

Appendix A: Survey results Dutch National Architecture Congress (LAC) 2008

A total of 76 people took part in this survey, which is approximately 20% of the participators of the Dutch architecture congress (LAC) 2008.

Age of the respondents

The average age of the respondents is 44 years, which is quite high. The above graph underlines the common knowledge that one has to have experience before being able to become an architect.

Gender of the respondents

The above figure points out that IT (architecture) still is a man’ business…

1%

16%

25%49%

9%

Age

< 25 years old

25 - 35 years old

35 - 45 years old

45 - 55 years old

> 55 years old

91%

9%

Gender

Male

Female

92

Years of experience in the architecture field

A little more than 50% of the respondents have more than 5 years of experience in the architecture field. When relating the level of experience with age, this shows a very strong correlation between them, older people tend to be more experienced.

Working in sector

4%

42%

26%

18%

10%

Experience

< 1 year

1-5 years

5-10 years

10-20 years

> 20 years

24%

2%

27%

28%

3%

16%

Working inRetail, Distribution, Transport, Financial

Production, pharmaceutical

IT services, Telecommunications, Media

Government, Utilities, Healthcare

Science

Other

93

Organisation size

The majority of the respondents are affiliated to large organisations in the Netherlands.

Familiarity with IAF

The familiarity of the IAF is quite high considering that the IAF is a proprietary standard. 46% of the respondents have read about the IAF and only 13% has never heard about the IAF.

5%

15%

8%

46%

26%

Organisation size

1-50

50-500

500-1.000

1.000-10.000

> 10.000

28%

46%

13%

13%

Familiarity with IAF

I heard about it

I read about it

I worked with it

No

94

Familiarity with ArchiMate

Most of the respondents are familiar with ArchiMate, only 3% has never even heard about ArchiMate. This means that ArchiMate is well known in the architects’ community.

Necessity to combine ArchiMate with another framework / methodology

From the respondents 86% found it necessary to combine ArchiMate with another kind of framework or methodology in order to construct an architecture. Most of the respondents noted that ArchiMate is only a language and therefore it lacks a process to guide the development of an architecture.

18%

50%

29%

3%

Familiarity with ArchiMate

I heard about it

I read about it

I worked with it

No

86%

14%

Necessity to combine ArchiMate with other framework / methodology

Yes

No

95

ArchiMate used in combination with another framework / methodology

From the results follows that many respondents did already combine ArchiMate with another framework or methodology. DYA is the most popular framework to combine with ArchiMate according to the results, 38% of the respondents that combined ArchiMate with another framework / methodology used DYA.

Experiences with relation to combining ArchiMate with another framework The respondents mentioned that not many problems were found in combining ArchiMate with another framework / methodology. However, a few respondents mentioned that one could have difficulties with combining the concepts of ArchiMate and the other framework / methodology.

58%

42%

Number of respondents that combined ArchiMate with an other framework /

methodology

Combined ArchiMate

Did not combine ArchiMate

27%

38%

10%

9%

16%

ArchiMate used in combination with other frameworks/methodologies

TOGAF

DYA

Zachman

IAF

Other

96

IT Governance

IT Governance definition / dynamic IT Governance The result of our research shows that there are many different perceptions on IT Governance. While some define it only as a monitoring instrument for IT, others define it as the control of business transformations and processes within them.

Governance maturity

The figure above illustrates the maturity levels of the organizations represented in the survey. Most of the companies in this survey are at stage 3: Under development.

Maturity versus KPI’s

This figure shows that as the maturity grows, the KPI’s in place do too. On the other hand, the yellow line that means no KPI’s in place, decreases.

7%

32%

40%

14%

0%7%

Governance maturity

None

Initial

Under development

Defined

Managed

Measured

97

Maturity versus Architecture The result on the question if architecture is used in a enterprise transformation and if it is used to measure the success of an implementation is shown below. As is visualized, the more mature the organization is, the more they make use of architecture.

98

Legislation taken into account when designing an architecture

The majority of the respondents takes legislation into account when designing and setting up an architecture.

Type of legislation

When asking to the type of legislation that is considered in the design of an architecture, financial legislation is mostly taken into account (70%). Privacy is second with 66%.

Respondents often filled in “Security legislation” in the “Other” section.

91%

5% 4%

Are requirements, originating from legislation, taken into account when

designing an architecture?

Yes

Not sure

No

00,10,20,30,40,50,60,70,80,9

1

Financial Environment Management Privacy Other

Type of legislation

99

Concrete examples of measures taken with regard to architecture, related to legislation Some examples were given, such as better protection of data with regard to the Dutch law for the protection of personal information, Dutch government projects and SOx compliance measures.

Change of legislation

Although 91% stated that legislation is taken into account when designing a new architecture, a surprisingly large portion is not sure if changes in legislation are also considered. 14% says no, 9% does not think so, but is not sure and 35% thinks it might be considered implicitly.

EA as basis for technical measures, related to requirements originating from legislation

The majority of the respondents (76%) states that an enterprise architecture is the first place to try to fulfil (technical) requirements, which originate from legislation.

42%

35%

9%

14%

When setting up an architecture, is the fact that legislation changes

taken into account?

Yes, explicitly

Not sure, I think implicitly

Not sure, I don't think so

No

76%

20%

4%

Is EA the basis for technical measures, related to requirements

originating from legislation?Yes

No, this has to be taken care of per application or applicationgroup

No, because…

100

Appendix B: IAF concepts

Contextual concepts

Principle

Definition A statement that defines an objective (or constraint) that is used to determine the organisation and structure of an architecture.

Description § An Architecture Principle is a statement of belief, approach, or intent, which directs the

formulation of the architecture. It does not have to explicitly reference architecture artifacts or structure. In this way, many “Business Principles” will often be expressed within the architecture. Architecture Principles may refer to the current state or to a desired future state.

§ Architecture Principles will usually address more than one IAF aspect areas. § Architecture Principles will have an implicit hierarchical structure where an Architecture

Principle may generate a number of consequential Architecture Principles, some of which may be within other aspect areas.

§ Architecture Principles are owned and validated by the architecture owner or owners. § Architecture Principles are the starting point for any architecture development. Without

Architecture Principles, it will be difficult to organise, structure the architecture, and manage the inevitable conflicting requirements.

§ Architecture Principles are guidelines for the development of the architecture, as they underpin analysis and investigation of architecture options, and provide a structured set of justifications for the decisions that were made about the components in the architecture.

§ Architecture Principles ensure that the architecture is defined consistently and in line with the business objectives.

§ The Architecture Principles are typically derived from Business mission / Strategy / objectives and any corresponding architecture assumptions, scope, constraints and objectives.

§ Additional inputs can be found in current state, business programme information, business and technical strategies, and business consulting studies, interviews, workshops, discussions, etc.

Constraint

Definition A statement that defines an objective (or constraint) that is used to determine the organisation and structure of an architecture.

Description An Architecture Constraint is an assertion of a fact that applies to the architecture and is recognised as having a fundamental impact on the architecture.

101

§ Constraints are inevitable when dealing with complex issues and the impact they have can have serious consequences when developing architecture.

§ Constraints may arise from internal or external sources and may be related to business, existing suppliers, technology, or even finance. Technology selection is a common constraint e.g. a stipulation that deployment must use a particular manufacturer’s technology.

§ It is unusual to uncover additional constraints (as opposed to risks and assumptions for example) during an architecture engagement so constraints are usually identified at the outset.

§ Constraints usually have a lifespan that may be greater or lesser than the architecture lifespan. This is important information as it potentially affects the options available to the architect.

§ The purpose of identifying constraints is to be aware of potential issues in the development (and realisation) of an architecture. Constraints will have impact on the way the architecture is organised and validated. Constraints may limit architectural options, make an “ideal” logical architecture unrealisable, or simply introduce challenges that cannot be overcome.

Assumption

Definition A statement that defines an objective (or constraint) that is used to determine the organisation and structure of an architecture.

Description § An Architecture Assumption is an unvalidated assertion that something is true, but if later

validated as false would introduce an impact on the architecture. § Assumptions must be reasonable, i.e. they will normally have a high probability of being

true. § Assumptions must have general agreement with the relevant stakeholders § Assumptions must have an owner who will be responsible for validating the assumption.

Assumptions have a lifecycle which must be defined in terms of risk, resolution and timeframe

§ Assumptions are a means to allow activities to continue even though validated information is not available.

§ The number of outstanding assumptions is a measure of the risk to the successful completion of an architecture.

Conceptual concepts

Business Service

Definition A Business Service characterises a unique “element of business behaviour” in terms of a Business Activity, undertaken by a specific Role that together support a specific Business Goal.

Description § Business services are basic building blocks of the things an organisation does.

102

§ A Business Service can be understood as the ‘elementary unit of work’ serving a single purpose.

§ A Business Service may be internal to the business, exposed externally to a customer, partner, supplier etc. or may be something that the business consumes from an external party.

§ Business Services are independent of process, organisation, and implementation. A Business Service collaborates with other Business Services through a Business Service Contract.

§ Business Services and their Business Service Contracts may describe all or part of the business. This includes the governance, security or other supporting Business Services.

§ Business Services describe the activities undertaken by a business. They may or may not be subject to automation.

§ Business Services define the fundamental behaviour of the business in terms of discreet activities that can be used to describe and represent a Service Orientated Enterprise or a more Traditional Process Orientated approach (or more usually a combination of both).

§ A Business Service is derived from a unique combination of a Business Goal, and the Business Activity and Role supporting that specific Business Goal.

Business Activity

Definition A business task or group of business tasks that are undertaken by the business to achieve a well defined goal.

Description § Business Activities support the realisation of the Business Goals § Business Activities are a description of WHAT the business does in order to meet its goals. § Business Activities are implementation independent i.e. independent of any organisational

structure or process. § Business activities have clearly defined objectives in transforming an initial state to another

state § Business Activity provides one aspect of the element of business behaviour characterised by

a Business Service.

Business Goal

Definition Business Goals define what the business needs to achieve in order to fulfil its Business Objectives.

Description --

Role

Definition A Business Role performs a Business Activity.

Description § Roles are responsible for the execution of activities

103

§ Roles may also have accountabilities for Goals (although there will be corresponding governance activities for those goals).

§ Roles should not be associated with people or systems as people have multiple roles. Roles are independent of implementation but are still needed to support the activities

§ Roles relate to specific activities and support the same Business Goal as the activity. § Actors are classified in terms of their value and contributions, accountability and

responsibility (cf. RACI-model) of an activity or service

Business Object

Definition A Business Object is a non-human resource used by the business that is significant to the architecture.

Description § Businesses use and consume things from pencils to transport, raw materials for manufacture

etc. § Sometimes it is significant to the architecture (structure) to identify what these Business

Objects are. § Business Objects are used and consumed (in IAF) by Business Service which is described in

an Object Contract. § Different Business Services will use and consume Business Objects in different ways. It may

be architecturally significant to understand these differences when structuring the architecture components.

§ Business Objects may be or infer Information Objects.

Object Contract

Definition An Object Contract describes how a Business Services uses a Business Object.

Description § The Object Contract describes how a Business Service utilises a Business Object. § Different Business Services may make different use of a Business object for example; Fleet

Management will regard transport differently to that of a shipping department.

Business Information Service

Definition A Business Information Service describes the communication behaviour of a Business Service.

Description § As described elsewhere Business Services describe the elementary units of work a company

does. The Business Information Service explicitly focuses on the use and communication aspects of information associated with the Business Services. The Business Information Service is a focus on information and its use by the business.

§ Business Information Services apply to any Business Service and therefore include governance, security or other supporting Business Services.

104

§ A Business Information Service makes no distinction between automated or non-automated use and communication of information. The Business Information Service is automated by Information System Services (you could automate a Business Service but that implies robotic automation as well e.g. automating “clean toilets” results in the automated super loos seen in France and the UK for example).

§ Business Information Services collaborate through the communication of Information Objects.

Information Object

Definition The information that resides in the Architecture

An Information Object is the subject of communication for Business Services.

Description The Information Object describes the information that is used or communicated by Business Information Services

§ An Information Object is a source of information § An Information Object is not a description of data but rather indicates where data is used. § An Information Object is independent of the media it is presented on. § An Information Object can be described by a collection of “STATEMENTS” § Automated Business Information Services will identify automated Information Objects for

use by Information System Services. § An Information Objects are characterised by STATEMENTS that have the general form of:

“Blah” is a “blur” that “bleeps”

Example STATEMENT

An (ORDER) “blah” is the (request of a CUSTOMER) “blur” that (supplies an ARTICLE) “bleeps”

Information System Service

Definition An Information System Service describes an element of behaviour of information automation required to support automated Business Information Services.

Description § An Information System Service supports one or more automated Business Information

Services. § Information System Services describe the Information System capabilities of the

architecture. § An Information System Service collaborates with other Information System Services. The

interaction of an Information System Service with other Information System Services is described in an Information System Service Collaboration Contract.

105

Technology Infrastructure Service

Definition Technology Infrastructure Services describe the behaviour of services that primarily support the Information System Services and may directly support generic business objectives (for example Office Automation type services).

Description § Technology Infrastructure Services are typically common or shared services that support

more than one Information System Service. § A Technology Infrastructure Service primarily interacts with each other to create a common

or shared environment. The interaction between Technology Infrastructure Services is described through the Technology Infrastructure Service Contracts.

§ An Information System Service, or another Technology Infrastructure Service typically consumes a Technology Infrastructure Service. In some cases, a Role may consume an Infrastructure Service directly.

§ Technology Infrastructure Services can be described at different levels of granularity like other services e.g. very granularly or atomic such as processing, communication, storage etc. or less granular, more molecular such as printing, collaboration, e-mail, web access, call centre etc.

Logical Concepts

Logical Business Component

Definition A Logical Business Component is the basic element of an “ideal” or “To Be” business structure created by the grouping of one or more Business Services.

Description § A Logical Business Component describes the basic elements of an “ideal” business structure

in terms of groups of Business Services. The Logical Business Components describe how business objectives will be achieved.

§ Logical Business Components maintains the interactions defined by the Business Service interactions and associated Business Service Contracts.

§ As Business Services reflect several different aspects of Business (role, activity, goal, resources) the Business Services can be grouped into Logical Business Components from one or more of these aspects. For example grouping around common goals will result in one set of Logical Business Components that might reflect the governance model for the business, grouping around organization criteria (roles and activities for example) will create an alternative set of Logical Business Components that describe the organisation, whilst grouping criteria based on activities in a common process will generate another set of Logical Business Components that describe the process components. Doing this allows the impact of the different criteria on the different business aspects to be analysed.

§ Note that the final Logical Business Component architecture will almost certainly be the best fit across all these alternatives.

106

§ The grouping a criterion of Business Services into Logical Business Components is typically justified by a combination of the Architecture Principles, Business Case, and other previously identified Business Objectives.

Actor

Definition An actor assumes a role to perform a task.

Description A component that represents one or more roles

Logical Information Component

Definition A Logical Information Component describes the structure of Information Objects that supports the architecture solution.

Description The Logical Information Component describes Information Objects that have been grouped according to some grouping criteria. One usual criterion is around commonality of use by Business Information Services (or Business Services by inference). Grouping of Information Objects in this way will indicate the most efficient structure for information. Where Business Information Services are to become automated then an automation criteria can be used to create the associated Logical Information Components. In this case, the Logical Information Components will indicate potential data stores

Note that the grouping of Information Objects may also have an influence on the way that Business Services are grouped into Logical Business Components.

Logical Business Information Component

Definition A Logical Business Information Component is a grouping of Business Information Services that represent the structure of the communication aspects of a business.

Description In the same way the Logical Business Component describe the fundamental structure of the business with respect to Role, Goal, Activity and resources (Business Objects) Logical Business Information Components describe the structure of the business with respect to the use and communication of information.

Logical Information System Component

Definition A Logical Information System Component is the basic element of an “ideal” or “To Be” Information system structure created by the grouping of one or more Information System Services.

107

Description The Logical Information System Components represent the “application” components for a given solution alternative. Logical Information System Components describe the implementation independent solution for Information Systems in terms of the desired to-be state.

There may be more than one alternative to-be state, each alternative using different clustering criteria and priorities. These alternatives are used to assess the merits or otherwise, for example balancing performance with cost, reliability with complexity.

The Logical Information System Components are used to build the Logical Information System Interaction Model that will depict and describe the major interfaces, and provide input to the Technology Infrastructure Aspect Area to support the derivation of Technology Infrastructure Services.

Logical Technology Infrastructure Component

Definition A Logical Technology Infrastructure Component is an implementation independent realizable element of the to-be technology infrastructure aspects of the architecture.

Description • Logical Technology Infrastructure Components represent logical realisable infrastructure

elements, for example servers, storage array, network, firewall etc.

• Logical Technology Infrastructure Components are grouping of Technology Infrastructure Services.

• Logical Technology Infrastructure Components support Information System Services (and Information System Components implicitly) and sometimes Business Information Services directly.

• Logical Technology Infrastructure Components are implementation independent.

• Solution Alternatives are based on grouping criteria derived from the Architecture Principles, for example centralisation, consolidation, scalability etc

Physical Concepts

Physical Business Component

Definition The implementation dependent description of a structured physical component that comprises one or more Logical Business Components.

Description A Physical Business Component is one or more Logical Business Components that defines what the logical architecture will be implemented with.

Physical Business Components are defined by the standards and products that implement them.

In some cases, the Physical Business Components may be allocated to current state components or they may need to be designed and built as new components. The Architecture Objectives and Constraints will drive the grouping/allocation criteria.

108

Physical Information Component

Definition The implementation dependent description of a structured physical component that comprises one or more Logical Information Components.

Description A Physical Information Component is one or more Logical Information Components that defines what the logical architecture will be implemented with.

Physical Information Components are defined by the standards and products that implement them.

In some cases, the Physical Information Components may be allocated to current state components (existing data stores for example) or they may need to be designed and built as new components. The Architecture Objectives and Constraints will drive the grouping/allocation criteria.

Physical Business Information Component

Definition The implementation dependent description of a structured physical component that comprises one or more Logical Business Information Components.

Description A Physical Business Information Component is one or more Logical Business Information Components that defines what the logical architecture will be implemented with.

Physical Business Information Components are the realisation of part of the overall business structure. They are therefore the information focus of the Physical Business Components. Note that they represent how the business will communicate and use information. They are not implemented independently of the Physical Business Components. (This is why Logical Business Components and Logical Business Information Components should be derived and iterated together)

Physical Business Information Components will be aligned with the Physical Business Components when being allocated to current state components or designed and built as new components.

Physical Information System Component

Definition The implementation dependent description of a structured physical component (e.g. software component) that comprises one or more Logical Information System Components.

Description Physical Information System Components are implementation dependent groups of one or more Logical Information System Components. Grouping criteria are derived from the Architecture Principles and more importantly from the Architecture Constraints. A common principle is one that describes the preference for package solutions over custom, in this instance the logical components being grouped to package functionalities.

In addition, some components will be designated for custom developments.

109

Physical Technology Infrastructure Component

Definition The implementation dependent description of a structured infrastructure component that comprises one or more logical technology infrastructure components.

Description Physical Technical Infrastructure Components are implementation dependent groups of Logical Technical Infrastructure Components. The grouping criteria are derived from the Architecture Principles and Architecture Constraints.

Physical Technical Infrastructure Components describe real components

The Physical Technical Infrastructure Components also defines the key connectivity points for the solution and provides a view of the real information flows across the architecture thereby allowing more precise and complete view of capacity requirements.

Business Specification

Definition What the design and implementation of the architecture will be realised with.

Description Describes:

§ Organisation models (re-structured, new etc) § Governance models § Process components § “SERVICE” descriptions (SOA type services) § Job Specifications (from roles – actor) § Interaction models § Migration (phasing) and other Views

Information Specification

Definition What the design and implementation of the information architecture aspect will be realised with.

Description Describes:

§ Information model (static information structure) § Information Stores (As-is and To-Be allocation) § Master – Slave designations, Replication objectives § Ownership § Information Archive and availability specification § Audit § Interaction model (Information Store Structure) § Migration (phasing) and other Views

110

Communication Specification

Definition What the design and implementation of the communication architecture aspect will be realised with.

Description Describes:

§ Automated and non automated communications § Allocation and mapping with current state elements of the business (where automation will

be applied, changed etc § What form manual communication will take (phone, forms, email etc

Information System Specification

Definition Specifies realization of Physical IS Components.

Description Describe specification for designing an interface. Do NOT describe the interface design itself

Include:

§ information elements associated with the interface § interface types (asynchronous, synchronous etc) § service characteristics (volumetric, importance, error handling, etc).

Technology Infrastructure Specification

Definition Specifies realization of Physical TI Components

Description § Commodity items (typically PTICs) can be specified with help of vendors (i.e. especially

sizing for throughput and capacity) § Specifications should generally not be described in terms of products (these are candidate

Technology Infrastructure Standards)

Business Standard

Definition What must the design and implementation of the business architecture aspects conform/comply with.

Description Describes:

§ Policies for governance and security § Codes of conduct § Legislation

111

§ Standards

Information Standard

Definition What must the design and implementation of the information architecture aspects conform/comply with.

Description Describes:

§ Policies - for back up, integrity, availability § Legislation – for archive, access , audit § Standards – corporate canonical forms

Communication Standard

Definition What must the design and implementation of the information architecture aspects conform/comply with.

Description Describes:

§ Policies – could include policies for email, communication with external organisations etc § Legislation – must use PAYE forms § Standards (examples might be EDI, BACS possibly XML)

Information System Standard

Definition Specifies what has to be adhered when implementing the IS aspects of the architecture solution.

Description Standards may be Mandatory or recommended to follow or use during creation and implementation.

Technology Infrastructure Standard

Definition Specifies what has to be adhered when implementing the IS aspects of the architecture solution.

Description Implementation (including detailed Design) Guidelines set out the core structural architecture decisions that must be adhered to during the detailed design and implementation phases.

The guidelines provide the starting points and pre-conditions for implementation and describe the objectives, assumptions, constraints and design principles.

112

Business Guideline

Definition Defines what flexibility is allowable with the design and implementation of the architecture.

Description Describes business principles and constraints.

Information Guideline

Definition Defines what flexibility is allowable with the design and implementation of the information architecture aspects.

Description Describes information principles and constraints.

Communication Guideline

Definition Defines what flexibility is allowable with the design and implementation of the information architecture aspects.

Description Describes communication principles and constraints.

Information System Guideline

Definition Defines the constraints for the realization and implementation of the Physical IS Components of the future state architecture.

Description § Description of methods, techniques, requirements, objectives and design principles for IS

architecture improvement. § Focus on change and change factors for design and implementation.

Technology Infrastructure Guideline

Definition Defines the constraints for the realization and implementation of the Physical TI Components of the future state architecture.

Description § Description of methods, techniques, requirements, objectives and design principles for IT

architecture improvement. § Focus on change and change factors for design and implementation.

113

Cross layer concepts

Business service collaboration contract & Business Component Collaboration Contract

Definition A Business Collaboration Contract describes the collaboration and behaviour between Business Services or between Business Components.

Description § The Business Services Collaboration Contract specifies the content and characteristics of the

relationship between Business Services. § The Logical Business Component Collaboration Contract specifies the content and

characteristics of the relationship between Logical Business Components. § The Physical Business Component Collaboration Contract specifies the content and

characteristics of the relationship between Physical Business Components. § The Contracts describes the rules that govern interaction behaviour. These rules may be

mandatory or optional, and may include precedence of behaviour i.e. dependency on other interactions.

§ All Business Collaboration contracts are essentially the same except that Component Collaboration Contracts are aggregations of the Business Service Collaboration Contracts that already exist between Business Services (see Collaboration Contract Artifacts)

§ This specification allows the development of service level objectives (irrespective of whether they are formalized into a service level agreement). A Business Collaboration Contract enables insight into the behavioural context of services, components, and associated specifications.

§ Business Collaboration Contracts form an important insight to developing the critical operational path.

Business Information Service Collaboration Contract & Business Information Component Collaboration Contract

Definition A Business Information Collaboration Contract describes the collaboration and behaviour between Business Information Services or between Business Information Components.

Description § The Business Information Services Collaboration Contract specifies the content and

characteristics of the relationship between Business Information Services. § The Logical Business Information Component Collaboration Contract specifies the content

and characteristics of the relationship between Logical Business Information Components. § The Physical Business Information Component Collaboration Contract specifies the content

and characteristics of the relationship between Physical Business Information Components. § The Contracts describes the rules that govern interaction behaviour only with respect to

information. These rules may be mandatory or optional, and may include precedence of behaviour i.e. dependency on other interactions.

§ All Business Information Collaboration contracts are essentially the same except that Component Collaboration Contracts are aggregations of the Business Information Service

114

Collaboration Contracts that already exist between Business Information Services (see Collaboration Contract Artifacts)

§ This specification allows the development of service level objectives (irrespective of whether they are formalized into a service level agreement). A Business Information Collaboration Contract enables insight into the behavioural context of services, components, and associated specifications.

§ Business Information Collaboration Contracts form an important insight to developing the critical operational path.

Information System Service Collaboration Contract & Information System Component Collaboration Contract

Definition An Information System Collaboration Contract describes the collaboration and behaviour between Information System Services or between Information System Components.

Description § The Information System Service Collaboration Contract specifies the content and

characteristics of the relationship between Information System Services. § The Logical Information System Component Collaboration Contract specifies the content and

characteristics of the relationship between Logical Information System Components. § The Physical Information System Component Collaboration Contract specifies the content

and characteristics of the relationship between Physical Information System Components. § The Contracts describes the rules that govern interaction behaviour only with respect to

information. These rules may be mandatory or optional, and may include precedence of behaviour i.e. dependency on other interactions.

§ All Information System Collaboration contracts are essentially the same with the proviso that Component Collaboration Contracts are aggregations of the Information System Service Collaboration Contracts that already exist between Information System Services (see Collaboration Contract Artifacts)

§ This specification allows the development of service level objectives (irrespective of whether they are formalized into a service level agreement). An Information System Collaboration Contract enables insight into the behavioural context of services, components, and associated specifications.

§ Information System Collaboration Contracts form an important insight to developing the critical operational path.

Technology Infrastructure Service Collaboration Contract & Technology Infrastructure Component Collaboration Contract

Definition A Technology Infrastructure Service Contract describes the behaviour and characteristics between Technology Infrastructure Services.

Description The Technology Infrastructure Service Contract defines the quality and behaviour characteristics of the interaction between two collaborating Technology Infrastructure Services.

115

The quality characteristics describe the necessary service-levels (volumetric, throughput, etc) of the interaction and the behaviour characteristics describe what happens in the interaction in terms of syntax & semantics and communication mechanisms.

The Technology Infrastructure Service Contract will reflect the supported information System Component Collaboration Contracts.

Solution Alternative

Definition To indicate component or component structure variants. This object exists for decision support.

Description --

116

Appendix C: ArchiMate concepts

Business concepts

Business Actor

Definition An organisational entity that is capable of performing behaviour.

Description A business actor performs the behaviour assigned to a (one or more) business role. Examples of business actors are humans, departments, business units or any other business entity that is capable of performing behaviour.

Business Collaboration

Definition A (temporary) configuration of two or more business roles resulting in specific collective behaviour in a particular context.

Description A business process (function) may be interpreted as the internal behaviour assigned to a single business role. In some cases, behaviour is the collective effort of more than one business role. Business collaborations represent this collective effort. Business interactions are used to describe the internal behaviour that takes place within business collaboration.

Business Event

Definition Something that happens (internally or externally) and influences behaviour.

Description An internal or external (business) event may trigger or interrupt. Business processes and other business behaviour may be triggered or interrupted by an event. Moreover, business processes may also generate (trigger) events that trigger other business processes, functions, or interactions.

Business Function

Definition A unit of internal behaviour that groups behaviour according to, e.g., required skills, knowledge, resources, etc, and is performed by a single role within the organisation.

Description A business function describes internal behaviour performed by a business role that is required to produce a set of products and services. For a consumer the products and services are relevant and the required behaviour is merely a black box, hence the designation: internal.

There is a potential many-to-many relation between business processes and business functions. Informally speaking, processes describe some kind of ''flow'' of activities whereas functions group activities according to required skills, knowledge, resources etc. Complex processes in general

117

involve activities that offer various functions. In this sense, a business process forms a string of business functions.

In general, a business function delivers benefit from a business point of view. Organisational units or applications may coincide with business functions due to their specific grouping of business activities.

Business Interaction

Definition A unit of behaviour performed as a collaboration of two or more business roles.

Description A business interaction is similar to a business process/function, but while a process/function may be performed by a single role, an interaction is performed by multiple roles in collaboration.

Business Interface

Definition A business interface declares how a business role can connect with its environment.

Description A business interface specifies how the functionality of a business role can be used by other business roles (provided interface), or which functionality the business roles requires from its environment (required interface). A business interface exposes an organisational service to the environment. The same organisational service may be exposed through different interfaces.

Business Object

Definition A unit of information that has relevance from a business perspective.

Description Business objects represent the important concepts in which the business thinks about a domain. Generally, a business object is used to model an object type (cf. a UML class), of which several instances may exist within the organisation. A wide variety of types of business objects can be defined. Business entities are passive in the sense that they do not trigger or perform processes.

Business Process

Definition A unit of internal behaviour or collection of causally related units of internal behaviour intended to produce a defined set of products and services.

Description A business process describes the internal behaviour performed by a business role that is required to produce a set of products and services. For a consumer the products and services are relevant and the required behaviour is merely a black box, hence the designation: internal.

118

In comparison to a business interaction, in which more than two business roles are (interactively) involved, only one business role is involved with a business process. However, a (complex) business process may consist of sub business processes assigned to different business roles.

There is a potential many-to-many relation between business processes and business functions. Informally speaking, processes describe some kind of "flow" of activities whereas functions group activities according to required skills, knowledge, resources, etc.

Business Role

Definition A named specific behaviour of a business actor participating in a particular context.

Description Business processes or business functions are assigned to a single business role with certain responsibilities or skills. A business actor that fulfils a business role ultimately performs the corresponding behaviour.

Next to the relation of a business role with behaviour, a business role is also useful in an (structural) organisational sense for instance in the division of an organisation.

Business Service (Organisational Service)

Definition An externally visible unit of functionality, which is meaningful to the environment and is provided by a business goal. One can distinguish between internal and external services.

Description An organisational service exposes the functionality of business roles or collaborations to their environment. This functionality is accessed through one or more business interfaces. An organisational service is realised by one or more business processes, business functions or business interactions that are performed by the business roles or business collaborations respectively. It may access business objects.

An organisational service should provide a unit of functionality that is meaningful from the point of view of the environment. It has a purpose, which states this utility. The environment includes the (behaviour of) users from outside as well as inside the organisation.

Contract

Definition A formal or informal specification of agreement that specifies the rights and obligations associated with a product.

Description The Contract concept may be used to model a contract in the legal sense, but also a more informal agreement associated with a product. It may also be or include a Service Level Agreement (SLA), describing an agreement about the functionality and quality of the services that are part of a product. A contract can be regarded as a specialisation of a business object.

119

Meaning

Definition The knowledge or expertise present in the representation of a business object, given a particular context.

Description A meaning is the representation-related counterpart of "Purpose": it represents the functionality of a representation (for example, a document, message; the representations related to a business object). A meaning is therefore not equal to the representation carrying the meaning (just like a purpose is not the same as the organisational service that fulfils it). It is a use case- like functional description that expresses what some representation is for, i.e. how it informs the external user.

It is possible that different users view the informative functionality of a representation differently. For example, what may be a "registration confirmation" for a client could be a "Client Mutation" for a CRM department (assuming for sake of the argument that it is modelled as an external user). In addition, various different representations may carry essentially the same meaning. For example, various different documents (a web document, a filled-in paper form, a "client contact" report from the call centre) may essentially carry the same meaning.

Product

Definition A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external).

Description A (financial or information) product consists of a collection of services, and a contract that specifies the characteristics, rights and requirements associated with the product. ‘Buying’ a product gives the customer the right to use the associated services. Generally, the product concept is used to specify a product type. The number of product types in an organisation are typically relatively stable compared to, e.g., the processes that realise or support the products. ‘Buying’ is usually one of the services associated with a product, which results in a new instance of that product (belonging to a specific customer). Similarly, there may be services to modify or ‘destroy’ a product.

Representation

Definition The perceptible form of the information carried by a business object.

Description Representations (for example, messages, and documents) are the perceptible carriers of information that are related to business objects. If relevant, representations can be classified in various ways, for example in terms of medium (electronic, paper, audio, etc), format (HTML, ASCII, PFD, RTF, etc).

120

Value

Definition The value of a product or service is that which makes some party appreciate it, possibly in relation to providing it, but more typically to acquiring it.

Description Value can go two ways: it may apply to what a party gets by selling or making available some product or service, or to what a party gets by buying or obtaining access to it. Value is often expressed in terms of money, but it has since long been recognised that non-monetary value also is essential to business, for example, practical/functional value (including the right to use a service), and the value of information or knowledge. Though value can hold internally for some system or organisational unit, it is most typically applied to external appreciation of goods, services, information, knowledge, or money, normally as part of some sort of customer-provider relationship.

Application concepts

Application Collaboration

Definition An application collaboration defines a (temporary) configuration of two or more components that cooperate to jointly perform application interactions.

Description Application collaboration specifies which components (have to) cooperate to perform some task. The collaborative behaviour, including e.g. the communication pattern of these components, is modelled by an application interaction.

Application Component

Definition A modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces.

Description An application component is a self-contained unit of functionality. As such, it is independently deployable, reusable, and replaceable. A component realises one or more application functions. It encapsulates its contents: its functionality is only accessible through a set of application interfaces. Cooperating application components are connected via application collaborations.

Application Function

Definition A coherent group of internal behaviour of a component.

Description An application function describes the internal behaviour of a component; for the user of a component that performs a application function, this function is invisible. If its behaviour is exposed

121

externally, this is done through one or more services. An application function abstracts from the way it is implemented. Only the necessary behaviour is specified.

Application Interaction

Definition A unit of behaviour jointly performed by two or more collaborating components.

Description An application interaction describes the externally visible behaviour that is performed by components that participate in an application collaboration. This may e.g. include the communication pattern between these components. An application interaction can also specify the externally visible behaviour needed to realise an application service.

Application Interface

Definition An application interface declares how a component can connect with its environment.

Description An application interface specifies how the functionality of a component can be accessed by other components (provided interface), or which functionality the component requires from its environment (required interface). An application interface exposes an application service to the environment. The same application service may be exposed through different interfaces.

In a sense, an application interface specifies a kind of contract that a component realising this interface must fulfil. This may include e.g. parameters, protocols used, pre- and post conditions, and data formats.

Application Service

Definition An externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. One can distinguish between internal and external services.

Description An application service exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces. An application service is realised by one or more software functions that are performed by the component. It may require, use and produce data objects.

A application service should be meaningful from the point of view of the environment; it should provide a unit of functionality that is in itself useful to its users. It has a purpose, which states this utility to the environment. This means, for example, that if this environment includes business processes, application services should have business relevance.

122

Data Object

Definition A coherent, self-contained piece of information suitable for automated processing.

Description An application functions operates on a data object. A data object may be communicated via interactions and used or produced by application services. It should be a useful, self-contained piece of information with a clear meaning to the business, not just to the application level. Typical examples of data objects are a customer record, a client database, or an insurance claim.

Technology concepts

Artifact

Definition An artifact is a physical piece of information that is used or produced in a software development process, or by deployment and operation of a system.

Description An artifact represents a concrete element in the physical world. It is typically used to model (software) products such as source files, executables, scripts, database tables, messages, documents, specifications, and model files. An instance (copy) of an artifact can be deployed on a node.

Communication Path

Definition A communication path is a relation between two or more nodes, through which these nodes can exchange information.

Description A communication path is used to model the logical communication relations between nodes. It is realised by one or more networks, which represent the physical communication links. The communication properties (e.g. bandwidth, latency) of a communication path are usually aggregated from these underlying networks.

Device

Definition A physical computational resource upon which artifacts may be deployed for execution.

Description A device is a specialisation of a node that represents a physical resource with processing capability. It is typically used to model hardware systems such as mainframes, PCs, or routers. Usually, they are part of a node together with system software. Devices may be composite, i.e., consist of sub-devices. Networks can interconnect devices.

123

System Software

Definition The software environment for specific types of components and objects that are deployed on it in the form of artifacts.

Description System software is a specialisation of a node that is used to model the software environment in which artifacts run. This can be e.g. an operating system, a J2EE application server, a CORBA ORB, a database system, or a workflow engine. In addition, system software can be used to represent e.g. communication middleware. Usually, system software is combined with a device representing the hardware environment to form a general node.

Infrastructure Interface

Definition An infrastructure interface declares how an infrastructure component can connect with its environment.

Description An infrastructure interface specifies how the infrastructure services of a node can be accessed by other nodes (provided interface), or which functionality the node requires from its environment (required interface). An infrastructure interface exposes an infrastructure service to the environment. The same service may be exposed through different interfaces.

In a sense, an infrastructure interface specifies a kind of contract that a component realising this interface must fulfil. This may include e.g. parameters, protocols used, pre- and post conditions, and data formats.

Infrastructure Service

Definition An externally visible unit of functionality, provided by one or more infrastructure components, exposed through well-defined interfaces, and meaningful to the environment. One can distinguish between internal and external services.

Description An infrastructure service exposes the functionality of a node to its environment. This functionality is accessed through one or more infrastructure interfaces. It may require, use, and produce artifacts.

An infrastructure service should be meaningful from the point of view of the environment; it should provide a unit of functionality that is in itself useful to its users, such as application components and nodes.

Typical infrastructure services may e.g. include messaging, storage, naming, and directory services. It may access artifacts, e.g. a file containing a message.

124

Network

Definition A network is a physical communication medium between two or more devices.

Description A network represents the physical communication infrastructure. This may comprise one or more fixed or wireless network links. The most basic network is a single link between two devices. A network has properties such as bandwidth and latency. It embodies the physical realisation of the logical communication paths between nodes.

Node

Definition A computational resource upon which artifacts may be deployed for execution.

Description Nodes are active processing elements that execute and process artifacts, which are the representation of components and data objects. Nodes are for example used to model application servers, database servers, or client workstations. They can consist of sub-nodes representing physical devices and execution environments for artifacts. Communication paths can interconnect nodes.

Relations

Access

Definition The access relationship models the access of behavioural concepts to business or data objects.

Description The access relationship indicates that a process, function, interaction, service, or event ‘does something’ with a (business or data) object: e.g., create a new object, read data from the object, write or modify the object data, or delete the object. The relationship can also be used to indicate that the object is just associated with the behaviour: e.g., it models the information that comes with an event, or the information that is made available as part of a service.

Aggregation

Definition The aggregation relationship indicates that an object groups a number of other objects.

Description Our aggregation relationship was inspired on the aggregation relationship in UML class diagrams, but is applicable to aggregate a wider range of concepts.

125

Assignment

Definition The assignment relationship links units of behaviour with active elements (e.g. roles, components) that perform them, or roles with actors that fulfil them.

Description n/a

Association

Definition Association models a relationship between objects that is not covered by another, more specific relationship.

Description Association is mainly used as in UML, to model relationships between business objects or data objects that are not modelled by the standard relationships aggregation, composition or specialisation. In addition to this, the association relationship is used to link the informational concepts with the other concepts: a business objects with a representation, a representation with a meaning and an organisational service with a purpose.

Composition

Definition The composition relationship indicates that an object consists of a number of other objects.

Description Our composition relationship was inspired on the composition relationship in UML class diagrams, but is applicable to aggregate a wider range of concepts.

Flow

Definition The flow relationship describes the exchange or transfer of, e.g., information or value between processes, function, interactions, and events.

Description The flow relationship is used to model the relationships between behaviour concepts in a process. Now, no distinction is made between an active triggering relationship and a passive causal relationship.

Grouping

Definition The grouping relationship indicates that objects belong together based on some common characteristic.

126

Description Similar to the UML package, the grouping relationship is used to group an arbitrary group of model objects, which can be of the same type or of different types. In contrast to the aggregation or composition relationships, there is no "overall" object of which the grouped objects form a part.

Junction

Definition A junction is used to connect relationships of the same type.

Description A junction is used in a number of situations to connect relationships of the same type: for example, to split or join relationships, or to indicate how relationships starting from an object are linked to internal (nested) objects of the same type.

Realisation

Definition The realisation relationship links a logical entity with a more concrete entity that realises it.

Description The realisation relationship indicates how logical entities ("what"), such as services, are realised by means of entities that are more concrete ("how"). For the moment, the realisation relationship is only used in an operational sense: e.g., a process/function realises a service. The relationship might also be applicable in a design/implementation context: e.g., a database application realises a group of (representations of) business objects.

Specialisation

Definition The specialisation relationship indicates that an object is a specialisation of another object.

Description Our composition relationship was inspired on the generalisation/specialisation relationship in UML class diagrams, but is applicable to specialise a wider range of concepts.

Triggering

Definition The triggering relationship describes the temporal or causal relations between processes, function, interactions, and events.

Description The triggering relationship is used to model the relationships between behaviour concepts in a process. Now, no distinction is made between an active triggering relationship and a passive causal relationship.

127

Use

Definition The use relationship models the use of services by processes, functions or interactions and the access to interfaces by roles, components, or collaborations.

Description The use relationship describes the services that a role or component offers are used by entities in the environment. The use relationship is used for both the behaviour aspect and the structure aspect.

128

Appendix D: Summary of Criteria No. Name Classification Source Description C1. Artifact definition Mapping creation

criteria I The mapping should be based on

the definition of the artifacts that are described in the IAF reference manual.

C2. Documentation Mapping creation criteria

I Clearly document the choices and the rationale behind the choices when mapping the concepts of IAF and ArchiMate

C3. Unidirectionality Mapping creation criteria

I Define a unidirectional mapping, from IAF to ArchiMate.

C4. Logical/physical layer Mapping creation criteria

I Carefully distinct between logical and physical layer concepts.

C5. Relation types Domain appropriateness

I Consider the types of relations used in the IAF and ArchiMate models in the mapping.

C6. Detail support Domain appropriateness

I the modelling language should support a low level of detail as well as a high level of detail.

C7. Automation Domain appropriateness

I The mapping should be able to address non-automated as well as automated parts of an organisation.

C8. Collaboration Contracts

Domain appropriateness

I ArchiMate needs to be able to represent IAF collaboration contracts.

C9. Levels of Abstraction domain appropriateness

I A modelling language should minimally consider two levels of abstraction.

C10. Same level of abstraction

Domain appropriateness

I Two concepts that are mapped must have the same level of abstraction.

C11. Implementation dependent physical layer

Domain appropriateness

I Any concept that represents an IAF logical layer concept should also be implementation independent.

C12. Implementation dependent logical layer

Domain appropriateness

I Any concept that represents an IAF physical layer concept should be implementation dependent.

C13. Hierarchy Domain appropriateness

L It must be possible to make hierarchical models

C14. Guidelines Participant language knowledge appropriateness

L It should have good guidelines for the use of the language.

C15. Representation Participant language knowledge appropriateness

L The external representation of concepts should be intuitive to the stakeholders.

C16. Number of concepts Comprehensibility appropriateness

L The number of concepts should be reasonable.

129

No. Name Classification Source Description C17. Simplicity Comprehensibility

appropriateness L One should strive for graphical

simplicity. C18. Syntax Technical actor

interpretation appropriateness

L The language should have a formal syntax.

C19. Semantics Technical actor interpretation appropriateness

L The language should have formal semantics.

C20. Tool support5 Organisational appropriateness

L The language must be supported by tools that are either already available or can be made easily available in the Organisation.

C21. Construct deficit Comprehensibility appropriateness

L All IAF constructs can be mapped to an ArchiMate equivalent

C22. Construct redundancy

Comprehensibility appropriateness

L There is only one ArchiMate construct mapped to one IAF construct.

C23. Construct overload Comprehensibility appropriateness

L There is only one IAF construct mapped to one ArchiMate construct.

C24. Construct excess Comprehensibility appropriateness

L All the ArchiMate constructs are mapped to a corresponding IAF construct.

Table 35: Summary of criteria

5 This criterion is not taken into account during the selection of the best mapping alternative, since it cannot be used on separate concepts. However, both IAF and ArchiMate have toolsupport. For ArchiMate there are several vendors that provide ArchiMate tools, such as TROUX, IDS Scheer, BiZZdesign, Telelogic, Casewise. For IAF there is only one tool called IAFworkbench, which is based on the BiZZdesign Architect.

130

Appendix E: Mapping of concepts IAF to ArchiMate

131

Appendix F: Proposed ArchiMate Meta model

132

Appendix G: Updated mapping IAF to ArchiMate

133

133

Appendix H: Validation Survey This survey is for the practical validation of a master’s research project, conducted at Capgemini. The goal of this research project is to unveil the possibilities to transform an architecture created using IAF into an architecture that uses ArchiMate models. First, a mapping between IAF and ArchiMate has been defined in order to compare IAF and ArchiMate. This mapping resulted in the knowledge of where IAF and ArchiMate overlap, but also where they differ. This survey presents a number of models, both IAF and ArchiMate. To create the ArchiMate models, the mapping is used to transform the IAF models into ArchiMate models. In order to overcome some deficits, we have also suggested some extensions to ArchiMate, which are also taken into account during the survey.

The goal of this survey is to research to what extend the meaning of the ArchiMate models is equivalent to that of the IAF models. Important is that the respondents consider whether the meaning of the two compared models is identical. The first section consists of the IAF models to which the ArchiMate models have to be compared. The same set of IAF models is used twice: first, to compare them to the standard ArchiMate models, and second, to compare the them to the Extended ArchiMate (ArchiMate with some changes) models.

134

IAF Models

Model 1 – Business interaction model The Business Interaction Model describes the behaviour of the business through the analysis of which Actor contributes to which Business Goal through what Business Activity. The Business Interaction Model describes the relationships between actors, activities, and functions of the business in terms of Business Services and the Business Service Contracts.

Figure 63: IAF model: Business interaction model

Model 2 – Business objects used by business services This model describes business services that use business objects, showing the business objects that are used by specific business services.

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Verdelen aantallen inspecties over units

Bepalen benodigde capaciteit

Matchen jaarplan

Maken globale planning

Bepaling # inspecties

Capaciteit

Bepaling # inspecties

Matching jaarplan

Verdeling inspecties

Service contract

Business service

Legend

135

Figure 64: IAF model: Business object usage by business services

Model 3 – Logical business components This model shows how the business services are grouped into logical business components.

Figure 65: IAF model: logical business components

Matchen jaarplan

Vooroverleg senior inspecteurs/werkvoorbereidersSamenstellen teams

Aanwijzen projectleiders voor thema acties

Controleren beschikbaarheid inspecteursBepalen Prioritering uit te voeren inspecties

Kenbaar maken specifieke wensen inspecteur

Geplande activiteitOndersteunende informatie

Business service

Business object

Legend

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Verdelen aantallen inspecties over unitsBepalen benodigde capaciteit Matchen jaarplan

Maken globale planning

Opstellen jaarwerkplan

Bijhouden individuele planning inspecteurs

Ondersteuning projectmatig werken

Herbevestigen inspectieafspraak

Maken inspectieafspraak

Onderling verdelen werkzaamheden inspecteursInplannen inspecteurs

Controleren beschikbaarheid inspecteurs

Aanwijzen projectleiders voor thema acties

Maken werkverdeling per team

Vooroverleg senior inspecteurs/werkvoorbereidersSamenstellen teams

Koppelen objecten van toezicht aan inspecteurs

Bepalen Prioritering uit te voeren inspecties

Kenbaar maken specifieke wensen inspecteur

Opstellen operationele planning

Leveren input aan beleidsdirectie

Opstellen jaarplan

Business service

Log. business comp

Legend

136

Model 4 – Information interaction model The information interaction model relates business information services to information objects. It states how information objects are used by business information services.

Figure 66: IAF model: Information interaction model

Aanwijzen projectleiders voor thema acties

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Bepalen benodigde capaciteit

Bepalen Prioritering uit te voeren inspecties

Bijhouden individuele planning inspecteurs

Controleren beschikbaarheid inspecteurs

Herbevestigen inspectieafspraak

Inplannen inspecteurs

Kenbaar maken specifieke wensen inspecteur

Koppelen objecten van toezicht aan inspecteurs

Leveren input aan beleidsdirectie

Maken globale planning

Maken inspectieafspraak

Maken werkverdeling per team

Matchen jaarplan

Onderling verdelen werkzaamheden inspecteurs

Samenstellen teams

Verdelen aantallen inspecties over units

Vooroverleg senior inspecteurs/werkvoorbereiders

Jaarwerkplan

Meerjarenplan

Natuurlijke persoon

Object

Operationeel plan

Politiek/Bestuurlijke regels

Proces

Rechtspersoon

Resources

Werkaanbod Werkwijze

Business information service

Information object

Legend

Legendinteractietypegetwritetransform

137

Model 5 – Logical information components The Logical Information Component Structure Model describes the grouping of Information Objects optimised through their affinity of use by Business Information Services. The outcomes of this model are the Logical Information Components.

Figure 67: IAF model: Logical information components

Dossier

CertificaatVergunning

Interventie

Besluit

Bevinding

Waarneming

Verantwoording

Document

Beleidsadvies

Resultaat

Nalevinggedrag

Risicoprofiel MiddelenbeslagEfficiencygraad

Effectiviteitgraad

Aggregaties

Werkwijze

Resources

Ondersteunendeinformatie

Natuurlijke persoonObject

Rechtspersoon Proces

Object van toezicht / subject van naleving

Wetsregel

Wetswijziging

Wetten/regels

Verloping/toelating Incident

Klacht

Aanvraag Bezwaar/beroep

Signaal Vervolginspectie

Externe gebeurtenis/trigger

Toezichtbeleid

Toezichtarrangement

Politiek/Bestuurlijke regels

Prestatie-indicatoren

Beleid- en uitvoeringsregels

Behandelschema

Aanpak

Meerjarenplan

Jaarwerkplan

Operationeel plan

Vervolgafspraken

Werkaanbod

Geplande activiteiten

Log. information comp

Information object

Legend

138

Model 6 – Logical Business information component interaction model The logical business information component interaction model describes the relationships and behaviour between logical business information components through the logical business information component collaboration contracts.

Figure 68: IAF model: Logical business information component interaction model

Controleren beschikbaarheid inspecteurs

Samenstellen teams

Aanwijzen projectleiders voor thema acties

Onderling verdelen werkzaamheden inspecteurs

Maken werkverdeling per team

Maken inspectieafspraak

Koppelen objecten van toezicht aan inspecteurs

Inplannen inspecteurs

Herbevestigen inspectieafspraak

Bepalen Prioritering uit te voeren inspecties

Bijhouden individuele planning inspecteurs

Vooroverleg senior inspecteurs/werkvoorbereiders

Creeeren Operationele planning

Verdelen aantallen inspecties over units

Matchen jaarplan

Bepalen benodigde capaciteit

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Maken globale planning

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Creeeren Jaarwerkplan

Kenbaar maken specifieke wensen inspecteur

Creeeren specifieke wensen

Leveren input aan beleidsdirectie

Creeeren Meerjarenplan

Ontvangen meerjarenplan

Ontvangen jaarwerkplan

Ontvangen resources

Ontvangen resource

Log. business comp

Business service

Service contract

Legend

139

Model 7 – Information object – information system service XREF The tables below describe how information objects are used by information system services. The first table shows the input information object and the second shows the information objects that are the output of an information system services.

Input Information Object Information System Service Ja

arw

erkp

lan

Mee

rjar

enpl

an

Nat

uurl

ijke

pers

oon

Obj

ect

Ope

rati

onee

l pla

n

Polit

iek/

Best

uurl

ijke

rege

ls

Proc

es

Rech

tspe

rsoo

n

Reso

urce

s

Wer

kaan

bod

Bijhouden individuele planning V Controleren beschikbaarheid personeel V V Inplannen inspecteurs V V Invoeren activiteiten V V Koppelen objecten van toezicht aan inspecteurs V V V V V Maken inspectie afspraak V V V V V V Opstellen planning V Opstellen werkverdeling V Uitlezen EU-richtlijn V Uitlezen jaarplan V Uitlezen team informatie V V Table 36: IAF model: Input information objects – information system services XREF

Output Information Object Information System Service Ja

arw

erkp

lan

Mee

rjar

enpl

an

Ope

rati

onee

l pla

n

Reso

urce

s

Bijhouden individuele planning V Inplannen inspecteurs V Invoeren activiteiten V Koppelen objecten van toezicht aan inspecteurs V Maken inspectie afspraak V Opstellen planning V Opstellen werkverdeling V Uitlezen team informatie V Vastleggen specifieke wensen V Versturen input V Table 37: IAF model: Output information objects – information system services XREF

140

Model 8 – Automated business information services This model shows which business information services are automated by information system services.

Figure 69: IAF model: Business information service - information system service XREF

Model 9 – Physical information system components This model shows how the logical information system components are grouped into physical information system components.

Figure 70: Physical information system components

Samenstellen teams

Controleren beschikbaarheid personeel

Controleren beschikbaarheid inspecteurs Bepalen Prioritering uit te voeren inspecties

Aanwijzen projectleiders voor thema acties

Vooroverleg senior inspecteurs/werkvoorbereidersVastleggen specifieke wensen

Kenbaar maken specifieke wensen inspecteur

Matchen jaarplan

Business information service

Information system service

Legend

RapportageAnalyse

SAP BW / Oracle

Planning

Planningstool

Inspectie

SAP CRM

Document management

TRIM

Verantwoorden

SAP CATS

HRMFinancieel

SAP R3

Risico analyse

TAMARA

Inspectie

Dianta

Ph. Information System Comp

Log. information system comp

Legend

141

Model 10 – Solution alternatives logical information system components This model describes three solution alternatives grouping business services into different information system components based on principles.

Figure 71: IAF model: Solution alternatives logical information system components

Verdelen aantallen inspecties over units

Samenstellen teams

Bepalen aantallen uit te voeren inspecties adhv jaarplan Maken globale planning

Herbevestigen inspectieafspraak

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Maken werkverdeling per team

Maken inspectieafspraak

Bijhouden individuele planning inspecteurs

Koppelen objecten van toezicht aan inspecteurs

Kenbaar maken specifieke wensen inspecteur

Inplannen inspecteurs

Controleren beschikbaarheid inspecteurs Gescheiden op basis van taakomschrijving (planning)

Planning

Mogelijkheid 1 - Planning

Maken werkverdeling per team

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Verdelen aantallen inspecties over units

Maken globale planning

Samenstellen teams

Opstellen Jaarwerkplan

Inplannen inspecteurs

Planning Coördinatie

Herbevestigen inspectieafspraak

Maken inspectieafspraak

Inspecties Plannen

Gescheiden op basis van uitvoerende rollen

Bijhouden individuele planning inspecteurs

Koppelen objecten van toezicht aan inspecteurs

Kenbaar maken specifieke wensen inspecteur

Controleren beschikbaarheid inspecteurs

Inspecteurs Plannen

Mogelijkheid 2 - Efficiëntie

Gescheiden op basis van informatie creatie

Maken werkverdeling per team

Herbevestigen inspectieafspraak

Samenstellen teams Maken inspectieafspraak

Bijhouden individuele planning inspecteurs

Koppelen objecten van toezicht aan inspecteurs

Inplannen inspecteurs

Controleren beschikbaarheid inspecteurs

Creeëren Operationele Planning

Verdelen aantallen inspecties over units

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Maken globale planning

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Creeëren Jaarwerkplan

Kenbaar maken specifieke wensen inspecteur

Creeëren Resources

Mogelijkheid 3 - Eenmalige registratie

Efficiëntie

Eenmalige registratie van gegevens bij de bron

Solution alternative

Business service

Log. information system comp

Legend

142

Standard ArchiMate models The pages below display models based on ArchiMate without any adjustments (standard ArchiMate).

Model 1 – Business interaction model

Figure 72: Standard ArchiMate model: Business interaction model

Model 2 – Business objects used by business services The IAF business objects could not be mapped to an ArchiMate equivalent, therefore it is not possible to transform this model into ArchiMate.

Model 3 – Logical business components

Figure 73: Standard ArchiMate model: Logical business components

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen benodigde capaciteit Verdelen aantallen inspecties over unitsMaken globale planning Matchen jaarplan

Business Service

Legend

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen benodigde capaciteit Verdelen aantallen inspecties over units

Maken globale planning

Matchen jaarplan

LBC Opstellen jaarwerkplan

Aanwijzen projectleiders voor thema acties

Samenstellen teams

Onderling verdelen werkzaamheden inspecteurs

Maken werkverdeling per team

Ondersteuning projectmatig werkenBepalen Prioritering uit te voeren inspecties

Bijhouden individuele planning inspecteurs

Controleren beschikbaarheid inspecteurs

Herbevestigen inspectieafspraak

Inplannen inspecteurs

Kenbaar maken specifieke wensen inspecteur

Koppelen objecten van toezicht aan inspecteurs

Maken inspectieafspraak

Vooroverleg senior inspecteurs/werkvoorbereiders

LBC Opstellen operationele planning

Leveren input aan beleidsdirectie

LBC Opstellen jaarplan

Business Service

Legend

143

Model 4 – Information interaction model Standard ArchiMate does not have a concept that maps to the IAF business information service concept. Therefore, the information interaction model only consists of information objects.

Figure 74: Standard ArchiMate model: Information interaction model

Jaarwerkplan

Meerjarenplan

Natuurlijke persoon

ObjectOperationeel plan

Politiek/Bestuurlijke regels

Proces

Rechtspersoon

Werkaanbod Werkwijze

Resources

Business Object

Legend

144

Model 5 – Logical information components

Figure 75: Standard ArchiMate model: Logical information components

Wetswijziging

Wetsregel

LIC Wetten/regels

Werkwijze

Resources

LIC Ondersteunendeinformatie

Natuurlijke persoon Rechtspersoon

ProcesObject

LIC Object van toezicht / subject van naleving

Jaarwerkplan

Operationeel plan

Werkaanbod

Vervolgafspraken

Meerjarenplan

LIC Geplande activiteiten

Bezwaar/beroep

Incident

Signaal vervolgonderzoek

Aanvraag

Klacht

Verloping/toelating

LIC Externe gebeurtenis/trigger

Toezichtbeleid

Politiek/Bestuurlijke regels

Prestatie-indicatoren

Toezichtarrangement

LIC Beleid- en uitvoeringsregels

Risicoprofiel

Nalevinggedrag Efficiencygraad

Middelenbeslag

Effectiviteitgraad

LIC Aggregaties

Behandelschema

LIC Aanpak

Verantwoording

Waarneming

Vergunning

Interventie

Dossier

Beleidsadvies

Besluit

Bevinding

Document

Certificaat

LIC Resultaat

Business Object

Legend

145

Model 6 – Logical Business information component interaction model As mentioned before, standard ArchiMate does not have a concept that maps to the IAF business information service concept. Therefore, the logical business information component interaction model is not transformable to ArchiMate without any adjustments.

Model 7 – Information object – information system service XREF

Figure 76: Standard ArchiMate model: Information object - information system service XREF

Model 8 – Automated business information service As mentioned before, standard ArchiMate does not have a concept that maps to the IAF business information service concept. Therefore, it is not possible to transform this model using standard ArchiMate, without any adjustments.

Model 9 – Physical information system components

Figure 77: Standard ArchiMate model: Physical information system components

Inspectie

Dianta

Planning

Planningstool

RapportageAnalyse

SAP BW / Oracle

Verantwoorden

SAP CATS

Inspectie

SAP CRM

Financieel HRM

SAP R3

Risico analyse

TAMARA

Document management

TRIM

Application Component

Artefact

Legend

146

Model 10 – Solution alternatives logical information system components

Figure 78: Standard ArchiMate model: Solution alterantives logical business components

Maken inspectieafspraak Koppelen objecten van toezicht aan inspecteurs

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Samenstellen teams

Verdelen aantallen inspecties over units Herbevestigen inspectieafspraak

Maken globale planning

Maken werkverdeling per team Kenbaar maken specifieke wensen inspecteur

Bijhouden individuele planning inspecteurs Inplannen inspecteurs

Controleren beschikbaarheid inspecteurs

LISC Planning

Gescheiden op basis van taakomschrijving (planning)

Mogelijkheid 1 - Planning

Maken globale planning

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Verdelen aantallen inspecties over units

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Maken werkverdeling per team

Samenstellen teams

Opstellen jaarwerkplan

Inplannen inspecteurs

Planning Coördinatie

Maken inspectieafspraak

Herbevestigen inspectieafspraak

Inspecties Plannen

Bijhouden individuele planning inspecteurs

Koppelen objecten van toezicht aan inspecteurs

Kenbaar maken specifieke wensen inspecteur

Controleren beschikbaarheid inspecteurs

Inspecteurs Plannen

Gescheiden op basis van uitvoerende rollen

Mogelijkheid 2 - Efficiëntie

Koppelen objecten van toezicht aan inspecteurs

Samenstellen teams Maken inspectieafspraak

Maken werkverdeling per team Inplannen inspecteurs

Bijhouden individuele planning inspecteurs

Controleren beschikbaarheid inspecteurs

Herbevestigen inspectieafspraak

Creeëren Operationele Planning

Verdelen aantallen inspecties over units Maken globale planning

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Creeëren Jaarwerkplan

Kenbaar maken specifieke wensen inspecteur

Creeëren Resources

Gescheiden op basis van informatie creatie

Mogelijkheid 3 - Eenmalige registratie

Eenmalige registratievan gegevens bij de bron

Efficiëntie

Application Component

Business Service

Principle

Legend

147

Extended ArchiMate models The following pages display models created using ArchiMate with some additions/changes. The major changes are discussed below.

Changes: • Contract into Product contract • Definition of business object

Old definition A unit of information that has relevance from a business perspective. New definition A resource that has relevance from a business perspective.

Additions: • Business service contract (based on the IAF collaboration contract definition)

A specification of the collaboration and behaviour between two services that define the behaviour, quality, security, and governance aspects of the communication between two services.

• Information service contract A specification of the collaboration and behaviour between two information services.

• Information object A unit of information that has relevance from a business perspective.

• Information service A service that describes the information need of a business service in order to realise that business service.

148

Model 1 – Business interaction model

Figure 79: Extended ArchiMate model: Business interaction model

Model 2 – Business objects used by business services

Figure 80: Extended ArchiMate model: Business objects used by business services

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen benodigde capaciteit

Matchen jaarplan

Verdelen aantallen inspecties over units

Maken globale planning

Bepaling # inspecties

Bepaling capaciteit

Bepaling # inspecties

Matching jaarplan

Verdeling inspecties

Business Service

Business Service Contract

Legend

Aanwijzen projectleiders voor thema acties

Bepalen Prioritering uit te voeren inspectiesKenbaar maken specifieke wensen inspecteur

Matchen jaarplan

Samenstellen teams

Vooroverleg senior inspecteurs/werkvoorbereiders

Controleren beschikbaarheid inspecteurs

Ondersteunende informatieGeplande activiteit

Business Service

Business Object

Legend

149

Model 3 – Logical business components

Figure 81: Extended ArchiMate model: Logical Business Components

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen benodigde capaciteit Verdelen aantallen inspecties over units

Maken globale planning

Matchen jaarplan

LBC Opstellen jaarwerkplan

Aanwijzen projectleiders voor thema acties

Samenstellen teams

Onderling verdelen werkzaamheden inspecteurs

Maken werkverdeling per team

Ondersteuning projectmatig werkenBepalen Prioritering uit te voeren inspecties

Bijhouden individuele planning inspecteurs

Controleren beschikbaarheid inspecteurs

Herbevestigen inspectieafspraak

Inplannen inspecteurs

Kenbaar maken specifieke wensen inspecteur

Koppelen objecten van toezicht aan inspecteurs

Maken inspectieafspraak

Vooroverleg senior inspecteurs/werkvoorbereiders

LBC Opstellen operationele planning

Leveren input aan beleidsdirectie

LBC Opstellen jaarplan

Business Service

Legend

150

Model 4 – Information interaction model

Figure 82: Extended ArchiMate model: Information interaction model

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Bepalen benodigde capaciteit

Bepalen Prioritering uit te voeren inspecties

Bijhouden individuele planning inspecteurs

Controleren beschikbaarheid inspecteurs

Herbevestigen inspectieafspraak

Inplannen inspecteurs

Kenbaar maken specifieke wensen inspecteur

Koppelen objecten van toezicht aan inspecteurs

Leveren input aan beleidsdirectie

Maken globale planning

Maken inspectieafspraak

Maken werkverdeling per team

Matchen jaarplan

Onderling verdelen werkzaamheden inspecteurs

Samenstellen teams

Verdelen aantallen inspecties over units

Vooroverleg senior inspecteurs/werkvoorbereiders

Jaarwerkplan

MeerjarenplanNatuurlijke persoon

Object

Operationeel plan

Politiek/Bestuurlijke regels

Proces

Rechtspersoon

Resources

Werkaanbod Werkwijze

Aanwijzen projectleiders voor thema acties

Information Service

Information Object

Legend

Legendtypeleesschrijf

151

Model 5 – Logical information components

Figure 83: Extended ArchiMate model: Logical information components

Certificaat

Besluit Document

Beleidsadvies

Dossier

Bevinding

Waarneming

Vergunning

Verantwoording Interventie

LIC Resultaat

Werkwijze

Resources

LIC Ondersteunendeinformatie

Behandelschema

LIC Aanpak

Object

Rechtspersoon Proces

Natuurlijke persoon

LIC Object van toezicht / subject van naleving

Operationeel plan

Meerjarenplan

JaarwerkplanVervolgafspraken

Werkaanbod

LIC Geplande activiteiten

Verloping/toelating

Signaal vervolgonderzoek Klacht

Incident

Bezwaar/beroepAanvraag

LIC Externe gebeurtenis/trigger

Prestatie-indicatoren Toezichtbeleid

Toezichtarrangement

Politiek/Bestuurlijke regels

LIC Beleid- en uitvoeringsregels

Effectiviteitgraad

Risicoprofiel

Nalevinggedrag

MiddelenbeslagEfficiencygraad

LIC Aggregaties

Wetswijziging

Wetsregel

LIC Wetten/regels

Information Object

Legend

152

Model 6 – Logical Business information component interaction model

Figure 84: Extended ArchiMate model: Logical business information component interaction model

Model 7 – Information object – information system service XREF

Figure 85: Extended ArchiMate model: Information System Service – Information object XREF

NB. The read (lees) relationship types represent the input objects and the write (schrijf) relationship types represent the output objects.

Aanwijzen projectleiders voor thema acties

Bepalen Prioritering uit te voeren inspecties

Bijhouden individuele planning inspecteurs

Controleren beschikbaarheid inspecteurs

Herbevestigen inspectieafspraak

Inplannen inspecteurs

Koppelen objecten van toezicht aan inspecteurs

Maken inspectieafspraak

Maken werkverdeling per team

Onderling verdelen werkzaamheden inspecteurs

Samenstellen teams

Vooroverleg senior inspecteurs/werkvoorbereiders

Creeeren Operationele planning

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen benodigde capaciteit

Maken globale planning

Matchen jaarplan

Verdelen aantallen inspecties over units

CreeerenJaarwerkplan

Leveren input aan beleidsdirectie

Creeeren Meerjarenplan

Kenbaar maken specifieke wensen inspecteur

Creeeren Specifieke wensen

Ontvangen jaarwerkplan

Ontvangen meerjarenplan Ontvangen resources

Ontvangen resource

Information Service

Information Service Contract

Legend

153

Model 8 – Automated business information services

Figure 86: Extended ArchiMate model: Business information service - information system service XREF

Model 9 – Physical information system components

Figure 87: Extended ArchiMate model: Physical information system components

Matchen jaarplan

Bepalen Prioritering uit te voeren inspecties

Controleren beschikbaarheid personeel

Controleren beschikbaarheid inspecteurs

Vastleggen specifieke wensen

Kenbaar maken specifieke wensen inspecteur

Samenstellen teams

Vooroverleg senior inspecteurs/werkvoorbereiders

Aanwijzen projectleiders voor thema acties

Information Service

Application Service

Legend

Inspectie

Dianta

Planning

Planningstool

RapportageAnalyse

SAP BW / Oracle

Verantwoorden

SAP CATS

Inspectie

SAP CRM

Financieel HRM

SAP R3

Risico analyse

TAMARA

Document management

TRIM

Application Component

Artefact

Legend

154

Model 10 – Solution alternatives logical information system components

Figure 88: Extended ArchiMate model: Solution alternatives logical business components

Maken inspectieafspraak Koppelen objecten van toezicht aan inspecteurs

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Samenstellen teams

Verdelen aantallen inspecties over units Herbevestigen inspectieafspraak

Maken globale planning

Maken werkverdeling per team Kenbaar maken specifieke wensen inspecteur

Bijhouden individuele planning inspecteurs Inplannen inspecteurs

Controleren beschikbaarheid inspecteurs

LISC Planning

Gescheiden op basis van taakomschrijving (planning)

Mogelijkheid 1 - Planning

Maken globale planning

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Verdelen aantallen inspecties over units

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Maken werkverdeling per team

Samenstellen teams

Opstellen jaarwerkplan

Inplannen inspecteurs

Planning Coördinatie

Maken inspectieafspraak

Herbevestigen inspectieafspraak

Inspecties Plannen

Bijhouden individuele planning inspecteurs

Koppelen objecten van toezicht aan inspecteurs

Kenbaar maken specifieke wensen inspecteur

Controleren beschikbaarheid inspecteurs

Inspecteurs Plannen

Gescheiden op basis van uitvoerende rollen

Mogelijkheid 2 - Efficiëntie

Koppelen objecten van toezicht aan inspecteurs

Samenstellen teams Maken inspectieafspraak

Maken werkverdeling per team Inplannen inspecteurs

Bijhouden individuele planning inspecteurs

Controleren beschikbaarheid inspecteurs

Herbevestigen inspectieafspraak

Creeëren Operationele Planning

Verdelen aantallen inspecties over units Maken globale planning

Bepalen aantallen uit te voeren inspecties adhv EU-richtlijn

Bepalen aantallen uit te voeren inspecties adhv jaarplan

Creeëren Jaarwerkplan

Kenbaar maken specifieke wensen inspecteur

Creeëren Resources

Gescheiden op basis van informatie creatie

Mogelijkheid 3 - Eenmalige registratie

Eenmalige registratievan gegevens bij de bron

Efficiëntie

Application Component

Business Service

Principle

Legend

Answers

Example The example below shows a small part of a business interaction model in IAF (Figure 89) and extended ArchiMate (Figure 90).

Figure 89: IAF model: Business interaction model

Figure 90: Extended ArchiMate model: Business interaction model

Comparison Tota

lly u

nequ

al

Une

qual

Und

ecid

ed

Equa

l

Tota

lly e

qual

Example IAF model compared to example Extended ArchiMate model X

The concepts and their meanings are the same. However, the relationships between the concepts are different. The relationships in the ArchiMate model say that a business service is assigned to a contract. However, the direction of the relationship is not specified in the ArchiMate model. Therefore, these models are marked unequal.

Outline solutionSolution outlining

Proposal creationReceive service request

External Supplier

Create proposal

External resource request reception

Business service

Service contract

Role

Legend

Receive service request

Outline solution Create proposal

External supplier

Solution outlining

Proposal creation

External resource request reception

Business Service

Business Service Contract

Business Role

Legend

156

Answer sheet Below, you can fill out to what extend you think the IAF model is equal to the corresponding standard ArchiMate or Extended ArchiMate model.

Comparison Tota

lly u

nequ

al

Une

qual

Und

ecid

ed

Equa

l

Tota

lly e

qual

IAF & Standard ArchiMate IAF model 1 compared to Standard ArchiMate model 1 IAF model 2 compared to Standard ArchiMate model 2 IAF model 3 compared to Standard ArchiMate model 3 IAF model 4 compared to Standard ArchiMate model 4 IAF model 5 compared to Standard ArchiMate model 5 IAF model 6 compared to Standard ArchiMate model 6 IAF model 7 compared to Standard ArchiMate model 7 IAF model 8 compared to Standard ArchiMate model 8 IAF model 9 compared to Standard ArchiMate model 9 IAF model 10 compared to Standard ArchiMate model 10

IAF & Extended ArchiMate IAF model 1 compared to Extended ArchiMate model 1 IAF model 2 compared to Extended ArchiMate model 2 IAF model 3 compared to Extended ArchiMate model 3 IAF model 4 compared to Extended ArchiMate model 4 IAF model 5 compared to Extended ArchiMate model 5 IAF model 6 compared to Extended ArchiMate model 6 IAF model 7 compared to Extended ArchiMate model 7 IAF model 8 compared to Extended ArchiMate model 8 IAF model 9 compared to Extended ArchiMate model 9 IAF model 10 compared to Extended ArchiMate model 10